想要预估测试的排期，那就要先了解下测试的工作量都在哪里。由于我们是预估迭代中的排期，所以像一些自动化测试开发等弱迭代性的工作就不会考虑了。
以下我们就针对测试具体的工作量来分析，所有时间的预估都是以2周一迭代&1个QA为标准（个人经验，欢迎讨论）：
1、对新需求的理解和分析
开始时间和结束时间应该和需求确认过程同步，但往往在需求完全定好后还会有少量的消化时间来服务之后的测试用例编写 - 0.3d
2、测试用例的设计及整理
编写测试用例我认为就是需求的再确认及拆解，最后落在纸面上供RD和QA使用 - 1d
测试用例是要QA、PM、RD一起评审的，评审过程中有时会发现需求歧义导致需求的变更优化，这个时间也需要考虑到 - 0.5d
3、新功能测试执行到结束
考虑范围应包括但不限于：线上环境&测试环境，功能，性能，接口，埋点，ios&android，低版本ios兼容（如ios8），web，新旧版本兼容，数据迁移...
这是占比最大的时间，排期的预估应以测试用例为依托，由于每一个迭代的业务需求不同，时间会有所浮动 - 2d～3d
* 测试人力资源多少可直接影响排期的预估
4、老功能回归
由于集成新功能有可能会影响老服务，需要按优先级回归下老功能 - 1d
* 如果配以卓有成效的自动化测试辅助，时间会缩短甚至大幅缩短。
5、新增缺陷修改后的回归
缺陷的回归往往会成为吃时间的怪兽（比如修改缺陷再次引入新的缺陷），尤其在项目工期紧或者倒排工期的时候。所以这个时间不容小视 - 1d
6、测试总结
测试报告产生时间排期，相对固定 - 0.5d
7、产品例会，产品变更引起的工作量增或减
浮动项目，时多时少，可根据实际情况修改排期或根据经验提前预估排期 - 0.3d
8、技术学习和交流等额外时间
浮动项目，根据业务时多时少，可根据实际情况修改排期或根据经验提前预估排期 - 0.1d
9、线上问题反馈跟进
浮动项目，时多时少，可根据实际情况修改排期或根据经验提前预估排期 - 0.3d
