standards/test_case_writing_standard.md

# 测试用例编写规范

## 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 测试步骤格式
```markdown
## 测试用例：[用例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 测试数据格式
```json
{
    "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 数据验证检查项
- [ ] 是否验证了数据完整性
- [ ] 是否验证了数据一致性
- [ ] 是否包含审计字段验证
- [ ] 是否有数据清理计划