作为一名软件测试人员，日常工作与bug是息息相关的。在发现bug之后，首先要做的就是定位bug，确定bug的存在，然后才是分析bug产生的原因并解决bug。

无论是自己找到的bug，还是开发修复后告诉我们的，能发现bug就是好事。接下来小编将给大家分享一些好用的定位bug原因的小妙招。

关于如何定位bug的产生原因，小编总结了以下几点：

1.冷静应对问题

遇到问题时，先别急着去定位原因，首要做的是保存bug产生的记录，保证可以复现，然后才是排除QA的低级问题 。为什么要保存记录？因为如果以后不能复现，那就不能证明bug的存在。常见的低级问题就是：hosts不对，网络不通，以及操作姿势不正确等。

还有一类问题就是数据问题，我们有时候会遇到服务端报500错误，查看日志后，报空指针，那么很有可能就是数据库中关联表的数据被人为删掉导致的。所以发现bug先别慌，冷静一下，先确认问题再去找原因。

2.直接查看页面呈现

当程序出现bug的时候，先立刻停止正在做的任何操作。不要按任何健，仔细地看一下屏幕，注意那些不正常的地方，记住它或者写下来。学着养成一种条件反射——一旦电脑出了问题，先不要动。要想摆脱这个bug，关掉受影响的程序或者重新启动计算机都不是最佳的解决方式，最好的办法是让bug再次产生，找到bug产生的源头。

3.查看状态码

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

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

4.查看服务器日志

如果发生5xx问题，或者需要检查后端接口执行的sql是否正确，我们最常见的排查方法就是去看服务器日志比如tomcat日志。开发人员一般会打出关键信息和报错信息，从而找到问题所在，所以，测试人员也要养成看日志的习惯。

5.查看需求文档

有时候，前端和服务端的交互都正确，但是从测试的角度看不合理。这个时候，我们应该翻翻需求文档。如果和需求文档不符，那么就要看下改什么比较合理，是改前端，还是改服务端，或者两者都要改。这里有一个原则，就是前端尽可能少地去承担逻辑，只负责渲染展现。

6.判断是否是后端生成页面的问题

后端生成页面，最常见的就是类似于jsp、php、python的某些前后端不分离的框架，这种比较特殊，常见于单人开发的项目，这种项目的问题排查和其他项目总的思路也一样，只不过前后端bug的修改可能都是同一个人而已。

7.向开发寻求可测性支持

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

8.检查一下配置

很多时候，bug不是代码的问题，而是tomcat配置、nginx配置、jdbc配置等的问题。在这个层面上，测试人员最好能够了解下它们的各项配置，在发现问题后可能就会想到这方面的问题。

9.经验法则

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

10.其他

常见的bug可能还有构建方面的原因。比如代码本身没错，但是合并代码到主干后出现了问题，比如代码存在冲突时手动解决的情况。

此外，定位到bug后，也需要具体情况具体分析，根据开发人员的性格采取合适的沟通方式以保证开发能够接受你发现的bug。

当然，在发现bug或者定位bug产生原因后，记得要再次确认bug。所谓确认bug，就是弄清楚bug是否每次都发生，是概率事件，还是工具相关的问题。

比如换个浏览器是否能重现？如果换个浏览器不能重现的话，很可能就是前端的兼容性问题，比如翻页控件。待测的系统有很多页面都有翻页控件，那么就要看下是否每个页面都会出现这个问题，进而报bug时进行统一说明，也更加方便开发人员批量处理，防止漏改。

以上是定位bug原因的一些妙招分享，更多资讯可关注卓码测评，持续更新。

卓码测评是一家[ 具备CMA、CNAS双重资质 ]的专业做软件测试的第三方软件测试服务机构, 可根据您的需求提供各类软件测试服务，并出具合格有效的测试报告。点击了解测试报价