背景：
事实回放：
2）测试工程师就会凭感觉和经验（而不是技能判断）判断这个BUG是哪个组，判断之后就会把这个BUG指派给该组的负责同事A。
注意：我们的绩效是按照每个团队每位同事产生的生产BUG去扣分的。
3）接收到这个BUG的开发同事A开始排查问题，花了半小时排查完之后发现这个BUG不是我这边的问题，于是就又丢给测试工程师，同时责备测试不应该把不是他的BUG指派给他，一来浪费他的时间，二来又影响他的绩效。
4）测试根据开发同事A的各种排查描述，得知这个BUG可能（是的，可能）是另一个组的开发同事B的问题，于是测试就把这个BUG指派给开发同事B。
5）接收到这个BUG的开发同事B开始排查问题（每个组的开发排查方式未必相同），顺利的情况下，最后排查得出这个BUG确实是我的。
6）开发同事B开始处理BUG，处理完之后给到测试验收，直到BUG关闭。
流程图如下图1：
图1
在这个过程中，还有隐形的多种问题：
1、验收在接收到测试工程师指派的无法确定是否是需要我处理的这类BUG时，会一直让这个BUG挂机在那不做处理，原因很简单，我花半小时去排查这个BUG，很有可能这个BUG不是我的。
2、开发经常性怼测试工程师，你怎么证明这个BUG就是我的？我就是不处理！还有你为什么总是把不是我的BUG指派给我？而测试工程师的回怼总是无力的“我怎么知道这个BUG是不是你的？”。
3、在互相扯皮的过程中，严重降低了“测试-研发”的合作效率。
处理方案：
孔子曰“其身正，不令而行；其身不正，虽令不从”，对于测试工程师来说，打铁还需自身硬。提高测试工程师排查BUG的能力势在必行。
当测试工程师拿到一个BUG时，可以通过APP抓包和查找数据库表的方式排查这个问题到底是那个开发工程师的。
举例：在APP上有一张图片无法正常呈现出来，而这个图片是由爬虫工程师采集过来的。
处理：
1）测试工程师先通过抓包的方式找出这个图片相关的HTTP请求内容，如果这个请求内容里面的图片URL为空，那么这个BUG很可能就是爬虫在采集数据或入库数据时出了问题，找出共性和规则给到爬虫工程师去处理。
2）如果这个图片URL是有值的，并且这个URL可以正常打开，但是这个URL的格式不是OSS的格式（服务端会把外面的图片保存到我们的OSS环境中），那么这个问题就是服务端在保存图片时出了问题，找出共性和规则给到服务端工程师去处理。
3）如果这个图片URL的格式是OSS，并且可以正常打开，但是只是在APP上无法呈现，那么这个问题就是客户端在显示图片时出了问题，找出共性和规则给到客户端工程师去处理。
如果测试工程师可以做到这样的话，BUG提交和处理的流程变成如下图2所示：
图2
当然，在这个过程中，测试工程师一要提高自己排查BUG的准确度，二要提高自己排查BUG过程可以给开发做参考的可用度。
扩展：
“作为一名软件测试工程师，需要具备哪些能力？”需要具备的能力很多，但是我觉得排查BUG能力是最重要，最有效，也是最容易被忽视的一点。
测试工程师的主要职责包括质检和质控，质检的东西大家都说的很多，质控的就比较少啦，我在这里也提一下。
质控一：上游工作质控
在产品刚立项、进行需求确认的时候，测试人员就会参与进去，仔细地Review需求，看需求是不是完整、有没有漏洞，这个时候还没有进入正式开发，修改需求对于项目组来说代价是最少的。在这个环节，测试人员凭借缜密的推演、发散性的思维，往往能发现很多需求的漏洞，提高了项目的整体效率。
另外，测试人员在完成测试计划、测试用例以后，会邀请开发、产品一起评审测试用例，在这个环节，由于测试人员把每个需求如何细化测试都体现在了用例里面，就相当于再次把需求分析了个透，往往还能发现很多需求的漏洞。这也是提早发现需求漏洞的有效环节。
质控二：下游工作质控
在产品完成了测试以后，就是发布的环节了，测试人员在发布的环节也能发挥作用。首先，测试人员为了部署测试环境，研究自动化部署的技术，可以把上线部署的环节也自动化，以前需要2个小时的部署环节压缩到半个小时甚至更少，而且更加准确可靠。
如果有些版本修改比较多，上线的质量风险大，测试人员会跟产品一起制定灰度发布的方案并在技术上进行实现，让版本先面向一小部分用户开放，如果发现Bug了，影响的用户也比较小，Bug改掉以后，再逐渐扩大用户范围。
另外，优秀的测试人员还会发动项目组的其他人一起来保证项目质量，比如推动开发进行代码Review；引入冒烟自测流程，让开发先自测以后再提交给测试做冒烟测试；通过在项目组分析Bug，让开发提高自测，降低Bug数量等；引入策划、交互、视觉在测试阶段进行走查等等各种措施。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
