ChinaITLab 收集整理 
2004-12-21 
|
测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一，设计良好的测试用例模板能提高测试用例的设计质量，便于跟踪测试用例的执行结果，自动生成测试用例覆盖率报告。这几年测试技术和理论有了长足的发展，就功能测试用例设计要素而言，样式上均大同小异，一般都包含主题、前置条件、执行步骤、期望结果等。 测试用例可以用数据库、Word 、Excel 、xml 等格式进行管理，市面亦有成熟的商业软件工具和开源工具等，对于一般中小软件企业，使用文档来管理测试用例是较为方便、经济的途径。 Word 格式的文档可以满足设计需要，但不利于跟踪和自动统计执行结果报告。下面我将介绍自己在多个项目中设计和改进的 Excel 模版，它可以方便地设计测试用例，记录执行结果并自动统计测试用例覆盖率。图-1 为 Excel 模板。具体细目说明如下：  测试用例 ID —— 用于唯一标识测试用例号，可根据自身需要定义规则，最好易于跟踪和维护； 测试前置条件 —— 如果有则描述之； 测试用例等级 —— 根据需求重要性区分测试用例等级，测试执行阶段可以根据测试用例等级安排测试任务，分为四级： 冒烟测试，即版本确认测试，每个测试版本需通过所有该级测试用例，否则拒绝继续测试； 关键路径测试，每个测试版本需执行该级测试用例，若该级测试用例均通过，意味着软件功能趋于稳定； 可接受级测试，该级测试用例只要执行一次通过即可，该级测试用例通过意味着可以准备发布了； 建议执行的用例，如果有时间，最好执行该级测试用例，但不作为发布的必要条件。 测试用例执行步骤、期望结果； 测试用例执行结果 —— 执行时填写，分为通过、失败、警告、阻塞、忽略。 通过开发 VBA 脚本，可以自动统计每轮测试用例执行结果，如图-2 所示，得到测试用例覆盖率结果报告，用于分析测试结果。  测试用例状态转换分析 图 -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 等。然而，如果显示十几个状态，则测试结果可能更难以解释。如何使结果明了又能精确反映实际结果，需要精明选择包括哪些状态。 使用该模板优点：使用维护简便，方便测试任务分配，易于与项目组其他角色交流，结果报告自动生成。 不足之处：测试变更跟踪不方便，每个测试用例的规模不等，所以测试覆盖率结果只是作为参考，结果百分比不能精确反映工作量，需要具体分析项目情况。这个模版没有跟踪统计缺陷，同时考虑是否使用加权评估缺陷严重性，一个测试用例往往对应几个缺陷的统计分析。 结论：在实际项目中，应该根据项目特点和开发流程定义测试用例各项。在精确和简单两个特性相对立时，需要好好权衡。如果您有好的解决方案，我将很乐意知道。 | |
 相关文章 |
热门文章 |
|
| 初学者入门：软件测试从零开始 深入浅出基于Java的代理设计模式 Java理论与实践:一个有缺陷的微基准剖析 杂谈小议：如何制定软件项目测试计划 IT 架构和应用程序的端到端测试 跳出程序员的视界 感悟软件测试 如何制定软件项目测试计划 测试：确保软件质量的最重要一环 软件质量：如何提高软件的可测试性 使用RUP统一过程构建Web解决方案 |
| 文章评论 | |||