遇到 bug 怎么分析, 这篇文章值得一看

为什么定位问题如此重要？

• 可以明确一个问题是不是真的“bug”

  很多时候，我们找到了问题的原因，结果发现这根本不是 bug。原因明确，误报就会降低

• 多个系统交互，可以明确指出是哪个系统的缺陷，防止“踢皮球”，提高问题解决的效率

• 增强开发对测试的信任度，沟通更有效，配合的更好，开发修改 bug 时效增强

• 更有效的了解系统的内部逻辑、数据流处理流程，更能提高测试人员的水平，缺陷修复后，影响的测试范围评估更精准，复测更准确

• 可以降低缺陷率

  这个可以说是最重要的。在 bug 系统中，会要求开发人员记录 bug 产生的原因。只有我们自己对 bug 有一个较全面的认识，才会判别出开发写的是不是真正的原因，也才能有助于我们后续对 bug 进行分析归类，根据 bug 分析，有针对性地未雨绸缪，进而提升产品质量，降低缺陷

01

定位原因之前

遇到问题时，先别急着去定位原因。

1、保存 bug 产生的记录：

首要做的是保存 bug 产生的记录，保证可以复现。

为什么要保存记录？因为如果以后不能复现，那就不能证明 bug 的存在。

2、排除低级问题：

然后是排除 QA 的低级问题，常见的低级问题：

• 【hosts 不对】

  hosts 文件主要是加快某个域名或者网站的解析速度，从而达到快速访问的作用，也可以屏蔽网站。

  hosts 异常可能会导致部分网页无法访问，能够加载，但是网页无法正常显示。

• 【网络不通】：抓包、ping

• 工具的影响导致的，例如 fiddler

• 以及操作姿势不正确等。

3、排除数据问题（脏数据）：

有时候会遇到服务端报 500 错误，查看日志后，报空指针，那么很有可能就是数据库中关联表的数据被人为删掉导致的。

• 脏数据：从目标中取出的数据已经过期、错误或者没有意义，这种数据就叫做脏数据

• 脏读：读取出来脏数据就叫脏读

测试自学教程这里获取… https://csx-t231.github.io/

02

定位问题的思路

排查顺序：

用户环境层面 -> 展示层面 -> 逻辑控制层面 -> 服务层面 -> 数据库层面

1、用户环境层面

主要是指基础环境是否可以使用。比如：

• 网络是否 ping 通

• ip 和端口配置是否正确

• jdk 版本是否符合标准

  有可能是由于 jdk 版本不兼容导致系统运行异常，这种问题根据实际情况来决定要不要兼容。

• 网络设了代理

• 弱网（如 js/css 未加载完全、请求超时）

• 浏览器不支持

• 系统版本不支持

• 数据库被删除

• 测试环境脏数据

• 项目配置开关

• 测试环境切了分支等

检查完成后，可以转到第二步

2、用户展示层

用户在使用过程中，通过查看等操作发现的一些问题：

• 页面样式（css 样式问题）

• 交互过程中 js 的提示（js 交互问题）

• 终端控制的提示信息

• 文本的展示（html 文本问题）

3、逻辑控制层

用户操作过程中，业务的处理逻辑有没有按照前期的设计实施。或者中间环节出现异常，比如缓存服务器（如 redis）、消息中间件（如 rabbitMQ）、数据存取中间件等。

4、服务层

服务层往往检查服务器的配置，如可能是 tomcat 配置、nginx 配置、jdbc 配置等的问题。测试人员最好能够了解下它们的各项配置。

5、数据库层

可能出现测试环境和正式环境数据库版本不同，前后端数据格式、长度限制不同。用户操作完成后，交易流程非常顺畅，这样也不代表整个交易没有问题，还需要测试人员检查数据库登记的表和字段是否正确

• 如果发现登记的字段与预期的结果不一致，则可以查看日志，检查请求报文送的字段是否正确，是否与前台填写的一致

• 有的一个操作会登记多张表，所以要检查多张表登记或者更新的是否正确，测试人员也需要对被测系统的数据表结构熟悉

6、经验法则

有经验的测试人员对于有部分 bug 已经见过多次，能够很快找到根源，直奔主题，迅速报告或者解决 bug

7、其他

常见的 bug 可能还有构建方面的原因

• 比如代码本身没错，但是合并代码到主干后出现了问题

• 比如代码存在冲突时手动解决的情况

03

定位问题的方法

1、常用的定位策略：

常用的定位策略分为三类：原始类(brute force)、回溯类(backtracking)、排除类(causeeliminations)

• 原始类定位方法

原始类定位方法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它，主要思想是“通过计算机找错”。

• 回溯法

回溯法能成功地用于程序的排错

方法是从出现 bug 征兆处开始，人工地沿控制流程往回追踪，直至发现出错的根源，不幸的是程序变大后，可能的回溯路线显著增加，以致人工进行完全回溯到望而不可及。

• 排除法

基于归纳和演绎原理，采用“分治”的概念。

首先确定所有与 bug 出现有关的所有数据，设想一个导致 bug 的原因，用这些数据证明或反驳它。或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端，则立即精化数据，乘胜追击

2、查看状态码

4xx 状态码：一般表示是客户端问题（当然也有可能是服务器端配置问题），比如：

• 发生了 401，那么要看下是否带了正确的身份验证信息

• 发生了 403 则要看下是否有权限访问

• 404 则要看下对应的 URL 是否真实存在

5xx 状态码：一般表示服务端出现问题。比如：

• 发生了 500 错误，则表明是服务器内部错误，这个时候要配合服务器 log 进行定位

• 发生了 502 错误则可能是服务器挂了导致的问题

• 发生 503 错误可能是由于网络过载导致的问题

• 发生 504 错误则可能是程序执行时间过长导致超时

3、查看服务器日志

如果发生 5xx 问题，或者需要检查后端接口执行的 sql 是否正确，我们最常见的排查方法就是去看服务器日志，比如 tomcat 日志。开发人员一般会打出关键信息和报错信息，从而找到问题所在，所以，测试人员也要养成看日志的习惯。

4、检查配置

很多时候，bug 不是代码的问题，而是 tomcat 配置、nginx 配置、jdbc 配置等的问题。在这个层面上，测试人员最好能够了解下它们的各项配置，在发现问题后可能就会想到这方面的问题。

5、查看需求文档

有时候，前端和服务端的交互都正确，但是从测试的角度看不合理。这个时候，我们应该翻翻需求文档。如果和需求文档不符，那么就要看下改什么比较合理，是改前端，还是改服务端，或者两者都要改。

这里有一个原则，就是前端尽可能少地去承担逻辑，只负责渲染展现。当然，不要以为需求文档就全部正确，它也可能会有错误，我们也应该去发现需求文档的 bug，然后再去协调 PM，敦促 FE 或者 RD 进行修改。

6、向开发寻求可测性支持

有时候，涉及到开发过程的一些测试，也需要开发提供可测性支持。

比如，要查看接口给另一个接口发的请求是否正确，可以让开发打印出完整的请求 log，还有一些逻辑开关、修改页面数据条数等，都属于可测性支持的范畴。

测试自学教程这里获取… https://csx-t231.github.io/

04

bug 定位常用工具

Firefox——firebug、web developer、live http - headers、http fox

IE 插件——httpwatch

第三方工具——fiddler

慢速网模拟工具——firefox throttle

05

如何区分前端/后端 bug

为什么要区分前端/后端 BUG？

• 如果是一个多人开发的系统，不能明确定位到这个 bug 是谁造成的，容易提交给错误的开发人员。

• 同时提交给前后端开发人员，每个人都会有依赖心理，bug 会像皮球一样被开发踢来踢去，耽误开发解决 bug 的时间。

• 另外，如果团队规模较大，或者由各地的项目组拼凑而成，势必会增加沟通成本，这更需要我们在类似禅道或者 Jira 等项目管理软件中提交 bug 时，先指明是谁的 bug，避免互相踢皮球的现象。

• 所以测试必须要自己学会区分出是前端还是后端 bug，经过 bug 分类处理，整个团队的效率都会有所提高。

前后端 BUG 各有什么样的特点？

1、利用抓包工具来进行分析

一般有 httpwatch，firebug，fiddler，charles 等抓包（数据包）工具。

• httpwatch，firebug 都是浏览器的插件，需要额外下载

• fiddler，charles 也需要额外下载安装包另行安装

• 还有一个简单实用的抓包工具，那就是浏览器的 F12 调试器

2、定位前端的 bug

前端的 bug 通常是功能、界面和兼容性等有关，涉及到 jstl，jsp，js，css，html 方面比较多。bug 主要有两块：

• JS 相关

• 页面

3、定位后端的 bug

后台涉及到 servlet，jms，ejb，还有很多框架 struts，hibernate，spring，ibatis 等

bug 比较难改，但是好找，主要就是看控制台报错，然后定位错误行号。如果配置文件没有问题，那么一般的报错就是空指针，或者是数组下标越界。看附近变量，看方法的参数基本上都可以定位错误。

06

定位完问题后

在发现问题或者定位到问题原因后，一定要进行一步，就是再次确认问题。所谓确认问题，就是弄清楚问题是否每次都发生，还是概率事件，或者是工具相关的问题：

• 比如换个浏览器是否依然出现？如果换个浏览器不出现的话，很可能就是前端的兼容性问题。

• 比如翻页控件，待测的系统有很多页面都有翻页控件，那么就要看下是否每个页面都会出现这个问题，进而报 bug 时进行统一说明，也更加方便开发人员批量处理，防止漏改。

• 
  

最后： 可以在公众号：伤心的辣条 ！ 自行领取一份 216 页软件测试工程师面试宝典文档资料【免费的】。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux 必备、Shell、互联网程序原理、Mysql 数据库、抓包工具专题、接口测试工具、测试进阶-Python 编程、Web 自动化测试、APP 自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

学习技术千万不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。你可以加入我们的测试技术交流扣扣群：746506216（里面有各种软件测试资源和技术讨论）

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！