今天又碰到一個問題，定位了差不多三天，最終的結果是：bug的出現是因為之前的一段程式碼修改造成的。這個bug的修改給了我啟示：如果出現bug，那麼請先參考一下我的上一篇文章：嵌入式軟體開發問題定位總結-----（一），如果定位不到問題，那麼參考一下下面的定位方法，我覺得很耗時，但是也是一種方法。

        今天碰到的bug剛好是跟機器模組之間的互動問題，

問題描述：上電起機，未插探頭，告警“SpO2 Sensor Malfunction”；插上探頭，沒插入手指，告警“SpO2 Equipment Malfunction”;插入手指，一開始提示告警“SpO2 Unplugged”,並且提示：資料顯示正常;拔出SpO2探頭，不提示使用者關閉；

定位方法如下：

         首先，新增相應的列印程式碼，將雙方的信令在控制檯打印出來。信令互動之間的問題，很有可能是因為傳送的命令導致執行錯誤，所以通過檢視互動過程，可能很快的會發現問題，這種方法在新開發的系統中運用起來可能會比較實用。

         如果互動的信令沒錯，那麼就可以定位問題是出現在命令傳送方，還是命令接收方，這樣就有縮小了範圍。通過列印，我還是沒判斷出現的問題，主要是因為測試的時候有點亂，分析有點失誤，結果導致得出了錯誤的結論，這次經驗也告訴我，上面的每一步驟分析都儘可能準確，否則，會導致完全不一樣的結果，甚至相反的，以至於耗費了大量的時間，但是後來糾正了思路，重新找到了原因。

         接下來進一步縮小範圍，一個軟體，每一個步驟的操作都是一小段程式碼的支援，所以根據問題產生的現象，原因和結果縮小產生問題的程式碼。這個問題產生在SpO2報警方面，那麼問題的原因肯定是出現在報警處理的程式碼方面，這時候，就可以思考一下程式碼裡面是如何報警的。程式碼報警包括MVC三層顯示，如果模組上傳的是正確的報警資訊，那麼就有可能處理資訊報警的時候出了問題，如果報警處理方面出了問題，那麼就有可能是正確的資訊，介面顯示錯誤。這時候就分析哪一塊程式碼出現問題的可能性更大。

        這個問題的解決，告訴我，定位問題，是一個連續的環節，哪一個環節出現問題，都會影響時間和效率，還有更重要的一點是：一定要想辦法縮小產生問題的程式碼。如果以上方法還解決不了，那麼很可能的原因是，對程式碼不是特別的熟悉。