【软件测试】5年测试总结测试技巧bug定位，畅通测试之路......

---

前言

bug定位也许有很多人不以为然，觉得测试无非就是发现bug后提交bug管理系统，描述操作步骤，预期结果和实际结果哪里不一致，然后继续执行找bug。

并不是说这样做的不对，只是说这样做的不够好，看似节约了测试时间，实则对于项目的进度没有起到应有的推动作用。

来具体分析一下：
1.如果是一个多人开发的系统，不能明确定位到这个bug是谁造成的，容易提交给错误的开发人员，于是bug会像皮球一样被开发踢来踢去，耽误开发解决bug的时间。

2.即便提交给对的开发，开发也未必能查到bug产生的原因和代码有问题的地方，因此不一定能修复bug，往往修改了自己认为可能有问题的地方，然后测试发现还有问题，继续发回给开发，开发继续查，来来回回耽误解决bug的时间。

3.再退一步来说，如果开发水平很高，没有1和2的问题，对于测试来说也很容易提交重复的bug，因为可能很多bug都是由于一个地方引起的，只是表现出问题不一样，但本质却是一样的，这样也是耽误了测试时间。

当然能遇到的远远不止以上3种情况，所以对于测试来说仅仅提交bug是不够的，无论对于测试自身的提高积累，还是对于项目进度推进都是非常重要的。

那么问题来了，要怎么样才能定位bug呢？
虽然说一言难尽，还是想提供一些个人的思路和方法。

当bug出现时，一般来说分大致3种情况，
1.数据库层面的：可能少某个字段，或者字段值为空等等，这些可能在设计数据库时就埋下了错误的种子，导致程序调用数据库错误的数据产生bug，这一类问题不算普遍，但也是最容易忽视的一种情况，有时候从数据库入手定位bug说不定还能发现数据库的设计缺陷呢。

2.网络层面的：通常这种都是网络情况较差的时候产生的，比如手机的移动网络信号不好，又或是公司网络不稳定，导致js/css未加载完全或者请求超时等等，这种问题其实非程序bug造成的，可以不用提交bug，也不用让开发毫无头绪的去查代码的问题。当然如果可以的话也可以当优化建议提给开发，让他优化代码，比如压缩js/css，增加超时时间，超时后的重试机制。

3.代码层面的：普遍的bug基本都是代码有问题造成的，排除掉1和2剩下后就可以确定是程序bug了。对于了解网络架构的人来说，其实程序也分前端和后端的，一般对于界面显示有问题直接可以判断是前端的问题，比如系统兼容性，浏览器兼容性。

而对于数据或者逻辑上的问题。
需要通过抓包工具来进行分析 ：
1）请求未返回数据，可能是client请求数据错误，可能是server端处理错误。
2）请求返回错误的数据，那就是server端处理错误。
3）请求返回正确的数据，那就是前端处理server端返回数据有错误

定位bug就像这样抽丝剥茧一层层排除，从而把最后剩下的可能性给找出来，说难其实也不难，但需要有足够的逻辑思维能力来推断，也需要足够的耐心去寻找bug的根源。

有些人觉得，定位修复BUG是开发做的事情。测试去干不是浪费时间吗？不要觉得这是浪费时间，把精力花在有用的点上总比花在和开发无意义的拉扯上好。

而且定位出问题所在不但可以对开发更有说服力，也方便开发解决问题，开发能解决问题对于测试来说也能减少重复的没效果的验证过程。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

生活一直都是美好的，虽然有辛苦的奔波，有人情的淡漠，也有偶尔的碰壁和受挫，有许许多多的痛和不幸，然而，这些都不能掩饰了生活的美好，生活中总有许多值得我们追求和向往的东西。

命运，是一个很飘渺的东西，有人相信命运，走到了塔顶，或者坠落到崖底。有人想逆天改命，但成功的几率，与中六合 彩一样，但有了毅力，终有那么一天，前方，不再是灰色的雾。

借口太多的人，往往都过不好这一生。成功永远属于努力的人，想做成一件事，只要心甘情愿，总能够变得简单。