今天又碰到一个问题，定位了差不多三天，最终的结果是：bug的出现是因为之前的一段代码修改造成的。这个bug的修改给了我启示：如果出现bug，那么请先参考一下我的上一篇文章：嵌入式软件开发问题定位总结-----（一），如果定位不到问题，那么参考一下下面的定位方法，我觉得很耗时，但是也是一种方法。
今天碰到的bug刚好是跟机器模块之间的交互问题，
问题描述：上电起机，未插探头，告警“SpO2 Sensor Malfunction”；插上探头，没插入手指，告警“SpO2 Equipment Malfunction”;插入手指，一开始提示告警“SpO2 Unplugged”,并且提示：数据显示正常;拔出SpO2探头，不提示用户关闭；
定位方法如下：
首先，添加相应的打印代码，将双方的信令在控制台打印出来。信令交互之间的问题，很有可能是因为发送的命令导致执行错误，所以通过查看交互过程，可能很快的会发现问题，这种方法在新开发的系统中运用起来可能会比较实用。
如果交互的信令没错，那么就可以定位问题是出现在命令发送方，还是命令接收方，这样就有缩小了范围。通过打印，我还是没判断出现的问题，主要是因为测试的时候有点乱，分析有点失误，结果导致得出了错误的结论，这次经验也告诉我，上面的每一步骤分析都尽可能准确，否则，会导致完全不一样的结果，甚至相反的，以至于耗费了大量的时间，但是后来纠正了思路，重新找到了原因。
接下来进一步缩小范围，一个软件，每一个步骤的操作都是一小段代码的支持，所以根据问题产生的现象，原因和结果缩小产生问题的代码。这个问题产生在SpO2报警方面，那么问题的原因肯定是出现在报警处理的代码方面，这时候，就可以思考一下代码里面是如何报警的。代码报警包括MVC三层显示，如果模块上传的是正确的报警信息，那么就有可能处理信息报警的时候出了问题，如果报警处理方面出了问题，那么就有可能是正确的信息，界面显示错误。这时候就分析哪一块代码出现问题的可能性更大。
这个问题的解决，告诉我，定位问题，是一个连续的环节，哪一个环节出现问题，都会影响时间和效率，还有更重要的一点是：一定要想办法缩小产生问题的代码。如果以上方法还解决不了，那么很可能的原因是，对代码不是特别的熟悉。