软件测试，漏测了怎么办？

 

 

   软件测试的最终目的就是保证被测产品的质量，在一定成本的投入下，尽最大努力来减少产品发布出去给公司造成的损失；软件测试是无穷尽的，因为你不知道什么时候是有Bug，在互联网快速迭代，测试时间被压缩或者其他因素，造成软件质量问题，这时有的就是不管三七二十一，软件测试就是背锅侠；

那对于测试背锅，我们要如何应付或者如何解决当发现漏测了，我们该怎么处理？可以分为事中，事后，事前（平常）三个阶段；事中当发现漏测，要根据反馈的问题的严重等级做相应的处理，如遇到严重的反馈，看能否复现，如无法复现，看下用户反馈的信息是否详细，没有的话让相关人员尽快联系，以便确认；当然在遇到严重问题或者漏测的问题，也许沉不住气的产品或者项目负责人等其职位，会跳出来你们测试怎么测的，怎么没有发现，对于这个别着急，分两种情况，如果你平常测试都有养成测试记录，确定不是自己的问题，看对方态度直接怼回去，委婉的就在项目组说明经过，千万不要私聊，要让大家知道这不是你的问题，并且后续要把这个问题出现原因经过结果发到项目组以及告知你的上级；如果无法确认的，别着急回复，先看会不会复现，复现了提交Bug，尽快让开发修复，并分析是否是没有测试到还是怎样；如果没有复现，尽量收集全信息，看能否复现；总结，漏测发生了，不管项目组的声音如何，就是先看Bug是否能复现，然后尽快解决，是否发版，然后分析原因，问题原因公开化，是自己测试问题就承担，不是就绝不要背锅，要项目组和你的上级都知道；

事后，有些Bug确实是没考虑到或者人为疏忽造成，或者环境原因，开发合并代码影响，开发优化代码直接发布，未经过测试发布，机型兼容等问题，所以一定要根据Bug的原因进行对症下药分析，并给出结果，防止再次出现的措施跟责任人，然后公开化。比如开发修改Bug或者优化了点，一定要邮件或者项目组周知，不能简单认为没有问题就自己合并不告知测试，直接发布，并且每个版本的合并开组主管要做好代码审查，来杜绝随便合并代码或者任意发布代码造成测试没有测试到，而造成发布的版本出现问题；Bug的对症下药，如何对症，首先确定Bug的复现步骤和结果，然后确认Bug的是由什么原因造成的，分析是人为还是考虑不周，人为的要根据严重等级，进行绩效处理，考虑不周，要根据场景，来判断影响的程度，并且要从点想到面，拓展这个点，哪些方面可能还存在问题，然后进行测试，把这个问题点分享给相关测试，并把考虑这个点等级到常规功能或者是再发防止列表，绝对可以避免这个类似问题发生；还有两个方法可以补充，一个常规出错的问题整理文档，新进的员工，必须看以及告知涉及到考核，在整个分析问题，要组织会议，以客观的角度去分析，敢于说事实，别找借口，这样的分析才有意义；另一个让出现这个问题测试人员，开分享会，自己总结如何避免出现这个问题，增加大家及自己的记忆；通过不断的对漏测的Bug分析，经验累积，测试场景累积，漏测的问题就会越来越少，背锅机会就会越来越少，项目组对你的信任度就会越来越高，就会有话语权；

平常（事前）：做事有理有据，保持良好测试分析能力，推进测试流程，提高测试技能，完善测试内容，培训常态化，测试责任制，漏测跟绩效挂钩，良好的质量保证错误，如常规功能清单；

最后，项目测试质量是相对的，会受到测试人员的能力，知识，技术水平和产品的周期阶段有关，所以在过程，一定要分析到位，把风险公开化，这样不仅在保护项目质量也在保护自己，也在保护测试团队的尊严；“兵怂怂一个，将怂怂一窝”上级也要及时关注测试人员的情况，要维护自己的军队尊严；当然兵出去了，也要代表整个军队的门面，别丢脸；

   漏测不可怕，怕的是不知道为什么漏测，还相互推诿，不知道如何改进，还重复出现，这样的测试，不背锅，才怪；漏测要的态度，发现问题，改进，保证措施，避免再次出现，累积经验，这样漏测机率就会越来越小了~