测试工作量估算清单把“拍脑袋报一个总人天”变成可逐行复核的表格：每一行是一个可独立估算的测试工作包，列上记录它的范围依据、复杂度、复用程度、执行轮次、人天和缓冲，最后按测试类型与阶段汇总。下面给出一张可直接复制填写的空白模板，并说明估算项怎么拆、哪些字段必填、如何汇总与维护。
要点总览（TL;DR）
- 估算清单以“估算单元”为行、以“范围依据与工作量”为列，按测试类型分组，每组设小计行，全表末尾设缓冲行与总计行。
- 估算项拆到“可独立说明范围、可独立判断工作量、可独立验收结果”的工作包粒度，先按测试类型分组，组内再按需求或模块拆行。
- 测试类型、估算单元、范围依据、执行轮次、单轮人天、风险缓冲为必填；需求/模块、复杂度、复用度、假设备注、估算人/日期按项目规模与风险补充。
- 汇总可按测试类型、阶段、模块三种口径，缓冲单独成行且不与其他工作量混算，避免重复计入。
- 清单在执行中按版本维护，记录实际人天与估算偏差，作为下一版本同类工作包的参考依据。
可复制空白估算清单模板
这张表以“估算单元”为行，按测试类型分组，每组末尾留小计行，全表末尾留缓冲行与总计行。复制到表格软件后，先填测试类型与估算单元，再逐列补齐依据与工作量。
| 序号 | 测试类型 | 需求/模块 | 估算单元（工作包） | 范围依据 | 复杂度（高/中/低） | 复用度（高/中/低） | 执行轮次 | 单轮人天 | 小计人天 | 风险缓冲（人天） | 假设与备注 | 估算人/日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 功能测试 | |||||||||||
| 2 | 功能测试 | |||||||||||
| 3 | 接口测试 | |||||||||||
| 4 | 性能测试 | |||||||||||
| 5 | 兼容性测试 | |||||||||||
| 6 | 回归测试 | |||||||||||
| 功能测试小计 | ||||||||||||
| 接口测试小计 | ||||||||||||
| 性能测试小计 | ||||||||||||
| 兼容性测试小计 | ||||||||||||
| 回归测试小计 | ||||||||||||
| 风险缓冲合计（按类型小计的约定比例或逐项累加） | ||||||||||||
| 测试工作量总计（各类型小计＋缓冲） | ||||||||||||
使用说明：小计人天＝单轮人天×执行轮次；缓冲行放在各类型小计之后、总计之前，避免缓冲被重复计入某一类型；假设与备注列必须写清估算所依赖的条件，例如“基于现有用例库”“不含环境搭建”。
估算项怎么拆：字段说明与拆分口径
估算项拆得对不对，直接决定清单能否复核。判断标准是：一行对应一个可独立说明范围、可独立判断工作量、可独立验收结果的工作包。拆到“某模块功能测试”这种笼统层级，复核时只能争论；拆到“某按钮点击一次”这种过细层级，行数膨胀、填写成本高于估算收益。
| 字段 | 含义 | 填写要点 |
|---|---|---|
| 测试类型 | 该工作包所属的测试活动类别 | 功能、接口、性能、兼容、回归等，与汇总口径一致 |
| 需求/模块 | 工作包对应的需求编号或功能模块 | 便于按模块汇总，也便于需求变更时定位受影响行 |
| 估算单元 | 可独立估算与复核的工作包名称 | 用“动词＋对象”描述，如“订单创建接口用例设计与执行” |
| 范围依据 | 工作量从何而来 | 用例条数、接口个数、场景数、设备组合数等可点数 |
| 复杂度 | 业务逻辑、数据状态、依赖关系的难易 | 高/中/低，用于解释同类工作包之间的单轮人天差异 |
| 复用度 | 可复用的用例、脚本、数据、环境比例 | 高/中/低，复用度高则单轮人天相应下调 |
| 执行轮次 | 预计执行几轮 | 与提测轮次、回归策略挂钩，写明轮次假设 |
| 单轮人天 | 完成一轮所需人天 | 含用例设计、执行、缺陷记录与复测 |
| 小计人天 | 单轮人天×执行轮次 | 公式列，避免手工加总出错 |
| 风险缓冲 | 应对需求变更、环境阻塞、缺陷集中的预留 | 按行或按类型设置，写明比例或依据 |
拆行时同时使用两个维度：先按测试类型分组，保证汇总口径清晰；组内再按需求或模块拆行，保证每行能追溯到具体范围。一个需求如果同时涉及功能与接口测试，就拆成两行，分别填写各自的依据与人天，而不是合并成一行再按比例估算。
拆分粒度的三个检查问题：这一行能否说清“测什么、测多少”；换一个人能否根据范围依据独立复核人天；这一行完成后是否有可观察的产出，例如用例集、执行记录、缺陷清单。三个问题都能回答，粒度基本合适。
必填与选填字段的取舍
清单字段越多，填写越完整，也越容易在项目压力下被跳过。建议把字段分成两档：必填字段保证估算可复核、可汇总；选填字段按项目规模与风险补充。
| 字段 | 档位 | 缺失后果 | 适用场景 |
|---|---|---|---|
| 测试类型 | 必填 | 无法按类型汇总，资源分配失去依据 | 所有项目 |
| 估算单元 | 必填 | 行无法识别，复核无从谈起 | 所有项目 |
| 范围依据 | 必填 | 人天缺乏来源，争议时无法回溯 | 所有项目 |
| 执行轮次 | 必填 | 小计失真，回归工作量被低估 | 所有项目 |
| 单轮人天 | 必填 | 无法计算小计 | 所有项目 |
| 风险缓冲 | 必填（可填0并说明） | 总工作量偏乐观，缺少应对空间 | 所有项目 |
| 需求/模块 | 选填 | 无法按模块汇总与追踪变更 | 多模块并行、需求频繁变更的项目 |
| 复杂度 | 选填 | 同类工作包人天差异缺少解释 | 业务逻辑复杂或首次承接的项目 |
| 复用度 | 选填 | 复用收益无法体现，估算偏保守 | 有存量用例库、自动化脚本的项目 |
| 假设与备注 | 选填（建议填） | 估算前提丢失，后续调整缺少依据 | 依赖外部环境、第三方接口的项目 |
| 估算人/日期 | 选填 | 无法追溯谁在何时基于什么信息估算 | 多人协作估算、需要评审的项目 |
裁剪建议：小型项目或单版本迭代，保留必填字段加假设备注即可，控制在十行以内；中型项目增加需求/模块与复杂度，便于按模块汇总和解释差异；跨团队或外包协作的项目补齐复用度、估算人与日期，让复核方能看到估算过程。字段裁剪要在清单头部注明，避免不同版本清单混用后口径不一致。
填写示例：一个版本的功能与接口测试估算
以下为演示情景，数据仅用于说明字段如何联动，不代表任何真实项目的工时结论。假设条件：某版本包含订单模块与支付接口改造；已有部分回归用例可复用；计划功能测试执行两轮、接口测试执行三轮；按类型设置10%的风险缓冲。
| 序号 | 测试类型 | 需求/模块 | 估算单元 | 范围依据 | 复杂度 | 复用度 | 执行轮次 | 单轮人天 | 小计人天 | 风险缓冲 | 假设与备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 功能测试 | 订单模块 | 订单创建与取消用例设计与执行 | 新增用例40条 | 中 | 低 | 2 | 2.0 | 4.0 | 0.4 | 含缺陷复测 |
| 2 | 功能测试 | 订单模块 | 订单列表与筛选回归 | 存量用例60条 | 低 | 高 | 2 | 0.5 | 1.0 | 0.1 | 复用现有用例 |
| 3 | 接口测试 | 支付接口 | 支付下单与回调接口用例设计与执行 | 接口8个、场景20个 | 高 | 低 | 3 | 1.5 | 4.5 | 0.5 | 依赖第三方沙箱环境 |
| 4 | 接口测试 | 支付接口 | 支付查询接口回归 | 接口3个、存量脚本可复用 | 低 | 高 | 3 | 0.3 | 0.9 | 0.1 | 脚本已存在 |
| 功能测试小计 | 5.0 | 0.5 | |||||||||
| 接口测试小计 | 5.4 | 0.6 | |||||||||
| 测试工作量总计 | 10.4 | 1.1 | 合计11.5人天 | ||||||||
计算过程：功能测试小计＝4.0＋1.0＝5.0人天，缓冲按10%计0.5人天；接口测试小计＝4.5＋0.9＝5.4人天，缓冲0.6人天；总计＝5.0＋5.4＋0.5＋0.6＝11.5人天。示例中第2、4行复用度高，单轮人天明显低于同类新写工作包，这正是复用度字段的作用——让复核者看到差异来自哪里，而不是只看到一个总数。
汇总口径与复核调整方法
同一张清单可以按三种口径汇总，用途不同，建议在表头固定一种作为主口径，其余作为辅助视图。
| 汇总口径 | 计算方式 | 主要用途 |
|---|---|---|
| 按测试类型 | 各类型小计相加，再加缓冲 | 判断功能、接口、性能等活动的资源配比 |
| 按阶段 | 按用例设计、执行、回归等阶段拆分人天后相加 | 排入版本计划，对齐提测与发布节点 |
| 按模块 | 按需求/模块列分组求和 | 识别高工作量模块，安排重点评审与人力 |
缓冲的计入方式有两种：按类型小计设置统一比例，适合历史数据较充分、波动可预期的项目；逐行填写风险缓冲并写明依据，适合新业务或外部依赖多的项目。两种方式不要在同一张表里混用，否则总计会出现重复计算。缓冲是应对不确定性的预留，应在清单中单独成行，不与常规工作量合并隐藏。
清单进入执行阶段后需要维护，建议遵循以下规则：
- 每次提测或需求变更后，更新受影响行的范围依据与执行轮次，并在备注中记录变更原因。
- 每轮测试结束后记录实际人天，与估算人天对比，偏差超过约定阈值（例如20%）的行标注原因。
- 版本结束时保留估算版本与实际版本的对照，作为下一个版本同类工作包的参考依据。
- 清单按版本存档，修订时保留历史行，避免覆盖后无法追溯估算演变。
当估算清单需要多人共同填写、按版本持续更新时，可以把每行估算单元落到工作项上承载：在 ONES 中为估算单元建立工作项，填写预估工时，按测试类型与模块设置字段，执行后登记实际工时，再用视图按类型或模块汇总预估与实际工时。这样清单的汇总口径与项目中的工时数据保持一致，偏差记录也有据可查，版本迭代时可以直接对照上一版本的估算与实际结果调整下一版清单。
常见问题
估算清单里的“执行轮次”怎么确定，写少了会怎样？
执行轮次与提测轮次、回归策略挂钩，通常在估算时按计划提测次数和回归范围给出假设，并在备注中写明。写少了会直接压低小计人天，回归工作量被低估，后续补测时清单失去参考价值。建议按“功能测试两轮、接口测试三轮”这类可说明的假设填写，需求变更或提测延期时同步更新轮次并记录原因。
小型项目字段太多填不完，最少保留哪些列？
小型项目或单版本迭代可保留测试类型、估算单元、范围依据、执行轮次、单轮人天、风险缓冲六项必填字段，再加一列假设与备注，控制在十行以内。需求/模块、复杂度、复用度、估算人/日期可以裁剪，但要在清单头部注明裁剪了哪些字段，避免与其他版本清单混用后汇总口径不一致。
风险缓冲按类型统一比例算，还是逐行填写？
两种方式各有适用条件：历史数据较充分、波动可预期的项目，按类型小计设置统一比例更省填写成本；新业务或外部依赖多的项目，逐行填写缓冲并写明依据更便于复核。关键是同一张表内只选一种方式，缓冲单独成行放在各类型小计之后、总计之前，避免与常规工作量合并后重复计算。
估算清单和测试计划是什么关系，需要各做一份吗？
估算清单回答“这项工作大概需要多少人天、依据是什么”，测试计划回答“什么时候测、谁来测、按什么策略测”。两者可以分开维护，也可以在测试计划中引用估算清单的汇总结果作为资源与排期输入。清单侧重工作量来源与复核，计划侧重范围、进度与责任分工，衔接点是按测试类型和阶段汇总后的人天数据。
实际人天和估算偏差较大时，清单怎么调整？
建议每轮测试结束后记录实际人天，与估算人天对比，偏差超过约定阈值（例如20%）的行标注原因，例如需求变更、环境阻塞、缺陷集中。版本结束时保留估算版本与实际版本的对照，不覆盖历史行。下一版本同类工作包可参考上一版本的实际数据调整单轮人天或缓冲比例，让清单逐步贴近团队真实投入。
