分享一个远程调试Bug的思路

前2天一个粉丝微信问了我一个问题，并希望我能远程帮忙改下bug，经过半小时左右的“折腾”，终于修改成功！现将自己的感悟分享给大家，希望能给大家提供一点点解决bug的思路。

bug 产生的原因不是很高深，发现过程也不是很难，但对于那些没有代码经验或代码经验薄弱的小伙伴来说确实是个挑战，因此那些代码水平高的小伙伴可以不用看了哈。

大致背景如下

这位粉丝也有几年的工作经验了，一直都是手工测试为主，最近想学点测试开发技术，自己从网上下载了前后端分离的养老院后台管理项目，想用自己开发的测试平台去对养老院项目进行接口测试，测试平台我们暂且称之为demo4吧，也是前后端分离的项目。

这位粉丝在测试平台配置好养老院项目的添加用户账号接口的测试用例，信息包括接口名称、接口路径、请求数据、描述等信息，如截图：

预期结果是执行完测试用例后，测试平台期望返回“{"msg":"添加成功","code":200}”，并且养老院用户账号查询列表会有一条具体的用户数据。

bug现象描述

配置完具体信息后，开始执行测试用例如截图：

接口返回添加用户成功，然后再去养老院页面web管理系统查看信息为空（除了id字段），如截图：

运行测试用例前养老院用户账号截图

运行测试用例后养老院用户账号截图

再运行一次：

还是只新增了一个id字段，就很诡异，明明测试平台运行测试用例，显示添加成功了，为啥养老院项目用户信息只有一个id字段呢？其他数据如用户姓名、性别等信息跑哪去了？

bug分析过程

说实话，当粉丝把这个bug描述发给我的时候，我也是很疑惑，接口都调用成功了，为什么页面只显示一个id字段？仔细一想可能会有以下几个原因：

1、测试平台后端执行添加用户接口（http://localhost:8089/root/addUsr）,响应是“添加成功”，是不是写死了接口返回结果？也就是说无论请求什么接口，都返回添加成功！

2、从页面显示信息来看，http://localhost:8089/root/addUsr接口肯定是调用成功了，不然也不会测试平台每执行一次测试用例，就多一行数据（虽然这条数据只有一个id字段），可能在某个接口调用链路中，参数传输或映射出现问题，但在哪个链路中出现问题呢？且听下文讲解。

带着这样的疑问，征求粉丝同意后，我用向日葵远程控制了粉丝的电脑。

第一个猜想验证过程

首先我看了下测试平台调用添加用户接口的代码，如截图：

大致分析了一下，没什么深奥的逻辑，无非就是接受测试用例传入的参数，然后再用httputils类中，postjson方法进行接口调用，传入相关参数，然后在接口返回的信息放入map中，并返回测试平台页面，也就是上面看到的输入框信息如下截图：

看来这里没有写死接口响应，那postjson方法会不会写死呢？

代码逻辑也不是很复杂，就是简单的使用httpclient 工具调用添加用户接口，最后直接返回接口的响应，看来也没有写死接口响应。

那养老院项目添加用户信息接口有没有写死接口响应呢？

上图是养老院项目添加用户信息接口调用方法流程

RootInfoController.java

/** 添加用户 */
@RequestMapping("/addUsr")
public AjaxResult addUsr(UsrInfo usrInfo){
        UsrInfo results = usrInfoService.sltName(usrInfo);
if (results != null){
return error("添加失败,登录名已被注册");
        }
        int insert = usrInfoService.insert(usrInfo);
if (1 == insert){
return success("添加成功");
        }
return error("添加失败");
    }

上述代码养老院项目的添加用户接口处理逻辑，调用usrInfoService.insert 方法进行插入信息处理，我们继续追踪insert方法

UsrInfoService.java

public int insert(UsrInfo usrInfo) {
return usrInfoMapper.insert(usrInfo);
    }

又调用了usrInfoMapper.insert方法，这是mybatis框架，已经最底层了。

  @Insert("insert into usr_info(usr_login,usr_name,usr_sex,usr_tel,usr_addr,older_name) values(#{usrLogin},#{usrName},#{usrSex},#{usrTel},#{usrAddr},#{olderName})")
  int insert(UsrInfo usrInfo);

到这里我们已经看完养老院项目添加用户的方法调用流程了，通篇看下了，有没有写死接口调用的信息。

看来第一个猜想宣告失败，整个调用链路，并没有写死接口调用响应信息。

第二个猜想验证过程

通过第一个猜想验证过程，我们可以知道，整条处理链路还是比较清晰的，仔细分析，有2个关键节点，如“测试平台后端请求养老院接口”、“养老院添加用户接口”。

这就需要我们逐步划分bug产生在哪一条链路上，怎么划分呢？

我这边提供两种方法，打断点或打印请求日志，个人比较喜欢后者打印日志方法，就是在处理链路关键节点，打印输出请求或响应日志。

分别在测试平台后端请求方法、养老院添加用户接口打印相应的请求日志，重启项目后，再次运行，观察具体打印信息：

测试平台后端

说明参数请求一切正常，能接收到测试平台前端传入的测试用例参数

养老院添加用户接口

如截图所示，用户信息参数输出为空，果然，如我所料，就在测试平台后端请求养老院接口这快链路上接口参数映射出现问题。

为什么会出现这种情况呢？

仔细分析测试平台调用养老院接口的代码逻辑，

其中58行就是构造一个post请求，传入url；59行代码将用户信息参数转化成字符串塞进Entity中，当做post请求体。

等等，post请求方法，为啥养老院添加用户接口，接收参数仅用一个usrInfo实体去接收？似乎少了什么？

其实分析到这里就已经很明了，post请求，想要一个实体类接受参数，还需添加一个注解才行@RequestBody 。

@RequestBody主要用来接收前端传递给后端的json字符串中的数据的(请求体中的数据的);
GET方式无请求体，所以使用@RequestBody接收数据时，前端不能使用GET方式提交数据，而是用POST方式进行提交.

通俗理解就是，如果你定义一个接口是post请求，并且用一个实体去接收参数，那么得加上@RequestBody 注解才行。

添加以后运行结果如下：

什么情况？怎么又报错了？“HttpMediaTypeNotSupportedException: Content type 'text/plain;charset=UTF-8' not supported” 这是什么鬼？

哦，想起来了，这句话的含义是说，你请求接口，content-type用的是“text/plain”类型的，但添加用户接口只接受application/json类型的，

咋整？

很简单，只需在测试平台后端，请求添加用户接口的那块添加一行代码、重启再次运行即可。

添加重启，再次运行程序运行成功了，没有报错，页面查询用户信息如下：

页面已显示用户信息，喜大普奔，终于成功了；

分析一下，第60行就是添加的那行代码，告诉httpclient 工具，
我的接口请求指定的content-type是“application/json”，
如果不添加这句话，httpclient默认你的content-type是“text/plain”类型的，
这种类型不是养老项目添加用户接口想要的content-type，
也就会提示“HttpMediaTypeNotSupportedException: Content type 'text/plain;charset=UTF-8' not supported” 这样的错误！

总结

至此，bug已经完美解决，整个过程还是比较有意思的，解决bug的思路总结如下：

当遇到bug时，切忌心浮气躁，应该先沉下心来，弄清楚bug具体表现，然后再捋清楚接口或方法调用链路，找到关键节点打日志或打断点，分析具体原因；大而化小，缩小范围，我也征求过开发小伙伴的意见，其实他们解决bug，大部分情况下也是用这种思路。

当然了以上只是方法，最重要的还是得在日常工作或学习中，加强基础知识学习。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。