软硬件调试九法：第五条规则 一次只改一个地方

Posted 2020-07-01

1、隔离关键元素

就像小学生物课，考察阳光对植物生长的影响，则需要保持养分、灌溉、生长温度等完全一致，一个有阳光照射，一个没有阳光照射，这样才能比较出阳光对植物的生产的影响.bug查找过程也要如此,在查找一个具有多个参数的函数的计算错误时，固定其它参数，同时修改一个参数的输入值，验证输出结果是否正确，从而可以确定是哪个参数导致的计算错误，确定bug。

2、一次只改一个测试

软件工程师有时为了修复一个问题而修改了一个地方，但这个修改没有解决问题，而他又认为这不会产生影响，这是一个错误的假设，这个改动可能的确对解决问题有影响，因此没有解决问题的改动要及时恢复。否则可能产生无法预料的错误。一次只改变一个参数，以便确定哪个参数有影响！与第一条互为补充！

硬件也是类似，如果同时更换多个器件，你无法判断到底是哪个器件导致系统出现问题，也要一次只更换一个，测试验证没有问题后再更换下一个！

3、与正常情况比较

        使用两个例子，一个成功的，一个失败的，对比示波器的观察结果、代码、调试输出以及其它任何插桩工具 显示结果，往往比较容易找到bug！如果两个之间又很多不同，比如代码改变了很多，则必须不断的解释这些差别，并且不断减少他们之间的差别直至只与bug有关。

       因为你不知道哪些方面与bug有关，因此应该对一切能够测试的地方进行测试，如果证明无关，则把它从调试日志中删除。大量数据对比查找，这个不是很容易做到，既不适合初学者，也不适合软件自动化分析，需要一个充满智慧的大脑，从大量对比数据中，快速找到差别。

案例：以前有一个项目，设计一个独立的下载编程器，之前公司使用的是通过PC上厂家提供的下载软件通过串口进行下载，但是无法满足安装现场的升级维护需求。通过监控监控获取到的通讯命令码和格式后，编写完程序下载编程器可以工作了，但是总会执行下载一段后，出现下载失败，于是我把下载器发送的串口数据和上位机软件发送的串口进行字节对比，发现上位机软件有的数据包长度会改变，仔细对比内容发现，通讯协议中为了防止内容中的字节与通讯命令码的起始字节冲突，进行了替换处理，即使用两个字节的不同内容替换内容中与命令码相同的字节内容。下载编程器采用同样的操作后，下载过程不再出错！

4、确认自上次正常以来的你修改的地方

      有时，正常的系统和错误的系统之间的区别是有一项改动导致的，因此一种非常有效的方法就是找出第一个导致bug的版本，这个需要连续测试，直至找到没有bug的版本，一旦找到后，就可以把问题范围限制到这两个版本之间的差别。如果两个版本不是大幅度修改，bug往往比较容易找到。

 

通常新的设计会出问题，这也是我们在产品发布前总要对新设计进行测试的原因，有的可能时前后部分不兼容（比如工装探针的分布顺序，间距改动），也有较为复杂的，就是问题存在了很长时间，知识莫些地方被改变后才暴露出来

 

案例：在32位系统中，比如8位指针向32位指针强制转换时，如果以前版本软件编译时8位指针的地址4字节对齐，那么赋值转换不会出现问题，运行也正常；当软件修改，重新编译后，8位指针的地址不是4字节对齐，那么就会出现数据错乱甚至死机、看门狗复位等问题。这种问题，只对比代码的修改处，时看不出问题的，需要综合考虑代码修改的影响，除了代码逻辑、功能的影响外，还有编译的影响、代码布局的影响等。