测试用例编写规范参考

一、规范目的

• 规范合理，可执行性。
• 一定要保证高可读性。

二、模块划分

• 同级别、同等级功能点。
• 产品线下的业务模块。
• 子功能点。
• 主干用例库中的产品、功能点已废除的需要删除。

三、颗粒度规范

• 单用例：
  • 一个功能的正常流程。
  • 同一功能，不同入口。
• 多用例：
  • 同一功能，多个异常流程。
  • 同一功能，不同数据准备。
• 同一功能：自动化用例和功能用例匹配，若自动化用例不能完全覆盖功能用例，则拆分为两个互补测试用例。

四、编写规范

• 清晰的名称、前提条件、操作步骤、期望结果的。
• 可被他人理解和执行的。

五、具体分项

5.1 用例标题

• 常用结构：“主，谓，宾”。
• 名称简洁易懂，不要包括具体操作步骤。

5.2 前置条件

• 执行步骤前所有必备条件，原则上所有用例都有前置条件。
• 不可将其他用例作为前置条件，并且需要语言描述。
• 完整清除，包括入口，账号类型、账号权限、数据准备等：
  • 入口：覆盖所有功能入口，包含 URL 直接访问。
  • 账号类型和权限：覆盖全部会员类型，注意业务权限控制。
  • 数据准备：完整正确，覆盖线上所有情况，标识业务流程处于条件，写明数据库字段值，复杂数据准备写清楚 SQL 。

5.3 操作步骤

• 描述清晰：在什么页面，点什么链接或按钮。
• 操作和结果是一一对应的，但操作中不要包含结果的检查。
• 用例描述中不允许出现连词，介词（而且，和，还）
• 注意：不允许出现假设性词、二义性语句。

5.4 预期结果

• 原则上，用例必须有预期结果，结果不能为空。
• 结果中只能包含结果，不能有步骤。
• 多个检查点时，确保检查点完整。
  • 结果需要验证所有结果输出：如页面检查、存储检查、消息检查等。
  • 涉及页面：需明确页面提示结果、数据变化。
  • 涉及存储：需明确关键值变化、数据库具体的表和关键子字段变化。
  • 涉及消息：明确关键查看内容。
  • 对应不同输入数据有差别时，需分别对应描述清晰。

六、用例维护

• 新项目需求变更，应及时对测试用例进行修改。
• 维护期项目，可根据项目组情况周期对用例进行维护。
• 所有发现的 bug 和故障，基于测试用例无法发现，需转化为测试用例。
• 项目发布后的三个工作日内，需将项目用例根据具体情况归入产品用例库下。

七、结束语

---

“-------怕什么真理无穷，进一寸有一寸的欢喜。”

微信公众号搜索：饺子泡牛奶。