前言：日常工作中，每天可能都会遇到不同的bug，有些刚入行的测试喜欢不加分析就直接甩给开发去解决。开发比较闲还好，如果手头工作比较多，就容易烦。甚至有可能是后端的问题，但是你却把问题丢给了前端，这种事情发生的次数多了，就比较容易暴露水平，那么正确的操作姿势是什么呢？首先遇到一个问题应该尝试自己独立去定位分析，自己去查找问题出现的原因，去定位是前端导致的bug还是后端导致的。分析好原因之后，带上问题和截图去提交bug，找到指定开发去解决问题。不同技术水平的测试人员，bug分析定位能力也有高低。这个除了需要不断总结之外，能决定你水平高低的原因其实就是工作经验。测试的项目多了，遇到的bug，踩的坑多了，水平自然就上去了。
bug的来源很多，有产品体验、开发自测、测试发现、用户反馈、运营反馈等等。我们做bug分析首先面临的就是“如何挑选合适的bug”。这里给出几点建议：
总之，只要是符合目标通过bug分析，更高效、有效的保证产品质量的bug，都可以选来做bug分析。
假设你已经选定了待分析的bug，我们接下来要做的是对bug收集尽量多的有效信息。比较常见的“bug信息”如下所示：
需要指出的是，结合bug的实际表现，我们在提交bug时应该尽量多的提供有效信息，对问题本身做“隔离”。这样做的好处是能够帮助开发过滤掉干扰因素，减少排查时间，更高效的定位到bug。来看个例子，通过隔离法做“初筛”，测试可以快速对bug做一轮初步定位。
我们前面说过，bug分析就是要追踪bug产生的本质原因。实际测试中，基于BUG分析的经验总结，我们将bug分析的过程分为三大类型。结合自己bug的特点，在分析时可以选择合适的方法去套用。
适用场景：可以直观的看到，或者通过隔离筛查，已经初步定位到bug模块。
举个例子：
“三星某版本（6.0内核）下，图片显示异常”
特定系统的问题，看起来bug原因比较明确，就是某系统下的显示问题。我们通过查看官方版本更新文档、了解代码变更，通常可以很快找到bug原因。
适用场景：比较没有头绪，bug本身以外的信息较少。
5W是一种分析方法，通过不断的追问“为什么”，来识别和说明因果关系，解释事件发生的本质原因。这里我们用在BUG分析中，借鉴5W思想，深入追踪BUG产生的根本原因，从源头上寻找BUG原因。
5W bug分析的特点是：从表象入手，一步步追问，由上一个问题的回答引发下一个问题，直至得到bug产生的本质原因。
举个例子：
BUG来源：QQ浏览器v9.0.0.4770版本
标题：使用第三方字体，页面显示异常
测试步骤：
【5W分析法开始追本溯源】
1、WHY：为什么页面文字会显示异常？
答：与系统字体作比较，系统字体显示正常，而第三方字体显示错误，所以判定是第三方字体显示逻辑出错
2、WHY：为什么第三方字体显示逻辑出错？
答：通过代码定位，发现第三方字体显示时，fileName参数传入了一个空值，导致跳出了字体设置逻辑？
3、WHY：为什么fileName会出现空值？
答：因为第三方字体读取数据时获取的是ID，未获得属性值
4、WHY：为什么第三方字体读取的是ID？
答：第三方字体与系统字体读取的逻辑不同，从系统接口读进来的就是ID，ID通过反射机制与字体属性对应，因此没有直接获取到属性值
5、WHY：为什么ID在显示时就会出错？
答：因为显示逻辑里面有个过滤原则，把path为空和fileName为空的字体过滤掉了，所以只有ID值的第三方字体会被过滤掉，无法显示
6、WHY：为什么显示逻辑里没有考虑到第三方字体只有ID，而path和fileName是空？
答：开发只想到path不能为空的情况，特意伪造了第三方字体的path值（没有实际意义），但过滤逻辑里还有fileName的为空判断，开发没有注意到，导致第三方字体会跳出显示逻辑
7、WHY：为什么开发会忘记过滤逻辑里有fileName为空的判断？
答：开发在写字体获取逻辑时，没仔细看字体显示逻辑的过滤条件，忽略了这个条件
可见，通过连续不断地追问why，我们总可以深挖到bug产生的最根本原因。当然，对新手来说，你可能没办法一次问到bug的本质，不过没关系，多问几次，培养对问题的敏感度，你总能从某条“线”上挖到你想到的结果。
适用场景：基于现有的知识储备，有一定的追查思路，能划分bug可能的几大类原因。
探案分析法，从案情的发生过程，基于经验分析确定可能的嫌疑人，再用高科技工具逐个排查疑犯，最终由证据指认真正的“凶手”。
举个例子：
“三星S10（Android 11）进入看准网任意二级链接进度条加载完成后白屏”
首先，从bug的描述信息提炼有价值的点：
【初步评估】
【怀疑对象】
【提炼疑点】
【收集证据&排除干扰】
【分析推理】
【结案陈词】
这里我们分为 5 个核心流程方法，其中包括：梳理流程、日志分析、最小路径、猜测排除、独立验证。
遇到问题后，要第一时间了解该问题重现的最小路径，通过最小路径来判断该问题的严重性以及影响面。如果重现路径复杂，那么可以思考影响面应该比较小，如果重现路径简单，那么该问题影响面应该很大，必须要尽快解决。
磨刀不误砍柴工，不要以为自己非常了解自己写的代码逻辑，往往是太熟悉了反而丢失了细节。在遇到疑难病症之前，一定要重现梳理逻辑流程，绘制出相应的逻辑流转图，根据业务逻辑重现梳理一遍。这样可以协助自己更快的定位到问题。如果觉得麻烦，可以直接使用脑图来绘制，更为简单快捷。比如像这样：
在业务出现一些异常情况时，需要增加日志信息了辅助定位，需要在逻辑分叉处以及外部调用增加日志即可。比如 if else、catch 、接口调用、SDK 调用等等。比如下面这段代码，为了检查问题，增加了各种日志信息。
在遇到问题后，要大胆的猜测，应该怀着任何都有可能出现问题的猜测，比如第三方库、系统调用等等，不要带着这部分肯定不会有问题的想法，把有可能出现问题的场景都列举出来。
| 猜测点 | 猜测说明 | 验证情况 |
|---|---|---|
| for 循环异常 | 中途抛异常退出 | |
| SDK 调用返回异常 | 返回数据接口异常 | |
| 获取系统 API 返回异常 | 系统存在缓存，导致更新不及时 |
拿到猜测列表后，就逐一进行验证，这里需要注意的是所有的验证都必须是独立的，不能多项同时进行验证。
如果遇到不能重现的问题，无法找到最小重现路径的，因为影响面是可控的，因此只需要增加日志加强定位辅助判断即可，对于核心重要的模块应该加强跟进。
大家都知道，bug发现的越早，修复的成本越低。通过bug分析，做好预防，尽量早的发现问题，从而降低修复成本和产品风险。
通过bug分析的案例积累，提升测试对产品整体架构的理解，高效、有效的设计测试方案，更好的把控产品质量风险。
产品侧：需求更合理、预知实现风险，前期从设计层面规避bug
开发侧：通过编码规范、加强自测和code review，提高代码质量
测试侧：补充优化测试方案，了解产品架构逻辑，经验和技术提升，更精准的关注重点bug、提升产品风险评估能力
举个例子：
Bug分析案例：“一个较大excel文件的白屏问题”
通过分析后得到的bug根因：在实现文件加载渐隐渐显效果时代码有逻辑缺陷，会导致文章内容在加载完成前webview被隐藏，页面白屏，文件打开失败。
(1) 测试优化改进方案
(2) 补充文件测试中对于文件大小的关注
实际效果：
从6.0版本至7.6版本，共发现16个与特定文件格式相关的bug
比如：
Bug分析是一种手段，但不是目的。从得到的bug根因，反思和回溯bug产生的各个阶段，思考如何避免类似问题，不再踩坑，在下次测试中得到提升，才是我们想要的结果。同样的，bug分析的成果是一个持续改进优化闭环的过程，它是测试人员潜移默化中测试能力的提升，也是项目流程中各个角色共同保障产品质量意识的推动。因此，请做好bug分析，为产品质量保驾护航 !
