没有风险时间吗

估一个大概的时间就行了，bug 多改不完项目延期也是开发的锅，估那么准确干啥

拆分功能点，按照一轮的测试时间估算，然后测试 3 轮左右，有多个环境自由调整

开发提测质量，应该通过提测标准限制。没达到标准的，直接认为提测不通过，没进入测试阶段，不占用预估的测试时间。
至于开发解决问题能力，这个不用管那么多吧，开发解决不完导致延期，那是开发的责任，也不会怪你测试时间预估不足的。不过阻塞测试的缺陷（比如某个功能入口压根打不开，导致里面的功能无法测试的）一定要强力 push，最迟也得 24 小时内解决，因为这玩意是真切影响测试时间的

然后因为有可能临时被抓开会、处理线上问题之类的，所以估完后多加 10%-20% 的风险时间，这样一般就比较稳了。

拍脑袋定时间就是开发计划人力的 1/2，另外就是楼上所言，一定要固守住的底线：未转测不算人力、转测质量差导致打回不算人力、出现验证阻塞问题导致所有需求无法进行测试不算人力、各种非测试问题导致的空档都不算入测试人力内。
一句话，该干干该顶顶，守不住底线就老实的自己把锅背上吧，不用等着别人甩了

领导让估一个准确的时间，要看工作量

谢谢大佬

当你不知道怎么估总时间的时候，可以试下做 breakdown：把你各个测试阶段和模块拆分开来分别评估，然后汇总一个时间。比如测试方案需要多长时间准备？测试用例？数据准备？环境搭建？测试执行（拆分到每个模块分别多少时间）？回归测试？ 缺陷跟踪和验证？

具体要看你们提测的方式：如果是全部完成提测，那就按提测标准，符合就正常测试，不符合就打回继续开发；如果是边开发边提测，那只能根据每个研发的能力，分开评估每个人开发功能需要测试和修改 bug 的时间；
这个测试时间不管怎么评估，在领导面前都是很难满意的。你只能给出一个比较合理，领导相对能接受的时间范围；

好勒，这个还是不能像前端或者后端那样，每天几个写几个页面，几个接口那样评估，只能大概

感觉二分之一有点多，哈哈，我们这开发完成后，开发人员直接就进入下一个项目了，改 bug 的时间有限

往多了估，你估计 10 天，领导觉得一周，你估计一周，领导肯定觉得 4 天就行。而且测试时间越紧，根据我的经验，测试效果越垃圾。

哈哈，有道理

一方面首先是：关于测试时间评估这块最好能有个标准搞出来大家可以参考，不然很容易变成一个人说了算（比如测试负责人），其实风险挺大的。

1. 按照用例的数量和执行难度评估：100 个用例跟 10 个用例的执行时长自然不一样，一个用例要查缓存查数据库查日志跟一个用例只看响应的执行时长也不一样，所以需要做明确的区分。
2. 明确测试时间有效评估的前提：测试肯定不是一帆风顺的，所以要明确说清楚，评估出来的时间是指正常顺利测试的时间，如果别人非要你给一个准确时间，就不要把因提测质量不佳、功能不可测等承诺进去，这块说清楚就好。再给到 修 bug 的一些 buffer 时间，基本 ok。

我都是直接回复只能估一个大概时间，不能惯他们