同样的测试人员一样的工资，一样的工作范围，工作目标，但跟开发人员合作时的工作效率就是不一样。
为什么呢？其实提交BUG是有技巧的。定位BUG更是有方法。不管是开发人员还是测试人员能快速定位BUG在这个行业来说是提高工作效率的有效方向之一。为什么我们认为定位问题非常重要呢？
1、如果一个项目中提交的BUG没有一个是无效的BUG，可以增加开发和测试的信任度。
2、如果能够明确BUG的原因，对应的开发人员看到BUG就知道用最简单快速的方法解决问题，他们也不会推卸责任，同时也能提高缺陷的修改速度。
3、自己在定位问题过程中能学到平时学不到的知识，同时有助于理解产品业务逻辑，理解数据流，日志流。随着对产品业务逻辑的熟悉日益成熟，反而又会促进对问题的定位更加精准。
分享一些常用的定位BUG的方法：
- 需求对比法。测试人员会通过编写测试用例把需求的要求加工成预期结果，把执行之后的实际结果与预期结果进行比较，这样很快就能明确是不是BUG。
- 经验推测法。测试人员测试的项目平时会总结开发人员容易出错的地方，一般执行的时候会重点去关注易错点。
- 日志分析法。测试人员在执行测试的时候，除了关注业务流，也会关注日志流或是数据流。日志中能明确问题的位置和原因。
- 返回状态码分析法。状态码反应的问题是可以从开发文档中理现出来的，比如，4一般代码是前端的问题，我们在看到4开头的状态码时，会把重心放在前端。那如果有明确说明4是什么原因产生那就更加容易定位了。一般情况下在开发文档状态码说明中是很明确的。
- 抓包分析法。使用抓包软件抓包进行分析。如fiddler请求前中断分析填写的内容和网络上传输的内容是否一致。响应后中断分析网络上响应结果是否和预期结果一致。
- 调试脚本分析法。这种方法也叫断点分析法。开发人员或是测试人员用得比较多。在脚本中增加一些特殊的日志分析BUG的位置或是原因。
- 版本回滚分析法。有时候新版本中有BUG，老版本中没有BUG，那么我们就会要求开发人员回滚到前一个版本对比脚本，查看问题出在哪里。
- 注释脚本分析法。就是把干扰的脚本注释掉，只测试认为可能出现问题的脚本，发现问题的时间会缩短。
- 排除分析法。出现某个问题时，我们头脑中会出可能的多个原因，记录下来，一条一条的做减法操作。
- 求助解决。如果你把上面9种方法都用完了，还是不能定位问题，请求助于网络，同事，老师，同学，同行。
找问题，分析问题，重现问题是测试人员的主要工作，测试人员可以从中获得工作带来的成就感，满足感。也希望 这些方法能帮助到你，为你的工作助力。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
