嵌入式軟體的測試(二)

假設有一個非常簡單的嵌入式軟體，它的開機模組功能包括要檢查所有主機內 10 個硬體組件是否能正常運作；其中具輸出功能的燈號、螢幕、喇叭，具輸入功能的按鈕、麥克風，具儲存功能的記憶體等都必須完整檢查(否則就算開了機，使用者可能不知道，或是使用者知道已開機但操作按鈕卻無法動作)，其他的如插孔或卡槽介面就等要用時再檢查。

要怎樣設計測試案例來測試這個開機模組呢？負責嵌入式軟體的朋友最怕是硬體出毛病，自己不知道卻還一直在那裡找問題，所以就瞄準這一方面先下手無妨。測試目的就定為「找出螢幕壞了卻還繼續處理開機程序的錯誤」，測試步驟是找一台主機、把螢幕拆掉(或把相關連線拔掉、真的把螢幕弄壞等等)、然後按開關鈕。預期的正確結果應該是開機模組要用其他的燈號或喇叭來輸出訊息提醒使用者螢幕壞了，同時停止繼續開機的程序。真正測試的時候如果出現的不是這樣的預期結果就證明開機程式還有這個錯誤存在。

負責測試的朋友幫負責寫軟體的朋友找出這個錯誤以後，程式的邏輯處理內容就改成如果檢查到螢幕有問題就要用閃爍燈號或喇叭發聲來提醒使用者，看是要送修或怎樣，然後停止執行。這時候的潛在衍生錯誤就可能會發生了，譬如原來設計的開機檢查順序是先檢查螢幕再檢查燈號及喇叭，所以如果螢幕不正常時可以馬上就用燈號及喇叭嗎？它們還沒有被檢查呢。還有，如果螢幕有問題要先閃爍燈號，要閃爍多久後才停止繼續處理呢？需要再測試嗎？

據一些有經驗的專家表示，現在採用以開放原始碼(open source)為軟體基礎的嵌入式個人隨身設備，例如 PDA 手機，其程式規模(包括系統軟體及應用軟體)大約在 500 萬行左右。可以想像的是，這裡面絕對是夠複雜的，不管它們是怎麼樣組合而成。如果再回頭去看那一段最基本的開機模組部份，最原始的版本可能只需要 200 行就足夠了；但是為了要陸續通過那些測試案例而再加進去的部份，會有多少行？說不定是 2000 行。另外的議題則是，加進這些行數以後的新版本，是否提高了產品的品質？如果是，那當初看來似乎沒有什麼了不起的測試案例就是有意義的。

相關文章：嵌入式軟體的測試(一)