test-planning

为冲刺和发布制定可执行的测试计划。测试计划要回答四个问题：测试什么、测试得多深入、由谁负责，以及何时必须完成。计划应是一份跟踪进度、持续更新的文档，而不是归档后便被遗忘的官僚文件。如果把所有可用时间都排满，找到第一个 Bug 时计划就会失效——预留缓冲时间并做好优先级排序，才能让计划经受现实考验。

快速指引

情况	前往
规划单个冲刺	参照以下第 1-6 步，然后使用 references/plan-documents.md 中的单页冲刺模板
规划发布	使用 references/plan-documents.md 中的发布模板；是否发布的决策本身应由 release-readiness 负责
跟踪正在执行的计划／反馈结果	参阅 references/tracking-formats.md（每日状态 + 回顾）
容量超出时决定砍掉哪些内容	第 4 步优先级矩阵

---

调研问题

编写测试计划前，先收集背景信息。先检查 .agents/qa-project-context.md——如果该文件存在，就以其为基础，并跳过其中已有答案的问题。

范围

• 范围是什么？（单个冲刺、发布、热修复、功能）
• 哪些功能是新增、变更或未变更的？
• 哪些功能是首次发布？
• 是否有基础设施或依赖项变更（数据库迁移、API 版本升级、切换第三方服务提供商）？
• 是否有可用于对照的需求文档、PRD 或用户故事？

时间和资源

• 测试窗口有多长？（可用天数、小时数）
• 有哪些人员可参与测试？（SDET、手动测试人员、开发人员）
• 是否有可能成为瓶颈的共享资源？（预发布环境、测试账号、设备）
• 是否有无法更改的硬性截止日期，还是发布日期可以灵活调整？

风险背景

• 本周期哪些领域的变更最多？
• 上次发布或冲刺中有哪些问题？
• 是否存在会增加风险的已知脆弱领域或技术债务？
• 关于基于风险的优先级排序方法，请参阅 risk-based-testing。

现有覆盖情况

• 对于范围内的功能，现有哪些自动化测试？
• 自动化测试套件当前的通过率是多少？
• 是否存在需要手动测试的自动化覆盖缺口？
• 上次对这些功能开展探索性测试是什么时候？

---

核心原则

1. 以覆盖率为导向：每项需求至少映射一个测试

无法追溯到需求的测试计划只是猜测。每个用户故事、验收标准或需求都必须映射到至少一个测试用例。映射中的缺口就是未测试的需求——这是最危险的风险类型。

2. 设定时间盒：计划须符合可用时间窗口

如果不设限，测试会不断扩展，直至占满所有可用时间。为每项活动设定时间盒并严格遵守。当时间窗口过短时，应由优先级矩阵决定砍掉什么，而不是凭直觉决定。

3. 排定优先级：并非所有内容都需要同等深度的测试

支付流程变更和工具提示修复不应投入同等精力。使用风险 × 工作量矩阵分配测试深度：有些功能需要全面回归测试，有些只需冒烟测试；对于风险低且未变更的功能，有些甚至无需测试。

4. 预留缓冲：为意外情况留出空间

找到 Bug 时，排满 100% 可用时间的计划就会失效。计划工作只占测试窗口的 70-80%，并明确预留剩余 20-30% 的时间用于 Bug 验证、重新测试和计划外调查。如果计划中没有明确列出缓冲时间，就等于没有预留。

5. 信息透明：计划是沟通工具

开发人员需要了解测试范围，才能编写便于测试的代码。产品经理需要了解覆盖情况，才能决定是否发布。应将计划发布到团队所有成员都能查看的位置。

6. 入口和退出标准至关重要

任何计划中最常被复用的部分都是门槛。要明确写出，而不是将其埋在其他内容中：入口 = 代码已在预发布环境完成 + 现有测试套件全部通过 + 测试数据已准备就绪；退出 = 所有高风险区域均已覆盖 + 没有未解决的 P0/P1 问题 + 覆盖矩阵中没有无法解释的 GAP 行。其他内容都是围绕这两个检查点的细节。

---

工作流

六个工作流步骤各自都有一个填空式框架。决策说明放在这里；可复制粘贴的模板（分解、覆盖矩阵、估算工作表、优先级矩阵、分配表、时间表）位于 references/workflow-templates.md。

步骤 1：功能分析与分解

将每个范围内的功能拆分为可测试单元。“可测试单元”指可通过明确的通过/失败结果进行验证的特定行为。逐一检查每项功能是否涵盖以下场景类别，确保没有遗漏：

• 正常路径 — 主要成功流程。
• 验证 — 必填字段为空、格式违规、边界值。
• 错误情况 — 服务器 5xx、网络超时、输入被拒绝。
• 边缘情况 — Unicode、超大载荷、不受支持的格式。
• 并发 / 竞态条件 — 两名用户同时编辑同一条记录、重复提交、超时后重试。这些情况往往隐藏着最严重的数据损坏错误，也是最常被遗漏的类别。
• 集成点 — 功能跨越的每个边界上的行为。

请参阅 references/workflow-templates.md，了解分解模板，以及涵盖全部六种类别的“用户资料编辑”示例。

AI 分解交叉检查。 Agent 分解功能后，应立即要求它将自己的场景映射回步骤 2 的覆盖矩阵。任何没有对应场景的需求，或上述任何没有对应条目的场景类别，都是分解缺口；Agent 必须在估算前指出这些缺口——这样才能发现 Agent 的盲点，而不是等到 CI 发现。

步骤 2：需求到测试的覆盖映射

创建可追溯性矩阵，将每项需求映射到对应的测试用例。请参阅 references/workflow-templates.md，了解覆盖矩阵模板。

覆盖矩阵规则：

• 每项需求都必须出现在矩阵中（目标：映射率达到 100%）
• “GAP”状态会触发决策：编写测试、接受风险或延期
• 自动化测试使用测试 ID，并关联到实际的测试文件 / 函数
• 手动测试引用测试用例文档或测试纲要

第 3 步：工作量估算

使用历史数据估算每种测试类型的工作量。如果没有历史数据，请使用以下参考估算值，并在第一个冲刺后进行校准。

估算参考（每个测试用例）：

测试类型	编写时间	执行时间	维护时间（每季度）
单元测试	0.5 小时	< 1 秒	5 分钟
集成测试	1 小时	5-30 秒	15 分钟
端到端测试（Playwright/Cypress）	2-3 小时	30 秒-2 分钟	30 分钟
手动测试用例（编写）	0.25 小时	每次执行 5-15 分钟	10 分钟
探索性测试会话（测试章程）	15 分钟	每次会话 1.5 小时	不适用
无障碍审查（手动）	每个区域 0.5-1 小时	已包含在编写时间中	15 分钟
视觉回归测试	30-60 分钟	10-30 秒	20 分钟（更新基线）
性能测试（k6 脚本）	2-4 小时	每次运行 5-30 分钟	30 分钟
提示词回归 / 大模型评估	每个用例 30-60 分钟	30 秒 - 2 分钟（含 API 费用）	20 分钟
设置和测试数据（每个功能）	0.5-2 小时	一次性	每个环境重新填充

编写时间仅指撰写测试的时间。“设置和测试数据”这一项是规划人员最常遗漏的——环境、测试夹具和模拟配置通常占总工作量的 20-40%，因此应将其作为一项实际工作纳入预算，而不是等到冲刺进行到一半才发现。

使用 AI 编写的权衡。 使用 Agent 编写测试可将编写时间缩短约 40-60%，但应为每个用例增加一项相近规模的审查时间——Bolton 的“AI 生产力悖论”（2026）指出，如果 Agent 交付看似合理但实际有问题的测试，这些测试通过了粗略审查，却在 CI 中失败，那么效率提升就会消失。请参阅 ai-test-generation 的第 7 步，了解审查清单；另请参阅 ai-qa-review，了解测试异味分类。

测试异味审查。 ISTQB 的 CTAL-AT v2.0（2026 年 5 月）将测试异味列为一项规划考量。每个冲刺都应预留 30 分钟定期进行“测试异味审查”，参照 ai-qa-review 中的分类检查——成本低，还能在维护债务不断累积之前将其发现。

使用 references/workflow-templates.md 中的冲刺估算工作表，将每个用例的估算汇总为产能利用率（目标：70-80%，留出 20-30% 的缓冲）。

第 4 步：优先级矩阵（风险 x 工作量）

当估算工作量超出可用产能时（通常如此），请使用风险 x 工作量矩阵决定删减哪些工作。完整矩阵请参阅 references/workflow-templates.md。

对于每个测试用例，根据 risk-based-testing 中的风险评分和第 3 步的工作量估算，将其标记在矩阵上，然后按优先级顺序安排产能：优先执行 → 第二优先执行 → 第三优先执行 → 延后 → 跳过。

**优先级判定规则：**在高风险项目中，低工作量项目优先于高工作量项目——高风险 / 低工作量测试（优先执行）高于高风险 / 高工作量测试（第三优先执行），因为前者每小时能降低更多风险。应先延后中风险项目，再删减任何高风险覆盖；低风险项目可延后或直接跳过。切勿削减缓冲时间来容纳更多计划工作。

第 5 步：资源分配

根据技能匹配度和可用性分配测试工作。

分配原则：

• 自动化测试编写工作交由 SDET 或具备框架经验的开发人员负责
• 探索性测试交由最了解该功能的人员负责（通常是开发人员或产品经理，而不只是 QA）
• 新功能测试应由未参与构建该功能的人员执行，以获得全新视角
• 关键路径测试不应只有一个人能负责——应确保至少有两人可以承担
• 每个人的工作负荷应保持在 70-80% 的利用率，而不是 100%——剩余部分作为其缓冲
• 缓冲按个人分配，而不是集中在某一位测试人员的工作安排中：每位受派人员都应有自己的缓冲时间，这样一人遇到阻塞时，就不会消耗所有人的余量

分配表格式请参阅 references/workflow-templates.md。

第 6 步：安排缓冲时间

将测试活动映射到迭代时间表中。不要把测试都推迟到最后两天。2 周迭代的时间表模板请参阅 references/workflow-templates.md。

关键排期规则：

• 功能完成编码后就立即开始测试，而不是等到迭代结束
• 环境设置和测试数据准备应在第 1 天完成，而不是第 3 天
• 持续验证 Bug，而不是集中处理
• 最后一天用于确认，而不是开始新的测试

---

计划文档

完整的可直接复制粘贴的计划文档位于 references/plan-documents.md：

• 迭代测试计划（1 页）——范围、覆盖率概要、工作量预算、进入/退出标准、计划风险。迭代计划应控制在 1 页。
• 发布测试计划——汇总迭代计划，并补充发布特定关注事项（完整回归测试、跨浏览器测试、性能基准测试、安全扫描、冒烟测试）以及发布/不发布标准。发布/不发布的决策本身应归入 release-readiness。
• 功能覆盖矩阵——按功能列出场景，并注明优先级、测试类型、位置和状态。
• 测试估算工作表——新测试开发、现有测试套件执行、手动测试，以及与可用容量相比的差额汇总。

---

在迭代期间跟踪进度

如果第 1 天之后没人查看，测试计划就毫无用处。每天跟踪进度，并在迭代结束时将结果反馈到后续计划中。

• 每日测试状态——已完成事项、受阻事项、发现的 Bug、明日计划、覆盖率百分比和已使用的缓冲时间。格式请参阅 references/tracking-formats.md。
• 迭代回顾输入——按测试类型细分的估算准确度、覆盖率差额、按严重程度统计的 Bug 数量，以及经验教训。格式请参阅 references/tracking-formats.md；将这些数据点纳入下一次迭代的估算。

---

反模式

未进行风险评估就制定计划

对每个功能投入同等深度的测试，会在低风险区域浪费精力，并导致关键路径测试不足。分配工作量之前，务必先运行优先级矩阵（第 4 步）。完整的风险方法请参阅 risk-based-testing。

未为发现 Bug 留出缓冲时间

将 100% 的可用工时安排用于计划内活动，发现 Bug 后就没有时间进行验证。预留 20-30% 作为缓冲，并每天跟踪使用情况。

将测试都推迟到迭代结束

把所有测试留到最后两天，会导致覆盖仓促，也会让 Bug 太晚才暴露，以至于无法修复。功能一旦可用就开始测试；持续测试胜过在迭代结束时集中测试。

把测试计划当作合规文件

一份存档后便无人问津的 30 页计划毫无帮助。迭代计划应控制在 1 页，并主动跟踪、每日更新。如果计划没有变化，就说明没人使用它。

不依据历史数据进行估算

凭空得出的工作量估算并不可靠。按测试类型跟踪实际耗时，并用这些数据进行后续估算。经过 2-3 次迭代后，估算会变得可靠。

忽略环境和数据设置

环境设置、测试数据创建和模拟配置可能占测试工作量的 20-40%。估算时应纳入第 3 步中的“设置和测试数据”一行，否则计划总会超时。

关键路径仅由一人负责

由单个测试人员负责所有关键路径工作会形成故障点。确保至少有两人能够承担关键路径测试。

---

验证

打开生成的计划并确认：迭代看板中所有范围内的工单 ID 都出现在“范围”表格中；覆盖矩阵没有无法解释的 GAP 行（每个 GAP 都附有接受/延期说明）；分配的容量合计为 70-80%，并且有明确标注的缓冲时间；进入/退出标准检查清单已填写，而不是占位内容。如果其中任一项未通过，计划就尚未完成。

完成标准

• 已创建冲刺或发布测试计划文档（1 页冲刺模板或发布模板），其中范围表、覆盖率摘要、工作量预算以及进入/退出标准均已填写，且没有占位符
• 每项范围内的功能都已拆解为具体、可测试的场景，并设有通过/失败标准，涵盖正常流程、验证、错误、边界和并发类别
• 已创建需求到测试的覆盖率矩阵，且没有未说明的 GAP 条目（每个 GAP 均有接受风险或延期说明）
• 每个场景都已估算，并绘制在风险×工作量矩阵上；延期项目也已明确列出
• 已分配产能的 70-80%，并明确预留 20-30% 的缓冲，且单独列出
• 计划中已记录测试数据需求、环境详情和资源分配

参考文件（位于 references/ 中）

• workflow-templates.md — 六个工作流步骤的填空模板：拆解模板及示例、覆盖率矩阵、冲刺估算工作表、风险×工作量矩阵网格、分配表和 2 周计划。
• plan-documents.md — 可直接复制粘贴的完整文档：1 页冲刺测试计划、发布测试计划、功能覆盖率矩阵和估算工作表。
• tracking-formats.md — 每日测试状态格式和冲刺回顾输入格式（包含各测试类型的偏差）。

相关技能

• test-strategy -- 更全面的 QA 策略，测试计划据此执行；策略定义方法，计划则在每个冲刺中落实策略。
• risk-based-testing -- 风险评估的深入方法，为第 4 步中的优先级矩阵提供依据。
• release-readiness -- Go/No-Go 决策，其依据来自发布测试计划的退出标准；此技能用于制定计划，该技能用于作出发布决策。
• qa-metrics -- 缺陷逃逸率和估算准确度等指标，可用于改进未来的测试计划。
• exploratory-testing -- 计划手动测试部分中提及的结构化探索式测试会话。
• qa-project-context -- 提供发现问题基准答案的项目上下文文件。