测试时间评估

功能测试时间评估法则：开发时间的 1/3 ~ 1/2。
适用范围：
1、不怎么复杂的功能，测试时间一般按照开发时间的 1/3 来评估。
2、稍微复杂一点的功能，测试时间一般按照开发时间的 1/2 来评估。
3、对于以上测试时间的评估，可依据实际项目中可能发生的测试风险，酌情再增加 20%。

比如，实际测试下来发现 BUG 很多，开发修复时间长，测试需要等待开发提测新版本；
比如实际测试过程中测试人员有变动，其他测试人员在不熟悉该项目的情况，测试时间就需要增加。
如果项目无法保证我们所评估的测试时间，上线时间已经固定无法变更，测试时间只能被压缩；
此时，测试人员需要提前预告风险，建议本次上线优先保证核心业务，或者让产品划分优先级，砍掉当前不必要的功能。

不能适用的范围：
功能测试时间评估法则适用于新版本的功能测试，不适用优化的功能即包含大量的回归测试，这需要根据开发提供的影响范围评估测试时间，这时开发和测试的投入时间不成正比。
比如开发改了一个接口参数，但影响范围很大，影响到后面的业务流程结果，需要全流程或半流程回归。这时评审时，测试需要根据影响范围进行评估，往往测试时间远超开发时间。
比如前端修改了一个公共组件，影响到几个或十几个页面，测试需要根据开发提供的影响范围进行评估，是否等价类抑或正交测试划定测试时间。

回归测试建议使用接口自动化+UI自动化，减少测试投入