测试排期估时多长合理？
在研发同学技术评审完之后，研发同学基本上可以预估自己需要多长的开发时间，所以往往技术评审会上会给出开发排期和提测时间点，这时需要我们给出我们 QA 的测试排期，那么排期估时多长是合理的呢？估短了怕自己测不完，估长了怕研发和产品同学质疑和拷问，作为一个专业的测试，排期绝对不是拍脑袋决定的，下面是我根据经验总结出来测试排期策略。
排期策略：
1、以研发同学的总开发工时的一半为基调，比如如果前后端同学排期加起来 10 天，那我们的测试时间就折半，初步定在 5 ~ 6 天
2、考虑需求的复杂程度，复杂程度从两方面体现，一是前端跟后端的改动比例，二是修改的链路长度，如果大部分是后端改动或者修改的链路较长，排期可以稍微多一两天，反之，如果大部分是前端样式的改动或者改动的链路较短，可以适当缩短排期或者维持排期不变。
4、结合开发同学一贯的提测质量，如果提测质量一贯较高而且改 bug 一直都很高效，这时可以适当缩短排期或者维持排期不变，否则适当加长排期估时。
5、想想自己在测试过程中还有哪些事需要并行的做，大概会占用多少时间，在初步确定的时间上进行调整
注意：
1、排期不要定得太紧张，给自己留点 buffer，特别是当自己不是全人力都在当前需求测试时，更需要考虑到这方面，尽可能把排期时间加长一些。遇到特别没把握不确定的，可以先说第一次测这块业务或者这段时间还有xxx事在并行地做，估时先估这么长时间，后面如果提前测完则提前上线，但也不要估时太长，这样会让开发和产品同学觉得你能力不行。。。
2、排期完毕之后在需求管理平台或者需求群里更新周知排期信息。
3、互联网企业的需求相较于传统软件公司的软件项目有些不同，传统软件公司的项目一般都是开发上线周期长达半年的大型软件项目，这时一般测试排期定基调以开发同学总工时的 1/3 更为合适，但是对于我们这种迭代非常快的互联网公司，每个需求量级都不会太大，开发总工时也不会太长，一般在1个月以内，所以我们一般用 1/2 的开发工时来做为测试排期的参考。
