软件测试中浅谈功能测试用例模板设计

软件测试中浅谈功能测试用例模板设计

测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一，设计良好的测试用例模板能提高测试用例的设计质量，便于跟踪测试用例的执行结果，自动生成测试用例覆盖率报告。这几年测试技术和理论有了长足的发展，就功能测试用例设计要素而言，样式上均大同小异，一般都包含主题、前置条件、执行步骤、期望结果等。

测试用例可以用数据库、Word 、Excel 、xml 等格式进行管理，市面亦有成熟的商业软件工具和开源工具等，对于一般中小软件企业，使用文档来管理测试用例是较为方便、经济的途径。 Word 格式的文档可以满足设计需要，但不利于跟踪和自动统计执行结果报告。下面我将介绍自己在多个项目中设计和改进的 Excel 模版，它可以方便地设计测试用例，记录执行结果并自动统计测试用例覆盖率。图-1 为 Excel 模板。具体细目说明如下：


图-1 Excel 模板

测试用例 ID —— 用于唯一标识测试用例号，可根据自身需要定义规则，最好易于跟踪和维护；

测试前置条件 —— 如果有则描述之；

测试用例等级 —— 根据需求重要性区分测试用例等级，测试执行阶段可以根据测试用例等级安排测试任务，分为四级：

• 冒烟测试，即版本确认测试，每个测试版本需通过所有该级测试用例，否则拒绝继续测试；

• 关键路径测试，每个测试版本需执行该级测试用例，若该级测试用例均通过，意味着软件功能趋于稳定；

• 可接受级测试，该级测试用例只要执行一次通过即可，该级测试用例通过意味着可以准备发布了；

• 建议执行的用例，如果有时间，最好执行该级测试用例，但不作为发布的必要条件。

测试用例执行步骤、期望结果；

测试用例执行结果 —— 执行时填写，分为通过、失败、警告、阻塞、忽略。

通过开发 VBA 脚本，可以自动统计每轮测试用例执行结果，如图-2 所示，得到测试用例覆盖率结果报告，用于分析测试结果。


图-2 测试用例覆盖率分析报告

测试用例状态转换分析

图 -3 显示了一个典型测试用例的生命周期，依据不同类型和规模的项目可以自行定制。



图-3 测试用例生命周期

队列中（ In Queue ） -- 测试用例在排队等待中；

进程中（ In Progress ） -- 表示测试正在进行，并且可能会持续一段时间，如果一个测试花费的时间少于一天或两天，只需将它显示在处于排队状态；

阻塞（ Block ） -- 一些外部条件 — 如缺少部分功能 — 将无法执行测试；

忽略（ Skip ） -- 已经决定（或被告知）跳过这个测试用例；

通过（ Pass ） -- 终点状态，没问题；

失败（ Fail ） -- 测试用例执行出错；

警告（ Warn ） -- 结果处于 Pass 和 Fail 之间，错误严重性等级较轻，不影响功能和性能；

关闭（ Closed ） -- 以前识别出的错误都已经被修正。

实际项目中，一个测试用例有多个执行步骤，每个步骤可能有不同结果，如步骤 1 通过，步骤 2 失败，步骤 3 被步骤 2 中的失败所阻塞，那么该测试状态如何？单纯指出这个测试用例阻塞或失败都将遗漏重要的信息。因此必须指定双重状态，如 Block/Fail ， Block/Warn ， Skip/Pass ， Skip/Closed 等。然而，如果显示十几个状态，则测试结果可能更难以解释。如何使结果明了又能精确反映实际结果，需要精明选择包括哪些状态。

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

不足之处：测试变更跟踪不方便，每个测试用例的规模不等，所以测试覆盖率结果只是作为参考，结果百分比不能精确反映工作量，需要具体分析项目情况。这个模版没有跟踪统计缺陷，同时考虑是否使用加权评估缺陷严重性，一个测试用例往往对应几个缺陷的统计分析。
结论：在实际项目中，应该根据项目特点和开发流程定义测试用例各项。在精确和简单两个特性相对立时，需要好好权衡。如果您有好的解决方案，我将很乐意知道。

原文转自：http://www.ltesting.net