WHY为何要作bug分析?web
缘由一:借助bug,提高测试人员对产品质量的总体把控
从项目初期的产品需求PK,到开发阶段的自测、迭代提测、集成上线提测,直至发布后用户反馈,能够说bug几乎贯穿了产品发展的各个阶段。对于测试人员来讲,用好手中的bug,提高对产品的理解,可以更高效、更有效的测试,从而把控质量风险,提高产品质量。
缘由二:追本溯源,从新审视项目过程,推进优化
有人说,产品一切bug的根源都是代码。若是把产品的诞生看成一场马拉松,那bug就是那些年咱们踩过的坑。从哪儿跌倒就从哪儿爬起来,经过分析找到bug产生的根因,思考如何从各个方面去优化改进,避免之后踩到相似的“坑”,下一场比赛才能跑的更快更远。浏览器
HOW怎么作bug分析?服务器
第一步:怎么选bug网络
bug的来源不少,有产品体验、开发自测、测试发现、众测反馈、灰度反馈、发布后反馈,等等。咱们作bug分析首先面临的就是“如何挑选合适的bug”。这里给出几点建议:架构
选择对用户影响大的:好比闪退、或者致使某功能没法使用的bug 工具
选择典型有表明性的:同类型的一系列问题,好比:skia适配致使2.3和4.4手机必现没法启动 测试
选择有发现难度的:积累问题库,对测试用例作补充 字体
总之,只要是符合目标经过bug分析,更高效、有效的保证产品质量的bug,均可以选来作bug分析。优化
第二步、收集哪些bug信息编码
假设你已经选定了待分析的bug,咱们接下来要作的是,对bug收集尽可能多的有效信息。比较常见的“bug信息”包括如下:
被测产品信息:好比APP名称、版本号
测试机型和环境:好比小米手机4.4系统、wifi网络、wup测试环境
严重级别:好比分为严重、通常、建议
BUG模块:好比书签模块、字体模块
测试步骤:描述测试操做的123步骤
预期结果&实际结果:对比正常状况下的预知结果,给出bug的表现
附加信息:好比截图、视频录像、logcat信息等
须要指出的是,结合bug的实际表现,咱们在提交bug时应该尽可能多的提供有效信息,对问题自己作“隔离”。这样作的好处是,可以帮助开发过滤掉干扰因素,减小排查时间,更高效的定位到bug。来看个例子,经过隔离法作“初筛”,测试能够快速对bug作一轮初步定位。
第三步、如何作bug分析
咱们前面说过,bug分析就是要追踪bug产生的本质缘由。实际测试中,基于BUG分析小组的经验总结,咱们将bug分析的过程分为三大类型。结合本身bug的特色,在分析时能够选择合适的方法去套用。
一、直接分析法
适用场景:能够直观的看到,或者经过隔离筛查,已经初步定位到bug模块。
举个例子:
“华为M版本(6.0内核)下,图片显示异常”。
特定系统的问题,看起来bug缘由比较明确,就是M系统下的显示问题。咱们经过查看官方版本更新文档、了解代码变动,一般能够很快找到bug缘由。
以这个bug来讲,Chrome存在一样问题并已经作了修复,咱们在官网上查找相关资料,就能够了解到bug根因了。
二、5W分析法
适用场景:比较没有头绪,bug自己之外的信息较少。
5W是一种分析方法,经过不断的追问“为何”,来识别和说明因果关系,解释事件发生的本质缘由。这里咱们用在BUG分析中,借鉴5W思想,深刻追踪BUG产生的根本缘由,从源头上寻找BUG缘由。
5W bug分析的特色是:从表象入手,一步步追问,由上一个问题的回答引起下一个问题,直至获得bug产生的本质缘由。
举个例子:
BUG来源:X5 实验室Blink版本
标题:使用第三方字体,页面显示异常
测试步骤:
1. 对手机更换热门的“花漾水果”字体;
2. 进入QQ浏览器,访问百度,网易等页面;
现象:页面文字不显示
分析步骤:
(1)先找到问题的最外层表现,即明确BUG的表现是什么;
(2)对最外层表现提问,找出BUG的直接缘由;
(3)用5W方法,针对直接缘由,连续追问屡次,直至找到BUG的本质缘由;
可见,经过接二连三地追问why,咱们总能够深挖到bug产生的最根本缘由。固然,对新手来讲,你可能没办法一次问到bug的本质,不过不要紧,多问几回,培养对问题的敏感度,你总能从某条“线”上挖到你想到的结果。
三、探案分析法
适用场景:基于现有的知识储备,有必定的追查思路,能划分bug可能的几大类缘由。
探案分析法,从案情的发生过程,基于经验分析肯定可能的嫌疑人,再用高科技工具逐个排查疑犯,最终由证据指认真正的“凶手”。
举个例子:
“小米4(4.4.4)进入看准网任意二级连接进度条加载完成后白屏”。
首先,从bug的描述信息提炼有价值的点。
【初步评估】
一、UC正常能够排除网络异常致使
二、小米4手机独有问题
三、网址导航配置的连接,较容易被发现
【怀疑对象】
一、渲染模块,渲染异常,没有正确上屏
二、网络模块,网络交互异常,没有拉取到资源
【提炼疑点】
疑点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分析的案例积累,提高测试对产品总体架构的理解,高效、有效的设计测试方案,更好的把控产品质量风险。
三、项目各角色改进
产品侧:需求更合理、预知实现风险,前期从设计层面规避bug;
开发侧:经过编码规范、增强自测和code review,提升代码质量 ;
测试侧:补充优化测试方案,了解产品架构逻辑,经验和技术提高,更精准的关注重点bug、提高产品风险评估能力.
举个例子:
Bug分析案例:“一个较大excel文件的白屏问题”
经过分析后获得的bug根因:在实现文件加载渐隐渐显效果时代码有逻辑缺陷,会致使文章内容在加载完成前webview被隐藏,页面白屏,文件打开失败。
(1) 测试优化改进方案:
a. 补充了须要验证的QB支持的文件格式;
b. 从以前的随意选取几个格式进行文件逻辑验证改成有针对性的选取文件格式以保证;
c. 特定打开逻辑的验证(集成时要求每种逻辑至少用一种文件格式验证)保证了文件格式和打开逻辑验证的覆盖度;
(2) 补充文件测试中对于文件大小的关注。
收获:文件格式兼容的测试更有针对性,后面在测试第三方调起打开需求和手Q拉新需求的时候,都是直接按照表格上的格式让开发自测,同时咱们本身也是这样验证的,既覆盖了QB的文件打开逻辑,也基本涵盖了用户经常使用的文件格式
实际效果:
从6.2版本至6.9版本,共发现14个与特定文件格式相关的bug;
好比:
【文件】gz压缩包格式文件打开均失败ID:51182410
【文件】第三方使用浏览器打开txt显示乱码ID:51343519
上线后:线上没有出现关于文件格式相关的用户反馈。
Bug分析是一种手段,但不是目的。从获得的bug根因,反思和回溯bug产生的各个阶段,思考如何避免相似问题,再也不踩坑,在下次测试中获得提高,才是咱们想要的结果。一样的,bug分析的成果是一个持续改进优化闭环的过程,它是测试人员潜移默化中测试能力的提高,也是项目流程中各个角色共同保障产品质量意识的推进。所以,请作好bug分析,为产品质量保驾护航 !