需要制定多季度 QA 测试策略时：生成可执行的测试策略文档…

适用于为产品、团队和风险画像制定跨季度 QA 测试策略，输出驱动日常测试决策的可执行文档。

适用场景

解决思路

1. 写策略前先收集产品与业务上下文：产品类型（SaaS、电商、API 平台、移动应用、内容站点）、用户（消费者、企业、内部、开发者）、业务关键流程（注册、结账、支付、数据导出）、发布节奏（持续、每周、双周、季度）、合规要求（SOC2、HIPAA、PCI-DSS、GDPR、EU AI Act）。
2. 收集当前测试状态：现有测试层级及数量、使用的框架和工具、当前代码覆盖率和目标、CI 管道端到端耗时、当前 flakiness rate。
3. 收集痛点与目标：最大质量痛点（回归、反馈慢、flaky tests、缺口）、最近 3 个 release 坏在哪里以及什么逃逸到生产、团队对「足够好质量」的定义、对测试基础设施的投资意愿。
4. 收集团队与约束：团队规模和构成（devs、QA、SDET、manual testers）、自动化工具技能水平、工具预算约束、时间线压力。
5. 先检查 `.agents/qa-project-context.md`；若存在，作为基础并跳过已回答问题。
6. 校准团队成熟度，在 `.agents/qa-project-context.md` 设置 `team_maturity`：startup 用最小金字塔（单元测试 + 少量关键 E2E 路径），跳过契约测试和正式指标直到 CI 可靠，Phase 1 少于 4 周；growing 用完整金字塔，定义覆盖率目标、flakiness 阈值、CI 质量门，并加入风险优先级；established 用 SLA 支持的质量门、多环境覆盖、高级工具（契约测试、混沌、可观测性）和正式审查节奏。
7. 按风险优先而非穷尽覆盖：按业务风险而非代码量分配测试努力；若无风险矩阵，先运行 `risk-based-testing`。
8. 诊断测试金字塔健康：健康套件是大量快速单元、较少集成、最少 E2E；先诊断当前形状再开方。
9. 左移：静态分析在测试前，单元在集成前，契约在 E2E 前；用设计审查捕获架构 bug。
10. 每个策略元素配 KPI：覆盖率目标、flakiness 阈值、逃逸率目标、MTTR 限制；每个部分命名数字和跟踪节奏。
11. 保持活文档：至少每季度审查；包含修订历史、每节命名 owner、显式再评估触发器（新产品领域、团队变化、重大事故、缺陷逃逸）。
12. 按 13 节结构生成最终文档（Executive Summary 到 Revision History）；参考 `references/diagrams-and-worksheets.md` 的 markdown skeleton 和 `references/strategy-templates.md` 的四个完整示例（SaaS、e-commerce、API-first、media）；按复杂度调整深度（5 人 startup 需 5 页，不是 50 页）。
13. 第 1 节 Scope & Objectives：定义在范围内（每个产品区域、服务、集成；功能和非功能类型；平台和浏览器/设备）；不在范围内（说明未覆盖及原因，如第三方服务仅契约级测试、计划废弃的遗留系统）；写 3-5 个可衡量目标及时间线。
14. 第 2 节 Test Levels & Types：为每个层级定义验证内容、负责人、框架、目标数量、运行频率。Unit：函数/业务逻辑/边缘案例，开发者，Vitest/Jest/pytest，70-80% 测试，每次提交。Integration：服务交互/DB 查询/API 契约，开发者+QA，Supertest/pytest + Testcontainers，15-20%，每个 PR。E2E：关键用户旅程通过全栈，QA/SDET，Playwright/Cypress，5-10%，部署前+每晚。API：契约合规/schemas/错误处理，开发者，Playwright APIRequestContext/Schemathesis，每个 endpoint，每个 PR。Visual：UI 回归/布局偏移/响应式，QA，Playwright/Argos/Chromatic，关键页面，每晚。Performance：响应时间/吞吐/资源使用，DevOps/QA，k6/Lighthouse，关键路径，每周+发布前。Security：OWASP Top 10/依赖漏洞/认证流程，Security/DevOps，OWASP ZAP/Snyk，每个 release，发布前+计划。Accessibility：WCAG 2.2 AA/屏幕阅读器兼容，QA/Frontend，axe-core，关键流程，每个 PR。调整到产品实际需要；不是每个产品都需要 visual regression；每个产品都需要 unit 和 integration。
15. 第 3 节 Test Pyramid Analysis：诊断当前形状并定义目标。形状包括健康金字塔、ice cream cone、diamond、hourglass。当前状态：计算每层测试数，计算百分比拆分，识别形状，捕获 CI 持续时间、flaky rate、pass rate；使用 Current State Assessment Worksheet。目标状态：定义目标比例（70-80% 单元，15-20% 集成，5-10% E2E）及具体数量，目标 CI 持续时间和 flaky rate；使用 Target State Worksheet。
16. 若为 ice cream cone 或 diamond，执行：冻结 E2E 增长（除非覆盖净新关键路径不新增 E2E）；分解现有 E2E（把可在单元级测试的逻辑重写为低一级测试）；将单元要求加入 PR checklist（每个触及业务逻辑的 PR 都带单元测试）；设置 CI 门（当 unit:E2E 比例低于阈值时使 PR 失败）。重新平衡前区分真正 flaky 的 E2E 与暴露真实 bug 的测试；隔离隐藏竞态条件的 flaky 测试会让回归逃逸；flaky 根因分类和隔离见 `test-reliability`。
17. 若为 hourglass，执行：投资集成基础设施（DB fixtures、service stubs、contract tests）；识别服务边界（每个边界需要集成测试覆盖 happy path + error cases）；对服务间通信使用契约测试（Pact）。
18. 第 4 节 Risk Assessment Matrix：对每个功能评分 Impact（1 Negligible→5 Catastrophic）× Likelihood（1 Rare→5 Almost Certain）；乘积 1-25 映射到 LOW/MED/HIGH/CRIT。按风险等级行动：CRITICAL（15-25）全自动化+手动探索+负载测试，强制每次提交，实时告警和合成监控；HIGH（10-14）全自动化+定期手动审查，强制每个 PR，仪表盘+每日检查；MEDIUM（5-9）自动化 happy path+关键错误案例，推荐，每周审查；LOW（1-4）手动测试或跳过，可选，无需。参考 5x5 矩阵和示例映射表。
19. 第 5 节 Environment Strategy：定义 Local、CI、Staging、Production。Local：开发者反馈，unit/integration，mocked/seeded，保存时。CI：自动化验证，unit/integration/lint/SAST，ephemeral，push/PR。Staging：预生产验证，E2E/visual/performance/security，production-like（anonymized），merge to main。Production：监控&smoke，smoke tests/synthetic monitoring，live，deploy。记录每个环境测试数据管理、环境是 ephemeral（preview deployments）还是 long-lived、访问权限、环境特定配置管理。
20. 第 6 节 Tool Selection Rationale：不要先选工具；先理解需求，再按加权标准评分选工具。标准权重：Fits tech stack 25%、Team familiarity 20%、Community & docs 15%、CI integration 15%、Maintenance cost 10%、Speed of execution 10%、License cost 5%；每个 1-5 分，乘权重求和。考虑总拥有成本：setup time、writing time（计时 5 个真实测试）、maintenance time、debug time、infrastructure cost。记录选择或偏离常见技术栈起点。常见栈起点：React SaaS/Vue SaaS/Next.js：Vitest + Testing Library + MSW + Playwright + Supertest + Playwright screenshots；Python API：pytest + Testcontainers + pytest + requests + Schemathesis；Mobile（RN）：Jest + Testing Library + MSW + Detox/Maestro/Appium 3.x + Supertest + Appium screenshots；AI/LLM：Vitest + DeepEval + Playwright + Promptfoo evals + Promptfoo/Ragas；并增加幻觉、偏见、提示注入、隐私风险测试，见 `ai-system-testing` 和 `compliance-testing`（EU AI Act）。参考框架：CTAL-AT v2.0、CT-GenAI v1.1、CTFL v4.0、HTSM v6.3、World Quality Report 2025-26。
21. 第 7 节 CI Scaling Levers：在删除测试前使用：Sharding（Playwright `--shard=1/4`、Jest `--shard`、pytest-xdist、Cypress parallelization）；Test impact analysis（仅运行 diff 影响的测试，依赖图 Nx affected、Vitest `--changed`、Bazel 或 coverage-to-file maps；保留全量套件在 nightly/merge gate）；Caching（依赖、构建产物、浏览器二进制）；Selective E2E on PR（PR 上 smoke E2E，merge/nightly 全量 E2E）。衡量收益：Parallel efficiency = summed test-run time ÷ wall-clock time，目标接近 shard count（如 4 shards 上 >3x）；跟踪 CI-minutes-per-PR 捕捉 wall-clock 降低但 billed compute 膨胀。
22. 第 8 节 Entry/Exit Criteria：为每层写进入/退出标准。Unit Entry：代码编译，函数有文档化契约（输入/输出）；Exit：所有分支覆盖，边缘案例测试，无 skipped tests，覆盖率目标达成。Integration Entry：单元测试通过，依赖服务可用或 stubbed，测试数据已 seeded；Exit：所有服务边界测试，错误路径验证，无 flaky tests。E2E Entry：集成测试通过，staging 已部署，测试账号已 provisioned；Exit：所有关键用户旅程通过，无 P0/P1 缺陷，性能在 SLA 内。Release Entry：所有测试层级通过，无 CRITICAL/HIGH 缺陷，release notes 草拟；Exit：生产 smoke tests 通过，监控在约定 bake window（默认 30 分钟，按部署频率和告警延迟调整）内无异常，回滚计划已验证。
23. 第 9 节 Quality Gates & Definition of Done：定义自动化门。PR gate：unit tests 通过；integration tests 通过；覆盖率不下降（或达最低）；无新 lint 错误；SAST 扫描通过（无新高/严重）；bundle size 在阈值内；至少一个 reviewer 批准。Merge gate：所有 PR-gate 检查通过；E2E smoke suite 对 preview deployment 通过；无合并冲突；分支与 main 同步。Deploy gate：完整 E2E 在 staging 通过；性能基准在范围内；安全扫描通过；feature flags 已配置；回滚计划已文档化并测试。Nightly gate：完整 E2E 包括边缘案例；visual regression；performance/load tests；accessibility scan；依赖漏洞扫描；结果次日早上由 QA lead 审查。每个门命名具体通过/失败阈值并在 CI 强制执行；能被点击绕过的门是文档不是门。
24. 第 10 节 Metrics & KPIs：定义并跟踪：Code Coverage 行/分支覆盖率，目标 >80% 关键服务、>60% 整体，每个 PR；Test Pyramid Ratio unit:integration:E2E = 70:20:10（±10%），每月；Flakiness Rate 非确定性失败运行占比 <2%，每周；Defect Escape Rate 生产发现缺陷占总缺陷 <5%，每个 release；MTTR 检测到修复部署 <4h P0、<24h P1，每个 incident；CI Pipeline Duration push 到绿/红信号 <15 min PR、<30 min full，每周；CI Parallel Efficiency 和测试时间÷wall-clock time，接近 shard count（4 shards 上 >3x），每周；CI-Minutes-per-PR 每个 PR 计费计算分钟，持平或下降，每月；Defect Density 每 1000 LOC 缺陷数，下降趋势，每月；Automation Rate 自动化测试案例占比，回归套件 >80%，每季度；False Positive Rate 非真实 bug 的失败占比 <5%，每周。使用指标：跟踪趋势不是绝对值；从当前状态设现实目标；每季度与领导审查；庆祝改进；调查尖峰；绝不用于惩罚团队；见 `qa-metrics`。
25. 第 11 节 Timeline & Milestones：分阶段。Phase 1 Foundation（Weeks 1-4）：为所有产品区域做风险评估；CI 管道带 unit-test gate；基线指标（coverage、flakiness、pipeline time）；为 top 5 高风险区域写单元测试；选择并配置 E2E 框架。Exit：CI 在每个 PR 运行单元测试，基线指标记录。Phase 2 Coverage Expansion（Weeks 5-10）：为所有服务边界写集成测试；为 top 10 关键旅程写 E2E；关键页面 visual regression；测试数据管理；nightly runs。Exit：所有关键路径有 E2E 覆盖，集成测试覆盖所有 APIs。Phase 3 Quality Gates（Weeks 11-14）：PR 覆盖率门（不下降）；CI 性能基准；安全扫描；所有 KPI 监控仪表盘。Exit：四个门（PR、merge、deploy、nightly）活跃并强制执行。Phase 4 Optimization（Weeks 15-20）：修复或隔离 flaky tests；CI 扩展杠杆（sharding、caching、test impact analysis）；生产合成监控；第一次季度策略审查。Exit：CI 低于 15 分钟，flakiness 低于 2%，第一版策略修订发布。Ongoing：季度策略审查和修订；每月指标审查；持续维护（重构、去 flake、退役）。
26. 避免反模式：不要设 100% 覆盖率目标（80% 后收益递减，最后 20% 测 getter 和琐碎代码而忽略集成缺口；按模块风险设覆盖率）。避免 ice cream cone（太多 E2E、太少单元；症状：CI 45+ 分钟、每次 UI 变更测试断裂、无人信任套件；通过冻结 E2E 增长并把 E2E 分解到低层修复）。不要把策略当一次性文档（写一次从不更新比没有更糟；设置季度日历审查、事故后、新产品领域、团队构成变化等审查触发器）。不要工具优先（「我们应该用 Playwright」是工具选择伪装成计划；从需要验证什么开始，再选工具）。不要无指标（无指标=无问责；每个部分连接 KPI）。不要孤立测试（策略只活在 QA wiki 对开发者不可见；必须活在 PR templates、CI gates、Definition of Done 中）。不要复制粘贴策略（照搬他司策略忽略自身风险、团队技能和约束；模板只是起点，每节都要定制）。不要立即自动化一切（手动探索测试有巨大价值，尤其早期；自动化回归，保留探索手动，策略指定什么保持手动及原因）。
27. 验证文档完整：运行 `DOC=docs/qa-strategy.md`；检查 `grep -cE '^### [0-9]+\.' $DOC` 返回 13；检查 Metrics & KPIs 表 Target 列非空；检查存在 revision history 和 owner。手工检查金字塔数学：target unit% + integration% + E2E% 应约等于 100%；若建议 sharding，确认 Metrics 表出现 parallel-efficiency 或 CI-minutes 目标。
28. Done When 检查：策略文档在约定路径存在且编号章节标题数量为 13；金字塔目标比例有具体数量和时间线，unit+integration+E2E 约 100%；每层写 entry/exit criteria；工具选择有评分加权理由矩阵；四个阶段质量门定义并有具体通过/失败阈值；每个 Metrics & KPIs 行有非空 Target 和跟踪节奏。
29. 相关技能与参考文件：先运行 `risk-based-testing`；单 sprint/release 用 `test-planning`；flake 用 `test-reliability`；KPI 用 `qa-metrics`；release 用 `release-readiness`；CI 用 `ci-cd-integration`；左移用 `shift-left-testing`；AI/LLM 用 `ai-system-testing`；合规用 `compliance-testing`；参考 `references/diagrams-and-worksheets.md` 和 `references/strategy-templates.md`。

适用边界 · 注意事项

• 单一 sprint 或 single-release 计划：应使用 `test-planning`，而不是多季度测试策略。
• 需要先识别哪些区域风险最高：应先使用 `risk-based-testing` 建立风险矩阵。