“测试时间估算”的现状 及 三分之一评估法

关于测试时间评估，最近收到很多测试从业者的提问，也与一些测试从业者沟通交流 & 了解他们的执行现状 。

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

关于时间评估，有很多非常专业的评估方法 & 评估公式（具体有哪些，老徐也不记得了，可以百度找找）。

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

老徐给一个简单粗暴的评估方法：「三分之一」大法 。

具体怎么做呢 ？

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

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

注：如上的时间，并非一成不变，自己灵活运用 。

补充 ，

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

2. 自己估算的时间，如果后续发现时间不够，自己加班，想办法消化 。另外，版本结束后，吸取经验，总结下，是哪个点消耗时间过多，是否可加速（自己总结的经验，终身受益） 。如果确实不可加速，说明整个团队的效能，是低于「三分之一」评估大法的，下次估算，在之前评估时间的基础上，再加上20%的时间 。

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

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