1、如何分析Bug?

1)抓包接口定位分析

web项目的话,一般工作中使用方式比较多的是使用浏览器自带的F12抓包看接口请求。
如果是app客户端之类的,一般采用fiddler等工具进行抓包接口。
不管哪种方式,目的都是通过查看接口,去定位分析属于前端问题还是后端问题。

比如你在淘宝上边购买了一件商品,并且成功支付,但是在我的订单里面却没有记录,你应该如何去分析定位这个问题?

首先需要搞明白的是这个场景的数据流调用的逻辑关系,不过这个问题比较简单。

整体来说就是前端购买商品,支付成功,会把这条数据的商品信息加支付信息都落入数据库中。

然后点击我的订单,会调后端接口,后端从数据库取相关信息,然后前端渲染展示商品和支付信息。

搞明白这个场景的数据流转就很容易定位分析这个bug了,可以使用抓包工具抓包这个我的订单调后端的接口。

如果抓不到这个接口,就是前端没有发出请求,显然是前端问题。

如果有请求并且响应了,就查看这个接口响应信息,如果返回报错了,则需要具体分析报错内容。

这个时候既有可能是前端入参传的不对,导致后端报错。也有可能是前端传对了,后端处理错误,需要具体分析是前端问题还是后端问题。

如果后端成功响应了且返回信息跟接口文档定义的一致,那么大概率是前端展示的问题,这个时候需要找前端同事。

以上,就是定位一个bug是属于前端还是后端的分析思路。

2)看系统日志

既然可以抓包定位看接口返回了,为什么还需要查日志系统呢?
这是因为对于一家公司来说,一般不止一个系统。很多公司都是根据业务不同划分出不同的组,不同系统共同完成公司一个项目。

举个例子,比如一家保险公司,可能有系统是负责用户下单的就是交易系统,管理保单变更比如退保之类的就是保单系统,负责收钱的就是财务系统,负责赔钱的就是理赔系统……

每个系统就是一个组,一般二三十人不等。每个组有开发,测试,产品,具体看公司了。

那么这些系统是怎么交互合作的呢?就是通过接口来交互,这也是接口测试比较复杂的地方,涉及到多个系统多个接口的逻辑调用。

理解完这个,再说到为什么要查看日志的问题?

比如页面调后端系统接口报错了,但是你知道整个流程能有多长吗?

页面可能直接调用的是系统A接口,但是这时候系统A又调用了系统B,系统B又调用了系统C。页面上看到的接口返回报错结果,本质上可能是系统C接口报错返回的。

这个时候仅仅通过抓包就无能为力了,你需要去查看系统日志,去一层层去分析,究竟是哪个系统报错了,然后定位到问题。把报错信息和日志截图丢给那个系统同事。

一般我发送错误,协调处理时都会发下面几样东西,调对方接口的url,入参信息,返回报错信息。

再简单描述下调用接口业务场景,如果对方很熟悉的话一看url就知道了,这时候就不用描述了。

再来说下系统日志是怎么一回事?

日志本质上就是开发写在项目中的代码,报错会抛出异常信息,以及打印一些接口返回信息等等。

有的公司会有专门的日志查询系统,有的公司是通过xshell工具连接上linux系统再查找日志,这就看公司了。

因为现在公司系统一般是linux系统,所以查询日志的命令自然就是linux命令了。

我一般用的比较多的是grep,tail这两个命令,前者是精确查找,后者是动态查找,大家可以百度学习下这两个命令。

说一下精确查找,就是根据开发代码中打印的关键字信息去精确查找日志,一般是requestid,证件号或者订单号之类的。

这个可以提测后问下开发,查找日志的关键字是什么,日志文件名是什么,以及去哪个服务里面去查找。

因为现在一般是微服务架构,不同的服务处理不同的业务,存储不同的日志。不同公司可能不太一样,但是方式大同小异。

Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐