测试用例编写规范

目录：

一.测试用例包含的元素

二.测试用例编写原则及规范

1. 用例模块划分规范
2. 用例颗粒度划分规范
3. 用例编写要求规范
4. 用例维护规范

三.测试用例编号规则

 

---

 

一.测试用例包含的元素

1. 序号：就是按顺序下去的。
2. 模块：该功能点具体属于哪个模块的，如：注册/登录模块
3. 编号：对每个用例进行编号，方便后期跟进。建议编号设计的有点规则，方便快速定位查找。如：A0001。其中A表示注册/登录模块。00表示账号登录，01 表示账号密码登录下的第一个测试用例。
4. 功能点：具体指某个功能，如：账号登录、首页、发布等。
5. 子功能点：具体指功能点，如：账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。
6. 用例名称：具体测试用例的名称。如：输入账号、输入密码、密码不合规等等。
7. 前置条件：指要达到预期测试结果，需要满足哪些条件才能达到。
8. 操作步骤：指要达到预期测试结果，需要按这些步骤来。最好说明在什么页面，点击或操作什么内容，输入什么内容。
9. 预期结果：说明按照前面写的应该呈现出怎样的结果。
10. 测试结果：如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO，
11. 结果描述：如果正常，可以不用填写，如果不符合预期结果，则说明哪里不符合。
12. 测试人员：填写测试人的名字，方便后期跟踪BUG。
13. 测试日期：填写测试的时间，方便后期查询。
14. BUGID：跟测试编号一样，自己设定ID规则，方便快速查询。
15. BUG负责人：此处应该由技术那边填写，具体落实到某个人身上，才能更好的解决到问题。

 

二.测试用例编写原则及规范

• 统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。
• 测试用例，不仅仅用于QA阅读和执行。它们也可能会被开发、PD、PM等阅读审查或执行；也更可能被其他测试人员或者新员工作为业务学习、测试执行的参照。
• 编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例并执行用例。

 

　　1.用例模块划分规范

• 产品、功能点同一层级的结构按同一个纬度来划分。如应用、同等级产品、同等级功能点等；
• 产品是指产品线下大的业务模块。如交易购物车、交易下单；
• 功能点指业务模块下的子功能点，是最小功能点叶子节点。如01 功能_02 购物车展示_01 顶部及导航；
• 功能点目前无法再细分层级，后续会扩展功能点层次，在此之前，允许使用功能点名进行分层用例划分。
• 产品、功能点划分不允许包含冒烟、回归、自动化这类以测试阶段或测试方法的命名的名称；

 

　　2.用例颗粒度划分规范

　　用例颗粒度原则：测试用例是执行的最小实体。用例划分基本原则是以最小功能模块来划分，为保障用例的可执行性、覆盖度，规范编写用例的粒度要求如下：

• 一个功能正常流程，编写一个测试用例；
• 一个功能中多个异常流程，应分开编写多个测试用例；
• 同一功能不同入口，可合并编写一个测试用例；
• 同一功能不同数据准备，应分开编写多个测试用例；
• 同一个功能用例的自动化用例和功能用例要匹配，若自动化用例不能完全覆盖功能用例，自动化用例和功能用例拆分两个互补测试用例；

 

　　3.用例编写要求规范

• 具有清晰名称、前置条件、操作步骤、期望结果；
• 可被他人理解的；
• 可被他人执行的；

　　具体分项要求如下：

 

　　用例名称

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

　　

　　前置条件

• 执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；
• 不可将其他用例作为前置条件，前置条件需要语言描述；
• 完整清楚，包括入口、帐号类型、账号权限、数据准备等，具体要求如下：

1. 入口：覆盖所有功能入口，包含URL直接访问；
2. 账号类型和权限：覆盖全部账号类型，注意业务权限控制，比如子账号权限
3. 数据准备：数据准备完整正确，覆盖到线上环境的所有情况；标识出业务流程处于的条件，写明数据库表字段值；对于复杂的数据准备，写清具体SQL

　　

　　操作步骤

• 操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
• 操作和结果是一一对应的，但操作中不要包含结果的检查；
• 用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）；
• 用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
• 用例描述中不允许出现二义性语句；

　　预期结果

• 原则上每个用例必需要有预期结果，结果不能为空；
• 　结果中只能包含结果，不能有步骤；
• 一个结果有多个检查点时，确保检查点完整；

1. 结果包含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
2. 结果涉及页面，需明确页面提示结果、数据变化；
3. 结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
4. 结果涉及消息：需明确关键查看内容；
5. 结果对应不同输入数据有差别时需分别对应描述清晰；

　　

　　4.用例维护规范

• 新项目需求变更，应及时对测试用例进行修改；
• 维护期项目，可根据项目组情况周期对用例进行维护；
• 所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例。

 

 

三.测试用例编号规则

1. 目的：好的测试用例编号，可以更好的去了解此项用例所针对的模块，也有助于记忆和新用例的增加。
2. 规则：测试用例编号采用“版本+细类+编号”的形式。
3. 备注：其中“版本”为设计此测试用例的软件版本。
4. “细类”为小模块中的汉字头一个字母，以最多5个字母为标准。
5. “编号”为BUG用例的编号，以4位为标准，依次递增。
6. 例如：引导系统V2.01版本中，候车点设置，用例编号可以书写为：2.01_HCDSZ_0001