软件测试/测试开发|如何定位bug，一篇文章告诉你

在这里插入图片描述

在我们对软件进行测试时，遇见bug是无法避免的，但是我们如何对出现的bug进行定位呢？bug究竟是哪个原因引起的就是我们解决bug的关键所在了，本文就来介绍一下如何定位bug。

很多测试人员可能会说，测试的职责就是找到bug，至于找原因并修复，那是开发的事情，关我什么事？

好，我的回答是，如果只想做一个测试人员最基本最本分的事情，那么可以这么想。但是，如果想要在测试甚至开发的道路上长足发展，就要知其所以然。

bug定位的重要性

可以明确一个问题是不是真的“bug”。很多时候，我们找到了问题的原因，也许发现这根本不是bug。原因明确，误报就会降低
找到bug原因后，可以明确地指给某个开发，防止他们打太极推来推去，提高缺陷的修复速度。
让开发人员能够佩服你，提升开发对测试的信任度，提升测试话语权
自己在这个过程中能学到很多东西，有助于理解产品内部逻辑，对架构的理解，以及数据流是怎样的走向。随着对业务架构逻辑的理解，反过来又会促进对问题的定位。
可以降低缺陷率。这个可以说是最重要的。在bug系统中，我们会要求开发人员记录bug产生的原因。只有我们自己对bug有一个较全面的认识，才会判别出开发写的是不是真正的原因，也才能有助于我们后续对bug进行分析归类，根据bug分析，有针对性地未雨绸缪，进而提升产品质量，降低缺陷。

首先，定位问题有一个总的思路，而这个思路是和数据的走向一致的。大致是这样：

首先当系统出现bug时，一定要将bug现象进行录制保留，保留现象是为了证明这个bug出现过，如果bug是固定重现还好说，如果该bug无法重现，那么保存的截图都是直接证据，要养成良好的保存现场的习惯。

提BUG这块，还是要体现出测试的专业性，标题简洁、问题环境标识清楚、问题详细描述清楚、系统错误表象贴图、接口传参返参贴图、必要时贴服务器日志，总结来说不该少的bug标签一个不要少。

1. 分析问题场景进行预判

先查看页面表象，根据问题表像判断问题可能出现的原因，进行缩小范围，并且准备好录制工具，录制问题

系统页面无法正常访问的提示5开头的找后端，4开头的先检查请求地址或者对应的权限，进入系统页面正常打开，提示异常代码错误的直接找后端

进入系统页面展示异常图片视频相关提示Flash等相关信息进行安装Flash如若还不行找前端，界面UI展示兼容性错误找前端

如若系统访问正常，进入操作页面，功能性报错信息，就进入下面环节，抓包查看对应请求体，看日志等。

2. 关注请求体的状态码

在发起请求后，我们可以借助浏览器的开发者工具来查看请求的状态码，如下图：

在这里插入图片描述

4**开头的状态码一般都是客户端（前端）的问题；例如常见的404确认下是否是请求的地址有错，403确认是否有权限访问

5**开头的状态码一般都是服务端（后端）问题，例如常见的500，则表示是服务器内部错误，503网络过载导致服务端延时，502服务器崩溃等

3. 关注请求的入参与响应数据

通过访问报错的页面，加载错误请求时我们通过开发者工具进行分析请求包，查看对应的入参以及响应数据。

请求入参错误，那么该bug属于前端的错误；入参标准可以根据前端页面的输入的内容或者选择的内容，进行核验，入参格式以及是否必填等可以对应接口文档去进行分析或跟开发确认

求未响应或者响应数据错误，那么该bug就属于后端的错误；一般是数据库查看报错，例如删了某个表查询报错误空指针等。

4. 查看日志

针对服务端类型的报错，我们可以进行登录日志平台或者服务器对应Log目录下查看打印出的日志

常用查看日志命令tail ,/error进行快速检索关键词接口名等相关内容，将找到的内容贴在bug单中。

5. 经验法则

在系统前端页面当碰见服务器配置相关报错的信息例如Nginx或者代码以及SQL相关的提示报错信息直接找后端处理，例如JAVA* 、.PHP、SQL等异常报错。

前端字符校验、格式校验、等，浏览器界面UI兼容性以及插件，或者APP、小程序类调用手机相关功能拍照、语音无法正常调用直接找前端。

本文主要介绍了定位bug的三板斧，在bug定位中，我们一定要保持细心和耐心，灵活运用我们的技巧，这样才能快速精准定位到bug。希望本文能够帮到大家！