最近项目发补丁，笔者所负责的模块进行回归测试。提供的补丁版本在回归测试前已经进行过一些时日的测试，并且发现的故障也已经修复完成。但是情理之中意料之外的是，已经测试完成的功能陆陆续续又发现了几个故障，让笔者不得不检讨和怀疑自己。那么，这些故障为什么会测试遗漏呢？
经过笔者对比和总结，复测发现的故障主要出现在以下情况：
·交互模块测试不充足，导致其他模块引用笔者测试模块时发现故障；
·测试样本数据量小，无法触发大数据量场景下的故障；
·非正常途径获取测试版本，导致故障未能及时发现；
·版本升级，兼容性测试不足；
·忽略一般类打印错误，导致数据残留；
那么，所述的这几种测试遗漏场景，具体是什么样的情况呢？在测试中可以如何尽量避免呢？
1.交互模块测试不充足，导致其他模块引用笔者测试模块时发现故障
此类故障在笔者回归测试的时候出现过两次。笔者负责的测试模块功能是大数据转储和查询。出现的两次故障一次是上层模块引用查询功能时，后台报错不存在的查询字段；一次是模拟数据测试，查询模拟的数据时搜索不到结果。
经过开发人员分析，两个故障属于代码异常故障。其一是代码异常拦截，导致字段查询失败；其二是存在相同字段时转储异常，导致模拟数据中部分字段未能正常存入。
那么，从测试角度分析，为何会出现这两个故障呢？其一是笔者在测试时只关注自己模块功能、接口等是否正常，从已知的场景中分析、编写测试用例进行测试，未能与其他模块进行联调测试；其二是笔者不曾模拟过出现问题时的模拟数据，选用常见数据进行拓展模拟，忽略了测试样本多样性。
那么，可以如何避免这类故障的出现或尽早发现这类故障呢？联合测试，我想是一个十分有效的办法。由于精力和时间以及经验和知识等局限性，测试人员特别是团队测试人员往往难以避免的只关注或重点关注自己模块的功能可用性和健全性，可能会忽略其他交互模块的调用方式和多样性数据传递。因此，加强联合测试可以多脑联合扩大测试场景，提升测试效果。
2.测试样本数据量小，无法触发大数据量场景下的故障
此类故障笔者在回归测试的时候出现过一次，主要出现在数据转储时。此前笔者为了能够快速地进行自动化回归测试，转储测试使用的数据量不是很大。因此，发现的转储功能故障基本处于代码合入时。但回归测试时，大数据量的冲击导致转储过慢、转储报错等问题频现。
那么，可以如何避免这类故障的出现或今早发现这类故障呢？建立大数据量测试环境或性能测试环境。保持一个长期稳定的性能测试环境用于大数据量转储和查询测试。这样，可以让常规化测试通过的版本在版本发布前经过性能测试环境的过滤。
3.非正常途径获取测试版本，导致故障未能及时发现
此类故障笔者在回归测试的时候出现过一次。现象时将发布版本进行基本回归测试，发现竟然存在基本功能故障。经过思考和分析，发现问题出在笔者之前测试时环境上的版本不是笔者从流水线正常获取的，而是开发人员调试过的版本。也是由于笔者的偷懒，没有在之后拉取正规版本进行测试，导致这个基本功能故障在版本回归测试时才发现。
那么，可以如何避免这类故障的出现或今早发现这类故障呢？一定要正规途径获取版本，不要试图偷懒。只有这样，我们才能保证我们发布版本与测试版本一致。
4.版本升级，兼容性测试不足
此类故障笔者在回归测试的时候出现过一次。由于基础环境升级，联合测试时笔者负责模块出现了接口功能故障。而之前测试时未能发现的原因是笔者使用的老版本基础环境测试，到这升级后出现接口不兼容。特别是参数调用和返回结构发生了改变。
那么，可以如何避免这类故障的出现或今早发现这类故障呢？定时更新测试环境，尤其是基础环境，或者使用项目上提供的自动化测试环境进行测试。这样能够“紧跟潮流”，获取最新基础环境信息，及早发现故障。
5.忽略一般类打印错误，导致数据残留
此类故障笔者在回归测试的时候出现过一次。其现象是在进行版本卸载重装时发现数据残留。而此类故障并非笔者在回归测试时首次发现，其实在之前测试中隐隐约约也见过类似错误，但是笔者并未深究。直到回归测试时，笔者方式重视起这个问题，认真排查后发现时卸载时java环境变量未能成功获取导致数据残留。由于卸载时控制台输出错误未能明显标注（比如加粗、红色），所以笔者未能很快发现打印输出的错误。
那么，可以如何避免这类故障的出现或今早发现这类故障呢？测试一定要小心谨慎，不能放过任何可疑行为。一旦我们在测试过程中发现某些可疑输出，即使是偶现，我们也一定要提高警惕，认真排查。
说了这么多，不知道正在阅读的你有什么收获呢？本文只是笔者从自身角度将最近测试工作中的一些心得分享出来，希望浅薄之语能对你有所启发和帮助。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
