测试用例是测试过程中不可或缺的部分，如何形成一种合理的工作流程，设计出高效的测试用例，用例应该遵循什么样的书写规范，这是对整个项目质量提高的一种保证，也是对我们测试人员自身用例设计能力的一种提高。本文初步整理了一些测试用例的设计规范，希望能够抛砖引玉，多多收获大家的意见或建议。
测试用例的六大特性
1.测试用例对需求覆盖的完整性
测试是基于需求的，所以说测试用例应该尽可能100%的覆盖需求。100%的覆盖跟0缺陷的要求有些类似了，实现起来是非常非常困难的，但是我们应该做到尽可能的去覆盖，至少显性的需求必须保证有用例覆盖，隐性的需求可允许有一定遗漏，一旦发现遗漏后需要及时的对测试用例进行补充。
2.测试用例的有效性
如何定义用例的有效性，什么是有效的用例，个人认为可归结为两类，一类是能发现问题，特别是严重问题，甚至是致命问题的用例，这类用例可以称之为高效用例，另一类是覆盖了需求所要求功能的用例，这类用例不一定能发现问题，但是必不可少的。
3.测试用例的易理解性
测试用例应该是易于理解的，主要表现在语言组织方面，不使用生涩词汇，不让人产生歧义。目前我们期望的最理想的状态就是，任何一个用户，在不熟悉系统，不了解需求的情况下，拿到这个用例就可以根据步骤一步一步执行。
4.测试用例的清晰性
测试用例的清晰性包括测试用例分类明确、设计思路清晰、操作步骤简洁明了等等。
5.测试用例的可复用性和可维护性
之所以花很大的代价去设计测试用例就是为了能够重复使用，但是用例又不可能是一成不变的，随着产品的升级或需求的变化，用例也需要做相应的维护，如果用例设计的比较混乱，维护成本就会非常高。如何降低维护成本，提高用例的可维护性，最重要的就是需要我们设计用例时能遵循统一的规范，这样不论将来谁来维护，都可以比较容易的去进行。这一点也避免了人员流动后造成用例无法重用的尴尬局面。
测试用例的生命周期
测试用例从开始规划到设计完成直至被执行是需要一个过程的，在这里我称之为测试用例的生命周期，其实最主要的还是一个流程问题。
1.版本确定下来，需求完成并收到评审邮件时，就分配专门的测试人员熟悉需求并为用例设计做准备
2.根据产品需求或开发需求提取测试需求点，保证测试用例对需求的覆盖
在我们开始接触需求并了解需求的时候，就可以适当的提取出测试需求点，这个需求点可以是非常详细的，也可以是比较粗略的，可以是一个测试需求对应一个测试用例，也可以是一个需求对应多个测试用例，用例设计的时候再对测试需求进行分解。
提取测试需求的目的有二，一是帮助测试人员更快更好的理解需求，把问题发现在需求阶段，降低整个项目成本。二是对用例设计起到一定的指导作用。
测试需求提取后记录到QC的｛需求｝模块中，还是记录到Excel中，这个大家可以讨论。
3.需求评审后及时对测试需求进行调整
需求评审后，肯定会或多或少的有些变动，这个时候需要对变更后的测试需求及时做调整。此类情况是针对产品需求进行的测试需求提取，如果针对开发需求，变化的可能性会小一些。
4.根据测试需求设计测试用例，并且测试用例要覆盖到每个测试需求
可直接在QC中覆盖
5.用例完成后提前1-2天发给相关人员阅读并发评审通知
6.用例评审结束后，需要对有问题的用例及时调整，调整后的用例可单独导出来，邮件给所有相关评审人员再次确认
7.将用例拖入执行计划，准备用例执行，执行可分两种情况，自己设计自己执行，或者交换执行，对于有条件的项目最好是交换执行。
可直接在QC中进行
用例执行过程中，如发现BUG，请及时将BUG ID更新到相应的用例中
8.执行过程中发现用例遗漏，需及时补充，如无遗漏，用例执行通过，整个生命周期结束。
测试用例设计规范
测试用例的组织结构
测试用例首先需要清晰的表达出我们的测试思路，拿到一个需求后，应该先测什么，再测试什么，最后测试什么。
如何保证测试用例的清晰性，可以先从测试用例的组织结构入手，结合之前用例设计思路，加上在网上参考的一些资料，目前测试用例可分以下几类进行设计，这几个分类在QC中表现形式为5个文件夹。
功能
该文件夹中主要包含一些的功能性的用例，可以包含正常流或异常流，以登录为列：
正常流：用户名和密码正确，登录成功
异常流：用户名和密码均为空，登录失败
用户名或密码有一个为空，登录失败
……
业务逻辑与规则
该文件夹主要包含一些业务逻辑和规则，跟具体的业务相关的用例，比如说系统允许用户名50个字符以内，采用及时校验机制。用例设计为：
用户名正好为50个字符，离开焦点，验证通过
用户名为中文，离开焦点，验证失败
……
接口
该文件夹主要包含一些接口相关的用例，特别是遇到系统间相互调用、模块间相互调用，与数据库的接口。比如说领动与OSS订单的接口，爱聘才与OSS编辑系统的接口，TM与MIC VO的接口等等。
以近期TM项目与MIC VO的一个举例，MIC VO中修改了用户基本信息，在TM的个人设置页面显示。
设计该类用例时，需要有清晰的操作步骤，如果用户对系统不舒适，需要在明确说明
操作步骤：
（1） 用TM账号登录MIC VO
（2） 修改个人信息
（3） 用该账号重新登录TM客户端
（4） 点击TM头像旁边的个人设置，检查信息是否变化
期望结果：
TM个人设置中的信息与用户在VO中修改的个人信息一致
接口用例中请注意对数据库表的检查
页面
该文件夹主要包含一些与页面相关的用例，如果页面元素检查、有特殊要求的页面检查
权限
该文件夹主要包含一些与权限有关的用例，比如说XXX网站只允许高级会员使用统计功能，用例设计为：
用高级会员登录，有【统计】功能
用非高级会员登录，没有【统计】功能
控件
该文件夹主要包含一些特殊控件的用例，比如说日历控件、分页按钮等等，因为这些控件基本上都统一调用的，我们可以作为公共用例来设计
测试用例的设计要素
目前测试用例的设计主要是在QC中进行，用例的要素包括：用例概述、用例优先级、前置条件、操作步骤、测试数据、预期结果、备注、对应JIRA_BUG_ID。
测试用例的书写规范
测试用例最好能够做到尽量详细，我们的要求是尽量保证一个用例只有一个主要结果，可以包含其他辅助结果，也就是主结果完成后出现的其他现象，没有必要另建一个测试用例的，比如说xxx模块添加用户成功（主结果），系统自动跳转到用户列表页面（辅助结果）。
关于用例设计要素的书写规范，我做了如下描述：
用例概述（必需项）：在QC中表现为一个Test Case的名称，要简明扼要对该用例设计的目的进行描述。
用例优先级（必需项）：一些功能性的、流程性、业务规则的、接口的用例优先级最高，必须执行，一些页面的用例优先级会相对较低，可选择执行，优先级别需要视需求而定。优先级必须定义，这对建立测试执行计划有很大的帮助
前置条件（可选项）：对于当前的用例，必须要满足一个前提条件才能完成，这些条件如果写在操作步骤中就会很繁琐，就可以单独放置在前置条件中。前置条件可以是一个说明，一个注意事项，也可以是一个前面的case，具体视情况而定。
操作步骤（必需项）：尽量详细，步骤鲜明，语言简洁，为清晰的描述最终结果，操作步骤中可适当包含一些中间结果。
测试数据（必需项）：基本上每个测试用例都是需要有测试数据支持的，该项必不可少，有的时候可能是多种情况的测试数据对应同一个结果，这就需要每种情况准备一组数据。比如说，用户年龄范围必需为【18-25】岁之间，才可以注册XXX游戏，若满足【18-25】这个区间范围，我们可以用三个数据，18岁、20岁、25岁，这三个数据时都必须要验证的。
如果不能给出明确的测试数据，可以提供测试数据准备条件，准备了几组数据，就相当于要执行这个Test case几次。
预期结果（必需项）：准确描述出用例的结果，结果具有唯一性。
备注（可选项）：一些特殊的说明地方
BUG_ID（如果该用例有对应的BUG，此项必填）：这个主要用于测试用例执行过程中，尽量不要怕麻烦，每发现一个BUG就要把BUG_ID记录到这个用例中，一来可以我们的BUG_ID和测试用例连接起来，二来便于对用例的有效性作统计。
