作者:phenyzhang
bug分析:本文指的是微观的bug分析。从单个有价值的bug入手,追踪和分析bug产生的本质原因,在此基础上对产品各个角色、以及项目流程做改善和优化。
可见,bug分析分为两部分。一是“bug分析”本身,二是以分析结果为前提,所做的一系列优化改善。
原因一:借助bug,提升测试人员对产品质量的整体把控
从项目初期的产品需求PK,到开发阶段的自测、迭代提测、集成上线提测,直至发布后用户反馈,可以说bug几乎贯穿了产品发展的各个阶段。对于测试人员来说,用好手中的bug,提升对产品的理解,能够更高效、更有效的测试,从而把控质量风险,提升产品质量。
原因二:追本溯源,重新审视项目过程,推动优化
有人说,产品一切bug的根源都是代码。如果把产品的诞生当作一场马拉松,那bug就是那些年我们踩过的坑。从哪儿跌倒就从哪儿爬起来,通过分析找到bug产生的根因,思考如何从各个方面去优化改进,避免以后踩到类似的“坑”,下一场比赛才能跑的更快更远。
先上模型,以下我们逐步讲解怎么对应模型去做bug分析。
bug的来源很多,有产品体验、开发自测、测试发现、众测反馈、灰度反馈、发布后反馈,等等。我们做bug分析首先面临的就是“如何挑选合适的bug”。这里给出几点建议:
总之,只要是符合目标通过bug分析,更高效、有效的保证产品质量的bug,都可以选来做bug分析。
假设你已经选定了待分析的bug,我们接下来要做的是,对bug收集尽量多的有效信息。比较常见的“bug信息”包括以下:
我们前面说过,bug分析就是要追踪bug产生的本质原因。实际测试中,基于BUG分析小组的经验总结,我们将bug分析的过程分为三大类型。结合自己bug的特点,在分析时可以选择合适的方法去套用。
适用场景:可以直观的看到,或者通过隔离筛查,已经初步定位到bug模块。
举个例子:
“华为M版本(6.0内核)下,图片显示异常”。
特定系统的问题,看起来bug原因比较明确,就是M系统下的显示问题。我们通过查看官方版本更新文档、了解代码变更,通常可以很快找到bug原因。
以这个bug来说,Chrome存在同样问题并已经做了修复,我们在官网上查找相关资料,就可以了解到bug根因了。
适用场景:比较没有头绪,bug本身以外的信息较少。
5W是一种分析方法,通过不断的追问“为什么”,来识别和说明因果关系,解释事件发生的本质原因。这里我们用在BUG分析中,借鉴5W思想,深入追踪BUG产生的根本原因,从源头上寻找BUG原因。
5W bug分析的特点是:从表象入手,一步步追问,由上一个问题的回答引发下一个问题,直至得到bug产生的本质原因。
举个例子:
BUG来源:X5 实验室Blink版本
标题:使用第三方字体,页面显示异常
测试步骤:
对手机更换热门的“花漾水果”字体;
进入QQ浏览器,访问百度,网易等页面;
现象:页面文字不显示
分析步骤:
(1)先找到问题的最外层表现,即明确BUG的表现是什么;
(2)对最外层表现提问,找出BUG的直接原因;
(3)用5W方法,针对直接原因,连续追问多次,直至找到BUG的本质原因;
可见,通过连续不断地追问why,我们总可以深挖到bug产生的最根本原因。当然,对新手来说,你可能没办法一次问到bug的本质,不过没关系,多问几次,培养对问题的敏感度,你总能从某条“线”上挖到你想到的结果。
适用场景:基于现有的知识储备,有一定的追查思路,能划分bug可能的几大类原因。
探案分析法,从案情的发生过程,基于经验分析确定可能的嫌疑人,再用高科技工具逐个排查疑犯,最终由证据指认真正的“凶手”。
举个例子:
“小米4(4.4.4)进入看准网任意二级链接进度条加载完成后白屏”。
首先,从bug的描述信息提炼有价值的点。
【初步评估】
1、UC正常可以排除网络异常导致
2、小米4手机独有问题
3、网址导航配置的链接,较容易被发现
【怀疑对象】
1、渲染模块,渲染异常,没有正确上屏
2、网络模块,网络交互异常,没有拉取到资源
【提炼疑点】
疑点1:只有小米4手机有这个问题?跟机型和ROM版本有关吗?线上是否有类似用户反馈?
疑点2:看准网是做什么的?有什么特殊性?为什么一级链接正常,二级链接就白屏了?
【收集证据&排除干扰】
Step1 针对疑点1用其他机型做对比验证,验证结果:其他机型未复现。
Step2 查找线上数据,确认线上是否有类似用户反馈。查找结果:有1条反馈
获取到如下关键信息:
(1)反馈版本是6.5.0.2170,反馈时间20160324,早于上述bug发现时间。
(2)用户机型是:LetvX500,换手机也是如此。推翻上述单个机型问题的判断。
Step3 看准网是中国最大的企业点评、雇主品牌展示和员工分享平台。
其他招聘类站点未出现类似问题,初步看不出这个站点有什么特殊性。
Step4 通过inspector调试发现,访问看准网二级链接,网络请求直接返回403,并没有拉取到网页资源,请求被服务器拒绝了。
【分析推理】
服务器为什么在有些场景下会拒绝网络请求呢?怀疑是代理直连的策略导致,部分机型走直连,部分机型走代理。另外即使是配置成代理,但是由于各种不可控因素会导致走直连。
从log看当时出现白屏时,确实是走的代理。
当时未能进一步验证:没有出现问题的手机访问该站点走的直连。
猜测原因:代理情况下会出现,同一个IP高频访问,看准网屏蔽了我们的代理IP。
解决方案:在强制直连白名单里增加看准网,之后可以正常拉取到资源。如下是QB从后台拉取的强制代理白名单,确实有增加看准网。
【结案陈词】
白屏问题是由网络模块异常导致,代理策略的局限性会导致:代理方式访问有做无效访问屏蔽的站点可能会存在这类问题(如:购票、投票等)。
大家都知道,bug发现的越早,修复的成本越低。通过bug分析,做好预防,尽量早的发现问题,从而降低修复成本和产品风险。
通过bug分析的案例积累,提升测试对产品整体架构的理解,高效、有效的设计测试方案,更好的把控产品质量风险。
举个例子:
Bug分析案例:“一个较大excel文件的白屏问题”
通过分析后得到的bug根因:在实现文件加载渐隐渐显效果时代码有逻辑缺陷,会导致文章内容在加载完成前webview被隐藏,页面白屏,文件打开失败。
(1) 测试优化改进方案:
(2) 补充文件测试中对于文件大小的关注。
收获:文件格式兼容的测试更有针对性,后面在测试第三方调起打开需求和手Q拉新需求的时候,都是直接按照表格上的格式让开发自测,同时我们自己也是这样验证的,既覆盖了QB的文件打开逻辑,也基本涵盖了用户常用的文件格式
实际效果:
从6.2版本至6.9版本,共发现14个与特定文件格式相关的bug;
比如:
上线后:线上没有出现关于文件格式相关的用户反馈。
Bug分析是一种手段,但不是目的。从得到的bug根因,反思和回溯bug产生的各个阶段,思考如何避免类似问题,不再踩坑,在下次测试中得到提升,才是我们想要的结果。同样的,bug分析的成果是一个持续改进优化闭环的过程,它是测试人员潜移默化中测试能力的提升,也是项目流程中各个角色共同保障产品质量意识的推动。因此,请做好bug分析,为产品质量保驾护航 !
本章完~
原文链接:http://tmq.cs0309.3g.qq.com/2016/10/dont-do-bug-analysisroutine-start/
扫码关注我们