场景：产品经理评审完需求，预留了1天的时间由研发人员和测试人员对此次需求进行了解，预估出接下来的工作量时间。依此项目经理等来评估确认此次版本的发布时间。
如下是经过以上场景后，由测试人员输出的某2个需求的测试时间：
示例：
【行動計劃】日曆優化 1.5天
【个人主页】个人主页新增模版数量5个左右 一次测试+回归 2.5d
结论：如上的示例给出的测试时间缺乏说服力，详解如下
如上示例，未输出测试用例的情况下，当前给出的测试时间没有说服力，影响因素包括：
1、测试用例未输出、评估时间的标准是什么？
2、在测试中不可避免会发生 产品需求变更，此部分时间是否有考虑添加？
3、用例中涉及 纯功能的用例，则测试时间的速度上则更快
4、用例中涉及 偏逻辑验证 的部分，相对的时间会稍长
5、用例中涉及 大量需要环境准备和数据准备 时，测试的时间上可能会更久些。
6、测试中的主功能流程的阻塞bug、开发自测质量与开发的修复时长，都将影响我们一轮测试时间的进度。
7、属迭代功能的需求，人员对此模块的熟悉程度
8、不同的项目背景决定着质量要求，同时关乎着测试时长。（如：iBer Care 和 资讯、OSS）
9、回归的bug时间：提交bug数量和回归bug的时间存在必然的联系，目前未进入测试阶段，具体到某个需求会有几条bug？2条 or 10条，
根据不同的bug数量则回归时长均不同，因此在未有bug数量的前提条件下，则评估出的回归bug的时间没有依据条件。
合理的评估测试工作量的时间周期，可参考：
首先，测试工作量时间的评估基础是：输出测试用例（也代表着：测试范围）：
不同的测试范围，对测试量的评估起到至关重要的因素。比如：测试一个模块或测试多个模块或整个系统等等，都属于测试范围不一样，明显工作量也不同，差别也挺大的。
首轮测试的时间评估参考：根据测试用例的输出条数、高级别的用例、以及复杂的用例校验来评估输出大致的测试时长。
其次，回归bug时间的评估基础是：bug数量、开发解决bug的质量
bug的提交数量和回归时长直接受研发人员的开发需求质量与自测质量的影响。如：某模块开发质量不高，则提交的bug比较多、改动一个bug后连带的bug比较多、回归一个bug的reopen次数比较多，如上则都会严重的影响我们回归bug的时间。因此，开发需求提测后的测试与回归bug重点在团队之间的沟通。如有阻塞及时间较久的测试与bug的回归。应及时同步出当前遇到的阻塞性等问题与项目成员、项目经理等进行沟通。协商出具体的解决方案。
bug回归可能存在的影响因素：
（1）自己提交的bug自己回归：因对所提交的bug场景明确，因此回归时间快
（2）自己回归别人提交的bug：因对所提bug的出现场景不明确，因此回归时间慢，
如上2种情况，若出现第2种情况时，及时向测试主管及项目经理提出可能存在的时间上的风险。好在我们目前第1种情况较多。
bug回归的测试提议：
（1）首轮中不同功能点的测试与bug回归测试交叉进行。
示例：A 人员负责“资讯”模块的测试，模块的第一个功能点第一轮测试完毕bug提交后，在进行第二个功能点测试结束，则可进行第一个功能点的bug回归。
（2）整个模块或一个需求测试完毕，第一轮所提交的bug回归结束后，则可完整的再次走查一遍功能进行最后的回归测试。
最后，测试的周期时长涉及的因素较多，因此根据如上的要求，在测试用例评审完成后，输出第一轮单人测试的工作时长即可。
补充，工作中多总结初步给定的测试时长与实际测试的使用时长相差周期，总结出现偏差的原因，逐步提升对工作量时长的评估准确性。