关于时间评估，有很多非常专业的评估方法 & 评估公式
实际执行的情况是：没有那么多时间给你去估算（也许，从接到项目到上线，总共只有两天时间；你期望用1天时间去估算测试需要多长时间，明显不现实）。而且，不同的项目、不同的团队、不同的质量要求、不同需求的紧急度，需要的测试时间，完全不同 。
在需求都不完全清楚的情况下，怎么估算测试时间呢 ？
简单粗暴的评估方法：「三分之一」大法 。
根据开发评估的整体时间，除以3 ，得到测试总时间 。再结合经验 ，适当加减20%时间即可 。
如果需要把每个模块的时间，细分呢 ？还是保持如上的原则：总时间不变，等比拆分，得到每个模块的时间 。
四点建议
-
测试估算的时间，只需考虑测试的执行时间。如果中途，由于开发延期提测，或者开发修改Bug时间过长，等待新版本测试。在时间评估的时候，需考虑这个时间，把此块时间加上（或者，发版时间，顺延） 。
-
自己估算的时间，如果后续发现时间不够，自己加班，想办法消化 。另外，版本结束后，吸取经验，总结下，是哪个点消耗时间过多，是否可加速（自己总结的经验，终身受益） 。如果确实不可加速，说明整个团队的效能，是低于「三分之一」评估大法的，下次估算，在之前评估时间的基础上，再加上20%的时间 。
-
项目过程中，不接受临时新增需求的测试，如果有临时需求，需要增加对应的测试时间（这块，理论上是这样，实际情况是，很多同学，经常被强塞任务，时间却没有增加）。
-
现实情况是，估算好的测试时间，已确定的上线时间，往往由于一些外部因素，提前上线，这个时候，测试同学，需列出已知风险，并做好本职工作，避免背锅 。
文章转载自公众号为 IDO老徐 简尚 文章： “测试时间估算”的现状 及 4点建议 文章地址： https://mp.weixin.qq.com/s/wGnWcSUhhWIvThgOd1-j2A