软件测试：测试用例

一、测试用例：

　　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、评审退出准则：

　　在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。

__EOF__

本文作者：我命倾尘
本文链接：https://www.cnblogs.com/guobin-/p/10860919.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！