# 测试用例完成定义

面向当前仓库的固定流水线，一个测试任务被视为“完成”，不是只看是否产出了文档，而是看产出的测试点和测试用例是否已经达到可评审、可执行、可追溯、可导出的质量门槛。

## 1. 覆盖范围达标

至少覆盖以下维度，不得只覆盖主流程：

- 主流程：核心业务 Happy Path 必须覆盖。
- 异常流程：参数非法、前置条件不满足、状态不允许、库存不足、余额不足、权限不足、重复操作、超限操作等必须覆盖。
- 边界条件：最小值、最大值、临界值、空值、默认值、长度边界、数量边界、时间边界、金额边界必须按需求实际场景覆盖。
- 状态流转：创建、提交、生效、失效、取消、关闭、撤回、恢复等关键状态变化必须覆盖。
- 规则组合：多条件叠加、互斥、优先级、覆盖关系、兜底规则必须覆盖。
- 数据校验：展示数据、落库数据、统计口径、列表汇总、详情字段、外部回传字段必须覆盖。
- 中后台页面：如果需求包含列表、新建、编辑、查看、失效、删除、筛选、选择弹窗等管理能力，除失败态外，正向成功链路和交互细项也必须覆盖。
- 历史风险：`common_missed_scenes.md`、`historical_defects.md` 中与当前需求相关的高风险场景必须映射到测试点或测试用例。
- 跨需求影响：`关联与冲突.md` 中识别出的关联规则、潜在冲突、修订建议，必须至少落一条可验证测试点或用例。
- 项目差异化：`project_profile.md` 中的业务边界、禁用能力、特殊限制、风控要求必须体现。

## 2. 风险覆盖达标

对于高风险模块，测试用例必须体现风险导向，而不是平均用力。

- P0/P1 业务规则必须覆盖正向、逆向、边界、互斥、并发或幂等中的关键场景。
- 资金、库存、优惠、权益、运单状态等资损类风险，必须覆盖结果一致性校验。
- 涉及角色隔离、数据隔离、组织隔离的需求，必须覆盖权限与越权场景。
- 涉及外部系统、回调、异步任务、延迟生效、重试补偿的需求，必须覆盖时序异常与重复触发场景。

## 3. 用例设计质量达标

每条用例必须满足以下要求：

- 原子性：一条用例只验证一个主验证点，避免多个核心断言混在一条用例里。
- 可执行：前置条件、步骤、测试数据明确，执行人无需猜测。
- 可验证：预期结果必须同时覆盖 UI/接口反馈和数据状态变化。
- 可定位：失败后能大致判断是前端展示、后端规则、数据落库、异步处理还是外部依赖问题。
- 可复现：步骤中要包含关键账号、角色、商品、金额、券、积分、库存、时间或状态等必要数据。
- 类型准确：`类型` 字段必须使用标准枚举，且与用例真实目的匹配。
- 术语一致：术语表达必须与生效术语文件一致，不混用平台券、商家券、店铺券等概念。
- 模块清晰：`模块` 字段应使用层级路径表达，例如 `平台端-营销管理-商家优惠券`。

## 4. 测试点到用例的映射达标

- 每个高价值测试点都应被至少一条用例承接。
- 历史缺陷防御点、漏测清单项、冲突修订项不得只停留在测试点层，必须在用例层落地。
- 如果某类测试点因为当前范围不做用例，必须明确写出原因，不能静默遗漏。

## 5. 待确认项处理达标

- 需求存在缺失、冲突、口径不明时，必须显式写出：

```md
> ⚠️ 待确认：问题、影响范围、建议确认方向
```

- 待确认项影响主流程、金额、库存、权限、状态流转、优惠规则时，不得擅自臆造高风险业务规则。
- 对待确认项，至少要补一条“确认后需重点回归”的提醒性测试点或备注。

## 6. 非功能与稳健性覆盖达标

以下场景按风险选择，不要求机械凑数量，但高风险需求不能缺失：

- 幂等：重复提交、重复支付、重复领券、重复核销、重复回调。
- 并发：多人抢占、库存竞争、优惠领取竞争、重复操作竞争。
- 弱网与超时：请求超时、接口重试、页面重复点击、异步结果延迟返回。
- 兼容与稳定性：分页、排序、筛选、导入导出、大数据量、长名称、特殊字符。
- 权限与审计：无权限、低权限、跨组织、跨门店、跨商家操作及日志留痕。
- 展示状态：若多个业务状态会影响 C 端资格、弹窗或按钮展示，需拆分到可定位的独立用例，不得用一条模糊负向用例笼统代替。

## 7. 评审与产物达标

- `output/analysis/{BASE_NAME}_分析.md`、`output/test_points/{BASE_NAME}_测试点.md`、`output/test_cases/{BASE_NAME}_测试用例.md` 必须完整存在。
- 测试用例表头必须严格符合 `test_case_template.md` 的唯一规范。
- 测试用例文件必须可通过 `verify` 校验，并可成功 `export` 为 Excel。
- 评审阶段必须对照本 DoD、历史缺陷、关联冲突报告、项目画像进行检查；未达标时应直接修正原文件，不另起草稿。

## 8. 默认判定原则

如果产物满足以下任一情况，则不能视为完成：

- 只有主流程，没有异常、边界、状态流转或冲突防御场景。
- 用例步骤泛化，没有可执行的数据。
- 预期结果只有“提示成功/失败”，没有数据状态校验。
- 历史缺陷、漏测清单、项目差异化约束未落入测试点或用例。
- 明显存在待确认问题，但未显式标记。
- Markdown 表格不规范，导致后续 `verify` 或 `export` 无法通过。
