模板包含什么
注意执行的那几根条是重叠的，而缺陷闭环那根条贯穿它们的全长。一份真实的测试进度图，就长这样：
- 测试策划与判据 — 测试策略、范围与基于风险的优先级排序，在执行开始之前就写下来的各阶段准入与准出判据，工作量估算与人力计划。里程碑：测试计划与判据获批。
- 环境与测试数据就绪 — 真正的门禁所在。环境搭建、配置与挡板服务、测试数据准备与脱敏、账号与权限开通，以及一次在任何人开始测之前先证明环境可用的冒烟测试。里程碑：环境准入判据达成。
- 测试设计与自动化 — 测试条件与用例设计、与需求的双向追溯、自动化框架、回归套件建设与性能脚本。里程碑：用例具备执行条件。
- 执行——单元、集成、系统 — 重叠推进的执行波次，而不是排队：单元与组件测试、集成与接口测试，然后是系统测试与安全测试。里程碑：系统测试准出判据达成。
- 缺陷定级、修复与重测闭环 — 真正消耗日历的那个回路——每日缺陷评审会、严重级别判定、修复批次、重测与回归影响分析，以及遗留缺陷的处置决定。里程碑：缺陷阈值达标。
- UAT、回归与发布就绪 — 由业务用户执行的用户验收测试、全量回归、性能与压力测试，以及发布就绪评审与签批。里程碑：发布签批。
测试排期最常见的失败，是把环境和测试数据当成一项任务，而不是一道门禁。如果环境不稳，或者数据支撑不了场景，测试人员照样在记工时，但他们提的是环境的缺陷而不是产品的缺陷——那些工时是找不回来的。把环境准入判据写下来，跑一次冒烟测试去对它，判据没过就拒绝开始执行。第二个失败，是把缺陷闭环当成余量来排。修复与重测不是测试周边的开销；在多数项目上，它是图上最长的一根条，就应当画成一根条。
如何调整
- 把真实的准入与准出判据写进每个阶段行的备注里——通过率、按严重级别统计的未关闭缺陷数、覆盖率——好让门禁是可核对的，而不是一句口号。
- 执行波次按你的构建节奏重叠；首尾相接地排队，几乎总是高估总工期、低估风险。
- 缺陷闭环的长度按你自己历史上的缺陷发现率和修复速度来估，不要按测试工作量的一个百分比来估。
- 如果集成测试依赖各自掌控环境的合作方，每个接口或被集成系统各加一行。
- 如果你是增量发布而不是一次性投产，UAT 按模块提前。
- 在回归之前加一行代码冻结，并把回归放在它之后——对着一个还在变的构建做的回归，不是回归。
排期建议
- 准出判据要能用数字判定。"测试完成"不是门禁；"零个未关闭的一级缺陷、二级少于五个、计划用例执行率 95%"才是。
- 测试数据要在设计收尾之前就准备好。设计者会发现数据缺口，而数据准备是整份计划里周期最长的一项。
- 执行高峰期要每天评审缺陷。每周开一次评审会，意味着一个缺陷可能躺五天都没人决定该谁修。
- 把回归和修复流隔开。每一个后来的修复都会让一部分回归结果作废，代码冻结那一行就是为此存在的。
- 盯缺陷发现率，不盯缺陷总数。发现率在下降，才是一个阶段正在收敛的诚实信号；一个原始计数几乎什么都说明不了。
相关模板
本模板为中文。尚未翻译的相关页面会以英文打开。
常见问题
测试计划里的准入与准出判据是什么？
准入判据是一个测试阶段可以开始之前必须成立的条件——环境稳定、构建已部署、测试数据已加载、冒烟测试通过。准出判据是它可以宣告结束之前必须成立的条件——执行覆盖率、通过率、按严重级别统计的未关闭缺陷数。两者都应当是数字化的、在执行开始前就谈定的，并且真的被执行。
测试阶段为什么重叠而不是串行？
因为构建是增量到达的。已经完成单元测试的模块就可以开始集成测试，已经打通的业务流程可以先做 UAT，同时其他部分的系统测试还在继续。首尾相接地排队会把工期吹大，还会把真正的约束藏起来——那个约束通常是修复与重测闭环。
缺陷修复该留多少时间？
按你自己的历史来估：每个测试日发现多少缺陷、其中多大比例需要修复、以及平均的"修复加重测"周转时间。在多数项目上，这个回路是图上最长的一根条。按测试工作量拍一个固定百分比，是进度滑掉的常见方式。
测试环境没就绪怎么办？
不要开始执行。对着一个不稳定的环境测，产出的是环境缺陷而不是产品缺陷，而且这些时间找不回来。模板把环境就绪做成一个前面带冒烟测试的门禁里程碑，正是为了让这个决定被看见，而不是被无声地吸收掉。
UAT 应该什么时候开始？
在 UAT 要覆盖的那部分范围达成系统测试准出判据之后——而不是等所有地方的系统测试全部做完。UAT 是业务侧的确认，需要稳定的构建和形态真实的数据；对着一个还在接收修复的构建跑 UAT，浪费的是业务用户，而他们是这份计划里最稀缺的资源。
这份测试计划模板免费吗？
免费。可免费下载 Excel、PowerPoint 和 CSV，也可免费在线编辑，无需注册。