遇到bug我们如何分析定位？_怎么定位bug

前言：日常工作中，每天可能都会遇到不同的bug，有些刚入行的测试喜欢不加分析就直接甩给开发去解决。开发比较闲还好，如果手头工作比较多，就容易烦。甚至有可能是后端的问题，但是你却把问题丢给了前端，这种事情发生的次数多了，就比较容易暴露水平，那么正确的操作姿势是什么呢？首先遇到一个问题应该尝试自己独立去定位分析，自己去查找问题出现的原因，去定位是前端导致的bug还是后端导致的。分析好原因之后，带上问题和截图去提交bug，找到指定开发去解决问题。不同技术水平的测试人员，bug分析定位能力也有高低。这个除了需要不断总结之外，能决定你水平高低的原因其实就是工作经验。测试的项目多了，遇到的bug，踩的坑多了，水平自然就上去了。

一、为什么要做bug分析定位？

1. 借助bug，提升测试人员对产品质量的整体把控
   从项目初期的产品需求评审，到开发阶段的自测、迭代提测、集成测试，直至发布后的用户反馈，可以说bug几乎贯穿了产品的各个阶段。对于测试来说，用好手中的bug，提升对产品的理解，能够更高效、更有效的测试，从而把控质量风险，提升产品质量。
2. 追本溯源，重新审视项目过程，推动优化
   有人说，产品一切bug的根源都是代码。如果把产品的诞生当作一场马拉松，那bug就是那些年我们踩过的坑。从哪儿跌倒就从哪儿爬起来，通过分析找到bug产生的根因，思考如何从各个方面去优化改进，避免以后踩到类似的“坑”，下一场比赛才能跑的更快更远。

二、怎么做bug分析定位？

1、第一步：怎么选bug？

bug的来源很多，有产品体验、开发自测、测试发现、用户反馈、运营反馈等等。我们做bug分析首先面临的就是“如何挑选合适的bug”。这里给出几点建议：

• 选择对用户影响大的：比如闪退、或者导致某功能无法使用的bug
• 选择典型有代表性的：同类型的一系列问题，比如：王者营地三星S10必现无法启动，得应用程序设置里才能打开
• 选择有发现难度的：积累问题库，对测试用例做补充
• 选择有推广价值的：可借鉴到其他平台或其他产品，比如：APP闪退系列专题

总之，只要是符合目标通过bug分析，更高效、有效的保证产品质量的bug，都可以选来做bug分析。

2、第二步：收集哪些bug信息？

假设你已经选定了待分析的bug，我们接下来要做的是对bug收集尽量多的有效信息。比较常见的“bug信息”如下所示：

• 被测产品信息：比如APP名称、版本号
• 测试机型和环境：比如三星手机S10型号、wifi网络、wup测试环境
• 严重级别：比如分为严重、一般、建议
• BUG模块：比如登录模块、首页模块 、下单模块
• 测试步骤：描述测试操作的12345步骤 ，确保问题能够复现
• 预期结果&实际结果：对比正常情况下的预知结果，给出bug的实际表现
• 附加信息：比如截图、视频录像、logcat信息等

需要指出的是，结合bug的实际表现，我们在提交bug时应该尽量多的提供有效信息，对问题本身做“隔离”。这样做的好处是能够帮助开发过滤掉干扰因素，减少排查时间，更高效的定位到bug。来看个例子，通过隔离法做“初筛”，测试可以快速对bug做一轮初步定位。

3、第三步：如何做bug分析定位？

我们前面说过，bug分析就是要追踪bug产生的本质原因。实际测试中，基于BUG分析的经验总结，我们将bug分析的过程分为三大类型。结合自己bug的特点，在分析时可以选择合适的方法去套用。

1、从三大类型分析

1. 直接分析法

适用场景：可以直观的看到，或者通过隔离筛查，已经初步定位到bug模块。

举个例子：
“三星某版本（6.0内核）下，图片显示异常”
特定系统的问题，看起来bug原因比较明确，就是某系统下的显示问题。我们通过查看官方版本更新文档、了解代码变更，通常可以很快找到bug原因。

2. 5W分析法

适用场景：比较没有头绪，bug本身以外的信息较少。
5W是一种分析方法，通过不断的追问“为什么”，来识别和说明因果关系，解释事件发生的本质原因。这里我们用在BUG分析中，借鉴5W思想，深入追踪BUG产生的根本原因，从源头上寻找BUG原因。

5W bug分析的特点是：从表象入手，一步步追问，由上一个问题的回答引发下一个问题，直至得到bug产生的本质原因。

举个例子：
BUG来源：QQ浏览器v9.0.0.4770版本
标题：使用第三方字体，页面显示异常
测试步骤：

1. 对手机更换热门的“喵嗚”字体；
2. 进入QQ浏览器，访问百度页面；
   现象：页面文字不显示
   分析步骤：
   （1）先找到问题的最外层表现，即明确BUG的表现是什么
   （2）对最外层表现提问，找出BUG的直接原因
   （3）用5W方法，针对直接原因，连续追问多次，直至找到BUG的本质原因

【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的本质，不过没关系，多问几次，培养对问题的敏感度，你总能从某条“线”上挖到你想到的结果。

3. 探案分析法

适用场景：基于现有的知识储备，有一定的追查思路，能划分bug可能的几大类原因。
探案分析法，从案情的发生过程，基于经验分析确定可能的嫌疑人，再用高科技工具逐个排查疑犯，最终由证据指认真正的“凶手”。

举个例子：
“三星S10（Android 11）进入看准网任意二级链接进度条加载完成后白屏”
首先，从bug的描述信息提炼有价值的点：

【初步评估】

• UC正常可以排除网络异常导致
• 三星S10手机独有问题
• 网址导航配置的链接，较容易被发现

【怀疑对象】

• 渲染模块，渲染异常，没有正确上屏
• 网络模块，网络交互异常，没有拉取到资源

【提炼疑点】

• 疑点1：只有三星S10手机有这个问题？跟机型和ROM版本有关吗？线上是否有类似用户反馈？
• 疑点2：看准网是做什么的？有什么特殊性？为什么一级链接正常，二级链接就白屏了？

【收集证据&排除干扰】

• 第一步：针对疑点1用其他机型做对比验证，验证结果：其他机型未复现。
• 第二步：查找线上数据，确认线上是否有类似用户反馈。查找结果：有1条反馈
  获取到如下关键信息：
  （1）反馈版本是9.5.0.2170，反馈时间20190617，早于上述bug发现时间。
  （2）用户机型是：华为P7，换手机也是如此。推翻上述单个机型问题的判断。
• 第三步：看准网是中国最大的企业点评、雇主品牌展示和员工分享平台
  其他招聘类站点未出现类似问题，初步看不出这个站点有什么特殊性
• 第四步：通过inspector调试发现，访问看准网二级链接，网络请求直接返回403，并没有拉取到网页资源，请求被服务器拒绝了

【分析推理】

• 服务器为什么在有些场景下会拒绝网络请求呢？怀疑是代理直连的策略导致，部分机型走直连，部分机型走代理。另外即使是配置成代理，但是由于各种不可控因素会导致走直连。
• 从log看当时出现白屏时，确实是走的代理。
  当时未能进一步验证：没有出现问题的手机访问该站点走的直连。
  猜测原因：代理情况下会出现，同一个IP高频访问，看准网屏蔽了我们的代理IP。
  解决方案：在强制直连白名单里增加看准网，之后可以正常拉取到资源

【结案陈词】

• 白屏问题是由网络模块异常导致，代理策略的局限性会导致：代理方式访问有做无效访问屏蔽的站点可能会存在这类问题（如：购票、投票等）

2、核心流程方法分析

这里我们分为 5 个核心流程方法，其中包括：梳理流程、日志分析、最小路径、猜测排除、独立验证。

1. 最小路径

遇到问题后，要第一时间了解该问题重现的最小路径，通过最小路径来判断该问题的严重性以及影响面。如果重现路径复杂，那么可以思考影响面应该比较小，如果重现路径简单，那么该问题影响面应该很大，必须要尽快解决。

2. 梳理流程

磨刀不误砍柴工，不要以为自己非常了解自己写的代码逻辑，往往是太熟悉了反而丢失了细节。在遇到疑难病症之前，一定要重现梳理逻辑流程，绘制出相应的逻辑流转图，根据业务逻辑重现梳理一遍。这样可以协助自己更快的定位到问题。如果觉得麻烦，可以直接使用脑图来绘制，更为简单快捷。比如像这样：

3. 日志分析

在业务出现一些异常情况时，需要增加日志信息了辅助定位，需要在逻辑分叉处以及外部调用增加日志即可。比如 if else、catch 、接口调用、SDK 调用等等。比如下面这段代码，为了检查问题，增加了各种日志信息。

4. 猜测排除

在遇到问题后，要大胆的猜测，应该怀着任何都有可能出现问题的猜测，比如第三方库、系统调用等等，不要带着这部分肯定不会有问题的想法，把有可能出现问题的场景都列举出来。

5. 独立验证

拿到猜测列表后，就逐一进行验证，这里需要注意的是所有的验证都必须是独立的，不能多项同时进行验证。

如果遇到不能重现的问题，无法找到最小重现路径的，因为影响面是可控的，因此只需要增加日志加强定位辅助判断即可，对于核心重要的模块应该加强跟进。

4、第四步：总结经验和改进优化

1、Bug左移

大家都知道，bug发现的越早，修复的成本越低。通过bug分析，做好预防，尽量早的发现问题，从而降低修复成本和产品风险。

2、测试优化

通过bug分析的案例积累，提升测试对产品整体架构的理解，高效、有效的设计测试方案，更好的把控产品质量风险。

3、项目各角色改进

产品侧：需求更合理、预知实现风险，前期从设计层面规避bug
开发侧：通过编码规范、加强自测和code review，提高代码质量
测试侧：补充优化测试方案，了解产品架构逻辑，经验和技术提升，更精准的关注重点bug、提升产品风险评估能力

举个例子：
Bug分析案例：“一个较大excel文件的白屏问题”
通过分析后得到的bug根因：在实现文件加载渐隐渐显效果时代码有逻辑缺陷，会导致文章内容在加载完成前webview被隐藏，页面白屏，文件打开失败。
(1) 测试优化改进方案

• 补充了需要验证的QB支持的文件格式
• 从之前的随意选取几个格式进行文件逻辑验证改为有针对性的选取文件格式以保证
• 特定打开逻辑的验证（集成时要求每种逻辑至少用一种文件格式验证）保证了文件格式和打开逻辑验证的覆盖度
  

(2) 补充文件测试中对于文件大小的关注

• 文件格式兼容的测试更有针对性，后面在测试第三方调起打开需求和手Q拉新需求的时候，都是直接按照表格上的格式让开发自测，同时我们自己也是这样验证的，既覆盖了系统的文件打开逻辑，也基本涵盖了用户常用的文件格式

实际效果：
从6.0版本至7.6版本，共发现16个与特定文件格式相关的bug

比如：

• 【文件】gz压缩包格式文件打开均失败ID:51182410
• 【文件】第三方使用浏览器打开txt显示乱码ID:51343519
• 产品上线后线上没有出现关于文件格式相关的用户反馈

三、思考总结

Bug分析是一种手段，但不是目的。从得到的bug根因，反思和回溯bug产生的各个阶段，思考如何避免类似问题，不再踩坑，在下次测试中得到提升，才是我们想要的结果。同样的，bug分析的成果是一个持续改进优化闭环的过程，它是测试人员潜移默化中测试能力的提升，也是项目流程中各个角色共同保障产品质量意识的推动。因此，请做好bug分析，为产品质量保驾护航 !