# 测试策略

**功能 / 项目**:
**最后更新**:
**负责人**:

## 测试层级

- 单元:
- 组件:
- API / 契约:
- 集成:
- E2E:
- 视觉:

## 开发验证与验收验证分层

Harness 把实现过程中的快速反馈和交付前的完整验收拆成两个独立闸门:

| 闸门 | 目的 | 典型验证 | 完成条件 |
| --- | --- | --- | --- |
| 自然语言测试用例 | 把 PRD 每条需求转成可审查、可追溯、可转脚本的测试用例 | `NATURAL_LANGUAGE_TEST_CASES.md`、需求类型覆盖矩阵、Gherkin/步骤化用例、Oracle、测试数据、证据路径、TDD RED 预期失败 | 每条需求都要分类；P0/P1 按需求类型满足最小用例数；P2 需写用例或豁免原因；TDD 候选用例可被 `tdd_contract.red.source_case_ids` 引用 |
| TDD RED | 在生产代码变更前证明新增或变更行为当前缺失 | 聚焦单元、组件、契约或 API 测试；必须先失败且失败原因匹配预期 | 作为 `tdd_contract.red` 证据进入任务；失败原因不是目标行为缺失时不得进入实现 |
| TDD GREEN / REFACTOR | 用最小实现让同一聚焦测试通过，并在重构后保持相关验证绿色 | 同一 focused test、affected tests、coverage、lint 或类型检查 | 作为 `tdd_contract.green` 和 `tdd_contract.refactor_guard` 证据进入任务；不能替代最终验收 |
| 开发验证 | 支撑编码过程中的快速反馈，证明局部改动没有破坏直接相关行为 | 单元、组件、局部 API、契约检查、affected tests、静态检查、类型检查、lint | 作为实现过程证据进入 `development_validation`，但不能单独声明任务完成 |
| 验收验证 | 从用户、业务闭环或发布候选视角证明当前交付可被验收 | 用户故事完整链路、跨故事主流程、真实入口 E2E、数据副作用、失败态、P0/P1 回归、视觉/可访问性确认 | 作为完成前 fresh evidence 进入 `acceptance_validation`，缺失时任务必须 BLOCKED 或有 owner 批准的 exemption |

开发验证通过只说明局部实现可继续推进，不等于用户验收通过。PRD 完成后、进入实现前必须先生成自然语言测试用例；每个 `feature_impl` 默认要求 TDD：从自然语言用例选择 TDD 候选，先写聚焦测试并确认 RED 失败，再写最小实现确认 GREEN，通过后才允许重构。每个 `feature_impl` 完成前必须在代码写完后重新运行故事级验收链路；每个 `release` 完成前必须运行发布候选级跨故事验收链路。验收验证不得直接复用编码中途的旧日志，除非证据协议明确证明其仍是当前变更集的 fresh evidence。

## 自然语言用例规模规则

自然语言测试用例不是每条需求固定写 1 条，而是先判定需求类型，再按 `NATURAL_LANGUAGE_TEST_CASES.md` 的覆盖矩阵取最小用例数。基础原则:

- P0 需求默认不少于 5 条，P1 需求默认不少于 3 条，P2 可为 1-2 条并说明不进入 TDD 候选的原因。
- 低于默认数量必须写明豁免原因、替代证据和 owner 批准人。
- 只读查询至少覆盖正常、空数据和无权限；列表类还要覆盖筛选、分页、排序或组合条件。
- 新增、编辑、删除等写操作至少覆盖成功副作用、输入失败、权限失败无副作用、非法状态或并发冲突。
- 权限、状态机、异步链路、外部系统、金额库存、文件处理和安全需求必须按风险路径加量，不能只写 happy path。
- 一个需求跨多个类型时，按风险最高类型取基准，再补齐其他类型的必需路径。
- TESTCASE 阶段必须在覆盖检查表中写明“需求类型、风险因子、矩阵基准用例数、风险加量、最终要求用例数、已写用例数、加量理由”，不足时不得进入 `feature_impl`。
- 非 TDD 自然语言用例必须映射到 `story_full_chain`、`acceptance_validation`、回归或 `verify-matrix`，不能因为不适合作为 RED 种子就从验收链路消失。
- 业务规则如果会影响状态流转、副作用、金额/库存、权限或幂等，必须至少有一条异常路径或无副作用路径用例。

## QA Harness 最小闭环

测试设计按下面顺序推进，不允许直接从需求跳到测试脚本:

1. 资料输入: 读取需求、代码、API 契约、UI、数据模型、权限规则和历史缺陷。
2. 风险建模: 输出业务实体、状态、角色权限、接口、数据副作用和外部依赖风险。
3. 自然语言用例: 按 PRD / Requirement ID 识别需求类型和风险因子，按覆盖矩阵写出目标、来源、前置条件、动作、预期结果、Oracle、测试数据、证据路径和 TDD RED 预期失败。
4. 测试意图: 将自然语言用例映射到测试层级、风险、数据和可执行验证命令。
5. Oracle 审查: 通过后才生成或修改测试脚本。
6. TDD RED: `feature_impl` 从 `NATURAL_LANGUAGE_TEST_CASES.md` 的 TDD 候选用例生成聚焦测试，运行 `tdd_contract.red.command`，确认失败原因匹配目标行为缺失并记录证据。
7. TDD GREEN: 写最小实现后运行 `tdd_contract.green.command`，确认同一聚焦测试通过。
8. TDD REFACTOR: 重构后运行 `tdd_contract.refactor_guard.command` 和必要覆盖率命令，确认相关验证仍通过。
9. 开发验证: 编码过程中运行 affected tests、局部契约、类型检查、lint 或单元 / 组件测试，记录 `development_validation` 证据。
10. 验收验证: 代码写完后从用户、业务闭环或发布候选视角运行完整链路，记录 `acceptance_validation` fresh evidence。
11. 证据归档: 把命令、退出码、日志、截图、DB diff、事件、Trace 等写入证据路径。
12. 失败归因: 区分产品缺陷、测试缺陷、环境问题和数据问题。
13. 回归沉淀: 真实缺陷修复后补充回归用例或知识候选。

## Oracle 优先规则

每个测试用例必须在写脚本前定义至少一个业务 Oracle。写接口、状态流转、权限和数据一致性场景通常需要多个 Oracle 组合:

| Oracle 类型 | 适用场景 | 最小要求 |
| --- | --- | --- |
| 返回值 | API、服务、UI 动作 | 状态码、错误码、关键字段和业务语义 |
| Schema / Contract | API、事件、文件 | 字段类型、必填、枚举、版本兼容 |
| 数据库副作用 | POST / PUT / PATCH / DELETE、批处理 | before / after diff、目标字段变化、非目标字段不变 |
| 缓存 | 读写缓存、权限缓存、多租户 | key 维度、TTL、失效、跨用户隔离 |
| 事件 / 队列 | 异步链路、Webhook、消息消费 | event type、payload、重试、幂等、DLQ |
| 审计 | 登录、权限、资金、删除、审批 | actor、action、object、result、time |
| 权限 | 水平越权、垂直越权、字段级权限 | 允许 / 拒绝符合权限矩阵，拒绝时无副作用 |
| 状态机 | 订单、审批、发布、退款等状态流转 | 合法转移成功，非法转移失败且无污染 |
| 不变量 | 金额、库存、次数、唯一性 | 余额 / 库存不为负，总额守恒，唯一业务结果 |
| Trace / 证据 | E2E、集成、跨服务 | 命中预期链路、日志或 coverage 可证明目标路径 |

## 假测试拦截规则

Stage 2 必须拦截下列测试:

- 只断言 `200`、`truthy`、元素存在或 snapshot，没有业务断言。
- 写操作没有 DB、缓存、事件、审计、文件或通知等副作用断言。
- 权限失败只断言 `403`，没有验证目标数据未变化、响应未泄露和缓存未污染。
- mock 了当前被测 service、权限判断、状态机、数据库写入或核心业务路径。
- 没有绑定 Requirement ID、代码分支、API 契约、安全风险、状态机转移或历史缺陷来源。
- 没有执行证据，或证据不是当前变更集产生的 fresh evidence。
- 测试名称覆盖多个路径，但实际只跑 happy path。

## 阻塞性失败

-

## Fresh Evidence 策略

- Stage 17 只确认 fresh evidence 和回归状态。
- 缺少验收示例或需求追溯属于实现前缺口，不是 Stage 17 的任务。
