测试用例要点

测试用例设计要点
测试用例：
是为特定的目的而设计的一组测试输入，执行条件和预期结果。

测试用例是最小的执行实体，体现测试方案、方法、技术和测策，内容包括测试环境、输入数据、测试步骤、预期结果、测试脚本等形成文档，目的是测试某个程序路径或核实是否满足某个特定需求。

测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一，设计良好的测试用例模板能提高测试用例的设计质量，便于跟踪测试用例的执行结果，自动生成测试用例覆盖率报告。

这几年测试技术和理论有了长足的发展，就功能测试用例设计要素而言，样式上均大同小异，一般都包含主题、前置条件、执行步骤、期望结果等。

测试用例可以用数据库、Word 、Excel 、xml 等格式进行管理，对于一般中小软件企业，使用文档来管理测试用例是较为方便、经济的途径。

Word 格式的文档可以满足设计需要，但不利于跟踪和自动统计执行结果报告。

测试用例中经常用到的术语：
测试用例 ID ——用于唯一标识测试用例号，可根据自身需要定义规则，最好易于跟踪和维护；
测试前置条件——如果有则描述之；
测试用例执行步骤、期望结果；
测试用例执行结果——执行时填写，分为通过、失败、警告、阻塞、忽略。

队列中（ In Queue ） -- 测试用例在排队等待中；
进程中（ In Progress ） -- 表示测试正在进行，并且可能会持续一段时间，如果一个测试花费的时间少于一天或两天，只需将它显示在处于排队状态；
阻塞（ Block ） -- 一些外部条件—如缺少部分功能—将无法执行测试；
忽略（ Skip ） -- 已经决定（或被告知）跳过这个测试用例；
通过（ Pass ） -- 终点状态，没问题；
失败（ Fail ） -- 测试用例执行出错；
警告（ Warn ） -- 结果处于 Pass 和 Fail 之间，错误严重性等级较轻，不影响功能和性能；
关闭（ Closed ） -- 以前识别出的错误都已经被修正。

实际项目中，一个测试用例有多个执行步骤，每个步骤可能有不同结果，如步骤 1 通过，步骤 2 失败，步骤 3 被步骤 2 中的失败所阻塞，那么该测试状态如何？单纯指出这个测试用例阻塞或失败都将遗漏重要的信息。

因此必须指定双重状态，如 Block/Fail ， Block/Warn ， Skip/Pass ， Skip/Closed 等。

然而，如果显示十几个状态，则测试结果可能更难以解释。

如何使结果明了又能精确反映实际结果，需要精明选择包括哪些状态。

使用模板优点：使用维护简便，方便测试任务分配，易于与项目组其他角色交流，结果报告自动生成。

不足之处：测试变更跟踪不方便，每个测试用例的规模不等，所以测试覆盖率结果只是作为参考，结果百分比不能精确反映工作量，需要具体分析项目情况。

结论：在实际项目中，应该根据项目特点和开发流程定义测试用例各项。

一个优秀的测试用例，应该包含以下信息：
1）软件或项目的名称
2）软件或项目的版本（内部版本号）
3）功能模块名
4）测试用例的简单描述，即该用例执行的目的或方法
5）测试用例的参考信息（便于跟踪和参考）
6）本测试用例与其他测试用例间的依赖关系
7）本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限
8）用例的编号（ID），如可以是软件名称简写-功能块简写-NO.。

9）步骤号、操作步骤描述、测试数据描述
10）预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略）
11）开发人员（必须有）和测试人员（可有可无）
12）测试执行日期
等价类划分分析
等价类划分测试用例
用来场景分析
测试用例表
测试用例表。