test-strategy

生成一份针对产品、团队和风险状况制定的可执行 QA 策略文档，推动日常测试决策，而不是一份束之高阁的合规材料。一个拥有 150 个 E2E 测试、流水线耗时 52 分钟的团队可能自以为覆盖率不错；此技能会诊断倒置的测试金字塔，给出调整建议，并将每个要素与可衡量的 KPI 关联起来。

---

调研问题

在动笔编写策略之前，先收集背景信息。先检查 .agents/qa-project-context.md——如果该文件存在，就以其内容为基础，并跳过已在其中回答的问题。

产品与业务背景

• 产品是什么？（SaaS、电商、API 平台、移动应用、内容网站）
• 用户是谁？（消费者、企业、内部人员、开发者）
• 哪些业务流程至关重要？（注册、结账、付款、数据导出）
• 发布频率如何？（持续发布、每周、每两周、每季度）
• 有哪些合规要求？（SOC2、HIPAA、PCI-DSS、GDPR、EU AI Act）

当前测试状态

• 目前有哪些测试级别，各级别的测试数量是多少？
• 使用哪些框架和工具？
• 当前代码覆盖率是多少？是否设有目标？
• CI 流水线端到端耗时多长？
• 当前的测试不稳定率是多少？

痛点与目标

• 最大的质量痛点是什么？（回归、反馈慢、测试不稳定、覆盖缺口）
• 最近 3 次发布中出了什么问题？有哪些问题流入了生产环境？
• 对团队而言，“质量足够好”是什么样的？
• 愿意投入多少资源建设测试基础设施？

团队与约束

• 团队规模和组成如何？（开发人员、QA、SDET、手动测试人员）
• 团队对自动化工具的熟练程度如何？
• 工具预算有何限制？
• 时间压力如何——是否有推动制定此策略的截止日期？

---

根据团队成熟度进行调整（在 .agents/qa-project-context.md 中设置 team_maturity）：

• startup — 采用精简测试金字塔：单元测试加少量关键 E2E 路径。CI 稳定运行前，暂不进行契约测试或正式指标管理。阶段 1 不超过 4 周。
• growing — 建立完整测试金字塔，设定明确的覆盖率目标、不稳定率阈值和 CI 质量门禁。增加基于风险的优先级排序。
• established — 采用由 SLA 支撑的质量门禁、多环境覆盖、先进工具（契约测试、混沌测试、可观测性）以及正式评审周期。

---

核心原则

1. 优先基于风险排序，而非追求穷尽覆盖。 并非所有代码都同等重要——支付缺陷的代价可能是工具提示文字错误的 1000 倍。测试投入应与业务风险成正比，而不是与代码量成正比。风险矩阵决定投入方向；如果还没有矩阵，请先运行 risk-based-testing。

2. 测试金字塔的健康状况是领先指标。 健康的测试套件包含大量快速单元测试、较少的集成测试，以及最少的 E2E 测试。如果结构倒置成“冰淇淋筒”，反馈会变慢、维护成本会升高，信心反而会降低。在提出改进方案前，先诊断当前结构。

3. 左移：尽早发现缺陷。 越晚发现缺陷，修复成本就会呈指数级增长。将验证前移——先做静态分析，再做测试；先做单元测试，再做集成测试；先做契约测试，再做 E2E 测试。设计评审还能发现任何测试都无法发现的架构缺陷。

4. 策略中的每个要素都要有 KPI。 无法衡量，就无法改进。覆盖率目标、不稳定率阈值、缺陷逃逸率目标、MTTR 限制——每个章节都应列明具体数值和跟踪频率。

5. 让文档持续更新，而不是束之高阁。 至少每季度评审一次。文档应包含修订历史、各章节的明确负责人，以及明确的重新评估触发条件（新增产品领域、团队变动、重大事故、缺陷流入生产环境）。

---

策略文档模板

逐节完成内容，编写最终文档。根据复杂程度调整深度——5 人的初创公司需要的是 5 页，而不是 50 页。最终文档采用 13 节结构（从执行摘要到修订历史）；可参阅 references/diagrams-and-worksheets.md 中可复制粘贴的 Markdown 大纲，以及 references/strategy-templates.md 中 4 个完整示例（SaaS、电商、API 优先、媒体）。

1. 范围与目标

明确界定边界。此处含糊不清会导致后续工作出现遗漏和浪费。

• 范围内： 此策略涵盖的所有产品领域、服务和集成；功能与非功能类型；平台和浏览器／设备。
• 范围外： 说明哪些内容不在覆盖范围内以及原因——仅在契约层面测试的第三方服务、计划弃用的遗留系统。
• 目标： 制定 3-5 个可衡量的目标，并设定时间线，例如：“在两个季度内，将缺陷逃逸率从 12% 降至 5% 以下”“2026 年第一季度后上线的所有服务，单元测试覆盖率达到 80%。”

2. 测试级别与类型

定义每个级别、覆盖内容、负责人和预期数量。

级别	验证内容	负责人	框架	目标数量	运行频率
单元测试	函数、业务逻辑、边界情况	开发人员	Vitest/Jest/pytest	占所有测试的 70-80%	每次提交
集成测试	服务交互、数据库查询、API 契约	开发人员 + QA	Supertest/pytest + Testcontainers	占所有测试的 15-20%	每个 PR
端到端测试	通过完整技术栈验证关键用户旅程	QA/SDET	Playwright/Cypress	占所有测试的 5-10%	部署前 + 每晚
API 测试	契约合规性、架构、错误处理	开发人员	Playwright APIRequestContext/Schemathesis	每个端点	每个 PR
视觉测试	UI 回归、布局偏移、响应式表现	QA	Playwright/Argos/Chromatic	关键页面	每晚
性能测试	响应时间、吞吐量、资源使用情况	DevOps/QA	k6/Lighthouse	关键路径	每周 + 发布前
安全测试	OWASP Top 10、依赖项漏洞、身份验证流程	安全/DevOps	OWASP ZAP/Snyk	每次发布	发布前 + 定期
无障碍测试	WCAG 2.2 AA、屏幕阅读器兼容性	QA/前端	axe-core	关键流程	每个 PR

根据产品的实际需求进行调整。并非每个产品都需要视觉回归测试，但每个产品都需要单元测试和集成测试。

3. 测试金字塔分析

诊断当前形态，然后定义目标。

形态。 测试套件有四种形态之一：健康金字塔（单元测试多，端到端测试少）、冰淇淋筒（倒置，端到端测试占主导）、菱形（集成测试占主导）或沙漏（单元测试多、端到端测试少，且缺少中间的集成测试）。每种形态都代表不同的反馈与维护权衡。请参阅 references/diagrams-and-worksheets.md 中并排展示的 ASCII 图。

当前状态。 统计各级测试的数量，计算占比，识别形态，然后记录 CI 耗时、测试不稳定率和通过率。请参阅参考文件中的“当前状态评估工作表”。

目标状态。 定义目标比例（单元测试占 70-80%，集成测试占 15-20%，端到端测试占 5-10%）及具体数量，并设定目标 CI 耗时和测试不稳定率。请参阅“目标状态工作表”。

行动计划——适用于冰淇淋筒或菱形：

1. 冻结端到端测试增长——除非要覆盖全新的关键路径，否则不新增端到端测试。
2. 拆解现有端到端测试——找出那些验证了可在单元测试级别测试的逻辑的端到端测试（例如，将验证税费计算的结账测试改为针对税费函数的单元测试），并将其改写为较低级别的测试。
3. 在 PR 检查清单中加入单元测试要求——每个涉及业务逻辑的 PR 都必须附带单元测试。
4. 设置 CI 门禁——当单元测试与端到端测试的比例低于阈值时，使 PR 检查失败。

在重新平衡之前，先区分真正不稳定的端到端测试和暴露实际错误的测试——隔离一个掩盖竞态条件的不稳定测试，可能导致回归问题漏网。有关测试不稳定的根因排查和隔离机制，请参阅 test-reliability。

行动计划——适用于沙漏：

1. 投入集成测试基础设施——数据库测试夹具、服务桩和契约测试。
2. 识别服务边界——每个边界都需要涵盖成功路径和错误情况的集成测试。
3. 使用契约测试（Pact）测试服务间通信。

4. 风险评估矩阵

将功能映射到风险等级——这会直接决定测试深度。为每项功能评分：影响（1 轻微 → 5 灾难性）× 可能性（1 罕见 → 5 几乎确定）；乘积（1-25）对应 LOW/MED/HIGH/CRIT 风险区间。完整的 5x5 矩阵及每个单元格的标签，请参阅 references/diagrams-and-worksheets.md。

风险等级	测试措施	自动化	监控
CRITICAL (15-25)	全面自动化 + 手动探索性测试 + 负载测试	强制执行，每次提交都运行	实时告警、合成监控
HIGH (10-14)	全面自动化 + 定期手动审查	强制执行，每个 PR 都运行	仪表板 + 每日检查
MEDIUM (5-9)	对成功路径 + 关键错误情况进行自动化测试	建议执行	每周审查
LOW (1-4)	手动测试或跳过	可选	无需监控

映射示例：

功能领域	影响	可能性	评分	测试方法
支付处理	5 - 灾难性	3 - 可能	15 - CRIT	自动化端到端测试 + 单元测试 + 契约测试 + 监控
用户身份验证	5 - 灾难性	2 - 不太可能	10 - HIGH	自动化端到端测试 + 安全扫描 + 单元测试
商品搜索	3 - 中等	3 - 可能	9 - MED	单元测试 + 集成测试 + 成功路径端到端测试
仪表板渲染	2 - 轻微	3 - 可能	6 - MED	单元测试 + 视觉回归测试
电子邮件偏好设置	1 - 轻微	2 - 不太可能	2 - LOW	手动验证

5. 环境策略

环境	用途	测试类型	数据	部署触发条件
本地	开发者反馈	单元、集成	模拟/预置	保存时
CI	自动化验证	单元、集成、代码检查、SAST	临时	推送/PR 时
预发布	生产前验证	E2E、视觉、性能、安全	类生产环境（已匿名化）	合并到 main 时
生产	监控与冒烟测试	冒烟测试、合成监控	实时	部署时

请记录：各环境如何管理测试数据、环境是临时的（预览部署）还是长期运行的、谁有访问权限，以及如何管理特定环境的配置。

6. 工具选择理由

不要先挑选工具。先了解需求，再选择合适的工具。根据加权标准为每个候选工具评分。

标准（权重）	工具 A	工具 B	工具 C
适配技术栈（25%）
团队熟悉度（20%）
社区与文档（15%）
CI 集成（15%）
维护成本（10%）
执行速度（10%）
许可成本（5%）
加权总分

每项按 1–5 分评分，乘以权重后求和，得出加权总分。除许可费用外，还应考虑总拥有成本：设置时间（配置 CI、编写首批测试、培训团队）、编写时间（编写 5 个真实测试并测量耗时）、维护时间（框架更新时测试出错的频率）、调试时间（清晰的错误信息可以缩短调试时间），以及基础设施成本（浏览器集群、并行运行器）。

常见技术栈起点——请记录选择这些工具或偏离这些方案的原因：

产品类型	单元测试	集成测试	E2E	API	视觉
React SaaS	Vitest	Testing Library + MSW	Playwright	Supertest	Playwright 截图
Next.js	Vitest	Testing Library + MSW	Playwright	Supertest	Playwright 截图
Python API	pytest	pytest + Testcontainers	pytest + requests	Schemathesis	不适用
移动端（RN）	Jest	Testing Library + MSW	Detox / Maestro / Appium 3.x	Supertest	Appium 截图
Vue SaaS	Vitest	Testing Library + MSW	Playwright	Supertest	Playwright 截图
AI/LLM 功能	Vitest	DeepEval	Playwright + Promptfoo 评估	Promptfoo / Ragas	不适用

对于 AI/LLM 功能，请增加针对幻觉、偏见、提示词注入和隐私的明确风险测试——参见 ai-system-testing 和 compliance-testing（EU AI Act）。

参考框架：

• CTAL-AT v2.0（ISTQB，Advanced Agile Tester，2026）——一项新的高级认证，要求先取得 CTFL v4.0；它并非对先前高级认证的更新，而是取代已退役的基础级 CTFL-AT Agile 扩展（其内容已纳入 CTFL v4.0）。涵盖测试策略与方法、全员参与的方法、左移、端到端测试、测试异味、探索式测试与 AI 辅助测试。
• CT-GenAI v1.1（ISTQB，发布于 2026-04-27）——将由 LLM 驱动的测试基础设施确立为一门学科；定义 AI 特有的风险类别（幻觉、推理错误、偏见、隐私、AI 法规）。
• CTFL v4.0（ISTQB）——基础术语；适用于统一来自不同测试传统的团队。
• HTSM v6.3（Bach）——启发式测试策略模型；强调基于状态的测试和边界启发法。是 ISTQB 框架的轻量级替代方案。
• World Quality Report 2025-26（Capgemini，第 17 版）——基准数据：43% 的组织正在 QA 中试用生成式 AI，15% 已扩大应用规模。可用于规划时判断 AI 采用阶段。

7. CI 扩展手段

随着测试套件或团队规模扩大，CI 的总耗时会成为制约策略的瓶颈。先尝试以下手段，再考虑删除测试：

• 分片 — 将测试套件拆分到 N 个并行运行器上（Playwright --shard=1/4、Jest --shard、pytest-xdist、Cypress 并行化）。只要每个分片的固定开销（安装、构建）尚未占据主导，就能实现线性提速。
• 测试影响分析 — 每个 PR 只运行受代码差异影响的测试，而不是整个测试套件。可通过依赖图（Nx affected、Vitest --changed、Bazel）或覆盖率到文件的映射来实现。保留每晚或合并门禁中的完整测试套件，避免测试失效。
• 缓存 — 在不同运行之间缓存依赖项、构建产物和浏览器二进制文件。
• PR 上选择性运行 E2E — PR 上运行冒烟 E2E 测试，合并时或每晚运行完整 E2E 测试。

衡量实际收益，不要想当然。并行效率 = 测试运行时间总和 ÷ 实际耗时；目标是接近分片数（例如，4 个分片时 >3x）。数值偏低说明固定设置开销或耗时最长的测试正在抵消提速效果。跟踪 每个 PR 的 CI 分钟数，以发现那些虽缩短实际耗时、却大幅增加计费计算量的并行化方案。

8. 准入/退出标准

明确每个级别开始测试前（准入）和完成测试前（退出）必须满足的条件。

单元测试 — 准入：代码可编译，函数具有文档化的契约（输入/输出）。退出：覆盖所有分支，测试边界情况，没有跳过的测试，达到覆盖率目标。

集成测试 — 准入：单元测试通过，依赖的服务可用或已使用桩替代，测试数据已准备就绪。退出：测试所有服务边界，验证错误路径，没有不稳定测试。

E2E 测试 — 准入：集成测试通过，已部署到预发布环境，已配置测试账号。退出：所有关键用户流程通过，没有未解决的 P0/P1 缺陷，性能符合 SLA。

发布 — 准入：所有测试级别均通过，没有未解决的 CRITICAL/HIGH 缺陷，已起草发布说明。退出：生产环境冒烟测试通过，监控在约定的观察窗口内未发现异常（30 min 是合理的默认值，可根据部署频率和告警延迟调整），回滚方案已验证。

9. 质量门禁与完成定义

通过自动化门禁，阻止不合格代码继续推进。

PR 门禁（每个 PR）：单元测试通过；集成测试通过；覆盖率没有下降（或达到最低要求）；没有新增 lint 错误；SAST 扫描通过（没有新增高危/严重问题）；包体积在阈值范围内；至少一位审查者批准。

合并门禁（合并到 main）：所有 PR 门禁检查均通过；针对预览部署的 E2E 冒烟测试套件通过；没有合并冲突；分支已与 main 同步。

部署门禁（生产部署前）：预发布环境中的完整 E2E 测试套件通过；性能基准在范围内；安全扫描通过；功能标志已配置；回滚方案已记录并测试。

每晚门禁（定时运行）：包含边界情况的完整 E2E 测试；视觉回归测试；性能/负载测试；无障碍扫描；依赖项漏洞扫描。次日上午由 QA 负责人审查结果。

每项门禁都要明确具体的通过/失败阈值，并在 CI 中强制执行——可以点击跳过的门禁只是文档，不是真正的门禁。

10. 指标与 KPI

指标	定义	目标	周期
代码覆盖率	单元测试 + 集成测试覆盖的行数/分支数	关键服务 >80%，整体 >60%	每个 PR
测试金字塔比例	单元测试：集成测试：端到端测试的比例	70:20:10（容差 ±10%）	每月
不稳定率	出现非确定性故障的运行占比	<2%	每周
缺陷逃逸率	生产环境中发现的缺陷占缺陷总数的比例	<5%	每次发布
MTTR	从发现问题到部署修复的时间	P0 <4 小时，P1 <24 小时	每次事故
CI 流水线时长	从推送到出现成功/失败信号的时间	PR <15 分钟，完整流水线 <30 分钟	每周
CI 并行效率	测试总时长 ÷ 实际经过时间	接近分片数量（4 个分片时 >3 倍）	每周
每个 PR 的 CI 分钟数	每次 PR 运行计费的计算分钟数	持平或下降	每月
缺陷密度	每 1000 行代码中的缺陷数	呈下降趋势	每月
自动化率	已自动化的测试用例占比	回归测试套件 >80%	每季度
误报率	并非真实缺陷的失败占比	<5%	每周

使用指标： 跟踪一段时间内的趋势，而不是绝对数值——团队的覆盖率从 30% 提高到 60%，就已经表现出色。根据当前状况设定切合实际的目标（一个季度内从 20% 提高到 90% 是幻想，不是计划）。每季度与管理层一起评审，并庆祝进步。调查指标骤升的情况——不稳定率突然上升，说明问题出在基础设施，而不是团队懒惰。绝不要用指标惩罚团队。参见 qa-metrics，了解完整的 KPI 定义、DORA 指标和仪表板。

11. 时间线与里程碑

分阶段推出。试图一次性完成所有工作，结果只会是什么都做不好。

阶段 1 — 奠定基础（第 1-4 周）： 评估所有产品领域的风险；搭建带有单元测试门禁的 CI 流水线；记录基线指标（覆盖率、不稳定率、流水线时长）；为风险最高的前 5 个领域编写单元测试；选择并配置端到端测试框架。退出标准：CI 在每个 PR 上运行单元测试，并记录基线指标。

阶段 2 — 扩大覆盖（第 5-10 周）： 为所有服务边界编写集成测试；为最关键的 10 个用户流程编写端到端测试；为关键页面进行视觉回归测试；管理测试数据；安排夜间运行。退出标准：所有关键路径均有端到端测试覆盖，集成测试覆盖所有 API。

阶段 3 — 质量门禁（第 11-14 周）： 在 PR 上设置覆盖率门禁（不得降低）；在 CI 中加入性能基准测试；进行安全扫描；为所有 KPI 设置监控仪表板。退出标准：四道门禁（PR、合并、部署、夜间）全部启用并强制执行。

阶段 4 — 优化（第 15-20 周）： 修复不稳定测试或将其隔离；采用 CI 扩展手段（分片、缓存、测试影响分析）；在生产环境进行合成监控；进行首次季度策略评审。退出标准：CI 时长低于 15 分钟，不稳定率低于 2%，发布首次策略修订版。

持续进行： 每季度评审并修订策略；每月评审指标；持续维护（重构、消除不稳定性、停用测试）。

---

反模式

追求 100% 覆盖率。 超过 80% 后，收益会递减。最后的 20% 意味着测试 getter 和琐碎代码，却忽视真正容易出现 bug 的集成缺口。应根据风险为各模块设定覆盖率，而不是一刀切。

冰淇淋甜筒（倒金字塔）。 E2E 测试太多，单元测试太少。表现：CI 耗时 45 分钟以上、每次 UI 变更都会导致测试失败、没人信任测试套件。解决方法是停止增加 E2E 测试，并将现有 E2E 测试分解到更低层级。

把策略当作一次性文档。 文档写完后从不更新，比没有文档更糟——它会带来虚假的信心。应设置评审触发条件：每季度定期评审、事故发生后、新产品领域上线时、团队组成变更时。

工具优先思维。 “我们应该使用 Playwright”是把工具选择伪装成计划。先明确需要验证什么，再选择合适的工具。文档应说明选择工具的理由，而不是以工具选择开篇。

没有指标，就没有问责。 没有可衡量目标的策略只是愿望清单。每个部分都要关联一个 KPI。如果无法用数字定义成功，就应质疑这一项是否有必要。

孤立地进行测试。 只存在于 QA Wiki 中的策略，开发人员看不到。策略必须体现在 PR 模板、CI 门禁和 Definition of Done 中。如果开发人员每天都看不到它，它就等于不存在。

复制粘贴策略。 原封不动地照搬其他公司的策略，会忽略自身的风险状况、团队技能和约束。模板只是起点；每个部分都应根据实际情况调整。

立即实现全面自动化。 手动探索性测试价值巨大，尤其是在早期阶段。自动化回归测试，保留手动探索。策略应说明哪些测试保留手动执行，以及原因。

---

验证

在将文档视为完成之前，先确认生成的文档完整无缺。针对已保存的策略文件运行：

DOC=docs/qa-strategy.md
# 1. All 13 numbered section headings present (Executive Summary → Revision History)
grep -cE '^### [0-9]+\.' "$DOC"          # expect 13
# 2. Every row in the Metrics & KPIs table has a non-empty Target cell
#    (no "| | " gaps in the target column) — visually scan the table block:
grep -nE '^\|' "$DOC" | grep -iE 'target|coverage|flak|mttr|escape'
# 3. A revision history and a named owner exist
grep -niE 'revision history|owner:' "$DOC"

然后手动检查测试金字塔的比例是否合理：目标单元测试占比 + 集成测试占比 + E2E 测试占比应约为 100%。如果文档建议分片，请确认 Metrics 表中列出了并行效率或 CI 分钟数目标——没有指标的优化只是猜测。

---

完成标准

• 策略文档已保存到约定路径，并且 grep -cE '^### [0-9]+\.' 返回 13（从 Executive Summary 到 Revision History 的所有章节均已填写）。
• 已定义具体数量和达成时间表的测试金字塔目标比例；单元测试 + 集成测试 + E2E 测试的占比合计约为 100%。
• 已为每个层级（单元、集成、E2E、发布）编写准入和退出标准。
• 已通过带评分和权重的理由矩阵记录工具选择，而非仅列出工具名称。
• 已为所有四个阶段（PR、合并、部署、夜间）定义质量门禁，每项都设有具体的通过/失败阈值。
• Metrics & KPIs 中每一行都填写了 Target，且指定了跟踪频率。

相关技能

• risk-based-testing — 首先运行；深入了解风险评估方法以及 AI/LLM 特有的故障类别。此技能会使用其矩阵。
• test-planning — 用于制定单个冲刺或发布的计划；test-strategy 是其上层的多季度总体策略。
• test-reliability — 用于排查不稳定测试的根本原因、实现定位器自愈，以及了解在测试金字塔再平衡步骤中引用的隔离机制。
• qa-metrics — 提供完整的 KPI 定义、DORA 指标、Test Impact Analysis、仪表板和趋势分析。
• release-readiness — 提供发布决策检查清单、金丝雀分析和发布信心评分。
• ci-cd-integration — 用于配置流水线、实现门禁和设置智能分片。
• shift-left-testing — 用于了解提前验证的相关技术。
• ai-system-testing — 当策略涵盖 AI/LLM 功能时，用于定义评估套件层。
• compliance-testing — 当策略面向受监管行业时使用（GDPR、EU AI Act、EAA、美国各州法律）。

参考文件（位于 references/ 中）

• diagrams-and-worksheets.md — 金字塔形状图、当前状态／目标状态工作表、完整的 5x5 风险矩阵，以及包含 13 个部分的输出框架。
• strategy-templates.md — 四份完整的策略文档（SaaS、电商、API 优先、媒体），以及分步式金字塔分析工作表和风险矩阵功能清单模板。