一个小小改动不会对其它功能有影响，在发版时间迫切的情况下（通常因为各种考虑都赶在晚上发版，谁不希望早点发完版回家睡觉呢？），测试员选择相信程序员的话，最终的结果可能是灾难性的，一些上线后的事故由此引出。
这是笔者公司在前面版本发布中出现的问题，在程序员极力保证APP小小改动对其他功能不会造成影响的前提下，测试员草草把涉及改动的小块功能测试通过后就申请发版，最终导致发布后出现灾难性bug！只得下架APP重新发版，两次过后惹怒了甲方，从而各种道歉和做补救安抚工作。
实际做到以下两点中任一一条就可以规避上述问题：
①开发仔细地做好代码改动分析、评估影响范围，让测试知晓便于测试覆盖。
②测试严格的做好版本迭代测试。
那具体应该怎么做呢？
针对第一点，在转测邮件中让对应程序员标明代码改动分析，以及评估影响范围。这个在能给出的情况下是最好的，然而这往往需要考验程序员的专业素养和能力。
更重要的是第二点，做好版本迭代测试。
如果有做测试自动化，那非常棒！我们只需要关注新增部分和自动化无法覆盖的部分就行了。但对于APP，能做到界面层测试自动化的很少，成本也太高，更多的是做到接口层自动化（我们属于后者）。
那如果自动化不能完全覆盖，该怎么办呢？
这时我们需要做基础checklist（也可以叫必测checklist），以保证版本正确性。
基础checklist有别于我们常用的checklist，不是让我们对整个版本进行测试（往往在最后发版前的频繁迭代中，时间也不允许）。
它应该具备以下几点：
通常不考虑各种异常测试，主要为正常流程的检查；
根据市场反馈用户使用情况，覆盖用户使用最频繁和对其最重要的功能，当然还包括该版本的新增部分功能；
每一条检查点应该清晰而简洁，以便能快速执行；
根据覆盖功能的使用频度和重要程度做好优先级，如高、中（没有低），“高”是必须覆盖的，“中”在时间允许情况下也应执行；
checklist应该根据市场的反馈随时做更新；
当有了基础checklist，不应该束之高阁做为一种“战略性”摆设（让领导了解我们有这么一个东西），而应该严格执行。不能因时间、人力等各种理由放弃，否则，这锅我们背不起。
你碰到过这样的问题吗？你们后面是怎么规避的呢？欢迎吐槽~