You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 

4.9 KiB

测试用例编写规范

1. 文档结构规范

1.1 文件命名规范

  • 测试用例文件必须以 test_ 开头
  • 文件名应清晰表明测试内容,如:test_create_basic.md
  • 使用小写字母,单词间用下划线连接

1.2 测试用例组织结构

module_name/                 # 模块名称
├── api/                    # API文档
│   └── api_doc.md         # 接口文档
├── test_cases/            # 测试用例
│   ├── feature1/          # 功能1相关测试
│   ├── feature2/          # 功能2相关测试
│   └── feature3/          # 功能3相关测试
└── test_case_standard.md  # 测试用例编写规范

2. 测试用例内容规范

2.1 基本信息

每个测试用例必须包含以下基本信息:

  • 测试用例ID:唯一标识符(格式:TC_[模块]_[功能]_[序号])
  • 测试标题:简明扼要的描述
  • 前置条件:执行测试用例的必要条件
  • 测试级别:单元测试/集成测试/系统测试
  • 测试类型:功能测试/性能测试/安全测试等
  • 执行优先级:P0/P1/P2/P3(P0最高,P3最低)

2.2 测试步骤格式

## 测试用例:[用例ID] - [测试标题]

### 基本信息
- 测试级别:[级别]
- 测试类型:[类型]
- 优先级:[优先级]

### 前置条件
1. [前置条件1]
2. [前置条件2]

### 测试步骤
1. [详细的操作步骤1]
2. [详细的操作步骤2]

### 预期结果
1. [对应步骤1的预期结果]
2. [对应步骤2的预期结果]

### 数据验证
- 状态码验证:[期望的状态码]
- 响应格式验证:[期望的响应格式]
- 数据完整性验证:[需要验证的字段]

3. 测试场景覆盖要求

3.1 必测场景

  1. 正向测试(Happy Path)

    • 使用有效的必填参数
    • 使用所有可选参数
    • 验证成功响应
  2. 参数验证

    • 必填参数缺失
    • 参数格式错误
    • 参数长度边界值
    • 特殊字符处理
  3. 权限验证

    • 无权限访问
    • 越权访问
    • Token过期/无效
  4. 业务规则验证

    • 唯一性约束
    • 状态转换规则
    • 关联数据完整性

3.2 边界值测试要求

  1. 字符串类型

    • 空字符串
    • 最小长度-1
    • 最小长度
    • 最大长度
    • 最大长度+1
    • 特殊字符
  2. 数值类型

    • 最小值-1
    • 最小值
    • 最大值
    • 最大值+1
    • 0值
    • 负值
  3. 日期时间类型

    • 无效格式
    • 过去时间
    • 当前时间
    • 未来时间
    • 跨时区处理
  4. 列表类型

    • 空列表
    • 单个元素
    • 最大元素数量
    • 重复元素
    • 无效元素

4. 响应验证规范

4.1 状态码验证

  • 200:成功响应
  • 400:请求参数错误
  • 401:未授权
  • 403:禁止访问
  • 404:资源不存在
  • 409:资源冲突
  • 422:数据验证失败
  • 500:服务器内部错误

4.2 响应数据验证

  1. 基础字段验证

    • code:响应码
    • message:响应消息
    • data:响应数据
  2. 数据完整性验证

    • 必填字段存在性
    • 字段类型正确性
    • 字段格式合规性
    • 关联数据完整性
  3. 审计字段验证(如适用)

    • created_at
    • created_by
    • updated_at
    • updated_by

5. 测试数据管理

5.1 测试数据要求

  • 使用固定的测试数据集
  • 测试数据应具有代表性
  • 避免使用生产环境数据
  • 测试完成后及时清理数据

5.2 测试数据格式

{
    "valid_case": {
        "field1": "valid_value1",
        "field2": "valid_value2"
    },
    "invalid_case": {
        "field1": "invalid_value1",
        "field2": "invalid_value2"
    }
}

6. 注意事项

  1. 测试用例命名

    • 名称应清晰表达测试目的
    • 使用统一的命名规范
    • 便于理解和维护
  2. 测试步骤描述

    • 步骤要清晰、具体
    • 每个步骤都要有对应的预期结果
    • 避免模糊的描述
  3. 测试数据处理

    • 测试前准备好测试数据
    • 测试后及时清理数据
    • 避免测试数据互相干扰
  4. 错误处理

    • 验证所有错误场景
    • 确保错误消息准确
    • 验证错误码的正确性
  5. 文档维护

    • 及时更新测试用例
    • 记录测试结果
    • 标注已知问题

7. 测试用例评审清单

7.1 基础检查项

  • 测试用例ID是否符合规范
  • 测试标题是否清晰明确
  • 优先级是否合理
  • 前置条件是否完整

7.2 测试步骤检查项

  • 步骤描述是否清晰
  • 是否包含具体的测试数据
  • 是否有明确的预期结果
  • 是否覆盖了边界条件

7.3 测试覆盖检查项

  • 是否覆盖所有必测场景
  • 是否包含异常场景测试
  • 是否验证了所有关键字段
  • 是否考虑了性能因素

7.4 数据验证检查项

  • 是否验证了数据完整性
  • 是否验证了数据一致性
  • 是否包含审计字段验证
  • 是否有数据清理计划