一、嵌入式軟件測試的方法
嵌入式軟件測試分爲4個階段，即模塊測試、集成測試、系統測試、硬件/軟件集成測試。前3個階段適用於任何軟件的測試，硬件/軟件集成測試階段是嵌入式軟件所特有的，目的是驗證嵌入式軟件與其所控制的硬件設備能否正確地交互。
在嵌入式軟件測試中，常採取折中的方式。基於目標的測試消耗較多的經費和時間，而基於宿主的測試代價較小，但畢竟是在模擬環境中進行的。目前的趨勢是把更多的測試轉移到宿主環境中進行，但是，目標環境的複雜性和獨特性不可能完全模擬。
在兩個環境中可以出現不同的軟件缺陷，重要的是目標環境和宿主環境的測試內容有所選擇。在宿主環境中，可以進行邏輯或界面的測試以及與硬件無關的測試。在模擬或宿主環境中的測試所消耗的時間通常相對較少，用調試工具可以更快地完成調試和測試任務。而與定時問題有關的白盒測試、中斷測試、硬件接口測試只能在目標環境中進行。在軟件測試周期中，基於目標的測試是在較晚的硬件/軟件集成測試階段開始的，如果不更早地在模擬環境中進行白盒測試，而是等到硬件/軟件集成測試階段再進行全部的白盒測試，將耗費更多的財力和人力。
二、嵌入式軟件測試的過程
根據嵌入式系統的開發流程，爲了最經濟地實現系統的功能，一般採用自頂向下、層層推進的方法對嵌入式系統進行測試。圖9.1爲基於模塊化設計的嵌入式軟件測試流程。
嵌入式軟件測試的總體步驟爲：首先進行操作系統移植並編寫系統底層驅動，然後進行系統平臺測試，其中包括硬件電路測試、操作系統及底層驅動程序的測試等。如果測試未通過，需要重新進行操作系統移植和編寫系統底層驅動；如果此測試通過，可以進入下一步的開發——用模塊化的方法編寫應用代碼，隨後再對軟件模塊進行測試。如果測試沒有通過，則要對此代碼模塊進行修改，然後對軟件模塊進行測試；如果所有的模塊都通過測試，需要進行集成測試。如果集成測試沒有通過，則要確定模塊接口函數錯誤模塊，然後修改錯誤模塊代碼，再利用關聯矩陣確定需測試模塊，並重新回到軟件模塊測試；如果集成測試通過，則需要進行系統測試。如果系統測試沒有通過，則需要修改程序代碼，如果問題出現在操作系統的移植上，需要重新進行操作系統的移植；如果問題只是出現在軟件模塊上，只需修改軟件模塊就行了。如果系統測試通過，就可以退出測試。在第一件產品生產出來之後，需要對產品進行測試，如果測試通過，則表示嵌入式產品的所有測試步驟已經完成。
三、嵌入式軟件測試的特點
嵌入式軟件測試作爲一種特殊的軟件測試，它的目的和原則同普通的軟件測試是一樣的，都是爲了驗證或達到可靠性要求而對軟件所進行的測試。嵌入式軟件測試除了要遵循普通軟件測試的原則之外，還需要遵循以下幾個原則：
(1) 嵌入式軟件測試對軟件在硬件平臺的測試是必不可少的。
(2) 嵌入式軟件測試需要在特定的環境下對軟件進行測試。
(3) 嵌入式軟件需進行必要的可靠性負載測試，比如測試某些嵌入式系統能否連續1000個小時不斷電工作。
(4) 除了要對嵌入式軟件系統的功能進行測試之外，還需要對實時性進行測試。在判斷系統是否失效方面，除了看它的輸出結果是否正確，還應考慮其是否在規定的時間裏輸出了結果。
(5) 在對嵌入式軟件進行測試的時候，需要在特定的硬件平臺上進行性能測試、內存測試、GUI測試、覆蓋分析測試。
四、嵌入式軟件測試的工具
1．內存分析工具
在嵌入式系統中，內存容量通常是有限的。內存分析工具用來處理在動態內存分配中存在的缺陷。動態內存分配錯誤，通常是難以復原的，其導致的失效難以追蹤，使用內存分析工具可以避免這類缺陷進入功能測試階段。目前有兩類內存分析工具—軟件工具和硬件工具。基於軟件的內存分析工具可能會對代碼的性能造成很大影響，從而嚴重影響實時操作；基於硬件的內存分析工具價格昂貴，而且只能在工具所限定的運行環境中使用。
2．性能分析工具
在嵌入式系統中，程序的性能通常是非常重要的。經常會有這樣的要求，在特定時間內處理一箇中斷，或生成具有特定定時要求的一幀。開發人員面臨的問題是決定應該對哪一部分代碼進行優化來改進性能，並避免花費大量的時間去優化那些對性能沒有任何影響的代碼。性能分析工具會提供有關的數據，說明執行時間是如何消耗，什麼時候消耗的，以及每個例程所用的時間。根據這些數據，確定哪些例程消耗部分執行時間，從而可以決定如何優化軟件，以獲得更好的時間性能。對於大多數應用來說，大部分執行時間用在相對少量的代碼上，費時的代碼估計只佔所有軟件總量的5%～20%。性能分析工具不僅能指出哪些例程花費了時間，而且與調試工具聯合使用可以引導開發人員查看需要優化的特定函數，性能分析工具還可以引導開發人員發現在系統調用中存在的錯誤以及程序結構上的缺陷。
3．GUI測試工具
很多嵌入式應用提供了某種形式的圖形用戶界面，有些系統性能測試是根據用戶輸入響應時間進行的。GUI測試工具可以作爲腳本工具在開發環境中運行測試用例，其功能包括對操作的記錄和回放、抓取屏幕顯示供以後分析和比較、設置和管理測試過程。對沒有GUI的嵌入式設備，可以對其進行插裝來運行GUI測試腳本，雖然這種方式可能要求對被測代碼進行更改，但是節省了功能測試和迴歸測試的時間。
4．覆蓋分析工具
在進行白盒測試時，可以使用代碼覆蓋分析工具追蹤被執行過的代碼。分析過程可以通過插裝的方式來完成，插裝可以是在測試環境中嵌入硬件，也可以是在可執行代碼中加入軟件，也可以是二者相結合。測試人員對結果數據加以總結，確定哪些代碼被執行過，哪些代碼被遺漏了。覆蓋分析工具一般會提供有關功能覆蓋、分支覆蓋、條件覆蓋的信息。對於嵌入式軟件來說，代碼覆蓋分析工具可能侵入代碼的執行，影響實時代碼的運行過程。基於硬件的代碼覆蓋分析工具的侵入程度要小一些，但是價格一般比較昂貴，而且限制被測代碼的數量。
五、嵌入式軟件測試策略
1．單元測試
所有單元測試都可以在主機環境上進行，除非少數情況特別指定了單元測試直接在目標環境進行。測試時，儘可能在主機環境中進行軟件測試，通過儘可能小的目標單元訪問所有目標指定的界面。
在主機平臺上運行的測試速度比在目標平臺上快得多，在主機平臺完成測試後，可以在目標環境中重複作一簡單的確認測試，確認測試結果不受主機和目標機的環境影響。在目標環境中進行確認測試將確定一些未知的、未預料到的、未說明的主機與目標機的不同。例如，目標編譯器可能有bug，但在主機編譯器上沒有。
2．集成測試
軟件集成也可在主機環境上完成，並在主機平臺上模擬目標環境運行。當然在目標環境上重複測試也是必需的，在此級別上的確認測試將確定一些環境上的問題，比如內存定位和分配上的一些錯誤。
在主機環境中如何進行集成測試，取決於目標系統的具體功能有多少。有些嵌入式系統與目標環境耦合得非常緊密，若在主機環境做集成是不切實際的。對於大型軟件的開發則可以分爲幾個級別的集成。低級別的軟件集成在主機平臺上完成有很大優勢，越往後的集成越依賴於目標環境。
3．系統測試和確認測試
所有的系統測試和確認測試都必須在目標環境下執行。當然在主機上開發和執行系統測試，然後移植到目標環境重複執行是很方便的。對目標系統的依賴性會妨礙將主機環境中的系統測試移植到目標系統上，況且只有少數開發者會捲入系統測試，所以有時放棄在主機環境上執行系統測試可能更方便。
確認測試最終的實施舞臺必須在目標環境中，系統的確認必須在真實系統之下測試，而不能在主機環境下模擬。這關係到嵌入式軟件的最終使用。
使用有效的cross-test測試策略可極大地提高嵌入式軟件開發測試的水平和效率，當然正確地使用測試工具也是必不可少的。
六、 嵌入式軟件測試實例
1) 軟件指令仿真
軟件指令仿真的主要工作是對相關的I/O操作進行替換。在80X86系列CPU指令集中，I/O指令有兩個IN和OUT，對這兩個指令，我們都定義相應的宏來代替其操作，同時在內存中組織變量來代替I/O操作中的寄存器變量。
在軟件中，I/O指令主要有以下幾類：
IN REGISTER, BYTE
IN REGISTER, WORD
OUT BYTE, REGISTER
OUT REGISTER, WORD
構造如下的宏指令仿真上述指令的功能：
2) 軟件插樁
爲了便於測試完成後分析軟件的執行路徑，必須在軟件中加入特定的輸出語句。這樣，我們才能在分析軟件的輸出數據時進行對比，得到軟件的實際運行情況。可在遙控攝像頭的控制及通信軟件中加入下列語句：
MOV DADIAN, PATH[NO]
將軟件中的上述插入點寫入軟件的輸出結果中，測試結束後分析語句時，就可以根據路徑編號來分析軟件的執行路徑。
3) 軟件移植
由於遙控攝像頭的控制及通信軟件在實際環境中的執行方式是直接操作底層硬件，而DOS系統中的軟件是和操作系統交互的，因此，爲了完成測試，必須對軟件進行移植，使軟件能夠在DOS系統中運行。
在基於8086組建的嵌入式系統中，一般將軟件安排在特定的存儲地址中，系統啓動時，CPU指令首先指向FF000H，在FF000H單元中安排特定的跳轉語句，使軟件跳轉到存儲器中存放軟件的地址，然後系統進入正常運行。然而，在DOS操作系統中不能直接操作CPU指令指針，使CPU指令指針切換到存放特定軟件的地址。DOS系統下的可執行程序必須符合DOS系統的規範。我們可以在程序中插入驅動模塊，然後對程序進行重新編譯，使它符合DOS系統的規範，就可以解決上述問題。
思 考 與 習 題
1．嵌入式軟件測試的過程是什麼？
2．嵌入式軟件的測試方法與普通軟件測試有何不同？
3．嵌入式軟件的測試工具有哪些？