测试用例是测试过程中不可或缺的部分，如何形成一种合理的
工作流程，设计出高效的测试用例，用例应该遵循什么样的书写规范，这是对整个项目质量提高的一种保证，也是对我们测试人员自身
用例设计能力的一种提高。本文初步整理了一些测试用例的设计规范，希望能够抛砖引玉，多多收获大家的意见或建议。
测试用例的六大特性
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和测试用例连接起来，二来便于对用例的有效性作统计。
