按测试阶段和测试类型拆分估算，核心是把总工作量拆成可独立核算的估算单元：阶段维度确定时间窗口，类型维度确定工作内容，两者交叉后逐项赋工时，再按阶段汇总并叠加公共投入。这套方法适合版本测试、项目测试和专项测试的工作量预估。估算结果最终要落到测试计划与工作项中跟踪，ONES 的测试管理支持测试计划与迭代关联、用例分配执行人，可作为承载估算与执行对比的工具之一。
要点总览（TL;DR）
- 拆分估算的核心是形成可独立核算的估算单元：阶段维度确定时间窗口，类型维度确定工作内容，两者交叉后逐项赋工时。
- 估算单元需记录测试对象、用例规模、执行轮次、单件工时、负责人和假设风险，单元工时等于规模乘单件工时再乘轮次。
- 估算方法按单元选择历史数据、类比、经验系数或三点估算，选择依据写入估算表，便于复核。
- 汇总时先按阶段合计类型工时，再叠加环境准备、缺陷复测、回归等公共投入，缓冲优先加在不确定性高的单元上。
- 提交前用检查清单核对阶段覆盖、类型完整性、规模依据、公共投入和汇总一致性，并在范围变更与阶段复盘后更新估算。
先定拆分口径：阶段、类型与估算单元
拆分估算的第一步是统一口径。阶段和类型是两个不同维度的切分方式，单独使用任何一个都会漏掉信息：只按阶段拆，看不出每个阶段内部各类测试的投入结构；只按类型拆，无法对应到版本节奏和交付节点。把两者交叉，才能得到既能排期又能核算的估算单元。
按测试阶段划分时间窗口
常见做法是沿用研发流程中的测试阶段，为每个阶段划定起止时间和准入条件。典型划分包括单元测试、集成测试、系统测试、验收测试；如果项目有明确的专项安排，也可以把性能测试、安全测试作为独立阶段或阶段内的专项窗口。阶段划分的作用是确定“什么时候做、做多久”，每个阶段应有明确的进入标准（如提测版本可用）和退出标准（如用例执行率、缺陷收敛情况）。
按测试类型划分工作内容
测试类型描述“做什么样的测试”，常见类型包括功能测试、接口测试、性能测试、兼容性测试、安全测试、易用性测试等。类型划分的依据是测试对象和验证目标：功能测试验证业务逻辑，接口测试验证服务间契约，性能测试验证响应时间与吞吐，兼容性测试覆盖终端与浏览器组合。每个类型对应不同的用例设计方法、执行环境和技能要求，因此工时差异明显，需要分开估算。
阶段与类型交叉形成估算单元
将阶段作为行、类型作为列，交叉点就是一个估算单元。例如“系统测试阶段的功能测试”“集成测试阶段的接口测试”各为一个单元。并非每个交叉点都有工作量，某阶段不涉及的测试类型可以留空并注明原因，这本身就是估算完整性的一部分。每个估算单元应记录以下字段，便于逐项复核和追溯：
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 测试对象 | 模块、服务或业务场景名称 | 界定估算边界，避免重复或遗漏 |
| 用例规模 | 用例条数或场景数，注明设计来源 | 作为工时计算的主要基数 |
| 执行轮次 | 计划执行几轮，含回归轮次 | 把单轮工时放大为总工时 |
| 单件工时 | 每条用例或每个场景的平均耗时 | 连接规模与总工时 |
| 负责人 | 该单元的估算与执行责任人 | 明确数据来源和复核对象 |
| 假设与风险 | 估算依赖的前提和不确定因素 | 支撑后续调整与复盘 |
从拆项到汇总的估算步骤
以下六步按顺序执行，每一步都给出输入、动作、输出和完成标志，便于测试负责人组织估算并检查进度。
第一步：确定估算范围与阶段划分
输入为需求文档、版本范围说明或项目计划。动作是确认本次估算覆盖哪些需求、哪些模块，并对照研发计划划定测试阶段的起止时间和准入退出标准。输出是一份范围说明加阶段时间表。完成标志是范围边界清晰、每个阶段都有负责人和时间窗口，且范围外内容已明确排除。
第二步：按测试类型列出测试对象与用例规模
输入为需求条目、设计文档和已有用例库。动作是逐个阶段梳理需要覆盖的测试类型，列出每类测试对应的对象，并估算用例条数或场景数。用例规模可以来自已有用例库的筛选结果，也可以按需求条目乘以经验密度推算。输出是阶段—类型明细表，每个单元都有对象和规模。完成标志是所有交叉单元均已填写或注明“不适用”及原因。
第三步：为每个估算单元选择估算方法
常用方法有四类，选择依据应在表中注明：
- 历史数据：同类项目或上一版本的实际工时，可信度最高，适用于重复性高的功能与回归测试。
- 类比估算：参照相似模块的已知工时按比例调整，适用于新模块但结构相近的情况。
- 经验系数：按每条用例的平均执行耗时乘以规模，系数来自团队积累，适用于用例库较规范的场景。
- 三点估算：分别给出乐观、最可能、悲观三个值，按（乐观+4×最可能+悲观）/6 计算期望工时，适用于不确定性高的性能、安全等专项测试。
输出是每个单元的方法标注和基础参数。完成标志是每个单元都能说明“为什么用这个方法”。
第四步：计算单元工时并标注假设与风险
输入为第三步的方法与参数。动作是按单元计算单轮工时，乘以执行轮次得到单元总工时，同时把依赖条件写入假设栏，例如“测试环境在第几周可用”“接口文档在提测前冻结”。输出是带工时和假设的估算明细。完成标志是每个单元都有工时数字、计算过程和至少一条假设或风险记录。
第五步：按阶段汇总并叠加公共投入
输入为单元工时明细。动作是先按阶段汇总类型工时，再加入不归属单一类型的公共投入：环境准备与维护、用例评审、缺陷复测、回归测试、测试报告编写与沟通协调。公共投入可按阶段工时的一定比例估算，也可单独列项估算。输出是阶段汇总表和公共投入清单。完成标志是汇总结果可逐项回溯到明细，公共投入没有与单元工时重复计算。
第六步：形成估算表并留出缓冲
输入为汇总结果和风险清单。动作是整理成正式估算表，按风险等级设置缓冲，通常对不确定性高的单元或阶段单独加缓冲，而非全表统一加比例。输出是可提交评审的估算表。完成标志是估算表通过评审、缓冲比例有说明、版本号与日期已记录。
角色分工与各阶段交付物
估算不是测试负责人一个人的工作，需要模块测试人员提供规模数据、开发与产品角色确认范围和假设。分工清晰可以减少估算返工。
| 角色 | 主要职责 | 参与时点 |
|---|---|---|
| 测试负责人 | 制定拆分口径、组织估算、汇总公共投入、设置缓冲、提交评审 | 估算启动、汇总与评审 |
| 模块测试人员 | 提供所负责模块的用例规模、执行轮次和历史工时数据 | 第二步至第四步 |
| 开发角色 | 确认提测时间、接口与环境的可用性，提供单元测试与集成测试的范围 | 第一步与假设确认 |
| 产品角色 | 确认需求范围与优先级，判断验收测试的覆盖要求 | 第一步与评审 |
各阶段应产出并留存以下交付物：阶段估算表（按阶段列时间窗口与总工时）、类型明细表（按类型列对象、规模、方法与工时）、汇总表（阶段合计加公共投入与缓冲）、假设与风险清单。评审环节建议安排在估算表初稿完成后、测试计划定稿前，由测试负责人主持，开发与产品角色确认范围与假设，评审结论记录在估算表版本说明中。
估算表定稿后，需要落到可跟踪的载体上。ONES 测试管理支持测试计划与迭代关联、用例分配执行人，并支持用例与需求、任务关联，便于把各阶段各类型的估算单元对应到具体测试计划和执行人，在执行过程中对比计划与实际。用例属性可自定义，团队可以按需补充估算相关字段；具体字段配置与汇总方式建议在实际环境中验证。
示例：一个版本的拆分估算过程
以下为演示情景，数字仅用于说明计算方法，不代表任何真实项目数据。
示例范围与假设
某版本包含订单模块改造，测试范围覆盖集成测试与系统测试两个阶段，验收测试由业务方另行组织，不计入本次估算。假设提测版本按计划可用、测试环境在集成测试开始前就绪、接口文档在提测前冻结。
估算单元与用例规模
| 阶段 | 测试类型 | 测试对象 | 用例规模 | 执行轮次 | 单件工时 | 单元工时 |
|---|---|---|---|---|---|---|
| 集成测试 | 接口测试 | 订单服务与支付服务 | 60 条 | 2 轮 | 0.5 小时 | 60 小时 |
| 集成测试 | 功能测试 | 订单创建与取消 | 40 条 | 2 轮 | 0.8 小时 | 64 小时 |
| 系统测试 | 功能测试 | 订单全流程 | 120 条 | 3 轮 | 0.8 小时 | 288 小时 |
| 系统测试 | 性能测试 | 下单接口压测 | 8 个场景 | 2 轮 | 6 小时 | 96 小时 |
| 系统测试 | 兼容性测试 | 主流浏览器与移动端 | 30 条 | 1 轮 | 1 小时 | 30 小时 |
阶段汇总与公共投入
集成测试阶段单元工时合计 124 小时，系统测试阶段合计 414 小时。公共投入按阶段单元工时的 20% 估算，包括环境准备、用例评审、缺陷复测与回归：集成测试阶段约 25 小时，系统测试阶段约 83 小时。性能测试不确定性较高，单独增加 15 小时缓冲。最终估算为集成测试约 149 小时、系统测试约 512 小时，合计约 661 小时。
可迁移的规律
这个示例体现三点：一是用例规模乘以单件工时再乘轮次，是单元工时的基本算法；二是公共投入按阶段比例估算比全表统一比例更贴近实际，因为各阶段的缺陷复测和回归强度不同；三是缓冲应加在不确定性最高的单元上，而不是平均分摊。迁移到其他项目时，替换对象、规模和系数即可，计算结构保持不变。
完成检查：估算表是否可用
估算表提交前，按以下清单逐项核对。清单分为通过项和阻断项，阻断项未解决时估算表不应进入评审定稿。
| 检查项 | 核对内容 | 类型 |
|---|---|---|
| 阶段覆盖 | 本次范围涉及的测试阶段是否全部列出，起止时间与准入退出标准是否明确 | 阻断项 |
| 类型完整性 | 每个阶段的测试类型是否逐一确认，不适用的类型是否注明原因 | 阻断项 |
| 用例规模依据 | 每个单元的规模是否来自用例库、需求推算或类比，来源是否可查 | 阻断项 |
| 方法与参数 | 每个单元是否标注估算方法，参数是否可复算 | 通过项 |
| 假设与风险 | 关键假设是否记录，高风险单元是否单独标注 | 阻断项 |
| 公共投入 | 环境准备、缺陷复测、回归、报告编写是否计入，是否与单元工时重复 | 阻断项 |
| 汇总一致性 | 阶段汇总能否逐项回溯到明细，合计数字与明细加总是否一致 | 阻断项 |
| 缓冲说明 | 缓冲比例或额度是否有依据，是否集中在高风险单元 | 通过项 |
通过标准是全部阻断项核对无误、通过项有明确记录。估算结果的复核时点建议设在三个节点：需求范围变更时、阶段复盘后、版本结束后。版本结束后应将实际工时与估算对比，把偏差原因回填到假设与风险清单，作为下一版本选择估算方法和系数的依据。执行过程中，ONES 测试管理可自动生成测试报告并统计项目缺陷分布，便于在阶段复盘中对照计划与实际；工时维度的统计能力建议结合团队实际配置确认。
常见问题
用例库还不完善时，用例规模怎么估算？
可以先用需求条目推算规模：按每个需求条目对应的平均用例密度乘以条目数，得到初步条数，再标注为待细化。对结构相近的模块，也可以参照已有模块的用例条数按比例调整。关键是把推算来源写进估算表，并在用例设计完成后回填实际条数，比较偏差。规模依据可查，估算才具备复核条件。
公共投入按固定比例估算，还是逐项列出？
两种方式可以结合。环境准备、用例评审、测试报告编写这类投入相对稳定，按阶段单元工时的一定比例估算即可；缺陷复测和回归的波动较大，建议单独列项，依据历史缺陷数量和回归范围估算。无论哪种方式，都要确认公共投入没有与单元工时重复计算，并在估算表中注明比例或额度的来源。
估算结果和实际执行偏差较大时怎么处理？
先定位偏差发生在哪一层：是用例规模估少了、单件工时偏低，还是公共投入或轮次没算够。版本结束后把实际工时与估算逐单元对比，将偏差原因回填到假设与风险清单，作为下一版本选择方法和系数的依据。如果偏差集中在某一测试类型，说明该类测试的经验系数需要重新校准，而不是全表统一调整。
估算表定稿后，如何让执行过程与估算保持对应？
把估算单元对应到测试计划和工作项上，按阶段、类型分配执行人，执行时记录实际轮次和耗时。ONES 测试管理支持测试计划与迭代关联、用例分配执行人，并支持用例与需求、任务关联，便于把估算单元落到具体计划中跟踪。工时维度的统计方式建议结合团队实际配置确认。
需求范围在测试执行中途变更，估算要不要重做？
不需要整表重做，按变更影响局部调整即可：确认新增或删减的需求对应哪些阶段和类型，更新这些单元的用例规模与轮次，同步调整阶段汇总和公共投入。变更记录写入估算表版本说明，保留调整前后的数字，便于后续复盘时区分范围变化与估算偏差。
