测试用例状态转换分析
图 -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 等。然而，如果显示十几个状态，则测试结果可能更难以解释。如何使结果明了又能精确反映实际结果，需要精明选择包括哪些状态。
使用该模板优点：使用维护简便，方便测试任务分配，易于与项目组其他角色交流，结果报告自动生成。
不足之处：测试变更跟踪不方便，每个测试用例的规模不等，所以测试覆盖率结果只是作为参考，结果百分比不能精确反映工作量，需要具体分析项目情况。这个模版没有跟踪统计缺陷，同时考虑是否使用加权评估缺陷严重性，一个测试用例往往对应几个缺陷的统计分析。
结论：在实际项目中，应该根据项目特点和开发流程定义测试用例各项。在精确和简单两个特性相对立时，需要好好权衡。如果您有好的解决方案，我将很乐意知道。
文章来源于领测软件测试网 https://www.ltesting.net/
