Testing System Blueprint

测试体系蓝本（Testing System Blueprint）

这是什么 / 不是什么

是：把"测试"从"写一堆用例"升级成"一套体系"的方法骨架。它定义六个能力维度与一套节奏， 让任何语言、任何框架、任何项目都能套用同一套思考方式来决定"测什么、何时测、测到什么程度、何时放行"。

不是：测试执行器，也不是某一技术栈的测试指南。本蓝本不告诉你"用 pytest 还是 jest"， 只告诉你"在这一层你需要的是单元 + 契约能力，工具由你读项目栈后实例化"。

谁用它：test-routing-advisor（决定一个任务该走哪类测试）与各类别测试 skill （如 backend-testing、frontend-testing）。它们把本蓝本的抽象原语，落到具体栈与具体项目上。

两条绝对约束（贯穿全文）

1. stack-agnostic（与栈无关）：本蓝本只规定"能力 / 维度 / 方法"，绝不锁定某一栈的工具或库。 凡举例工具，一律以"按栈实例化"的多栈示例形式给出（Python / Node / Go / JVM …）， 并明确：具体工具由调用方读项目栈后实例化，本蓝本不替你选。
2. project-agnostic（与项目无关）：不出现任何业务名词。通用测试概念 （BOLA、真库、迁移、并发、契约、幂等）允许使用，因为它们是跨项目的通用原语。

六个能力维度（速览，细节见 references）

附加护栏：自愈式补测的 5 条安全护栏见 references/self-heal-guardrails.md（作为参考， 在让任何"自动生成/自动修复测试"的流程动手前务必先读）。

一、风险分级测试设计 P0–P3（核心理念）

完整判据见 references/risk-tiers.md。这里给骨架。

测试预算永远有限。蓝本主张：不追逐覆盖率数字，而是按"出事的代价 × 出事的概率"给每条行为定级， 让有限的测试工时优先压在最贵的失败上。

• P0 必测：失败即不可逆损害——数据损坏/丢失、权限越界（任何用户拿到不属于自己的数据/操作）、 资金或额度错算、安全边界击穿。这一档不允许"延后"，是发布门的硬性输入。
• P1 该测：失败造成核心流程不可用，但可恢复——主用例走不通、关键集成断裂、对外契约破坏。
• P2 可延后：边缘路径、非关键降级、提示文案、非核心配置。
• P3 可不测：纯展示、无逻辑透传、临时脚手架。

定级是行为的属性，不是模块的属性：同一个模块里，"扣减额度"是 P0，"返回提示文案"可能是 P2。 权限相关行为（典型如 BOLA / 越权读写）默认进 P0，除非有明确理由降级。

二、需求↔测试可追溯（双向不漏）

完整规则与校验脚本思路见 references/traceability.md。这里给骨架。

体系的可信度来自"需求和测试能对上"。做法：

1. 每条验收标准（AC）给一个稳定 ID（如 AC-007.3），ID 一旦发布不重排、不复用。
2. 每个测试在元数据/命名/注释里引用它覆盖的 AC ID（如测试名含 AC-007.3 或注解 @covers AC-007.3）。
3. 双向机械校验：
   • 无孤儿需求：不存在"有 AC 但没有任何测试引用"的情况（= 漏测）。
   • 无幽灵需求：不存在"测试引用了一个不存在的 AC ID"的情况（= 需求已删/打错号，测试在裸奔）。

可追溯不是文档负担，而是**让发布门能机械地回答"这条需求测了没"**的前提——没有 ID，门就只能靠人肉判断。

三、三层测试节奏（WHEN：什么时候测什么）

蓝本把"何时测"和"测什么"解耦。同一类测试在不同时机价值不同，盲目"全都跑"既慢又掩盖问题。

L1 · 每个 task（开发期，TDD 红绿）

• 测什么：单元测试 + 契约测试（对外接口的形状/语义约定）。
• 怎么做：先写失败测试（红）→ 实现到最小通过（绿）→ 必要时重构。这是 TDD 主循环。
• 为什么在这层：缺陷在产生它的那一刻被抓住最便宜；契约在 task 内锁定，后续集成才有依据。

L2 · feature 全绿后（集成冒烟 + review）

• 测什么：feature 内部模块间的集成冒烟——真实依赖（真库、真迁移、真队列）跑通主路径。
• 关键纪律：集成测试绑 feature 边界，不绑项目边界。一个 feature 的所有 task 绿了， 就在这个 feature 的边界内做集成验证；不要等整个项目做完才第一次把模块拼起来。
• 为什么：feature 是"一组协同 task 的最小可验证单元"，在它的边界上做集成， 问题域小、定位快；拖到项目级才集成，等于把所有集成风险堆到最后。

L3 · 全部完成后（全链路 E2E + 跨模块一致性）

• 测什么：跨 feature 的端到端用户旅程 + 跨模块数据/状态一致性。
• 关键心态：L3 是"补网"，不是"首次发现 bug"的地方。如果一个本该在 L1/L2 抓住的缺陷 到 L3 才暴露，那是 L1/L2 漏了，应回填到对应层级，而不是把 L3 当成兜底垃圾桶。
• 为什么：E2E 慢且脆，只适合验证"整条链路确实通"这一件 L1/L2 无法覆盖的事； 把单元级断言塞进 E2E 会让套件又慢又难维护。

三层不是先后审批关卡，而是缺陷应在哪一层被最便宜地抓住的指南。越靠左越便宜。

四、闭环补测法（缺口 → 固化为回归）

完整流程与判定见 references/closed-loop-backfill.md。这里给骨架。

体系化测试不止"补一次测"，而是一个闭环循环，确保每个被发现的缺口都变成长期防回归的资产：

检测缺口 → 生成测试（复现缺口，先红）→ 跑 → 修产品码到绿 → 固化为回归测试（进常驻套件）

补测前先对每个候选缺口分类，避免做无用功：

• ✅ 已被开发期 TDD/契约覆盖 → 跳过。这条行为在 L1 已有红绿历史，重复补测是浪费。
• 🔧 结构性缺口 → 待闭环补。从未被任何层测到的真实风险（典型：跨模块边界、 错误路径、并发/幂等、权限越界），这才是闭环补测要吃的目标。

"固化为回归"是闭环的收尾，也是它和"临时跑一次测试"的本质区别：补出来的测试必须并入常驻套件， 否则同一个 bug 会再回来。

五、发布 go/no-go 门（机械门禁）

完整门项清单见 references/release-gate.md。这里给骨架与边界。

合并/发布前必须满足的机械判据（任一不满足 = no-go）：

1. 测试全绿：相关层级（至少 P0/P1 对应测试）全部通过，无 skip 掩盖、无 flaky 放行。
2. 无孤儿需求：可追溯校验通过——每条 AC 都有测试引用（见 §二）。
3. 无破坏性契约变更：对外契约若变更，必须是兼容变更，或已显式声明并被消费方确认。

关于"机械"二字的边界（必须明确）：本蓝本只给放行标准，不替你强制执行。 门的真正强制必须落到 CI 流水线 / git hook / pre-commit 等自动化设施上—— 由它们在合并前自动跑这些判据并卡住不达标的变更。本 skill 是"标准的来源"，不是"门本身"。 把强制写进自动化，才能让门不依赖人的自觉。

六、stack-agnostic 工具映射原则

完整多栈对照表见 references/capability-tool-mapping.md。这里给原则。

蓝本里出现的一切都是能力（capability）——通用原语，如"单元断言""HTTP 契约""真库集成""E2E 驱动"。 工具（tool）是能力在某个栈里的实例，由调用方读完项目实际技术栈后选定。

原则：先确定需要哪个能力，再把能力实例化为该栈的工具；蓝本永远停在能力层，不锁工具。

示意（仅说明"同一能力在不同栈有不同实例"，不构成推荐、不锁定）：

表里故意不写死库名——具体到哪个库，由 test-routing-advisor 或类别 skill 读项目栈后实例化。

怎么用本蓝本（给遵循它的 skill）

1. 路由器（test-routing-advisor）：用 §一 给任务定级、用 §三 决定落到哪一层、用 §六 把能力交给对应栈的类别 skill。
2. 类别 skill（如 backend-testing）：在自己负责的栈里，把 §六 的能力实例化为具体工具， 按 §二 维护可追溯，按 §四 做闭环补测，最终对齐 §五 的发布门。
3. 任何"自动生成/自动修复测试"的动作，先读 references/self-heal-guardrails.md 的 5 条护栏。