聊聊-如何准确定位bug原因

小v有话说

机会总是留给有准备人，多思考、多积累、多总结。

开发为什么排斥测试，为什么觉得测试就是给他们找麻烦，可能有的原因之一就是测试人员提交完bug就不管了，问题开发你自己查去吧；对于有些测试人员可能会有这种情况，而对于有些测试人员会通过各种方法，找到问题的原因所在，做到知其然，之其所以然，不仅提高自己，也有效的帮助开发解决问题。使其整个项目都推进的更有效，开发人员的态度也会越来越重视测试。

定位问题原因为什么这么重要

1、多个系统交互，可以明确指出是哪个系统的缺陷，防止“踢皮球”，提高问题解决效率

2、增强开发与测试的信任度，沟通更有效，配合的更好，开发修改bug时效增强。

3、更有效的了解系统的内部逻辑，数据流处理流程，更能提高测试人员的水平，缺陷修复后，影响的测试范围评估更精准，复测更准确。

4、提高bug的误报率，找到原因，能更有效的判断是不是真正的bug

简单列举了定位bug的重要性，那作为测试人员或者开发人员应该怎么样做，总要有个思路，去定位，来吧，看看用的方法。可能你会用到，高手可以考虑绕过了：）

排查顺序，可以列举为用户环境层面--》展示层面--》逻辑控制层面--》服务层面--》数据库层面

用户环境层面

主要是指基础环境是否可以使用，比如网络是否ping通，ip和端口配置是否正确，jdk版本是否符合标准；最近做的一个项目就是由于jdk版本不兼容导致系统运行异常，这种问题根据实际情况来决定要不要兼容；检查完成后，可以转到第二步

用户展示层

用户在操作过程中，通过查看，发现的一些问题，有页面样式、交互过程中js的提示、或者终端控制的提示信息，文本的展示，这种问题不通过与服务器的交互，由页面、终端直接控制，比如字段长度控制为4位，输入5位时，无法输入，或者大于4位页面弹出提示不允许输入大于4位，这种问题往往比较容易修改，检查后，进入到第三步

逻辑控制层

用户操作过程中，业务的处理逻辑有没有按照前期的设计实施，比如我们使用的贷记卡日累计额度为1万，当你消费时大于1万时，检查通过，经过排查，后台参数配置的不对，或者通过查代码发现该逻辑没有判断；

再比如多系统交互时，我们发送一个请求后，终端返回超时，这个时候需要查看日志定位具体哪个系统有问题，这种需要查看每个系统的日志请求及响应，如果没有系统返回超时，并且每个系统都收到了正常的响应，那可能是终端超时时间设置的时间过小，未等到返回先超时导致。该层的问题定位，一般都需要查看日志位。该层检查完，转到下一层

服务层

服务层往往检查服务器的配置，比如发现内存溢出问题，那么可能是tomcat配置错误；遇到过一个实际情况，应用系统为分布式部署，4路部署，当用户登录系统时，有的用户可以登录，有的无法登录，也不报错，经过逐层排查，发现有2路部署jdk版本不一致，原来用jdk1.6（2路） ，部署的为1.8（2路），是环境人员部署大意导致；类似问题可能还有tomcat版本等、jar包版本

数据库层

用户操作完成后，交易流程非常顺畅，这样也不代表整个交易没有问题，还需要测试人员检查数据库登记的表和字段是否正确，如果发现登记的字段与预期的结果不一致，则可以查看日志，检查请求报文送的字段是否正确，是否与前台填写的一致。有的一个操作会登记多张表，所以要检查多张表登记或者更新的是否正确，测试人员也需要对被测系统的数据表结构熟悉。

经验谈

有些问题，遇到的多了，看的多了，一眼就看出来是什么问题，测试人员也需要具备从现象看本质的能力，避免走弯路。但如果确实没有定位到，也不要“死磕”作为测试人员的你，读完本篇后，不防试试找问题的根源所在。就算提高自己的能力吧。