测试用例编写规范

Ryan Wu -

1. 编写测试用例的目的

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

2. 模块划分规范

要求：

  1. 产品、功能点同一层级的结构按同一个纬度来划分。如应用、同等级产品、同等级功能点等；
    产品是指大的业务模块。如门店管理、交易下单；
  2. 功能点指业务模块下的子功能点，是最小功能点叶子节点。如: 订单-订单详情-分页;
  3. 产品、功能点划分不允许包含冒烟、回归、自动化这类以测试阶段或测试方法的命名的名称；
  4. 用例库中产品、功能点已废弃的需要及时删除；
  5. 用例库命名格式需要统一标准格式；

3. 用例颗粒度划分规范

  1. 用例颗粒度原则：测试用例是执行的最小实体

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

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

4. 用例编写要求规范

用例编写最基本的要求：

  1. 具有清晰名称、前提条件、操作步骤、期望结果的；
  2. 可被他人理解的；
  3. 可被他人执行的；
  4. 具体分项要求如下：
    用例名称:
    1.1. 常用的结构“主、谓、宾”；
    1.2. 名称简洁易懂，不要包括具体操作步骤；
    前置条件:
    2.1. 执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；
    2.2. 不可将其他用例作为前置条件，前置条件需要语言描述；
    2.3. 完整清楚，包括入口、帐号类型、账号权限、数据准备等，具体要求如下:
    2.3.1. 入口：覆盖所有功能入口，包含URL直接访问； 　　
    2.3.2. 账号类型和权限：覆盖全部会员类型，注意业务权限控制，比如密码重置权限,车型库管理权限; 　　
    2.3.3. 数据准备：数据准备完整正确，覆盖到线上环境的所有情况；标识出业务流程处于的条件，写明数据库表字段值，如OFFER.status=TBD；对于复杂的数据准备，写清具体SQL
    操作步骤:
    3.1.操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
    3.2. 操作和结果是一一对应的，但操作中不要包含结果的检查；
    3.3. 用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）；
    3.4. 用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
    3.5. 用例描述中不允许出现二义性语句；
    预期结果:
    4.1. 原则上每个用例必需要有预期结果，结果不能为空；
    4.2. 结果中只能包含结果，不能有步骤；
    4.3. 一个结果有多个检查点时，确保检查点完整；
    4.4. 结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
    4.5. 结果涉及页面，需明确页面提示结果、数据变化；
    4.6. 结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
    4.7. 结果涉及消息：需明确关键查看内容；
    4.8. 结果对应不同输入数据有差别时需分别对应描述清晰；

用例维护规范

测试用例编写完成后，应对测试用例进行持续的维护：

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