adspecs 0.1.12

package/.adspecs/templates/13-/346/265/213/350/257/225/347/224/250/344/276/213/346/250/241/346/235/277.md

@@ -0,0 +1,543 @@
+# 测试用例编写规范
+
+> **版本**: v2.0
+> **创建日期**: 2026-06-09
+> **修订日期**: 2026-06-09
+> **适用人员**: 测试工程师、开发工程师、AI助手
+> **目的**: 规范测试用例的设计、编写和测试数据准备流程，确保测试用例覆盖面完整、可重复执行、结果可验证，并与上游需求形成可追溯闭环
+> **目的**: 规范测试用例的设计、编写和测试数据准备流程，确保测试用例覆盖面完整、可重复执行、结果可验证
+
+---
+
+## 📝 使用说明
+
+本规范用于指导团队成员在设计阶段编写**测试用例**（Test Case）和准备**测试数据**（Test Data），包含：
+
+1. **测试用例设计原则** — 覆盖度要求、设计方法论
+2. **测试用例编写模板** — 统一格式的结构化用例模板（含需求追溯字段）
+3. **测试数据规范** — 数据分类、命名、边界值选取准则
+4. **覆盖率要求** — 场景分类与最低覆盖标准
+5. **用例评审标准** — 评审清单和通过条件
+6. **需求追溯** — 用例与需求的映射规则、追溯矩阵自动生成说明
+
+本规范不包含：测试执行流程、测试报告模板（参考 `07-单元测试报告模板.md` / `08-系统集成测试报告模板.md`）。
+
+
+---
+
+## 一、测试用例设计原则
+
+### 1.1 场景分类
+
+每个被测功能点的测试用例必须覆盖以下三类场景：
+
+| 场景类型                   | 说明                         | 占比建议 | 最低数量 |
+| -------------------------- | ---------------------------- | -------- | -------- |
+| **正常场景**（Happy Path） | 合法输入、正常业务流程       | ~40%     | ≥1       |
+| **异常场景**（Exception）  | 非法输入、业务异常、系统异常 | ~35%     | ≥1       |
+| **边界场景**（Boundary）   | 临界值、空值、极值、特殊字符 | ~25%     | ≥1       |
+
+**规则**：每个公开方法（public method）至少 **3 个测试用例**（正常 + 异常 + 边界各至少 1 个）。
+
+### 1.2 设计方法论
+
+**等价类划分**：
+- 将输入域划分为若干等价类，每类中任选一个代表值即可
+- 示例：订单优先级 1-5 → 有效等价类 {1,2,3,4,5}，无效等价类 {0, 6, -1, null}
+
+**边界值分析**：
+- 重点关注等价类的边界上下限及其相邻值
+- 示例：需求量必须 > 0 → 测试值 0（边界外）、0.001（边界内）、极大值（上限）
+
+**判定表/因果图**：
+- 当输出依赖多个输入条件的组合时使用
+- 示例：母卷状态+订单状态+权限 → 操作是否允许
+
+**错误推测法**：
+- 基于经验推测易出错场景
+- 示例：并发操作、网络超时、数据为空、历史数据兼容
+
+### 1.3 独立性原则
+
+- 每个测试用例**独立运行**，不依赖其他用例的执行顺序
+- 测试数据在用例开始时准备（Given），在用例结束时清理（After）
+- 不允许用例间通过共享内存/数据库状态传递数据
+
+---
+
+## 二、测试用例编写模板
+
+### 2.1 单元测试用例模板
+
+适用于 Service 层、工具类、Mapper 层的单个方法测试。
+
+```markdown
+#### 用例编号: UT-{模块缩写}-{序号}
+
+| 属性         | 内容                                                                      |
+| ------------ | ------------------------------------------------------------------------- |
+| **用例编号** | UT-{模块}-{序号}（如 UT-MDM-001）                                         |
+| **测试方法** | `{ClassName}.{methodName}()`                                              |
+| **场景分类** | 正常场景 / 异常场景 / 边界场景                                            |
+| **覆盖需求** | 引用上游需求 ID，多个用逗号分隔（如 US-01-AC1, BR-01, FUNC-01）。**必填** |
+| **测试描述** | 用一句话描述本用例测试什么                                                |
+| **前置条件** | 执行前必须满足的条件（数据状态、Mock 行为）                               |
+
+**输入数据**:
+
+| 参数名   | 类型   | 值      | 说明           |
+| -------- | ------ | ------- | -------------- |
+| {param1} | {type} | {value} | 为什么选这个值 |
+| {param2} | {type} | {value} | 为什么选这个值 |
+
+**Mock 设置**（如有）:
+
+| 依赖         | 方法     | 返回值/行为  |
+| ------------ | -------- | ------------ |
+| {dependency} | {method} | {mockReturn} |
+
+**预期结果**:
+- 返回值：{expectedReturn}
+- 数据库变更：{expectedDBChange}（如有）
+- 异常抛出：{expectedException}（异常场景填写）
+
+**验证点**:
+1. {verificationPoint1}
+2. {verificationPoint2}
+```
+
+### 2.2 API 接口测试用例模板
+
+适用于 Controller 层接口测试（含权限校验）。
+
+```markdown
+#### 用例编号: API-{模块缩写}-{序号}
+
+| 属性         | 内容                                                        |
+| ------------ | ----------------------------------------------------------- |
+| **用例编号** | API-{模块}-{序号}（如 API-MDM-001）                         |
+| **接口路径** | `{HTTP_METHOD} /admin-api/{module}/{domain}/{action}`       |
+| **场景分类** | 正常场景 / 异常场景 / 边界场景 / 权限场景                   |
+| **覆盖需求** | 引用上游需求 ID（如 FUNC-01, US-01-AC1, PERM-02）。**必填** |
+| **测试描述** | 用一句话描述本用例测试什么                                  |
+| **前置条件** | 登录用户、数据状态                                          |
+
+**请求**:
+
+| 参数位置 | 参数名        | 类型   | 值             | 说明       |
+| -------- | ------------- | ------ | -------------- | ---------- |
+| Header   | Authorization | String | Bearer {token} | 认证 Token |
+| Body     | {field1}      | {type} | {value}        | {说明}     |
+
+**预期响应**:
+
+```json
+{
+  "code": 0,
+  "message": "操作成功",
+  "data": { ... }
+}
+```
+
+**验证点**:
+1. HTTP 状态码 = {statusCode}
+2. 响应体 code = {expectedCode}
+3. 响应体 data 包含 {expectedFields}
+```
+
+### 2.3 业务流程测试用例模板
+
+适用于端到端业务流程测试（跨越多个接口/方法）。
+
+```markdown
+#### 用例编号: E2E-{模块缩写}-{序号}
+
+| 属性         | 内容                                                        |
+| ------------ | ----------------------------------------------------------- |
+| **用例编号** | E2E-{模块}-{序号}                                           |
+| **业务流程** | {流程名称}（如"母卷导入→裁剪方案生成→订单分配→指导书导出"） |
+| **场景分类** | 正常流程 / 异常中断 / 并发流程                              |
+| **覆盖需求** | 引用上游用户故事 ID（如 US-01, US-02）。**必填**            |
+| **涉及角色** | {角色列表}                                                  |
+| **前置条件** | {整体前置条件}                                              |
+
+**操作步骤**:
+
+| 步骤 | 操作者 | 操作     | 接口/方法 | 预期响应/状态 |
+| ---- | ------ | -------- | --------- | ------------- |
+| 1    | {role} | {action} | {api}     | {expected}    |
+| 2    | {role} | {action} | {api}     | {expected}    |
+| 3    | {role} | {action} | {api}     | {expected}    |
+
+**最终验证**:
+1. {endState1}
+2. {endState2}
+```
+
+---
+
+## 三、测试数据规范
+
+### 3.1 测试数据分类
+
+| 数据类别                          | 说明                               | 示例                             |
+| --------------------------------- | ---------------------------------- | -------------------------------- |
+| **基础数据**（Fixtures）          | 所有测试共用、不频繁变动的参考数据 | 字典类型、错误码、常量枚举       |
+| **场景数据**（Scenarios）         | 按业务场景组织的、可复用的数据集   | "10母卷+20订单标准测试集"        |
+| **用例专属数据**（Case-specific） | 单个用例独用的边界/异常数据        | 宽度为负数的母卷、重复编号的订单 |
+| **Mock 数据**（Mock）             | 模拟外部依赖返回的数据             | 用户信息、文件服务响应           |
+
+### 3.2 测试数据命名规范
+
+**数据集命名**：`{模块缩写}_{场景描述}_{数据规模}`
+- 示例：`mdm_standard_10coils_20orders`（MDM 模块标准集 10 母卷 20 订单）
+- 示例：`aps_cutting_normal_1coil_3orders`（APS 单卷裁剪 1 母卷 3 订单）
+
+**测试数据文件命名**（SQL 脚本）：`test_data_{模块}_{场景}.sql`
+- 示例：`test_data_aps_standard.sql`、`test_data_aps_boundary.sql`
+
+### 3.3 边界值选取准则
+
+按数据类型选择合适的边界值测试点：
+
+| 数据类型                  | 边界测试点                                                                                 |
+| ------------------------- | ------------------------------------------------------------------------------------------ |
+| **数值**（Integer/Long）  | 最小值-1、最小值、最小值+1、0、最大值-1、最大值、最大值+1、负数                            |
+| **小数**（BigDecimal）    | 0.0、-0.01、0.01、精度极限值（如 DECIMAL(18,2) 的 9999999999999999.99）                    |
+| **字符串**（String）      | null、空串""、单字符、最大长度-1、最大长度、最大长度+1、特殊字符（`<>'"&;\|`）、中文/Emoji |
+| **日期**（LocalDateTime） | 当前日期、昨天/明天、未来一年、过去一年、epoch 边界（1970-01-01）、null                    |
+| **枚举**                  | 每个合法枚举值、null、非法枚举值（未定义的字符串/数字）                                    |
+| **集合**（List/Set）      | 空集合、单元素、最大数量-1、最大数量、最大数量+1、含 null 元素的集合                       |
+
+### 3.4 测试数据隔离策略
+
+- **单元测试**：使用内存数据库（H2）或 Mock，每条用例数据自包含
+- **集成测试**：使用专用测试数据库实例，用例执行前后通过 `@Sql` 脚本初始化/清理
+- **数据库清理**：`clean.sql` 按外键依赖逆序 TRUNCATE 所有表，确保幂等
+
+```sql
+-- clean.sql 示例
+SET FOREIGN_KEY_CHECKS = 0;
+TRUNCATE TABLE plan_assignments;
+TRUNCATE TABLE plan_cutting_details;
+TRUNCATE TABLE small_coils;
+TRUNCATE TABLE cutting_plans;
+TRUNCATE TABLE optimization_task;
+TRUNCATE TABLE orders;
+TRUNCATE TABLE mother_coils;
+SET FOREIGN_KEY_CHECKS = 1;
+```
+
+---
+
+## 四、覆盖率要求
+
+### 4.1 按测试层级
+
+| 测试层级                   | 行覆盖率                                        | 分支覆盖率 | 方法覆盖率 |
+| -------------------------- | ----------------------------------------------- | ---------- | ---------- |
+| 单元测试（Service/Mapper） | ≥ 90%                                           | ≥ 85%      | ≥ 95%      |
+| 工具类（Utils/Helper）     | 100%                                            | 100%       | 100%       |
+| Controller（API 测试）     | 接口 ≥ 100%（每个端点至少 1 个正常 + 1 个异常） | —          | —          |
+
+### 4.2 按场景维度
+
+| 维度         | 最低覆盖要求                                                                  |
+| ------------ | ----------------------------------------------------------------------------- |
+| **正常流程** | 每个用户故事的主流程至少 1 条                                                 |
+| **业务异常** | ErrorCodeConstants 中每个错误码至少 1 条触发用例                              |
+| **参数校验** | SaveReqVO 中每个 `@NotNull`/`@NotBlank`/`@InEnum` 等校验注解至少 1 条违规用例 |
+| **权限校验** | 每个 `@PreAuthorize` 注解至少 1 条无权限用户的拒绝用例                        |
+| **状态流转** | 每条合法的状态转换路径至少 1 条                                               |
+| **并发冲突** | 涉及分布式锁/乐观锁的方法至少 1 条并发用例                                    |
+
+### 4.3 覆盖率豁免
+
+以下情况可以免除覆盖率要求，但需在用例清单中注明原因：
+
+- 纯 POJO（只有 getter/setter 的 DO/VO/DTO）
+- 框架自动生成的代码（如 MapStruct 生成的 Convert 实现）
+- 仅包含 `throw new UnsupportedOperationException()` 的方法
+- 第三方依赖适配层（已由供应商测试），标注"第三方依赖，免测"
+
+---
+
+## 五、测试用例命名规范
+
+### 5.1 方法命名
+
+格式：`test{MethodName}_{Scenario}_{ExpectedOutcome}`
+
+| 部分                | 规则                 | 示例                                        |
+| ------------------- | -------------------- | ------------------------------------------- |
+| `{MethodName}`      | 被测方法名（大驼峰） | `CreateWarehouse`、`GetPage`                |
+| `{Scenario}`        | 场景简述（大驼峰）   | `Success`、`CodeDuplicate`、`StatusInvalid` |
+| `{ExpectedOutcome}` | 异常场景时的预期结果 | `ThrowsException`、`ReturnsNull`            |
+
+完整示例：
+- `testCreateWarehouse_Success` — 正常创建仓库
+- `testCreateWarehouse_CodeDuplicate_ThrowsException` — 编码重复时抛异常
+- `testCreateWarehouse_NullName_ThrowsException` — 名称为空时抛异常
+- `testGetWarehousePage_EmptyList_ReturnsEmpty` — 无数据时返回空列表
+- `testDeleteWarehouse_InvalidStatus_ThrowsException` — 状态非法时抛异常
+
+### 5.2 用例编号命名
+
+格式：`{层级}-{模块缩写}-{序号}`
+
+| 层级         | 前缀  | 示例          |
+| ------------ | ----- | ------------- |
+| 单元测试     | `UT`  | `UT-MDM-001`  |
+| API 测试     | `API` | `API-MDM-015` |
+| 业务流程测试 | `E2E` | `E2E-MDM-001` |
+
+模块缩写参考：`MDM`（主数据）、`WMS`（仓储）、`APS`（排产）、`MES`（制造）、`QMS`（质量）、`SRM`（供应商）、`SYS`（系统）
+
+---
+
+## 六、用例评审标准
+
+### 6.1 评审清单
+
+每个测试用例编写完成后，对照以下清单逐项自检：
+
+- [ ] **可执行性**：用例可以独立运行，不依赖其他用例的执行顺序
+- [ ] **可重复性**：多次运行结果一致（无时间/随机依赖）
+- [ ] **可验证性**：预期结果明确，有具体的断言（assert），不依赖人工目视判断
+- [ ] **场景覆盖**：同一方法至少覆盖正常、异常、边界三类场景
+- [ ] **数据隔离**：不会在数据库/缓存中留下影响其他用例的残留数据
+- [ ] **命名合规**：方法命名和用例编号符合本规范
+- [ ] **单一职责**：每个用例只测试一个行为/一条规则
+- [ ] **无冗余**：没有两个用例在相同条件下验证相同行为
+- [ ] **Mock 合理**：不 Mock 被测对象本身，只 Mock 外部依赖
+- [ ] **追溯完整**：`**覆盖需求**` 字段已填写，引用正确的上游需求 ID
+
+### 6.2 评审通过条件
+
+- 上述 10 项全部通过 → 通过
+- 1-2 项不通过 → 需修改后重新评审
+- ≥3 项不通过 → 打回重写
+
+---
+
+## 七、填写示例
+
+以下以 **MDM 模块 — 编码规则创建** 为例，演示如何填写本规范中的模板。
+
+### 7.1 单元测试用例示例
+
+#### 用例编号: UT-MDM-001
+
+| 属性         | 内容                                          |
+| ------------ | --------------------------------------------- |
+| **用例编号** | UT-MDM-001                                    |
+| **测试方法** | `CodeRuleServiceImpl.createCodeRule()`        |
+| **场景分类** | 正常场景                                      |
+| **覆盖需求** | US-01-AC1, BR-01                              |
+| **测试描述** | 验证使用合法参数创建编码规则成功，返回规则 ID |
+| **前置条件** | 同一 scope 下不存在相同的 ruleCode            |
+
+**输入数据**:
+
+| 参数名               | 类型    | 值                    | 说明                 |
+| -------------------- | ------- | --------------------- | -------------------- |
+| createReqVO.ruleCode | String  | "MAT-SEQ"             | 合法编码             |
+| createReqVO.scope    | String  | "MATERIAL"            | CodeScopeEnum 合法值 |
+| createReqVO.pattern  | String  | "PREFIX-YYYYMMDD-SEQ" | 合法模式             |
+| createReqVO.padding  | Integer | 6                     | 合法范围 1-10        |
+| createReqVO.step     | Integer | 1                     | 合法步进值           |
+| createReqVO.status   | Integer | 1                     | 启用状态             |
+
+**Mock 设置**:
+
+| 依赖           | 方法                                          | 返回值/行为    |
+| -------------- | --------------------------------------------- | -------------- |
+| codeRuleMapper | selectOne(CodeRuleDO::getRuleCode, "MAT-SEQ") | null（无重复） |
+| codeRuleMapper | insert(any)                                   | 1（插入成功）  |
+
+**预期结果**:
+- 返回值：Long（新规则 ID）
+- 数据库变更：code_rule 表新增一条记录
+- 异常抛出：无
+
+**验证点**:
+1. 返回的 ID 不为 null 且 > 0
+2. codeRuleMapper.insert() 被调用一次
+3. 插入的 DO 的 status = 1（启用）
+
+---
+
+#### 用例编号: UT-MDM-002
+
+| 属性         | 内容                                                     |
+| ------------ | -------------------------------------------------------- |
+| **用例编号** | UT-MDM-002                                               |
+| **测试方法** | `CodeRuleServiceImpl.createCodeRule()`                   |
+| **场景分类** | 异常场景                                                 |
+| **测试描述** | 验证同一 scope 下 ruleCode 重复时抛异常                  |
+| **前置条件** | 数据库已存在 ruleCode="MAT-SEQ", scope="MATERIAL" 的记录 |
+
+**输入数据**:
+
+| 参数名               | 类型   | 值         | 说明                 |
+| -------------------- | ------ | ---------- | -------------------- |
+| createReqVO.ruleCode | String | "MAT-SEQ"  | 与已有记录重复       |
+| createReqVO.scope    | String | "MATERIAL" | 与已有记录相同 scope |
+
+**Mock 设置**:
+
+| 依赖           | 方法                                          | 返回值/行为           |
+| -------------- | --------------------------------------------- | --------------------- |
+| codeRuleMapper | selectOne(CodeRuleDO::getRuleCode, "MAT-SEQ") | 已存在的 CodeRuleDO   |
+| codeRuleMapper | selectOne(CodeRuleDO::getScope, "MATERIAL")   | 返回 scope 相同的记录 |
+
+**预期结果**:
+- 返回值：无
+- 数据库变更：无
+- 异常抛出：`ServiceException`，错误码 = `ErrorCodeConstants.CODE_RULE_DUPLICATE`（1_070_001_002）
+
+**验证点**:
+1. 抛出 ServiceException
+2. 异常的错误码 = CODE_RULE_DUPLICATE（1_070_001_002）
+3. codeRuleMapper.insert() 没有被调用
+
+---
+
+### 7.2 API 测试用例示例
+
+#### 用例编号: API-MDM-001
+
+| 属性         | 内容                                         |
+| ------------ | -------------------------------------------- |
+| **用例编号** | API-MDM-001                                  |
+| **接口路径** | `POST /admin-api/mdm/code-rule/create`       |
+| **场景分类** | 正常场景                                     |
+| **测试描述** | 验证有权限的工艺员创建编码规则成功           |
+| **前置条件** | 用户已登录，具有 `mdm:code-rule:create` 权限 |
+
+**请求**:
+
+| 参数位置 | 参数名        | 类型   | 值                   | 说明       |
+| -------- | ------------- | ------ | -------------------- | ---------- |
+| Header   | Authorization | String | Bearer {valid_token} | 有效 Token |
+| Header   | tenant-id     | String | "1"                  | 租户 ID    |
+| Body     | ruleCode      | String | "MAT-SEQ"            | 规则编码   |
+| Body     | scope         | String | "MATERIAL"           | 编码范围   |
+
+**预期响应**:
+
+```json
+{
+  "code": 0,
+  "message": "操作成功",
+  "data": 1
+}
+```
+
+**验证点**:
+1. HTTP 状态码 = 200
+2. 响应体 code = 0
+3. 响应体 data > 0（返回有效的规则 ID）
+
+---
+
+#### 用例编号: API-MDM-002
+
+| 属性         | 内容                                               |
+| ------------ | -------------------------------------------------- |
+| **用例编号** | API-MDM-002                                        |
+| **接口路径** | `POST /admin-api/mdm/code-rule/create`             |
+| **场景分类** | 权限场景                                           |
+| **测试描述** | 验证无权限用户创建编码规则被拒绝                   |
+| **前置条件** | 用户已登录，但**没有** `mdm:code-rule:create` 权限 |
+
+**请求**:
+
+| 参数位置 | 参数名        | 类型   | 值                    | 说明         |
+| -------- | ------------- | ------ | --------------------- | ------------ |
+| Header   | Authorization | String | Bearer {viewer_token} | 查看员 Token |
+
+**预期响应**:
+
+```json
+{
+  "code": 403,
+  "message": "权限不足",
+  "data": null
+}
+```
+
+**验证点**:
+1. HTTP 状态码 = 403
+
+---
+
+## 八、需求追溯
+
+### 8.1 追溯链路
+
+全链路追溯体系见 `.adspecs/templates/02-产品需求说明书模板.md` 的“全链路ID体系约定”章节。
+
+测试用例在整条链路中负责"闭环验证"——通过 `**覆盖需求**` 字段向上游 PRD ID 锚定，证明每条需求都被至少一个测试用例验证。
+
+```
+PRD ID (如 US-01-AC1, BR-01, FUNC-01)
+    ↑ 通过 "**覆盖需求**" 字段引用
+测试用例 (UT-xxx / API-xxx / E2E-xxx)
+```
+
+### 8.2 ID 引用规则
+
+| 规则         | 说明                                                                                                                                               |
+| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **必填**     | 每个测试用例必须填写 `**覆盖需求**` 字段                                                                                                           |
+| **精确引用** | 引用上游 PRD ID，多个用逗号分隔（如 `US-01-AC1, BR-01`）                                                                                           |
+| **可验证性** | 每个引用的 ID 必须能在需求分析文档的"需求 ID 映射表"中找到（如果找不到，说明用例覆盖了不存在的需求）                                               |
+| **覆盖粒度** | UT 用例引用 `BR-{n}` 和 `US-{n}-AC{n}`（细粒度规则/场景）；API 用例引用 `FUNC-{n}` 和 `PERM-{n}`（功能+权限）；E2E 用例引用 `US-{n}`（粗粒度故事） |
+
+### 8.3 追溯矩阵自动生成
+
+AI 在测试用例编写完成后，通过以下步骤自动生成追溯矩阵：
+
+1. **解析基准**：扫描需求分析文档的"需求 ID 映射表"，得到完整 ID 清单
+2. **扫描用例**：扫描所有测试用例文件的 `**覆盖需求**:` 行，聚合成 `用例→需求` 映射
+3. **扫描设计**：扫描系统设计文档的 `**实现需求**:` 行，聚合成 `需求→设计` 映射
+4. **交叉聚合**：生成三张视图（需求→设计→用例 / 设计→需求 / 用例→需求）
+5. **覆盖率统计**：计算每个需求类别的设计覆盖率、用例覆盖率和全闭环率
+
+**全闭环判定**：一条需求为"全闭环"，当且仅当：
+- 至少一个系统设计要素标注了该 ID（`**实现需求**:` 标签）
+- 至少一个测试用例标注了该 ID（`**覆盖需求**:` 标签）
+- 关联的测试用例全部 PASS
+
+### 8.4 追溯矩阵模板
+
+追溯矩阵的完整模板和格式见 `docs/99-template/14-需求追溯矩阵模板.md`。
+
+---
+
+## 🎯 规范优势
+
+1. **模板化**：三类模板覆盖单元测试、API 测试、业务流程测试，统一输出格式
+2. **可量化**：明确的覆盖率数字指标和最低用例数量要求
+3. **可评审**：10 项自检清单确保用例质量
+4. **可追溯**：`**覆盖需求**` 字段 + 追溯矩阵，实现需求→用例双向追溯
+5. **数据规范**：边界值选取准则覆盖全数据类型，避免遗漏
+6. **与项目对齐**：命名规范、错误码引用、权限校验与 `04-Java后端编码规范.md` 一致
+7. **AI 友好**：结构化模板便于 AI 批量生成高质量测试用例
+
+---
+
+## 📞 使用流程
+
+1. **需求分析阶段** → 参照本规范设计测试策略，确定场景分类
+2. **系统设计阶段** → 编写测试用例清单（用例编号 + 测试描述 + 输入数据 + **覆盖需求**），准备测试数据集
+3. **编码阶段** → 对照用例清单实现测试代码
+4. **测试执行后** → 将执行结果填入 `07-单元测试报告模板.md` 或 `08-系统集成测试报告模板.md`
+5. **追溯矩阵生成** → AI 扫描所有用例的 `**覆盖需求**` 标签，自动生成 `14-需求追溯矩阵模板.md` 格式的追溯报告
+
+---
+
+**文档结束**
+
+*本规范由 AI 辅助生成，作为 sie-cloud 项目测试用例设计和测试数据准备的标准参考。*