大家好，欢迎来到IT知识分享网。

#头条文章养成计划#

在前面的文章中，我们介绍了测试计划和测试方案的编写规范和要点。本篇则来谈谈测试设计中的用例编写规范。测试用例是测试设计的直接输出，很大程度上决定了后续测试执行能否成功。

在项目测试中，测试用例的设计一般会根据需要结集归纳。结集的原则可以根据功能大类或执行范围来确定。比如：

• 版本新增功能用例集
• 冒烟测试用例集
• 安装包测试用例集
• 等等….

测试用例的作用

测试用例是测试设计的结果。所以测试用例的作用其实就是在设计阶段为后续的测试执行所预先进行梳理和思考。它的主要作用体现在：

1. 确保被测系统的需求被覆盖完全
2. 可以在设计阶段提前考虑软件风险，并通过同步给开发人员尽可能提前规避
3. 测试用例可以固化测试设计的结果，便于后续测试执行的准确和复用
4. 测试用例是从另一个角度对需求实现的深度挖掘，能帮助团队更深入地理解需求，也是团队在设计阶段沟通的重要材料

测试用例内容

• 唯一标识

用例的唯一ID，用于后续归档追溯的唯一标识

• 测试名称

用于表达测试目的的简短的、描述性的陈述

• 执行优先级

当前用例在后续执行时的优先级，一般根据需求优先级和测试计划的安排综合评定

• 需求追踪

追溯用例所对应的需求或设计来源

• 预置条件/测试环境

说明当前用例执行的预置条件限制。包括测试需要使用的测试环境、关联模块限制等。

• 测试步骤

包括用例执行时的关键步骤以

• 测试数据

测试时使用的测试数据或规则说明

• 预期结果

说明用例执行后，预期的期望结果

• 实际结果

用于记录测试执行后的实际结果

• 测试结论

用例执行的结果，通过或不通过等

• 备注信息

其他补充信息

示例

下面是一个简单的测试用例模板示例：

说明

虽然测试用例是一个重要的设计输出，但是实际工作中，往往占用了较大量的时间在文档的生成上。所以我们还是要回归测试设计的主要目的，不要拘泥于文档的形式。很多敏捷项目中对测试用例的输出形式进行了较大的裁剪，通过思维导图等方式仅保留测试人员在设计时的测试要点，往往也能起到很好的效果。

所以采用什么样的方式不是关键，还是要根据项目实际情况，是要求更加严谨、更加规范还是重在项目运作中快速地进入测试得到反馈来确定测试设计的输出形式。