
62
|
第三章
對大多數的記憶體而言,上述的模式是個很好的開始:
1. 讀取原有資料
2. 寫入某些相異但公式化的測試資料
3. 驗證測試資料
4. 重新寫回原有資料
5. 驗證原有資料
無法一一介紹其他不同形式的週邊,雖然自動化測試很好,但某些週邊需要透過外部設
備才能驗證,例如為了驗證 LCD 驅動程式必須顯示特定圖樣或線條。某些測試則需要
虛擬的外在輸入才能驗證感應元件。
對每個週邊與軟體子系統,試著找出哪些測試能讓自己有信心確認週邊可靠且如預期運
作。這聽起來並不困難,但實際上卻不容易,設計良好的測試能讓軟體更加傑出。
命令與回應
假設讀者接受了前一節的建議為每個硬體元件建立了相關測試,在 bring-up 過程中,
建立了啟動時執行所有測試的特殊映像。當有測試失敗時,讀者或硬體工程師可能會想
要一再執行單一的測試,於是重新編譯與載入,之後又想要測試其他東西,於是再一次
重新編譯載入。有沒有比較簡單的方式,能夠將命令送給嵌入式系統,讓它執行指定的
測試?
嵌入式系統的使用者介面比起個人電腦(或是智慧型手機)要簡單得多,很多只是透過
命令列控制,即使是擁有螢幕的系統,也是透過命令列介面除錯。接下來將介紹如何在
C 語言中透過命令處理表(command-handling jump table)中的函數指標送出命令,這
個特殊的問題與解答讓作者有機會介紹標準的 command 模式,不論使用何種程式語言,
這都是個十分有用的模式。
圖 3-13 呈現了自動命令處理函式的高階目標,能夠透過 PC 序列埠終端送出命令,取得 ...