Back to Details

test-strategy-hardening

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Test Strategy Hardening

测试策略强化

Use this skill to turn a decorative or fragile test suite into a trustworthy engineering control. Optimize for confidence per minute, not raw coverage count.
使用此技能可将装饰性或脆弱的测试套件转变为可靠的工程管控手段。优化目标是单位时间内的测试可信度，而非单纯的覆盖率数值。

Workflow

工作流程

  1. Inventory the test system
    • Discover test commands, frameworks, e2e harnesses, fixtures, mocks, snapshots, CI config, coverage tooling, and runtime.
    • Classify tests by layer: pure unit, contract/schema, integration, e2e/browser, visual, smoke, load/perf, migration/data.
    • Record current pass/fail/flaky/skip status and approximate runtime.
  2. Judge whether tests carry their weight
    • Identify tests that pin real product contracts, past regressions, critical user journeys, external/provider parsing, migrations, permissions, and failure modes.
    • Flag broad snapshots, duplicate happy paths, brittle implementation assertions, no-op smoke tests, overmocked tests, and tests whose names exceed their proof.
    • Keep valuable slow tests, but move them to explicit suites if they block normal development.
  3. Write a decision-complete test plan
    • Define the critical behaviors that must not regress.
    • Pick the minimum suite shape: fast local default, focused changed-surface suites, e2e golden paths, release smoke, and optional nightly/heavy checks.
    • Specify deletions, rewrites, new characterization tests, and fixtures before touching behavior.
  4. Harden in green slices
    • Add characterization tests before refactors.
    • Replace low-value tests with narrower tests that fail for the right reason.
    • Build contract tests around external/API/provider boundaries.
    • Add e2e/visual coverage only for user-critical journeys; visually inspect screenshots when UI matters.
    • Keep fixtures small, named, deterministic, and close to the behavior they prove.
  5. Report the result
    • Summarize tests added, removed, merged, skipped, or quarantined.
    • Report runtime before/after and what confidence improved.
    • Leave explicit gaps and next target suites.
  1. 盘点测试系统
    • 梳理测试命令、框架、端到端（e2e）测试工具、fixtures、mocks、快照、CI配置、覆盖率工具及运行环境。
    • 按层级对测试分类：纯单元测试、契约/schema测试、集成测试、端到端/浏览器测试、可视化测试、冒烟测试、负载/性能测试、迁移/数据测试。
    • 记录当前测试的通过/失败/不稳定/跳过状态及大致运行时间。
  2. 评估测试的实际价值
    • 识别那些能固定真实产品契约、过往回归问题、关键用户流程、外部/供应商解析逻辑、迁移操作、权限控制及故障模式的测试。
    • 标记范围过大的快照、重复的正常流程测试、脆弱的实现断言、无实际作用的冒烟测试、过度mock的测试，以及名称与实际验证内容不符的测试。
    • 保留有价值的慢测试，但如果它们阻碍日常开发，需将其移至专属测试套件。
  3. 制定完整的测试决策方案
    • 定义必须防止回归的关键行为。
    • 确定最小化测试套件结构：快速本地默认套件、聚焦变更范围的套件、端到端核心流程测试、发布冒烟测试，以及可选的夜间/重量级检查。
    • 在修改代码行为前，明确指定需要删除、重写、新增的特征测试及fixtures。
  4. 分阶段绿色强化
    • 在重构前添加特征测试。
    • 用更精准的测试替代低价值测试，确保测试因正确的原因失败。
    • 围绕外部/API/供应商边界构建契约测试。
    • 仅为用户关键流程添加端到端/可视化测试；当UI至关重要时，需人工检查截图。
    • 保持fixtures轻量化、命名清晰、可预测，并贴近其要验证的行为。
  5. 输出结果报告
    • 总结新增、移除、合并、跳过或隔离的测试。
    • 报告优化前后的运行时间，以及可信度提升的具体方面。
    • 明确列出当前存在的测试缺口及下一阶段的目标测试套件。

Quality Bar

质量标准

  • A normal developer can run the fast suite frequently.
  • Critical product journeys have at least one high-signal regression path.
  • External contracts fail loudly before bad data reaches UI or business logic.
  • Tests have clear names, minimal mocks, deterministic fixtures, and useful failure messages.
  • The final report answers: "What bugs would this suite catch that it used to miss?"
For the audit checklist, read checklist.md.
  • 普通开发者可频繁运行快速测试套件。
  • 关键产品流程至少有一条高信号的回归检测路径。
  • 外部契约出现问题时，能在错误数据到达UI或业务逻辑前及时报错。
  • 测试名称清晰、mock最少、fixtures可预测，且失败信息具备参考价值。
  • 最终报告需回答：“该测试套件现在能捕获哪些之前无法发现的bug？”
如需查看审核清单，请阅读 checklist.md。