提高处理BUG效率第一步:提高测试工程师排查BUG能力

2018-04-02  开心的小麻花 

转载:http://www.51testing.com/html/47/n-3725347.html
背景:

一家主要是做一款APP的公司,公司技术部门有三个组:爬虫组、服务端组和APP客户端组。

事实回放:

1)每次运营或产品提出一个BUG给到测试工程师后。

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数量等;引入策划、交互、视觉在测试阶段进行走查等等各种措施。


332°/3320 人阅读/0 条评论 发表评论

登录 后发表评论