认识达内从这里开始

通过对bug的收集与整理能够让软件测试程序员在日后的工作中更有效的查找和验证bug问题，今天我们就通过案例分析来简单了解一下，软件测试程序员是如何定位bug问题的。

1、定位bug

我相信每一个程序员都有自己的一套定位bug的方式。这里简单介绍一下以常用思维去分析定位一个bug，当然大神很多，可用以自动化的方式去定位项目中的bug，如使用工具、脚本等方式。

2、猜测

当发现一个bug时，先要做的就是分析猜测这个bug会产生的原因。

一般业务类型的bug容易猜测，如：文案错误，信息空缺，集合元素缺失，等数据不对的情况。此类bug基本上都是数据在终使用的时候，并不是自己想要的数据。如果能对自己代码比较熟悉，那么就能很快的猜测出数据在获取-解析-传输-转换-使用的哪个环节出了问题。如果无法猜测数据在哪个环节出了问题，排查起来也相对简单，数据的传输在代码中还是很清晰可见的。只要顺藤摸瓜很快就能寻找到出问题的地方。PS：“数据驱动编程”，从数据源上规划好数据结构，不仅可以避免掉很多不必要的bug，还能提高开发效率。

其次是策略类型bug，功能映射到的代码设计有缺陷，猜测此类bug难度会大一些。因为很多时候咋一看以为是业务类型的bug。猜测此类bug产生的原因，一是需要全局回想下自己的整体设计思路，确认是否有隐患的地方，二是根据bug发生的场景、时机，推算猜测出可能存在的错误设计思路。如果发生较大的策略类型bug，其实是很不好的，这很可能意味着自己之前的大部分设计思路需要调整，相应的很多代码也需要调整。虽然要调整的地方很多，但另一方面，也说明了你正在改变，你重新设定了一套设计思路，你在追求优化，而不是去建立补丁。PS：拿到需求后去思考优化方案是很有必要的。

再次是代码类型的bug，由于自身编码规范不足，埋下一些坑，出现的一些奇葩bug。要想猜测出此类bug产生的原因也是难的，它很可能跟数据关系不大，跟策略设计的影响也不大。想要猜测出此类bug发生的原因，需要结合更多的信息，如log、场景、时机、数据等，加上经验和感觉去推理猜测出bug产生的原因。PS：提高自己的基础和注意平时的编码习惯，应该是每个猿需要做的事情。

不管是什么类型的bug，当bug发生的时候，很多时候我们并不会知道这个bug是什么问题造成的，所以在猜测的时候，需要对业务类型、策略类型、代码类型的bug结合进行推理猜测。

3、定位

当我们大概猜测出一个或者多个可能产生这个bug的原因后，我们需要去定位具体产生bug的代码。由于猜测环节我们已经把范围缩小到了某一区域。如何在这个范围定位到具体的问题代码?这里可以提供几种思路可以参考下，一是直接浏览一下这块代码，排查有隐患的地方。二是模拟数据、场景、时间，确定有问题的代码。三是折半注释法，通过折半注释能快速的定位到具体代码。折半注释法在很多疑难杂症bug中更能见到奇效，通过注释掉一部分代码，让产生bug所处的局部功能运行正常，再放开被注释掉的一半代码，使运行正常，直至找到终打开注释就会有问题的那块代码。或者反注释，一个个打开注释判断是否正常，后留下的将会是有问题的代码，此类方法只能做辅助。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。