test-coverage

测试覆盖率

每次针对一个功能、规范、模块、PR 或工单的测试创建工作流。 在功能实现后（或与实现同步进行、或 PR 完成后）使用，以确定需要测试什么、选择合适的测试策略、推动测试编写者编写全面的测试、运行测试并记录结果。

它通过测试编写者产出人类可读的 Markdown（test-spec.md、test-report.md）和测试代码。报告记录事实——测试了什么、采用了什么测试类型、哪些测试通过——而不是评定置信度。

本技能负责的内容

• specs/<feature>/test-spec.md——持久的“测试什么”约定：行为、不变量、风险及各项声明的优先级。
• specs/<feature>/test-report.md——会话记录：测试了什么、采用了什么测试类型、运行了什么，以及哪些通过、失败或受阻。
• 仓库根目录的 TESTING.md（可选）——项目测试策略说明（首选测试方式、按优先级划分的门槛／策略、上下文标签）。可独立使用：缺少此文件时会采用内置默认值。

两个层面

1. 测试什么——必须验证的行为、属性、要求和不变量，以确保功能可信；每项都带有声明的优先级（P0–P3）。
2. 如何测试——用于验证它们的证据：单元、契约、集成、端到端、Agent、手动、遥测、静态、冒烟、脚本。

全面测试不等于测试数量。应优化每单位成本（编写 + 运行 + 维护）所能获得的合理置信度，并兼顾稳定性、延迟和诊断价值。以最低成本获得足够的置信度，并将稀缺且昂贵的测试预算（端到端、Agent）用于优先级最高的项目。

优先级是声明的事实

每个“测试什么”项目都带有一个 priority（P0–P3），取自上游开发工件——PRD、功能拆解或规范，而不是在此处臆造。优先级是投入力度的调节杆：P0 采用最严格的策略，P3 采用最轻量的策略。每项行为的优先级默认为功能声明的 P 级；只有规范或负责人声明了更细的级别时，才在 test-spec.md 中记录该级别。如果上游没有声明优先级，则标记为 UNKNOWN 并告知负责人，不要猜测——猜出来的优先级不是事实。

没有单独的 1–5 风险权重。优先级是唯一受治理的重要性信号。

测试类型是事实，并在此处记录

创建或识别测试时，其类型（unit、contract、integration、e2e、agent、manual、telemetry、static、smoke、script）是关于该工件的事实——产出该工件的测试编写者决定其类型。按行为在 test-report.md 中记录类型。不要编写强度标签（depth、reliability），也不要给出 HIGH/MEDIUM/LOW 评级——报告记录事实（优先级、测试类型、运行结果），而不是评定置信度。

测试策略与预算政策

为每项行为确定策略，按以下顺序匹配，命中即止：

1. test-spec.md 中针对单项行为的说明（单次调整）。
2. 仓库根目录的 TESTING.md（若存在；项目级策略说明）。
3. assets/default-testing-strategy.md 中的内置默认策略。

默认策略包含测试方式的成本分析、决策原则、三项防护原则（能力优先于成本；优先级下限／预算上限；纵深防御）以及不可协商的底线（核心／已更改逻辑的单元测试覆盖；每项 P0 检查至少有一道门禁）。可独立使用：绝不要求必须有 TESTING.md；缺少时回退到内置默认策略。

TESTING.md 是供 Agent 阅读的说明文本——不是采用 schema 的配置文件，也不会被 Quality Center 评分读取（评分保持透明）。它用于在各个功能之间统一项目级策略；由于更改 TESTING.md 会影响所有功能的策略，因此应先与用户确认。

能力地图 — 哪种模态能验证哪项检查

能力优先于成本：“最便宜”是指在能够实际验证该检查的模态中最便宜。单元测试无法验证真实浏览器流程。

• 确定性纯逻辑 → 单元测试。
• 公共边界、服务端操作、路由处理器、授权、模式验证 → 契约测试。
• 数据库状态、事务、审计记录、迁移、作业、跨模块不变量 → 集成测试。
• 浏览器渲染行为、路由、受会话／角色限制的 UI、渲染回归 → 项目标准的端到端测试、Agent 测试或手动浏览器检查。
• 第三方回调、仅限预发布环境的身份验证、生产 SLO、实时信号 → Agent 测试、手动检查或遥测。

专项测试编写

此技能负责确定策略并推动测试创建；实际编写工作委托给测试产出技能和项目工作流，然后记录已创建的内容。

• create-yaml-tests：确定性的 Shiplight YAML 端到端测试（Playwright + Agent 式 SDK）。
• create-agent-tests：由编码 Agent 驱动的 Markdown 用例，用于验证实时环境（浏览器、API、数据库、日志、云、遥测）。
• 其他类型使用项目自身的单元、契约、集成、浏览器、移动端、负载、迁移或遥测工作流。

对于与代码关联的测试（单元、契约、集成、API），请内联编写，或引导基础编码 Agent 针对优先级最高的缺口编写深入且覆盖率高的测试。修改范围应限于测试、夹具、测试脚本，以及测试所需的最少辅助代码。

当 Agent 测试生成报告时，请在 test-report.md 中记录其 PASS／FAIL／BLOCKED／ ABORTED 状态，以及可审计的产物（HTML 报告、截图、视频、追踪记录、日志）。仅有文字描述的浏览器检查结论并不足够；浏览器驱动的用例必须提供可审计的产物。将 ABORTED 视为编排中断，需要重新运行，而不是产品证据。

工作流

1. 确定目标和输入

• 确定功能目标（NNN-kebab-case slug；如果已有 specs/NNN-* slug，则沿用）。
• 阅读 PRD／功能拆解／规格说明，了解声明的优先级。
• 阅读已更改的实现和现有测试（如有，使用分支合并基点）。
• 查找之前的 specs/<feature>/test-spec.md 和 test-report.md（如存在）。

2. 定义或刷新测试内容

根据 assets/test-spec-template.md 编写 specs/<feature>/test-spec.md。 记录产品行为、系统／API／模式／数据不变量、基于风险的行为、运维／发布行为，以及利益相关方的信心目标。 如实保留每项行为声明的 priority。明确列出范围外的行为。

3. 确定策略并盘点现有证据

按照策略链确定每项行为的测试立场。盘点现有内容（单元、契约、集成、端到端、Agent、手动、遥测、静态分析、CI）及其覆盖的行为。

4. 分析缺口并选择验证方式

将每个缺口量化为要求的测试立场减去现有证据。选择能够弥补缺口的最便宜模态。将高成本测试预算用于优先级最高的缺口；同时考虑信心增益、易波动风险、运行时长、夹具复杂度、清理工作、诊断价值和维护成本。对于 P0 行为，考虑采用多层防御，而非仅使用单一的最低成本验证方式。

5. 推动创建

推动产出方完成测试（或内联编写与代码关联的测试），无论预算如何都要遵守不可妥协的最低要求。只有在能够实质性提升信心时才添加测试；不要为了凑数而添加脆弱的测试。如果预算迫使某项行为未能达到理想的验证标准，请记录所选的资源分配以及明确接受的缺口——绝不能默默地进行不足测试。

6. 运行验证

先运行针对性检查，只有在确有必要时再运行更全面的测试套件：新增或修改的测试、相关的现有测试、类型检查／lint／构建、迁移检查，以及规范要求的 Agent 检查。记录执行的确切命令和结果。如果缺少某项能力，将其标记为 BLOCKED 或 NOT MEASURED；绝不能声称已通过。

7. 编写或更新测试报告

使用 assets/test-report-template.md 编写 specs/<feature>/test-report.md。记录运行的命令、新增或更新的测试，以及覆盖矩阵——每种行为占一行，注明其优先级、为其编写的测试类型和本次会话的结果。将阻塞性发现放在最前面。不要撰写信心结论或任何强度标签。

产物骨架

产物	模板
specs/<feature>/test-spec.md	assets/test-spec-template.md
specs/<feature>/test-report.md	assets/test-report-template.md
仓库根目录中的 TESTING.md（可选）	assets/TESTING.template.md

状态词汇（测试类型、结果状态、覆盖状态）位于 references/vocabularies.md。

操作规则

• 可以编辑测试、测试夹具、测试脚本、specs/<feature>/test-spec.md、specs/<feature>/test-report.md，以及仓库根目录中的 TESTING.md（只有在用户确认后才可编辑，因为调整测试方针会影响每项功能）。
• 绝不撰写 depth、reliability、1–5 的风险权重，或 HIGH/MEDIUM/LOW 信心结论。只记录事实（优先级、测试类型、运行结果）。
• 避免进行无关的重构和无关的生产代码更改。
• 绝不要在规范、报告、日志或产物中包含机密、Cookie、令牌、数据库 URL 或客户隐私数据。
• 没有命令输出或可审计产物时，绝不要报告通过或失败。
• 保持独立运行安全：绝不要要求必须存在 TESTING.md；若其不存在，则使用内置默认设置。

何时不应使用

• 用户需要项目编排、PRD 或功能拆解时：这些属于项目级工作，不在此技能范围内。
• 用户只需要代码审查，不需要创建测试时：使用 review。
• 尚无实现，且用户只需要规划时。