一、测试用例：
1、定义：
为特定的目的而设计的一组测试输入、执行条件和预期的结果，它是执行的最小实体。
简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果，一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试。
2、作用：
（1）、指导测试的实施
（2）、提高测试效率
（3）、规划测试数据的准备
（4）、评估测试结果的度量基准
（5）、分析缺陷的标准
3、特性：
（1）、需求覆盖的完整性
（2）、有效性
（3）、易理解性
（4）、清晰性
（5）、可复用性
（6）、可维护性
4、设计要素：
（1）、用例ID （必需项）
（2）、用例概述（必需项）
（3）、用例优先级（必需项）
（4）、前置条件（可选项）
（5）、操作步骤（必需项）
（6）、测试数据（必需项）
（7）、预期结果（必需项）
（8）、备注（可选项）
（9）、对应BUG_ID（可选项）
5、书写规范：
（1）、用例概述：简明扼要对该用例设计的目的进行描述。
（2）、用例优先级：功能性的、流程性、业务规则的、接口的用例优先级最高，必须执行。一些页面的用例优先级会相对较低，可选择执行，优先级别需要视需求而定。
优先级必须定义，这对建立测试执行计划有很大的帮助。
（3）、前置条件：对于当前的用例，必须要满足一个前提条件才能完成，这些条件如果写在操作步骤中就会很繁琐，就可以单独放置在前置条件中。
前置条件可以是一个说明，一个注意事项，也可以是一个前面的case，具体视情况而定。
（4）、操作步骤：尽量详细，步骤鲜明，语言简洁，为清晰的描述最终结果。
（5）、测试数据：基本上每个测试用例都是需要有数据支持的，该项必不可少，有的时候可能是多种情况的测试数据对应同一个结果，这就需要每种情况准备一组数据。
（6）、预期结果：准确描述出用例的结果，结果具有唯一性。
（7）、备注：一些特殊的说明地方。
（8）、BUG_ID：这个主要用于测试用例执行过程中，尽量不要怕麻烦，每发现一个BUG就要把BUG_ID记录到这个用例中。
一来可以我们的BUG_ID和测试用例连接起来，二来便于对用例的有效性作统计。
二、测试用例评审：
1、为什么要进行评审？
（1）、确保用例更全面的覆盖需求；
（2）、使用例的结构更清晰；
（3）、规范对需求的了解，提高用例质量。
2、什么时间进行评审？
（1）、在用例的初步设计完成之后进行评审；
（2）、在整个详细用例全部完成之后进行二次评审。
3、评审内容：
（1）、用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖；
（2）、优先极安排是否合理；
（3）、是否覆盖测试需求上的所有功能点；
（4）、用例是否具有很好可执行性；
（5）、 是否已经删除了冗余的用例；
（6）、是否包含充分的负面测试用例；
（7）、是否从用户层面来设计用户使用场景和使用流程的测试用例；
（8）、是否简洁，复用性强。
4、评审方式：
评审之前1-2天把用例设计的相关文档发送给评审对象进行前期的学习和了解，以节省沟通成本。
（1）、召开评审会议，与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录；
（2）、通过邮件与相关人员沟通；
（3）、通过即时工具直接与相关人员交流。
5、参与评审人员：
（1）、部门评审：测试部门全体成员参与的评审；
（2）、公司评审：项目经理、需求分析人员、架构设计人员、开发人员和测试人员、QA；
（3）、客户评审：客户方的开发人员和测试人员。
6、评审退出准则：
在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。