一、规范目的
- 规范合理，可执行性。
- 一定要保证高可读性。
二、模块划分
- 同级别、同等级功能点。
- 产品线下的业务模块。
- 子功能点。
- 主干用例库中的产品、功能点已废除的需要删除。
三、颗粒度规范
-
单用例：
- 一个功能的正常流程。
- 同一功能，不同入口。
-
多用例：
- 同一功能，多个异常流程。
- 同一功能，不同数据准备。
- 同一功能：自动化用例和功能用例匹配，若自动化用例不能完全覆盖功能用例，则拆分为两个互补测试用例。
四、编写规范
- 清晰的名称、前提条件、操作步骤、期望结果的。
- 可被他人理解和执行的。
五、具体分项
5.1 用例标题
- 常用结构：“主，谓，宾”。
- 名称简洁易懂，不要包括具体操作步骤。
5.2 前置条件
- 执行步骤前所有必备条件，原则上所有用例都有前置条件。
- 不可将其他用例作为前置条件，并且需要语言描述。
- 完整清除，包括入口，账号类型、账号权限、数据准备等：
- 入口：覆盖所有功能入口，包含 URL 直接访问。
- 账号类型和权限：覆盖全部会员类型，注意业务权限控制。
- 数据准备：完整正确，覆盖线上所有情况，标识业务流程处于条件，写明数据库字段值，复杂数据准备写清楚
SQL。
5.3 操作步骤
- 描述清晰：在什么页面，点什么链接或按钮。
- 操作和结果是一一对应的，但操作中不要包含结果的检查。
- 用例描述中不允许出现连词，介词（而且，和，还）
- 注意：不允许出现假设性词、二义性语句。
5.4 预期结果
- 原则上，用例必须有预期结果，结果不能为空。
- 结果中只能包含结果，不能有步骤。
- 多个检查点时，确保检查点完整。
- 结果需要验证所有结果输出：如页面检查、存储检查、消息检查等。
- 涉及页面：需明确页面提示结果、数据变化。
- 涉及存储：需明确关键值变化、数据库具体的表和关键子字段变化。
- 涉及消息：明确关键查看内容。
- 对应不同输入数据有差别时，需分别对应描述清晰。
六、用例维护
- 新项目需求变更，应及时对测试用例进行修改。
- 维护期项目，可根据项目组情况周期对用例进行维护。
- 所有发现的 bug 和故障，基于测试用例无法发现，需转化为测试用例。
- 项目发布后的三个工作日内，需将项目用例根据具体情况归入产品用例库下。
七、结束语
“-------怕什么真理无穷，进一寸有一寸的欢喜。”文章来源：https://www.toymoban.com/news/detail-689217.html
微信公众号搜索：饺子泡牛奶。文章来源地址https://www.toymoban.com/news/detail-689217.html
到了这里，关于测试用例编写规范参考的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
