【测试】定位bug的思路和方法

---

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

• 可以明确一个问题是不是真的“bug”。很多时候，我们找到了问题的原因，结果发现这根本不是bug。原因明确，误报就会降低。
• 多个系统交互，可以明确指出是哪个系统的缺陷，防止“踢皮球”，提高问题解决的效率。
• 增强开发对测试的信任度，沟通更有效，配合的更好，开发修改bug时效增强。
• 更有效的了解系统的内部逻辑、数据流处理流程，更能提高测试人员的水平，缺陷修复后，影响的测试范围评估更精准，复测更准确。
• 可以降低缺陷率。这个可以说是最重要的。在bug系统中，会要求开发人员记录bug产生的原因。只有我们自己对bug有一个较全面的认识，才会判别出开发写的是不是真正的原因，也才能有助于我们后续对bug进行分析归类，根据bug分析，有针对性地未雨绸缪，进而提升产品质量，降低缺陷。

0）定位原因之前

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

• 保存bug产生的记录：

  首要做的是保存bug产生的记录，保证可以复现。
  • 为什么要保存记录？因为如果以后不能复现，那就不能证明bug的存在。

• 排除低级问题：

  然后是排除QA的低级问题 。常见的低级问题：
  • hosts不对
  • 网络不通
  • 工具的影响导致的，例如fiddler
  • 以及操作姿势不正确等。

• 排除数据问题（脏数据）：

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

1）定位问题的思路

*判断是否为bug的标准：

• 功能是否符合需求说明书
• 从使用者的角度：功能是否易操作、易理解
• 系统压力指标是否达到质量要求

• 排查顺序：

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

1.1 用户环境层面

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

• 网络是否ping通
• ip和端口配置是否正确
• jdk版本是否符合标准
  • 有可能是由于jdk版本不兼容导致系统运行异常，这种问题根据实际情况来决定要不要兼容。
• 网络设了代理
• 弱网（如js/css未加载完全、请求超时）
• 浏览器不支持
• 系统版本不支持
• 数据库被删除
• 测试环境脏数据
• 项目配置开关
• 测试环境切了分支等

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

1.2 用户展示层

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

• 页面样式（css样式问题）
• 交互过程中js的提示（js交互问题）
• 终端控制的提示信息
• 文本的展示（html文本问题）

比如字段长度控制为4位，输入5位时，无法输入，或者大于4位页面弹出提示不允许输入大于4位。

这种问题不通过与服务器的交互，由页面、终端直接控制。这种问题往往比较容易修改，检查后，进入到第三步。

1.3 逻辑控制层

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

比如我们使用的贷记卡日累计额度为1万，当消费大于1万时，检查通过。

• 经过排查，后台参数配置的不对，或者通过查代码发现该逻辑没有判断。
  
  

再比如多系统交互时，我们发送一个请求后，终端返回超时。

• 这个时候需要查看日志定位具体哪个系统有问题，这种需要查看每个系统的日志请求及响应。
• 如果没有系统返回超时，并且每个系统都收到了正常的响应，那可能是终端超时时间设置的时间过小，未等到返回先超时导致。

该层的问题定位，一般都需要查看日志。该层检查完，转到下一层。

1.4 服务层

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

比如发现内存溢出问题。

• 那么可能是tomcat配置错误。
• 遇到过一个实际情况，应用系统为分布式部署，4路部署，当用户登录系统时，有的用户可以登录，有的无法登录，也不报错。经过逐层排查，发现有2路部署jdk版本不一致，原来用jdk1.6（2路），部署的为1.8（2路），是环境人员部署大意导致。

类似问题可能还有tomcat版本等、jar包版本测试环境和正式环境不同。

1.5 数据库层

可能出现测试环境和正式环境数据库版本不同，前后端数据格式、长度限制不同。

用户操作完成后，交易流程非常顺畅，这样也不代表整个交易没有问题，还需要测试人员检查数据库登记的表和字段是否正确。

• 如果发现登记的字段与预期的结果不一致，则可以查看日志，检查请求报文送的字段是否正确，是否与前台填写的一致。
• 有的一个操作会登记多张表，所以要检查多张表登记或者更新的是否正确，测试人员也需要对被测系统的数据表结构熟悉。

*1.6 经验法则

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

*1.7 其他

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

• 比如代码本身没错，但是合并代码到主干后出现了问题。
• 比如代码存在冲突时手动解决的情况。

2）定位问题的方法

2.1 常用的定位策略：

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

• 原始类定位方法

  原始类定位方法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它。

  • 主要思想是“通过计算机找错”。
  • 例如输出存储器、寄存器的内容，在程序安排若干输出语句等。
  • 凭借大量的现场信息，从中找到出错的线索，虽然最终也能成功，但难免要耗费大量的时间和精力。

• 回溯法

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

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

• 排除法

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

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

上述每一类方法均可利用一些测试工具，开发工具。

• 目前，调试编译器、动态调试器（追踪器）、测试用例自动生成器、存储器映象及交叉访问示图等到一系列工具已广为使用。

2.2 查看状态码

• 关于状态码的详细介绍可看本栏目的《【计算机网络】基础知识之从输入url到浏览器解析的过程》（https://blog.csdn.net/m0_37621024/article/details/116719803）。
• 以及可参考HTTP状态码大全：https://blog.csdn.net/lhjuejiang/article/details/79474199

• 4xx状态码：

  • 4xx状态码一般表示是客户端问题（当然也有可能是服务器端配置问题）。比如：
    • 发生了401，那么要看下是否带了正确的身份验证信息。
    • 发生了403则要看下是否有权限访问。
    • 404则要看下对应的URL是否真实存在。

• 5xx状态码：

  • 5xx状态码则一般表示服务端出现问题。比如：
    • 发生了500错误，则表明是服务器内部错误，这个时候要配合服务器log进行定位。
    • 发生了502错误则可能是服务器挂了导致的问题。
    • 发生503错误可能是由于网络过载导致的问题。
    • 发生504错误则可能是程序执行时间过长导致超时。

2.3 查看服务器日志

如果发生5xx问题，或者需要检查后端接口执行的sql是否正确，我们最常见的排查方法就是去看服务器日志，比如tomcat日志。

• 开发人员一般会打出关键信息和报错信息，从而找到问题所在，所以，测试人员也要养成看日志的习惯。

2.4 检查配置

很多时候，bug不是代码的问题，而是tomcat配置、nginx配置、jdbc配置等的问题。

• 在这个层面上，测试人员最好能够了解下它们的各项配置，在发现问题后可能就会想到这方面的问题。

2.5 查看需求文档

有时候，前端和服务端的交互都正确，但是从测试的角度看不合理。这个时候，我们应该翻翻需求文档。

• 如果和需求文档不符，那么就要看下改什么比较合理，是改前端，还是改服务端，或者两者都要改。
• 这里有一个原则，就是前端尽可能少地去承担逻辑，只负责渲染展现。

当然，不要以为需求文档就全部正确，它也可能会有错误，我们也应该去发现需求文档的bug，然后再去协调PM，敦促FE或者RD进行修改。

2.6 向开发寻求可测性支持

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

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

3）bug定位常用工具

• Firefox——firebug、web developer、live http - headers、http fox
• IE插件——httpwatch
• 第三方工具——fiddler
• 慢速网模拟工具——firefox throttle

4）如何区分前端/后端bug？

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

• 如果是一个多人开发的系统，不能明确定位到这个bug是谁造成的，容易提交给错误的开发人员。
• 同时提交给前后端开发人员，每个人都会有依赖心理，bug会像皮球一样被开发踢来踢去，耽误开发解决bug的时间。
• 另外，如果团队规模较大，或者由各地的项目组拼凑而成，势必会增加沟通成本，这更需要我们在类似禅道或者Jira等项目管理软件中提交bug时，先指明是谁的bug，避免互相踢皮球的现象。
• 所以测试必须要自己学会区分出是前端还是后端bug，经过bug分类处理，整个团队的效率都会有所提高。

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

前端Bug	后端Bug
界面相关	业务逻辑相关
布局相关	性能相关
兼容性相关	数据相关
交互相关	安全性相关

4.1 利用抓包工具来进行分析

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

• httpwatch，firebug都是浏览器的插件，需要额外下载。
• fiddler，charles也需要额外下载安装包另行安装。

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

• 浏览器F12调试器是所有浏览器内置的调试器，不需要额外去安装，而且它提供的功能也比较强大。
• 如果测试web系统，可以先考虑使用这个调试器去抓包，用它来协助定位系统中的bug。
• 在NetWork中可以看到当前页面发送的每个http请求。

4.1.1 分析角度

利用抓包工具，可以从三个方面进行分析：请求接口、传参、响应。

• 请求接口：

  如果请求的接口url错误，为前端的bug。

• 传参：

  如果传参不正确，如pn、ps参数，为前端的bug。

• 响应：

  如果响应内容不正确，为后端bug。
  • 要继续深挖，是接口吐数据的时候出错了，还是数据库中的数据就错了，还是缓存中的数据错了（如果用到了缓存的话）。

假设有这么一种情况，要测试一个翻页控件，翻到第二页的时候，发现内容和第一页完全一样，接口请求返回的是200。

• 这个时候就要看前端发送的参数正不正常，后端返回的内容正不正常，即接口的请求和返回。

• 如果JS基础比较好的话，也可以在浏览器的控制台中输入JS代码进行调试。

4.1.2 F12调试器工具的使用

1、打开：

以火狐为例，打开浏览器，再按F12就可以打开调试器：

• 不同的浏览器，调试器在ui上可能会有少许差异，但基本功能都差不多。

2、控制台与网络

在分析一个系统bug来自于前端还是后台时，最有用的两个是调试器提供的两个标签，这两个标签底下都记录了一些数据，一个是控制台，一个网络。

• 控制台（Console）：

  记录了前端js执行的情况，以及前端向服务器发出去的所有http请求信息。
  • 如果有js错误，可以在控制台下看到。如果发现js执行报错了，那就是前端有问题，比如跨域问题。
  • 如果发送到后台的某个http请求没有得到服务器正常响应，也能看到其状态信息。

• 网络（Network）：

  记录了前端往服务器发的所有的http请求信息，而且每个请求发送了什么数据，服务器是否正常响应了请求。如果响应了，响应回来的状态码是什么，响应数据是什么，都可以在“网络”标签下看到。

• 实际案例可参考：怎么知道bug是提给前端还是后端?https://www.zhihu.com/question/46433185/answer/667924745

4.2 定位前端的bug

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

bug主要有两块：

4.2.1 JS相关：

第一就是JS写的有问题，这个可以按F12 打开控制台，在console中查看报错信息，一般浏览器都会显示报错的js 。

• 对于出错的js可以在Sources下查看对应报错的资源文件，基本上都会找到错误原因的变量未定义，参数未定义等，JS错误都很好解决的。

4.2.2 页面：

第二个就是页面中的bug了，现在做web项目基本上没有做静态页面的，都是动态了，所以页面中要么使用了小脚本要么使用了EL表达式来存值。

• 页面报错的话，在控制台是可以看到错误行号和附近代码的。
• 图片不显示：
  • 谷歌浏览器右键点击图片，点击【检查】，（火狐浏览器右键点击【使用firebug查看元素】。
  • 在打开的控制台上找出图片的属性，输入到浏览器的地址内，如果能打开图片，那么不显示图片的问题就是后台的问题。
  • 如果浏览器内不能打开图片，那么就是前端的问题。

4.3 定位后端的bug

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

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

• 详细介绍可见：http://www.51testing.com/html/69/n-3722469.html

4.3.1 查看报错日志

日志常见的问题：

命令行ssh/xshell工具登录到服务器，找到相应log日志所在的目录，实时查看日志 tail -f xx.log 或 cat xx.log |grep '关键词' ，如找到报错信息可以去代码里面查是哪块报错。

• 编码问题：

  tomcat是新的，需要改编码。修改tomcat的server.xml文件，特别是windows下的项目重新部署到linux系统下。

• 空指针：

  程序问题，一般没有考虑到空的情况，或者主外键约束数据为空，或者删除关联数据，导致为空。

• 长度过长：

  超过最大长度，测试环境修改数据库字段长度后生产环境未修改，导致错误。

• 非法数据

• 内存溢出：

  导致重启。

4.3.2 查看数据库的数据

了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。

响应中有数据，但是跟自己操作的结果不一致，可以根据数据库查询，如果数据库中也没有记录，可能是代码有问题，没有记录你的操作。

• 例如：注册了一个帐号，但是登录时提示帐号或密码错误，这就可以在数据库表中查看是否有注册的数据。

4.3.3 查看缓存

查看缓存（如Memcache、apc、redis等缓存）是否正确。

5）定位完问题后

在发现问题或者定位到问题原因后，一定要进行一步，就是再次确认问题。

• 所谓确认问题，就是弄清楚问题是否每次都发生，还是概率事件，或者是工具相关的问题。
  • 比如换个浏览器是否依然出现？如果换个浏览器不出现的话，很可能就是前端的兼容性问题。
  • 比如翻页控件，待测的系统有很多页面都有翻页控件，那么就要看下是否每个页面都会出现这个问题，进而报bug时进行统一说明，也更加方便开发人员批量处理，防止漏改。

---

【部分内容参考自】

• 聊聊-如何准确定位bug原因：https://cloud.tencent.com/developer/news/44973
• 10大定位bug原因妙招分享，软件测试人员必看：https://baijiahao.baidu.com/s?id=1634223794115270596&wfr=spider&for=pc
• 三种bug定位方法：https://www.jianshu.com/p/4dbe0a194036
• 定位bug方法及案例分享：https://www.jianshu.com/p/c0328eabd9a9
• Web测试中定位bug方法：https://www.cnblogs.com/loved-wangwei/p/8985751.html
• Web测试中定位bug方法：http://www.51testing.com/html/69/n-3722469.html