qa-testing-strategy

QA 测试策略

面向现代软件交付的基于风险的质量工程指南。使用此技能来决定测试什么、在哪一层测试、设置哪些门禁，以及如何保持测试信号可信。

请先查看 references/operational-playbook.md 中的导航中心。需要厂商或标准指南时，请使用 data/sources.json 中的官方最新资料。

范围

• 创建或更新基于风险的测试策略
• 根据架构和缺陷来源选择测试形态（金字塔、奖杯、蜂巢）
• 定义合并门禁、部署门禁和发布证据，包括与合并队列的交互
• 选择最小且有效的测试层：单元、组件、契约、模式模糊测试、集成、端到端、基于属性
• 借助产物、关联 ID、跟踪信息和责任归属，让失败易于诊断
• 将套件健康状况落到实处：波动 SLO、隔离策略、执行预算、仪表板

改用以下技能

需求	技能
实现或调试 Playwright 测试套件	qa-testing-playwright
深入设计 API 契约测试套件	qa-api-testing-contracts
调试失败的测试或事故	qa-debugging
添加可观测性、遥测或跟踪	qa-observability
测试 LLM Agent 或评估	qa-agent-testing
移动端专属策略或自动化	qa-testing-mobile
深入进行安全审计或威胁建模	software-security-appsec
设计 CI/CD 流水线和基础设施	ops-devops-platform

快速参考

层级	目标	典型用途
单元	快速验证逻辑和不变量	纯函数、领域规则、验证器
组件	在真实浏览器中，以有限范围验证 UI 行为	UI 组件、状态转换、无障碍冒烟测试
契约	防止服务边界发生破坏性变更	OpenAPI、AsyncAPI、JSON Schema、Protobuf
模式模糊测试	使用生成的有效和无效输入对 API 契约进行压力测试	请求/响应边界情况、解析器和验证逻辑漂移
基于属性	验证生成输入空间中的通用不变量	序列化往返、数值契约、状态机不变量、AI 代码边界情况
集成	验证真实边界和依赖项	API + DB、队列、适配器、身份验证流程
端到端	验证精简的关键旅程	注册、结账、发布、付款、管理员恢复
性能	执行预算并验证容量	负载、压力、浸泡、延迟回归
视觉	捕获有意或意外的 UI 变更	稳定页面、设计系统组件
无障碍	尽早检查常见的 WCAG 2.2 问题	axe 冒烟测试 + 人工审计计划
安全	尽早捕获常见的 Web/API 漏洞	SAST、DAST 冒烟测试、身份验证和依赖项检查

端到端门禁拓扑（默认）

使用三个不同范围的端到端测试，而不是一个庞大的测试套件：

• 冒烟测试：作为 PR 门禁，为风险最高的旅程提供最快反馈。
• 定向批次/测试规格：用于本地排查和消除波动，范围限于一个旅程、子系统或依赖链。
• 部署门禁重放：仅在验证发布就绪时使用，重放依赖链或关键旅程。

规则：

• 单个旅程失败时，不要首先运行完整的本地端到端测试。
• 将重跑通过视为尚未解决的测试波动债务。
• 只有较小范围的测试通过后，才扩大测试范围。

默认工作流

1. 明确范围和风险：关键用户旅程、故障模式、合规约束和非功能性风险。
2. 定义质量信号：SLO、预算、契约检查、无障碍目标，以及哪些情况会阻止合并或部署。
3. 将每项关键风险映射到一项声明、预言机、层级、环境、构建标识、证据产物、负责人和到期时间。标记为 configured、executed、behavior-verified 或 release-observed；静态分析、发现、覆盖率和绿色构建都不能证明已执行行为。
4. 优先选择最小且有效的层级：单元测试、组件测试、契约测试、模式模糊测试、集成测试，然后是端到端测试。
5. 让故障易于诊断：日志、跟踪、屏幕截图、视频、构建链接、请求 ID、跟踪 ID 和负责人。
6. 将测试套件纳入运维：明确冒烟测试、定向批次和部署门禁的范围，隔离测试并设置到期时间、测试套件预算、保留证据的重试机制和仪表板。列出尚未覆盖的关键风险和下一道门禁，不要把定向测试通过当作普遍适用的发布证明。

决策规则

Need to test: [Change or Risk]
    │
    ├─ Pure business rule or invariant?
    │   └─ Unit test
    │
    ├─ UI behavior or component state in isolation?
    │   └─ Component test in a real browser
    │
    ├─ API compatibility between teams/services?
    │   └─ Contract test
    │
    ├─ API parser/validation edge cases against the schema?
    │   └─ Schema-aware fuzzing + core integration smoke
    │
    ├─ Real dependency boundary or persistence behavior?
    │   └─ Integration test with real DB/queue/service doubles only at external edges
    │
    ├─ User-critical cross-page workflow?
    │   └─ Thin E2E test
    │
    ├─ Universal invariant or property that should hold for all valid inputs?
    │   └─ Property-based test (fast-check / Hypothesis / jqwik)
    │
    └─ Capacity, resilience, or reliability regression?
        └─ Performance, resilience, or synthetic monitoring tests

基于风险确定优先级

覆盖率按风险分配，而不是按形态分配。选择测试前，为每个用户旅程或模块评分，并将分数写入策略单页：

• 影响（1–3）：收入、数据丢失、安全或合规风险，以及故障能否在不联系客户的情况下恢复。
• 可能性（1–3）：过去一个季度的变更频率、缺陷逃逸历史、经过的集成边界数量，以及 AI 编写代码或新贡献者代码所占比例。
• 风险 = 影响 × 可能性。评分 ≥ 6 时，须在多个层级提供已执行行为的证据，并进行部署门禁检查；评分为 3–5 时，选择能证明该声明的最小单一层级；评分 ≤ 2 时，仅进行静态检查和适时的单元测试，并在策略中明确说明这一缺口。
• 每次事故后以及每个季度重新评分；评分下降的模块应先从 PR 门禁中移除测试，再考虑将其添加到其他位置。

契约测试与端到端测试

• 契约测试证明两个参与方在某个边界上对结构和语义达成一致；端到端测试证明某个用户旅程在已部署的构建中跨越多个边界后仍能正常工作。两者不能互相替代。
• 默认做法：每个部署节奏独立的服务边界都应在合并前进行契约检查；每个涉及收入或数据丢失的用户旅程都应在部署门禁中进行一次精简的端到端测试。其他情况默认不进行端到端测试。
• 如果上个季度捕获的故障是边界结构不匹配或持久化错误，则用契约测试加集成测试替代端到端测试；如果故障涉及跨服务顺序、身份验证会话流程，或低层无法观察到的 UI 状态，则保留端到端测试。
• 如果没有消费者侧验证的契约测试（提供方发布了模式，却没有人用它检查消费者），那只是文档，不是证据。

覆盖率指标

• 行覆盖率和分支覆盖率衡量的是执行情况，而非断言。仅将其用于 PR 中不允许下降的增量门禁，以及查找未经测试的文件；绝不要将其作为发布标准。
• 超出差异级增量门禁的任何覆盖率数字都是容易被钻空子的目标（测试执行了代码，却没有进行断言）。在认证、支付、迁移和领域规则等覆盖率数字确实重要的场景，应改为对变更文件设置变异分数门禁；相关策略见 references/quality-metrics-dashboard.md。
• 在测试影响分析或部分测试套件下收集的覆盖率，不能与完整测试套件的基线比较；应保持同类比较，否则增量门禁会被噪声触发。
• 对每个受检查的组件，至少有一项检查要在不进行覆盖或使用修补副本的情况下，运行随产品交付的默认配置、捆绑数据和入口点；自行构建或修补测试夹具的测试只能证明该夹具。如果某项检查通过得异常轻松，应先检查观测方法，再决定是否信任结果。

不稳定测试政策

• 在修改测试前，先依据分类体系进行分类；环境类故障应在环境中修复，绝不应隔离。
• 只有在指定负责人、工单、到期时间和最小范围（单个测试，而非整个文件）的情况下才进行隔离；被隔离的测试仍会运行并报告。隔离到期后，构建会失败。
• 重跑后通过应记为该测试的不稳定性债务；安全、身份验证和支付测试绝不重试至通过。
• 修复时限遵循 MTTR-Flake SLO 中的严重性分级；运维手册中的合并队列成本模型决定某项测试是否值得当天隔离。

测试数据

• 每个测试都通过工厂创建自己的数据，并使用唯一标识符；共享测试夹具和会被测试修改的种子数据行，是导致测试顺序相关不稳定的主要来源。
• CI、预览环境和预发布环境中不得使用真实客户数据。需要与生产数据形态相似的数据时，应使用无法逆向还原的脱敏子集，同时保留引用完整性，并为脱敏规则指定负责人；请参阅 references/synthetic-test-data.md。
• 为每次测试运行使用固定种子初始化数据生成器，并在失败时打印该种子，以便重放测试用例。

原则

• 优先选择能够验证行为的最小测试层级。
• 保持合并前检查快速：契约、静态检查、单元测试，以及有选择的组件／集成冒烟测试。
• 在本地优先针对性地批量重跑；完整 E2E 测试留给部署门禁或定期回归测试。
• 仅对关键流程或无法在技术栈更低层级验证的风险使用完整 E2E 测试。
• 优先采用以 Web 为先的断言和稳定定位器，避免自定义等待或脆弱的选择器。
• 将无障碍自动化视为不完整的覆盖。应结合人工检查和包容性设计评审。
• 将遥测作为证据。生产跟踪、事故和支持信号应推动新增测试。
• 仅在保留证据的前提下使用 AI 进行头脑风暴和分类处理。不要通过弱化断言来“修复”测试。
• 将 AI 编写的测试预言质量视为首要风险，与不稳定性债务同等重要。AI 生成的测试经常能达到很高的代码行覆盖率，却只是轻易通过（返回值硬编码、断言浅显）。接受测试前，先进行简单的人工预检：如果被测的每个函数都不返回任何内容，这个测试是否仍会通过？拒绝仅使用模拟对象或仅检查缺失情况的测试、自我指涉的预期、固定常量，以及断言自身的测试夹具。随后以变异分数而非覆盖率作为运行检查门槛：如果业务逻辑被还原后测试仍无法失败，那就不算测试。
• 当同一个模型既编写又审查变更时，它的审查会与编写者有相同的盲点。进行任何 AI 审查前，先运行测试和构建，并优先报告它们的失败。然后针对 AI 最常导致回归的情况添加回归测试：某个字段只在一条代码路径中添加，却未添加到对应路径（沙盒或模拟模式、标志分支、缓存或批处理路径）；响应字段未包含在查询投影或映射器中；错误处理设置了错误状态，却让过时数据留在屏幕上；调用失败时，乐观更新没有回滚。每个已修复的缺陷都要有一个在修复前版本上会失败的测试。

核心目标

信号	默认目标
PR 门禁	p50 <= 10 分钟，p95 <= 20 分钟
主线健康度	>= 99% 的构建／天为绿色
测试套件不稳定率	每周 <= 1%
隔离政策	指定负责人 + 工单 + 到期时间，不得无限期隔离
AI 编写的测试预言质量	对变更文件设置变异分数门槛（代码行覆盖率不是门槛）；根据测试套件校准阈值，绝不只凭覆盖率接受 AI 测试

资源

• references/operational-playbook.md：从这里开始
• references/component-testing-browser-mode.md：使用 Vitest Browser Mode 的真实浏览器组件测试策略
• references/playwright-webapp-testing.md：重定向占位文件 — 参见 qa-testing-playwright
• references/schema-aware-api-fuzzing.md：使用 OpenAPI 进行模式驱动的 API 模糊测试
• qa-api-testing-contracts：契约测试的负责人（Pact、Specmatic、can-i-deploy、破坏性变更门禁）
• references/observability-driven-testing.md：优先使用 OpenTelemetry 的调试和基于追踪的验证
• references/quality-metrics-dashboard.md：指标、仪表板、发布就绪硬性门禁和变异覆盖率门禁策略
• references/production-testing-and-shift-right.md：合成监控、暗发布、功能标志分批发布、MTTR-不稳定测试 SLO、生产环境回放、可观测性驱动的门禁
• references/test-impact-analysis.md：TIA 概念、CloudBees Smart Tests（原 Launchable）、Datadog Test Optimization、BuildPulse 不稳定测试趋势分析、jest --findRelatedTests
• references/shift-left-testing.md：左移实践、测试替身，以及将质量检查前移的覆盖率目标
• references/test-automation-patterns.md：页面对象模型、数据工厂、固定装置、测试替身、AAA 和隔离模式
• references/test-environment-management.md：环境即代码、数据填充、服务虚拟化、隔离，以及共享与专用方案之间的权衡
• references/synthetic-test-data.md：测试数据管理规则 — 每项测试使用独立工厂、脱敏生产数据子集、数据填充，以及合成数据可能产生误导的情况
• references/chaos-resilience-testing.md：重定向占位文件，指向 qa-resilience
• references/compliance-testing.md：合规即代码、审计证据自动化、访问控制、数据驻留和加密验证（HIPAA 渗透测试规则是拟议规则，并非最终规则）
• references/feature-matrix-vs-test-matrix-gate.md：发布前门禁，将已实现功能映射到可审计的测试证据
• references/property-based-testing.md：选择有效域和判定标准，然后使用 fast-check、Hypothesis、jqwik（注意其处于维护模式）或可移植契约运行器运行属性测试和蜕变测试
• references/comprehensive-testing-guide.md：已弃用的重定向映射，指向各测试层对应的专用同级技能
• references/reliability-theory-applied.md：将可靠性基础概念（MTBF/MTTR、错误预算、逃逸概率、最小割集）应用于 QA 测试策略
• scripts/release_readiness.py：发布就绪门禁 — 在计算任何加权分数之前评估硬性门禁（安全、关键 E2E、未解决的 P0）；参见 scripts/test_release_readiness.py

模板

• assets/test-strategy-template.md：策略单页文档
• assets/automation-pipeline-template.md：CI/CD 流水线蓝图
• assets/component/template-vitest-browser.md：浏览器模式组件测试
• assets/e2e/template-playwright.md：重定向占位文件——实时 Playwright 模板见 qa-testing-playwright
• assets/bdd/template-cucumber-gherkin.md：当关键流程以 Gherkin/BDD 场景描述时使用（参见 references/operational-playbook.md）
• assets/unit/template-jest-vitest.md：当最小有效测试层级为 Jest/Vitest 单元测试时使用（参见 references/operational-playbook.md）
• assets/integration/template-api-integration.md：API + DB 集成测试
• assets/performance/template-k6-load-testing.md：重定向占位文件——实时 k6 模板见 qa-testing-performance
• assets/visual-regression/template-visual-testing.md：重定向占位文件——视觉回归测试见 qa-testing-playwright；保留仅针对稳定页面的策略规则
• assets/runbooks/template-flaky-test-triage-deflake-runbook.md：消除不稳定测试的运行手册
• assets/runbooks/template-release-coverage-audit.md：从 references/feature-matrix-vs-test-matrix-gate.md 执行 feature-matrix-vs-test-matrix 发布门禁时使用
• assets/template-test-case-design.md：Given/When/Then 和判定依据

属性与蜕变契约工具

• scripts/property_contract_runner.py：无依赖的适配器运行器，支持确定性种子和按用例索引重放
• assets/property_contract_example.py：包含已知正确的计算器、配置解析器和 JSON 往返适配器，并带有有意引入的负向对照变异
• scripts/test_property_contract_runner.py：验证正确行为、变异检测、退出代码和重放

在此技能目录中运行 python3 scripts/property_contract_runner.py --contract assets/property_contract_example.py --seed 20260908 --cases 120 --json；从任何目录运行时，使用等效的绝对路径也可以。请先检查适配器，因为运行器会导入并执行该 Python 文件，且不会对其进行沙箱隔离。运行器会防御性地复制用例和结果值，但适配器全局状态由适配器作者负责管理。退出代码 0 表示抽样契约通过，退出代码 1 表示出现可重放的属性失败，退出代码 2 表示适配器或命令无效。

导航

• ## Default Workflow、## Decision Rules、## Risk-Based Prioritisation 和 ## Principles：了解基线策略顺序
• ## Resources 和 ## Templates：查阅更深入的材料
• ## Related Skills：了解特定工具的执行交接

相关技能

技能	用途
qa-refactoring	在保留行为的同时安全重构
software-code-review	代码审查流程和检查清单
software-architecture-design	系统设计和架构决策

经验循环

如果之前的决策或注意事项与当前任务相关，请查阅 learnings.consolidated.md（如果存在）；仅在需要查看历史记录或没有其他文件可用时，才查阅 learnings.md。否则，请跳过这两个文件。

应用相关经验后，如果你遇到了值得记住的模式、值得避免的错误，或令人意外的领域事实，请通过 agents-skills-feedback-loop/scripts/append_learning.py 向 learnings.md 追加一条带日期的条目。不要修改 SKILL.md 本身。