review-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Software Testing Fitness Review

软件测试健康度评审

Analyze the codebase (or specified files/modules) for software testing fitness. Evaluate test quality, coverage strategy, pyramid balance, and testing infrastructure using evidence from test files, the code they test, CI configuration, and production support tooling.

Reference: Fundamentals of Software Testing — see also Fundamentals of Software Quality Assurance and Fundamentals

分析代码库（或指定的文件/模块）的软件测试健康度。评估测试质量、覆盖策略、金字塔平衡度以及测试基础设施，并依据测试文件、被测代码、CI 配置和生产支持工具中的证据作出判断。

参考：软件测试基础——另见软件质量保证基础和基础。

Domain Knowledge

领域知识

```
references/rubric.md
```
is the scoring source: severity table, 1-10 anchors per dimension, N/A rules, how to cite an absence, and the overall-score formula. Read it first; it is short. Scores are only repeatable if every run uses the same anchors.
```
references/checklist.md
```
is what to check during the workflow steps. Its section 6 (QA Process) has no dimension of its own: its feedback-loop checks score under CI Integration and its regression and definition-of-done checks under Coverage Strategy.
```
references/wisdom.md
```
is optional background, generated from the two Fundamentals articles. It has no rubrics. Grep it by heading for a specific question (for example
```
grep -n '^### ' references/wisdom.md
```
); never read it whole.

```
references/rubric.md
```
是评分依据：包含严重度表、每个维度 1-10 分的锚点、N/A 规则、缺失项的引用方式以及总分公式。首先阅读它；文件很短。只有每次运行都使用相同的锚点，评分才具有可重复性。
```
references/checklist.md
```
是工作流各步骤的检查清单。其第 6 节（QA Process）没有独立维度：反馈循环检查归入 CI Integration，回归测试和完成定义检查归入 Coverage Strategy。
```
references/wisdom.md
```
是可选背景资料，由上述两篇“基础”文章生成。它不包含评分规则。按标题 grep 以查找特定问题（例如
```
grep -n '^### ' references/wisdom.md
```
）；绝不要整份读取。

Configuration

配置

Invoke the resolver CLI to obtain effective weights and thresholds for the review target. Never load

fitness-config.json

directly.

bash

python3 "${CLAUDE_SKILL_DIR}/../../scripts/fitness-config.py" show --path <target>

${CLAUDE_SKILL_DIR}

is this skill's directory; the resolver ships two levels up in the plugin's

scripts/

. If your agent does not expand the variable, substitute the directory containing this

SKILL.md

Where

<target>

is the file or directory under review. The CLI walks up to discover any module override and merges it with the root config. Include the

Config:

and

Effective weights:

lines from the resolver output within the first 10 lines of the final report as the provenance trail (AC-03.1, AC-08.2). The

effective

object inside the JSON block delimited by

<!-- BEGIN_EFFECTIVE_CONFIG_JSON -->

<!-- END_EFFECTIVE_CONFIG_JSON -->

carries weights, status thresholds, security, and scoring for any programmatic needs.

调用 resolver CLI 获取审查目标的有效权重和阈值。绝不直接加载

fitness-config.json

。

bash

python3 "${CLAUDE_SKILL_DIR}/../../scripts/fitness-config.py" show --path <target>

${CLAUDE_SKILL_DIR}

是此 skill 的目录；resolver 位于插件的

scripts/

中，向上两级。如果你的 Agent 不展开该变量，请替换为包含此

SKILL.md

的目录。

其中，

<target>

是受审查的文件或目录。CLI 会向上遍历以发现模块级覆盖配置，并将其与根配置合并。将 resolver 输出中的

Config:

和

Effective weights:

两行包含在最终报告的前 10 行内，作为来源追踪记录（AC-03.1、AC-08.2）。由

<!-- BEGIN_EFFECTIVE_CONFIG_JSON -->

<!-- END_EFFECTIVE_CONFIG_JSON -->

界定的 JSON 代码块内，

effective

对象包含权重、状态阈值、安全性设置和评分信息，可用于需要程序化处理的场景。

Workflow

工作流

Load the rubric — Read
```
references/rubric.md
```
, then skim
```
references/checklist.md
```
. Run the resolver and keep its
```
Config:
```
and
```
Effective weights:
```
lines.
Scope and inventory — Decide the target and identify what kind of project it is (service, library, CLI, script collection, polyglot). Find, per language:
- Test files and runners:
```
*_test.go
```
  (go test),
```
test/*.exs
```
  +
```
mix.exs
```
  (ExUnit),
```
*Tests.csproj
```
  /
```
[Fact]
```
  /
```
[Test]
```
  (xUnit/NUnit, dotnet test),
```
test_*.py
```
  /
```
pytest.ini
```
  /
```
pyproject.toml
```
  (pytest),
```
*.test.ts
```
  /
```
jest.config
```
  /
```
vitest.config
```
  /
```
.mocharc
```
  ,
```
phpunit.xml
```
  ,
```
*.feature
```
  (BDD), shell test harnesses.
- CI:
```
.github/workflows/
```
  ,
```
.gitlab-ci.yml
```
  ,
```
Jenkinsfile
```
  ,
```
.circleci/
```
  ; pre-commit hooks; coverage config.
- The source under test: the main modules each test file should cover.
Skip build and data artifacts:
```
_build/
```
,
```
deps/
```
,
```
bin/
```
,
```
obj/
```
,
```
target/
```
,
```
node_modules/
```
,
```
.venv/
```
,
```
dist/
```
, generated code, and large data or output files (anything over ~1 MB,
```
*.txt
```
dumps, fixtures you do not need to read). They are not tests even when "test" appears in the path, and reading them wastes the budget.
Decide applicability — Using the inventory and the N/A rules in
```
rubric.md
```
, decide which of the six dimensions apply. Mark the rest
```
N/A — <reason>
```
now so later steps do not invent evidence for them. A missing practice is a low score, not N/A.
Map the test pyramid — Count tests with the native collector, because file counts miss parametrized cases and multi-test files:
- Python:
```
pytest --collect-only -q
```
  (last line gives the total; add
```
-m <marker>
```
  or a path to split levels)
- Go:
```
go test -list . ./...
```
- Elixir:
```
mix test --trace
```
  (or count
```
test "
```
  blocks if deps cannot be fetched)
- .NET:
```
dotnet test --list-tests
```
- JS/TS:
```
npx jest --listTests
```
  /
```
npx vitest list
```
  ; otherwise count
```
it(
```
  /
```
test(
```
  calls
Run collectors read-only and offline where possible. If a collector cannot run (missing toolchain, no network), count by grep and say so in the evidence. Classify counts into unit, integration, and E2E/acceptance, and record the suite's run time if you ran it.
Evaluate test quality — Read a representative sample at each level against checklist section 2.
Assess coverage against the code — Read the source under test, not only the tests. List the core functions and which have tests. When you read untested code, note concrete defects or risky branches you can see (an empty result when a regex has no capture group, an unchecked error return, an off-by-one). Remediations must name these functions and behaviors, so the user gets "add a test for
```
parseArgs
```
rejecting a missing path" rather than "add more tests". Check git history for bug-fix commits without regression tests when
```
.git
```
is available.
Review performance testing — If applicable, search for load and benchmark tooling (k6, JMeter, Gatling, Locust, Artillery,
```
go test -bench
```
,
```
pytest-benchmark
```
, BenchmarkDotNet, Benchee) and stated performance requirements.
Inspect debugging support — Use the service or CLI/library criteria in
```
rubric.md
```
that fit the project type.
Audit CI test integration — Read CI files to confirm tests run on pull requests, with timeouts, and that every test suite found in step 2 is wired in. Apply checklist sections 6 and 7.
Score — Score each applicable dimension against the
```
rubric.md
```
anchors with file:line evidence (or an absence citation in the rubric's format). Compute the overall per the rubric.
Self-check, then write the report — Before writing, confirm:
- every cited file:line uses a repo-relative path (not a bare filename), exists, and says what the finding claims;
- every finding has confidence >= 7;
- the overall equals the mean of the scored dimensions (and the CRITICAL cap, if any);
- no secret values are reproduced; refer to secrets by file:line only.

加载评分标准——阅读
```
references/rubric.md
```
，然后浏览
```
references/checklist.md
```
。运行 resolver，并保留其
```
Config:
```
和
```
Effective weights:
```
两行。
确定范围并盘点——确定审查目标，并识别项目类型（service、library、CLI、脚本集合或多语言项目）。按语言查找：
- 测试文件和运行器：
```
*_test.go
```
  （go test）、
```
test/*.exs
```
  +
```
mix.exs
```
  （ExUnit）、
```
*Tests.csproj
```
  /
```
[Fact]
```
  /
```
[Test]
```
  （xUnit/NUnit、dotnet test）、
```
test_*.py
```
  /
```
pytest.ini
```
  /
```
pyproject.toml
```
  （pytest）、
```
*.test.ts
```
  /
```
jest.config
```
  /
```
vitest.config
```
  /
```
.mocharc
```
  、
```
phpunit.xml
```
  、
```
*.feature
```
  （BDD）、shell 测试工具。
- CI：
```
.github/workflows/
```
  、
```
.gitlab-ci.yml
```
  、
```
Jenkinsfile
```
  、
```
.circleci/
```
  ；pre-commit hooks；覆盖率配置。
- 被测源代码：每个测试文件应覆盖的主要模块。
跳过构建和数据产物：
```
_build/
```
、
```
deps/
```
、
```
bin/
```
、
```
obj/
```
、
```
target/
```
、
```
node_modules/
```
、
```
.venv/
```
、
```
dist/
```
、生成的代码，以及大型数据或输出文件（任何超过约 1 MB 的文件、
```
*.txt
```
转储和无需读取的 fixture）。即使路径中包含“test”，它们也不是测试；读取这些内容只会浪费预算。
判定适用性——根据盘点结果和
```
rubric.md
```
中的 N/A 规则，判定六个维度分别是否适用。现在就将其余维度标记为
```
N/A — <reason>
```
，避免后续步骤凭空编造证据。缺少某项实践应评为低分，而不是 N/A。
绘制测试金字塔——使用原生收集器进行计数，因为文件数量会遗漏参数化用例以及单个文件中的多个测试：
- Python：
```
pytest --collect-only -q
```
  （最后一行给出总数；可添加
```
-m <marker>
```
  或路径来拆分不同层级）
- Go：
```
go test -list . ./...
```
- Elixir：
```
mix test --trace
```
  （如果无法获取依赖，则统计
```
test "
```
  代码块）
- .NET：
```
dotnet test --list-tests
```
- JS/TS：
```
npx jest --listTests
```
  /
```
npx vitest list
```
  ；否则统计
```
it(
```
  /
```
test(
```
  调用
尽可能以只读、离线方式运行收集器。如果收集器无法运行（缺少工具链或网络不可用），则通过 grep 计数，并在证据中说明。将计数归类为单元、集成和 E2E/验收测试；如果实际运行了测试套件，还应记录其运行时间。
评估测试质量——根据清单第 2 节，阅读每个层级的代表性测试样本。
对照代码评估覆盖率——阅读被测源代码，而不只是测试。列出核心函数以及哪些函数已有测试。阅读未测试代码时，记录能够看到的具体缺陷或高风险分支（regex 没有捕获组时返回空结果、未检查的错误返回值、off-by-one）。整改建议必须明确指出这些函数和行为，使用户看到的应是“add a test for
```
parseArgs
```
rejecting a missing path”，而不是泛泛的“add more tests”。如果
```
.git
```
可用，检查 git 历史中是否存在没有回归测试的 bug-fix 提交。
审查性能测试——如果适用，搜索负载测试和基准测试工具（k6、JMeter、Gatling、Locust、Artillery、
```
go test -bench
```
、
```
pytest-benchmark
```
、BenchmarkDotNet、Benchee）以及明确提出的性能要求。
检查调试支持——使用
```
rubric.md
```
中适合项目类型（service、CLI 或 library）的评判标准。
审计 CI 测试集成——阅读 CI 文件，确认 pull request 会运行测试、设置了超时时间，并且第 2 步发现的每个测试套件都已接入。应用清单第 6 节和第 7 节。
评分——依据
```
rubric.md
```
中的锚点对每个适用维度评分，并提供 file:line 证据（或按 rubric 格式提供缺失项引用）。按照 rubric 计算总分。
自检，然后编写报告——写入前确认：
- 每个引用的 file:line 都使用仓库相对路径（不是单独的文件名）、确实存在，并且内容支持所声明的发现；
- 每项发现的置信度都 >= 7；
- 总分等于已评分维度分数的平均值（并应用 CRITICAL 上限，如果适用）；
- 不复现任何 secret 值；仅通过 file:line 引用 secret。

Confidence and Severity

置信度与严重度

Only report findings with confidence >= 7/10. For each finding, assess:

Is this a real pattern in the code, not a guess about runtime behavior?
Can you point to a specific file and line, or, for an absence, to the place it should be and the search that came up empty?
Is the problematic pattern actually reachable in normal execution?

If any answer is no, do not report it. It is better to miss a theoretical issue than to flood the report with noise.

Severity levels (CRITICAL, HIGH, MEDIUM, LOW) and their testing examples are defined in

references/rubric.md

. Calibrate to the project's purpose: an untested personal CLI is not a CRITICAL risk the way an untested payment path is.

仅报告置信度 >= 7/10 的发现。对于每项发现，评估：

这是代码中真实存在的模式，而不是对运行时行为的猜测吗？
能否指向具体的文件和行；对于缺失项，能否指出它本应出现的位置以及未找到内容的搜索范围？
该问题模式在正常执行过程中是否确实可达？

如果任一答案为否，则不要报告。遗漏一个理论问题，比用报告淹没真正的问题更好。

严重度级别（CRITICAL、HIGH、MEDIUM、LOW）及其测试示例定义在

references/rubric.md

中。应结合项目用途校准：未经测试的个人 CLI 不像未经测试的支付路径那样构成 CRITICAL 风险。

Scoring Dimensions (1-10 each)

评分维度（每项 1-10 分）

Anchors for each band are in

references/rubric.md

Test Pyramid Balance — Ratio of unit to integration to E2E tests, pyramid shape, execution time distribution
Test Quality — Naming conventions, assertion quality, test independence, determinism, behavior vs. implementation verification
Coverage Strategy — Coverage tooling and thresholds, critical path coverage, boundary value testing, regression tests, definition of done
Performance Testing — Load testing tools, performance requirements, benchmarks, regression detection (often N/A for small CLIs and libraries)
Debugging Support — Error context, test failure output, reproduction helpers; structured logging and correlation IDs for services
CI Integration — Automated test execution on PRs, required checks, stage separation, timeouts, flaky test handling, local feedback loops

每个分值区间的锚点见

references/rubric.md

。

测试金字塔平衡度——单元、集成与 E2E 测试的比例，金字塔形态，运行时长分布
测试质量——命名约定、断言质量、测试独立性、确定性，以及针对行为而非实现进行验证
覆盖策略——覆盖率工具和阈值、关键路径覆盖、边界值测试、回归测试、完成定义
性能测试——负载测试工具、性能要求、基准测试、回归检测（对于小型 CLI 和 library 通常为 N/A）
调试支持——错误上下文、测试失败输出、复现辅助工具；service 的结构化日志和关联 ID
CI 集成——在 PR 上自动执行测试、必需检查项、阶段隔离、超时、flaky test 处理、本地反馈循环

Empty or near-empty suites

测试套件为空或接近为空

When a project has no tests or only a scaffold, the report is still useful if it is short and specific:

Say plainly which languages or modules have zero tests and how you checked (collector output or the absence citation).
Score from the low anchors; do not award points for practices that cannot exist yet (for example, Test Quality cannot exceed 2 with no real tests).
Spend the effort on step 6: the action items should be a starter plan naming the first functions to test, the cases each needs, and the one command that will run them, ordered by where a bug would hurt most.

如果项目没有测试或只有脚手架，只要报告简短且具体，仍然具有价值：

明确说明哪些语言或模块的测试数量为零，以及你如何检查的（收集器输出或缺失项引用）。
从低分锚点开始评分；不要为尚不可能存在的实践加分（例如，没有真实测试时，测试质量不能超过 2 分）。
将精力集中在第 6 步：行动项应是一份入门计划，指明最先需要测试的函数、每个函数需要覆盖的用例，以及运行这些测试的一条命令，并按 bug 造成影响的严重程度排序。

Output Format

输出格式

Write the report to

docs/testing-review.md

at the root of the repository that contains the target, unless the user gives a path. For a review scoped to a subdirectory or file set, write

docs/testing-review-<scope-slug>.md

(for example

docs/testing-review-scripts.md

) so a scoped run does not replace the whole-repo report.

markdown

undefined

除非用户指定其他路径，否则将报告写入目标仓库根目录的

docs/testing-review.md

。对于范围限定为子目录或文件集的审查，写入

docs/testing-review-<scope-slug>.md

（例如

docs/testing-review-scripts.md

），避免局部审查覆盖全仓库报告。

markdown

undefined

Software Testing Fitness Report

Target: <path(s) or scope reviewed; project type> Config: <copied from resolver output> Effective weights: <copied from resolver output>

Direct Answer

(Only when the user asked a specific question. Answer it in 2-4 sentences before the scores.)

Summary

Overall fitness score: X.X / 10 — <status band> (mean of <list of scored dimensions>; <CRITICAL cap applied / not applied>)

Dimension	Score	Key Finding
Test Pyramid Balance	X/10	...
Test Quality	X/10	...
Coverage Strategy	X/10	...
Performance Testing	X/10 or N/A — reason	...
Debugging Support	X/10	...
CI Integration	X/10	...

Test inventory: <counts per level and per language, and the command used for each>

Overall fitness score: X.X / 10 — <status band> (mean of <list of scored dimensions>; <CRITICAL cap applied / not applied>)

Dimension	Score	Key Finding
Test Pyramid Balance	X/10	...
Test Quality	X/10	...
Coverage Strategy	X/10	...
Performance Testing	X/10 or N/A — reason	...
Debugging Support	X/10	...
CI Integration	X/10	...

Test inventory: <counts per level and per language, and the command used for each>

Detailed Findings

Finding 1: [Title]

Severity: CRITICAL / HIGH / MEDIUM / LOW
Confidence: X/10
Dimension: [which scoring dimension]
Location: file:line (or absence citation per rubric.md)
Description: What the issue is and why it matters.
Evidence: The specific code pattern found.
Impact: What could go wrong in production.
Remediation: Concrete fix naming the function or behavior to test and the cases to cover.

(repeat for each finding, ordered by severity)

Severity: CRITICAL / HIGH / MEDIUM / LOW
Confidence: X/10
Dimension: [which scoring dimension]
Location: file:line (or absence citation per rubric.md)
Description: What the issue is and why it matters.
Evidence: The specific code pattern found.
Impact: What could go wrong in production.
Remediation: Concrete fix naming the function or behavior to test and the cases to cover.

(repeat for each finding, ordered by severity)

Test Pyramid Balance (X/10)

Evidence: [collector output, counts per level, execution time] Strengths: ... Gaps: ...

(repeat for each dimension; for N/A dimensions, one line giving the reason)

Evidence: [collector output, counts per level, execution time] Strengths: ... Gaps: ...

(repeat for each dimension; for N/A dimensions, one line giving the reason)

Action Items (up to 5, by impact)

[SEVERITY] Description naming the function/file to change -- file:line
...

[SEVERITY] Description naming the function/file to change -- file:line
...

Reference

Checks from

review-testing/references/checklist.md

; scores from

review-testing/references/rubric.md

. Based on Fundamentals of Software Testing and Fundamentals of Software Quality Assurance.

undefined

Checks from

review-testing/references/checklist.md

; scores from

review-testing/references/rubric.md

. Based on Fundamentals of Software Testing and Fundamentals of Software Quality Assurance.

undefined