测试时间评估：三分之一估算法

注：这是 #精选100篇# 的 011

关于测试时间评估，经常收到测试从业者（测试工程师，测试Leader，测试总监）的提问，他们没有特别好的思路，期望老徐给一些参考思路 。

嗯，@IDO老徐 确实经常跟一些测试从业者沟通交流 & 了解他们的执行现状 。

这篇文章，聊聊 理论 & 现实 的差异化 ，以及老徐对于时间评估的做法 & 观点 。

关于时间评估，有很多非常专业的评估方法 & 评估公式（具体有哪些，不阐述，可以搜索引擎找找）。

实际执行的情况是：

没有那么多时间给你去估算；也许，从接到项目到上线，总共只有两天时间（甚至当天接到需求、1 小时后需要你给出估算的测试时间），你期望用1天时间去估算测试需要多长时间，明显不现实。而且，不同的项目、不同的团队、不同的质量要求、不同需求的紧急度，需要的测试时间，完全不同 。

在需求都不完全清楚的情况下，怎么估算测试时间呢 ？

老徐给一个简单粗暴的评估方法：「三分之一测试时间估算法」。

具体怎么做呢 ？

根据开发评估的整体时间（总工时），除以3 ，得到测试总工时 。再结合经验 ，适当加减20%时间即可 。

如果需要把每个模块的时间，细分呢 ？还是保持如上的原则：总时间不变，等比拆分，得到每个模块的时间 。

注：如上的时间，并非一成不变，在企业落地实践中，自己灵活运用 。

补充 ，

1. 测试估算的时间，只需考虑测试的执行时间。如果中途，由于开发延期提测（顺延即可），或者开发修改Bug时间过长（20%缓冲），等待新版本测试（站立会报风险）。在时间评估的时候，需考虑这个时间，把此块时间加上（或者，发版时间，顺延） 。

2. 自己估算的时间，如果中途执行过程中，发现时间不够，自己加班，想办法消化（即：自己估算的时间，含着泪也要接受），下次估算时间就有经验了 。另外，版本结束后，吸取经验，总结下，是哪个点消耗时间过多，是否可加速（自己总结的经验，终身受益） 。

如果确实不可加速，说明整个团队的效能，是低于「三分之一」评估大法的，下次估算，在之前评估时间的基础上，再加上20%的时间 。

3. 项目过程中，不接受临时新增需求的测试，如果有临时需求，需要增加对应的测试时间（这块，理论上是这样，实际情况是，很多同学，经常被强塞任务，时间却没有增加）。

4. 现实情况是，估算好的测试时间，已确定的上线时间，往往由于一些外部因素，提前上线，这个时候，测试同学，需列出已知风险，并做好本职工作，避免背锅 。

end ，这篇文章就到这 。