ALLIN小需求测试及发布建议的流程

项目已经发布，没有较大的功能点了，但是小需求的发布比较频繁，需求的提出也相对不够正式了，在这种情况下，测试负责人需要注意的点有：

1、需求确认：由于这种小需求经常是讨论一下大家就回去闷头做了，如果没有比较正式的方式通知测试，测试同学一定要督促发送邮件通知确认需求。

2、影响面分析：

a、在确认需求后，和开发确认此次小需求可能影响的点，由此判断测试范围，估计工时；

b、在提交测试后，和开发再次确认影响面，注意要细节，由此确认测试范围，并且和开发确认，是否测试这些场景就足够了，双方讨论一下是否有没有考虑到的地方。

3、估计工时：根据需求以及影响面分析，简单估计写用例，以及执行测试的时间。

4、用例的编写，任何小需求的测试用例，都要编写到QC中，可以写到原来的功能目录下，也可以单独管理。写用例时，有问题的地方一定要和开发、PD沟通确认，邮件的方式会比较好。

5、提测：在工时评估的基础上，督促开发尽早提测，保证测试时间足够，否则存在的风险需要向项目组说明。同时可以分配任务给开发同学帮忙回归（所以用例一定要细，开发能够看懂）。

6、自动化回归：自动化回归测试，一定要分析失败的用例的原因，保证不是由于本次小需求引入的bug。由于页面自动化回归时间较长，可以在发布前一天晚上执行，第二天看结果。

7、测试和发布验证：如果有可能，对自动化不能覆盖到的主干功能做一定的回归。

8、发布标准：判断当前质量情况是否达到发布标准。建议和PM、DEV一起过一遍未解决的bug，再做判断。注意一定要有清晰的分析建议，供大家参考。同时尽可能多从客户角度考虑性价比。