浅谈功能测试用例模板设计[3]

　　浅谈功能测试用例模板设计[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