WHY为什么要做bug分析
原因一：借助bug，提升测试人员对产品质量的整体把控
从项目初期的产品需求PK，到开发阶段的自测、迭代提测、集成上线提测，直至发布后用户反馈，可以说bug几乎贯穿了产品发展的各个阶段。对于测试人员来说，用好手中的bug，提升对产品的理解，能够更高效、更有效的测试，从而把控质量风险，提升产品质量。
原因二：追本溯源，重新审视项目过程，推动优化
有人说，产品一切bug的根源都是代码。如果把产品的诞生当作一场马拉松，那bug就是那些年我们踩过的坑。从哪儿跌倒就从哪儿爬起来，通过分析找到bug产生的根因，思考如何从各个方面去优化改进，避免以后踩到类似的“坑”，下一场比赛才能跑的更快更远。
HOW怎么做bug分析
HOW怎么做bug分析
先上模型，以下我们逐步讲解怎么对应模型去做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的特点，在分析时可以选择合适的方法去套用。
1、直接分析法
适用场景：可以直观的看到，或者通过隔离筛查，已经初步定位到bug模块。
举个例子：
“华为M版本（6.0内核）下，图片显示异常”。
特定系统的问题，看起来bug原因比较明确，就是M系统下的显示问题。我们通过查看官方版本更新文档、了解代码变更，通常可以很快找到bug原因。
以这个bug来说，Chrome存在同样问题并已经做了修复，我们在官网上查找相关资料，就可以了解到bug根因了。
2、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的本质，不过没关系，多问几次，培养对问题的敏感度，你总能从某条“线”上挖到你想到的结果。
3、探案分析法
适用场景：基于现有的知识储备，有一定的追查思路，能划分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从后台拉取的强制代理白名单，确实有增加看准网。
【结案陈词】
白屏问题是由网络模块异常导致，代理策略的局限性会导致：代理方式访问有做无效访问屏蔽的站点可能会存在这类问题（如：购票、投票等）。
第四步、总结经验和改进优化
1、Bug左移
大家都知道，bug发现的越早，修复的成本越低。通过bug分析，做好预防，尽量早的发现问题，从而降低修复成本和产品风险。
2、测试优化
通过bug分析的案例积累，提升测试对产品整体架构的理解，高效、有效的设计测试方案，更好的把控产品质量风险。
3、项目各角色改进
产品侧：需求更合理、预知实现风险，前期从设计层面规避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分析，为产品质量保驾护航 !
