test-coverage

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Test Coverage

测试覆盖

Test-creation workflow for one feature, spec, module, PR, or ticket at a time. Use after a feature is implemented (or alongside it, or after a PR) to decide what needs testing, choose the right testing strategy, drive the producers to write comprehensive tests, run them, and record the result.

It produces human-readable Markdown (

test-spec.md

test-report.md

) and test code via the producers. The report records facts — what was tested, by what test type, and what passed — not a graded confidence verdict.

一次针对单个功能、规格、模块、PR或工单的测试用例创建工作流。适用于功能实现完成后（或与实现同步，或PR提交后），用于确定需要测试的内容、选择合适的测试策略、推动生成者编写全面的测试用例、执行测试并记录结果。

它通过生成者生成人类可读的Markdown文件（

test-spec.md

、

test-report.md

）和测试代码。报告仅记录事实——包括测试内容、测试类型以及通过情况——而非分级的可信度结论。

What This Skill Owns

该技能负责的内容

```
specs/<feature>/test-spec.md
```
— the durable "testing what" contract: the behaviors, invariants, risks, and the declared priority of each.
```
specs/<feature>/test-report.md
```
— the session record: what was tested, by what test type, what ran, and what passed, failed, or was blocked.
Repo-root
```
TESTING.md
```
(optional) — project testing-strategy notes (preferred modalities, gate/posture by priority, context labels). Standalone-safe: a baked-in default applies when absent.

```
specs/<feature>/test-spec.md
```
— 持久化的“测试内容”约定：包含各项行为、不变量、风险以及各自声明的优先级。
```
specs/<feature>/test-report.md
```
— 测试会话记录：包括测试内容、测试类型、执行的测试以及通过、失败或阻塞的情况。
仓库根目录下的
```
TESTING.md
```
（可选）—— 项目测试策略说明（首选测试方式、按优先级划分的准入/测试姿态、上下文标签）。独立可用：当该文件不存在时，将使用内置的默认策略。

Two Layers

两个层面

Testing what — the behaviors, properties, requirements, and invariants that must be verified to trust the feature, each carrying a declared priority (P0–P3).
Testing how — the evidence used to verify them: unit, contract, integration, e2e, agent, manual, telemetry, static, smoke, script.

Comprehensive testing is not test count. Optimize for justified confidence per unit of cost (author + run + maintain), stability, latency, and diagnostic value. Buy sufficient confidence at the lowest cost, spending the scarce expensive-test budget (e2e, agent) where priority is highest.

测试内容 — 为确保功能可信必须验证的行为、属性、需求和不变量，每项都带有声明的优先级（P0–P3）。
测试方式 — 用于验证的证据类型：unit、contract、integration、e2e、agent、manual、telemetry、static、smoke、script。

全面测试并非指测试用例的数量。需针对每单位成本（编写+执行+维护）、稳定性、延迟和诊断价值优化可信度。以最低成本获取足够的可信度，将稀缺的高成本测试预算（e2e、agent）投入到优先级最高的内容上。

Priority Is A Declared Fact

优先级是已声明的事实

Each testing-what item carries a

priority

(P0–P3) read from an upstream dev artifact — the PRD, the feature breakdown, or the spec — never invented here. Priority is the effort lever: P0 gets the strongest posture, P3 the lightest. Per-behavior priority defaults to the feature's declared P-level; record a finer level in

test-spec.md

only when the spec or owner declares one. If nothing upstream declares a priority, mark it

UNKNOWN

and surface it for the owner rather than guessing — a guessed priority is not a fact.

There is no separate 1–5 risk weight. Priority is the single governed importance signal.

每个测试内容项的

priority

（P0–P3）均来自上游开发工件——PRD、功能分解文档或规格说明——绝不会在此处凭空设定。优先级是投入力度的杠杆：P0采用最强测试姿态，P3采用最轻测试姿态。每个行为的优先级默认继承功能声明的P级别；仅当规格说明或所有者明确声明更细粒度的优先级时，才在

test-spec.md

中记录。如果上游未声明任何优先级，则标记为

UNKNOWN

并告知所有者，而非自行猜测——猜测的优先级并非事实。

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

Test Type Is A Fact, Recorded Here

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

When you create or identify a test, its type (

unit

contract

integration

e2e

agent

manual

telemetry

static

smoke

script

) is a fact about the artifact — the producer that makes it fixes the type. Record the type per behavior in

test-report.md

. Do not author a strength label (

depth

reliability

) or a

HIGH/MEDIUM/LOW

verdict — the report records facts (priority, test type, run result), not a graded confidence verdict.

当你创建或识别一个测试用例时，其类型（

unit

、

contract

、

integration

、

e2e

、

agent

、

manual

、

telemetry

、

static

、

smoke

、

script

）是该工件的固有属性——生成该测试用例的工具会确定其类型。需在

test-report.md

中按行为记录测试类型。请勿添加强度标签（

depth

、

reliability

）或

HIGH/MEDIUM/LOW

结论——报告仅记录事实（优先级、测试类型、执行结果），而非分级的可信度结论。

Testing Strategy And Budget Policy

测试策略与预算规则

Resolve the strategy posture for each behavior, first match wins:

A per-behavior note in
```
test-spec.md
```
(one-off tuning).
Repo-root
```
TESTING.md
```
, if present (project-wide posture notes).
The baked-in default in
```
assets/default-testing-strategy.md
```
.

The default holds the modality economics, the decision principle, the three guardrails (capability-before-cost; priority-floor / budget-ceiling; defense-in-depth), and the non-negotiable floors (unit coverage on core/changed logic; at least one gate on every P0 check). Standalone-safe: never require

TESTING.md

; fall back to the baked-in default when absent.

TESTING.md

is prose guidance the agent reads — not a schema'd config, and not read by Quality Center scoring (scoring stays transparent). It exists to apply consistent project-wide posture across features; confirm a

TESTING.md

change with the user since it shifts every feature's posture.

按以下优先级确定每个行为的测试策略姿态，匹配到第一条即生效：

```
test-spec.md
```
中针对单个行为的说明（一次性调整）。
仓库根目录下的
```
TESTING.md
```
（若存在）—— 项目级测试姿态说明。
```
assets/default-testing-strategy.md
```
中的内置默认策略。

默认策略包含测试方式成本分析、决策原则、三项管控规则（能力优先于成本；优先级下限/预算上限；纵深防御），以及不可协商的最低要求（核心/变更逻辑的unit覆盖；每个P0检查至少有一个准入关卡）。独立可用：绝不强制要求

TESTING.md

；当该文件不存在时，自动回退到内置默认策略。

TESTING.md

是供Agent读取的说明性文档——并非结构化配置文件，也不会被质量中心评分系统读取（评分保持透明）。它的作用是在所有功能中应用一致的项目级测试姿态；修改

TESTING.md

需与用户确认，因为这会改变所有功能的测试姿态。

Capability Map — Which Modality Proves Which Check

能力映射——哪种方式可验证哪种检查

Capability before cost: "cheapest" means cheapest among modalities that can actually prove the check. A unit test cannot prove a real-browser flow.

Deterministic pure logic → unit tests.
Public boundaries, server actions, route handlers, authz, schema validation → contract tests.
DB state, transactions, audit rows, migrations, jobs, cross-module invariants → integration tests.
Browser-rendered behavior, routing, session/role-gated UI, rendered regressions → project-standard e2e, agent, or manual browser checks.
Third-party callbacks, staging-only auth, production SLOs, live signals → agent tests, manual checks, or telemetry.

能力优先于成本：“成本最低”指的是在能够实际验证该检查项的测试方式中选择成本最低的。unit测试无法验证真实浏览器流程。

确定性纯逻辑 → unit测试。
公共边界、服务器操作、路由处理器、授权（authz）、schema验证 → contract测试。
数据库状态、事务、审计记录、迁移、任务、跨模块不变量 → integration测试。
浏览器渲染行为、路由、会话/角色权限控制的UI、渲染回归 → 项目标准的e2e、agent或手动浏览器检查。
第三方回调、仅预发布环境可用的授权、生产环境SLO、实时信号 → agent测试、手动检查或telemetry。

Specialized Test Authoring

专项测试用例编写

This skill decides strategy and drives creation; it delegates the actual authoring to the producer skills and project workflows, then records what was made.

```
create-yaml-tests
```
: deterministic Shiplight YAML E2E tests (Playwright + agentic SDK).
```
create-agent-tests
```
: coding-agent-driven Markdown cases for live-environment verification (browser, API, DB, logs, cloud, telemetry).
The project's own unit, contract, integration, browser, mobile, load, migration, or telemetry workflow for other kinds.

For code-tied tests (unit, contract, integration, api), author them inline or drive the base coding agent toward deep, high-coverage tests on the highest-priority gaps. Keep edits scoped to tests, fixtures, test scripts, and the minimal support code needed for testability.

When an agent test produces a report, record its

PASS

FAIL

BLOCKED

ABORTED

status and auditable artifacts (HTML reports, screenshots, videos, traces, logs) in

test-report.md

. Text-only browser claims are not sufficient; require an auditable artifact for browser-driven cases. Treat

ABORTED

as an orchestration interruption to rerun, not as product evidence.

该技能负责制定策略并推动测试用例创建；实际编写工作将委托给生成者技能和项目工作流，之后记录生成的内容。

```
create-yaml-tests
```
：确定性的Shiplight YAML E2E测试（基于Playwright + agentic SDK）。
```
create-agent-tests
```
：由编码Agent驱动的Markdown测试用例，用于实时环境验证（浏览器、API、数据库、日志、云服务、telemetry）。
项目自身的unit、contract、integration、浏览器、移动端、负载、迁移或telemetry工作流，用于其他类型的测试。

对于与代码绑定的测试（unit、contract、integration、api），可内联编写，或驱动基础编码Agent针对最高优先级的测试缺口编写深度、高覆盖率的测试用例。编辑范围仅限测试用例、测试夹具、测试脚本以及为可测试性所需的最小支持代码。

当Agent测试生成报告时，需在

test-report.md

中记录其

PASS

FAIL

BLOCKED

ABORTED

状态以及可审计的工件（HTML报告、截图、视频、追踪日志、日志文件）。仅文字描述的浏览器测试结果不足够；浏览器驱动的测试用例必须提供可审计的工件。将

ABORTED

视为编排中断，需重新执行，而非产品证据。

Workflow

工作流

1. Resolve Target And Inputs

1. 确定目标与输入

Identify the feature target (a
```
NNN-kebab-case
```
slug; reuse an existing
```
specs/NNN-*
```
slug when one exists).
Read the PRD / feature breakdown / spec for declared priorities.
Read changed implementation and existing tests (use the branch merge base when available).

Locate prior

specs/<feature>/test-spec.md

and

test-report.md

if present.

确定功能目标（采用
```
NNN-kebab-case
```
格式的标识；若已有
```
specs/NNN-*
```
标识则复用）。
读取PRD/功能分解文档/规格说明中的已声明优先级。
读取变更的实现代码和现有测试用例（若可用，使用分支合并基准版本）。

查找已有的

specs/<feature>/test-spec.md

和

test-report.md

（若存在）。

2. Define Or Refresh Testing What

2. 定义或更新测试内容

Write

specs/<feature>/test-spec.md

from

assets/test-spec-template.md

. Capture product behaviors, system/API/schema/data invariants, risk-based behaviors, operational/release behaviors, and stakeholder confidence goals. Carry each behavior's declared

priority

as a fact. List out-of-scope behaviors explicitly.

基于

assets/test-spec-template.md

编写

specs/<feature>/test-spec.md

。记录产品行为、系统/API/schema/数据不变量、基于风险的行为、运维/发布行为以及相关方的可信度目标。如实记录每个行为的已声明

priority

。明确列出超出范围的行为。

3. Resolve Strategy And Inventory Existing Evidence

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

Resolve each behavior's posture via the policy chain. Inventory what already exists (unit, contract, integration, e2e, agent, manual, telemetry, static, CI) and which behaviors it covers.

通过策略链确定每个行为的测试姿态。盘点现有测试用例（unit、contract、integration、e2e、agent、manual、telemetry、static、CI）及其覆盖的行为。

4. Analyze Gaps And Select Proofs

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

Size each gap as required posture minus existing evidence. Choose the cheapest modality capable of closing it. Spend the expensive-test budget on the highest-priority gaps; consider confidence gained, flake risk, runtime, fixture complexity, cleanup, diagnostic value, and maintenance. For P0 behaviors, consider defense-in-depth (stacked layers) over a single cheapest proof.

将每个测试缺口定义为所需测试姿态减去现有证据。选择能够填补该缺口的成本最低的测试方式。将高成本测试预算投入到最高优先级的缺口；需考量获得的可信度、不稳定风险、运行时间、夹具复杂度、清理工作、诊断价值和维护成本。对于P0行为，考虑采用纵深防御（多层测试）而非单一的最低成本验证方式。

5. Drive Creation

5. 推动测试用例创建

Drive the producers (or author code-tied tests inline) to close worthwhile gaps, honoring the non-negotiable floors regardless of budget. Add tests only when they materially raise confidence; do not add brittle tests to inflate count. When budget forces a behavior to stop short of its ideal proof, record the chosen allocation and the knowingly accepted gap — never under-test silently.

推动生成者（或内联编写与代码绑定的测试用例）填补有价值的缺口，无论预算如何，都需遵守不可协商的最低要求。仅当测试用例能切实提升可信度时才添加；请勿添加不稳定的测试用例来凑数。当预算限制导致无法采用理想的验证方式时，需记录所选的分配方案以及明确接受的缺口——绝不能悄悄降低测试标准。

6. Run Verification

6. 执行验证

Run targeted checks first, then broader suites when justified: new/changed tests, relevant existing tests, typecheck/lint/build, migration checks, and agent checks required by the spec. Record exact commands and outcomes. If a capability is missing, mark it

BLOCKED

NOT MEASURED

; never claim it passed.

先执行针对性检查，在合理情况下再执行更全面的测试套件：新增/变更的测试用例、相关的现有测试用例、类型检查/代码扫描/构建、迁移检查以及规格说明要求的Agent检查。记录确切的命令和结果。若缺少相关能力，标记为

BLOCKED

或

NOT MEASURED

；绝不能声称测试通过。

7. Write Or Update Test Report

7. 编写或更新测试报告

Write

specs/<feature>/test-report.md

from

assets/test-report-template.md

. Record commands run, tests added/updated, and the coverage matrix — one row per behavior with its priority, the test type written for it, and the session result. Put blocking findings first. Do not author a confidence verdict or any strength label.

基于

assets/test-report-template.md

编写

specs/<feature>/test-report.md

。记录执行的命令、新增/更新的测试用例以及覆盖矩阵——每行对应一个行为，包含其优先级、为其编写的测试类型以及会话结果。将阻塞性发现放在最前面。请勿添加可信度结论或任何强度标签。

Artifact Skeletons

工件框架

Artifact	Template
`specs/<feature>/test-spec.md`	`assets/test-spec-template.md`
`specs/<feature>/test-report.md`	`assets/test-report-template.md`
repo-root `TESTING.md` (optional)	`assets/TESTING.template.md`

Status vocabularies (test type, result status, coverage status) live in

references/vocabularies.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

中。

Operating Rules

操作规则

May edit tests, test fixtures, test scripts,
```
specs/<feature>/test-spec.md
```
,
```
specs/<feature>/test-report.md
```
, and repo-root
```
TESTING.md
```
(only with user confirmation, since posture changes affect every feature).
Never author
```
depth
```
,
```
reliability
```
, a 1–5 risk weight, or a
```
HIGH/MEDIUM/LOW
```
confidence verdict. Record facts (priority, test type, run result) only.
Avoid unrelated refactors and unrelated production-code changes.
Never include secrets, cookies, tokens, database URLs, or private customer data in specs, reports, logs, or artifacts.
Never report pass/fail without command output or an auditable artifact.
Stay standalone-safe: never require
```
TESTING.md
```
; fall back to the baked-in default when absent.

可编辑测试用例、测试夹具、测试脚本、
```
specs/<feature>/test-spec.md
```
、
```
specs/<feature>/test-report.md
```
以及仓库根目录下的
```
TESTING.md
```
（仅在获得用户确认后可修改
```
TESTING.md
```
，因为测试姿态变更会影响所有功能）。
绝不添加
```
depth
```
、
```
reliability
```
、1–5风险权重或
```
HIGH/MEDIUM/LOW
```
可信度结论。仅记录事实（优先级、测试类型、执行结果）。
避免无关的重构和无关的生产代码变更。
绝不在规格说明、报告、日志或工件中包含密钥、Cookie、令牌、数据库URL或客户隐私数据。
若无命令输出或可审计工件，绝不能报告测试通过/失败。
保持独立可用：绝不强制要求
```
TESTING.md
```
；当该文件不存在时，自动回退到内置默认策略。

When Not To Use

不适用场景

When the user wants project orchestration, a PRD, or a feature breakdown: that is project-level work outside this skill's scope.
When the user only wants a code review with no test creation: use
```
review
```
.
When implementation does not exist and the user only wants planning.

当用户需要项目编排、PRD或功能分解文档时：这些属于项目级工作，超出本技能的范围。
当用户仅需要代码评审而无需创建测试用例时：使用
```
review
```
技能。
当功能尚未实现且用户仅需要规划时。