偶尔看到公司开发需要测试填工时，测试看了下开发排期后，直接写了测试工时数据，遂追问测试：你的工期是怎么排的？测试开始语无轮次，拉出了一个排期表说按照这个表中开发工时进行排的，我继续追问：有什么依据？怎么计算的？然后就是一脸茫然，说：测试开发配比为 1:4，开发有 4 个人，填的测试排期（测试自己计算了各开发人员排期）为：开发汇总工时 *4，我：......。要求重新调整测试工时，结果又计算：开发汇总工时/4 作为测试工时。。。。。。。关于怎么计算测试工时，这个是测试的基本功，基本功都做不好怎么能做好测试，关于怎么计算测试工时，采用 ISTQB 国际性认证体系测试评测师基础级/Foundation Level(CTFL) 文档中：“基于比率的估算”、“外推”、“宽带德尔菲”、“三点估算” 4 个方法做说明：
1、基于比率的估算 (Ratio-based Estimation)
在这种基于度量的技术中，数据是从组织内以前的项目中收集的，这使得可以得出类似项目的 “标准” 比率。组织自身项目的比率（例如，取自历史数据）通常是估算过程中能使用的最佳数据来源。可以使用这些标准比率来估算新项目的测试工作量。
举例说明
- 历史数据：某公司过去完成了三个电商平台项目。通过分析项目数据，发现这三个项目的开发总工作量与测试总工作量的比例稳定在 5:3。
- 新项目：现在，公司要开发一个新的电商平台。根据需求范围和复杂度评估，开发团队估算出开发工作量约为 1000 人日。
- 测试估算：应用历史比率（5:3）进行估算。
- 计算过程：测试工作量 = (开发工作量 / 开发比例) * 测试比例 = (1000 / 5) * 3 = 200 * 3 = 600 人日，因此，测试工作的估算工作量为 600 人日。
2、外推 (Extrapolation)
这是基于度量的技术，在当前项目中尽早进行测量以收集数据。有了足够的观测结果，剩余工作所需的工作量可以通过外推这些数据（通常通过应用数学模型）来估算。这种方法非常适用于迭代的 SDLC。
举例说明
- 项目背景： 一个采用敏捷开发（如 Scrum）的项目，每个迭代（Sprint）为期 2 周。测试工作随每个迭代同步进行。
- 收集数据： 项目已经完成了前三个迭代（Sprint 1, 2, 3）。其测试工作量实际消耗分别为：50 人时，55 人时，45 人时。
- 预测未来：团队采用 “最近三次迭代的平均值” 作为外推模型，来估算下一个迭代（Sprint 4）的测试工作量。
- 计算过程：Sprint 4 估算工作量 = (50 + 55 + 45) / 3 = 150 / 3 = 50 人时，因此，Sprint 4 的测试工作量估算为 50 人时。随着项目进行，这个平均值会不断更新（例如，用 Sprint 2,3,4 的平均值来估算 Sprint 5）。
3、宽带德尔菲 (Wideband Delphi) / 规划扑克 (Planning Poker)
这是基于专家的迭代技术，专家进行基于经验的估算。每一位专家独立估算工作量。收集到的结果，如果专家的估算存在超出商定边界范围的偏差，专家们将讨论他们目前的估算。然后，要求每个专家根据反馈重新独立估算。不断重复此过程，直到达成共识。规划扑克是宽带德尔菲方法的一个变体，通常用于敏捷软件开发。在计划扑克中，通常使用代表工作量大小的数字卡片进行估算。
举例说明 (规划扑克变体)
- 参与人员： 测试负责人、开发负责人、产品负责人、项目经理等组成估算小组。
- 估算对象： 用户故事 “实现微信快捷登录” 的测试工作量（包括编写测试用例、执行测试、回归测试等）。
-
过程：
- 主持人（Scrum Master）宣读用户故事。
- 每位专家独立选择代表工作量的卡片（单位可以是人时或故事点）。假设卡片序列为：1, 2, 3, 5, 8, 13...
- 所有专家同时亮出卡片。结果：有人出 3，有人出 5，有人出 8。
- 出牌最大（8）和最小（3）的专家分别阐述理由。出 8 的专家认为涉及第三方接口联调，测试场景复杂；出 3 的专家认为这只是个简单功能。
- 经过讨论，大家对技术细节和测试范围的理解达成一致。
- 进行第二轮估算。大家再次亮出卡片：这次大部分人出 5，少数人出 3 和 8。
- 继续讨论，最终第三轮大家一致认可了 5 这个估算值。
- 估算结果： 该用户故事的测试工作量最终共识为 ** 5 个故事点 **。
4. 三点估算 (Three-point Estimation)
在这种基于专家的技术中，专家做出三个估算：最乐观的估算（a）、最可能的估算（m）和最悲观的估算（b）。最终估算（E）是它们的加权算术平均值。在该技术最流行的版本中，估算值计算为 E=（a+4*m+b）/6。该技术的优点是允许专家计算测量误差：SD=（b–a）/6。
举例说明
- 估算任务：“对订单管理系统进行全流程端到端（E2E）测试” 的工作量。
- 专家估算：
- 最乐观 (a)： 一切顺利，无重大阻塞缺陷，环境稳定。估算为 6 人日。
- 最可能 (m)：考虑正常水平的缺陷修复和少量环境问题。估算为 9 人日。
- 最悲观 (b)：遇到严重缺陷导致测试频繁中断，或环境部署屡次失败。估算为 18 人日。
- 计算最终估算：使用公式 E = (a + 4m + b) / 6，代入：E = (6 + 4 * 9 + 18) / 6 = (6 + 36 + 18) / 6 = 60 / 6 = 10 人日
- 计算标准差（评估风险）：使用公式 SD = (b - a) / 6，代入：SD = (18 - 6) / 6 = 12 / 6 = 2 人日
- 汇报结果：最终估算可表示为 10 ± 2 人日。这意味着工作量有很大概率（在统计学上约为 68%）落在 8 到 12 人日 的区间内。这个区间范围（4 天）也向管理者揭示了该任务存在较高的不确定性或风险。
可参阅（Kan 2003，Koomen 2006，Westfall 2009）了解更多的测试估算技术。
Kan 2003 对应文档： 《软件工程度量：统一度量程序的最佳实践》
Koomen 2006 对应文档： 《TMap Next： 软件测试的实践指南》
Westfall 2009 对应文档： 《软件测试专家认证（CSTP）指南系列》
现实中貌似都是根据经验估算个大概时间，没什么好的量化的标准
现实中基本是赛马的玩法
评估只能有个大概. 有时测试工时受很多因素影响, 需求质量、需求变更程度, 研发水平, 提测质量, 测试人员水平, 环境稳定性、第三方稳定性/支持程度
Vanessa
回复
经验其实也是上述 4 个点总结出来的，估算时间并不等于实际时间，例如需求突然变动，测试的工时也会做出相应调整，工时反馈的是工作量，不一定是这个时间就能测试完成。例如：这个类似的需求我以前测试过，当时测试用了 4 人/天、开发 8 人/天，再就是看需求文档：有多少功能、有多少个开发，有没有碰到 delay 风险点，然后依据这个估算出可能测试的工时。本次需求如果开发比之前多 2 倍、开发周期 16 人/天、功能点差不多、经过讨论不存在风险点，测试在没有多余人力的情况下，估算测试工时为 8 人/天。