admin 管理员组

文章数量: 1184232


2024年1月12日发(作者：java创建map导入)

车载中bug定位分析

关于如何定位分析bug，大的方面就两种方式：一是抓包接口定位分析，二是看系统日志。

首先说抓包接口，如果你是XXX的话，一般工作中使用方式比较多的是使用浏览器自带的XXX抓包看接口请求。

如果是app客户端之类的，一般采用XXX等工具进行抓包接口。

不管哪种方式，目的都是一样的，就是通过查看接口，从而去定位分析属于前端问题还是后端问题。

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

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

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

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

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

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

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

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

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

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

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

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


本文标签： 接口 信息 报错 系统 返回

版权声明：本文标题：车载中bug定位分析 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/p/1705055647a471437.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。