概述
嵌入式軟體測試/嵌入式測試或叫交叉測試（cross-test）的目的與非嵌入式軟體是相同的。但是，在嵌入式系統設計中，軟體正越來越多地取代硬體，以降低系
嵌入式測試統的成本，獲得更大的靈活性，這就需要使用更好的測試方法和工具進行嵌入式和實時軟體的測試。
通常嵌入式系統對可靠性的要求比較高。嵌入式系統安全性的失效可能會導致災難性的後果，即使是非安全性系統，由於大批量生產也會導致嚴重的經濟損失。這就要求對嵌入式系統，包括嵌入式軟體進行嚴格的測試、確認和驗證。隨著越來越多的領域使用軟體和微處理器控制各種嵌入式設備，對門益複雜的嵌入式軟體進行快速有效的測試愈加顯得重要。
軟體測試的目的是保證軟體滿足需求規格說明。系統失效是系統沒有滿足—個或多個正式需求規範中所要求的需求項。嵌入式軟體有其特殊的失效判定準則，但是，嵌入式軟體測試的日的與非嵌入式軟體是相同的。在嵌入式系統設計中，軟體正越來越多地取代硬體，以降低系統的成本，獲得更大的靈活性，這就需要使用更好的測試方法和工具進行嵌入式和實時軟體的測試。
目的
軟體測試的目的是保證軟體滿足需求規格說明。系統失效是系統沒有滿足—個或多個正式需求規範中所要求的需求項。嵌入式軟體有其特殊的失效判定準則，但是，嵌入式軟體測試的日的與非嵌入式軟體是相同的。在嵌入式系統設計中，軟體正越來越多地取代硬體，以降低系統的成本，獲得更大的靈活性，這就需要使用更好的測試方法和工具進行嵌入式和實時軟體的測試。
方法
一、嵌入式軟體的測試方法
一般來說，軟體測試有7個基本階段，即單元或模組測試、集成測試、外部功能測試、回歸測試、系統測試、驗收測試、安裝測試。嵌入式軟體測試在4個階段上進行，即模組測試、集成測試、系統測試、硬體/軟體集成測試。前3個階段適用於任何軟體的測試，硬體/軟體集成測試階段是嵌入式軟體所特有的，目的是驗證嵌入式軟體與其所控制的硬體設備能否正確地互動。
1、白盒測試與黑盒測試
一般來說，軟體測試有兩種基本的方式，即白盒測試方法與黑盒測試方法，嵌入式軟體測試也不例外。
白盒測試或基本代碼的測試檢查程式的內部設計。根據原始碼的組織結構查找軟體缺陷，一股要求測試人員對軟體的結構和作用有詳細的了解，白盒測試與代碼
嵌入式測試覆蓋率密切相關，可以在白盒測試的同時計算出測試的代碼的覆蓋率，保證測試的充分性。把100％的代碼都測試到幾乎是不可能的， 所以要選擇最重要的代碼進行白盒測試。由於嚴格的安全性和可靠性的要求，嵌入式軟體測試同非嵌入式軟體測試相比，通常要求有更高的代碼覆蓋率。對於嵌入式軟體，白盒測試一般不必在目標硬體上進行，更為實際的方式是在開發環境中通過硬體仿真進行，所以選取的測試工具應該支持在宿主環境中的測試。
黑盒測試在某些情況下也稱為功能測試。這類測試方法根據軟體的用途和外部特徵查找軟體缺陷，不需要了解程式的內部結構。黑盒測試最大的優勢在於不依賴代碼，而是從實際使用的角度進行測試，通過黑盒測試可以發現白盒測試發現不了的問題。因為黑盒測試與需求緊密相關，需求規格說明的質量會直接影響測試的結果，黑盒測試只能限制在需求的範圍內進行。在進行嵌入式軟體黑盒測試時，要把系統的預期用途作為重要依據，根據需求中對負載、定時、性能的要求，判斷軟體是否滿足這些需求規範。為了保證正確地測試，還須要檢驗軟硬體之間的接口。嵌入式軟體黑盒測試的一個重要方面是極限測試。在使用環境中，通常要求嵌入式軟體的失效過程要平穩，所以，黑盒測試不儀要檢查軟體工作過程，也要檢查軟體換效過程。
2、目標環境測試和宿主環境測試
在嵌入式軟體測試中，常??折衷。基於目標的測試消耗較多的經費和時間，而基於宿主的測試代價較小，但畢竟是在模擬環境中進行的。目前的趨勢是把更多的測試轉移到宿主環境中進行，但是，目標環境的複雜性和獨特性不可能完全模擬。
在兩個環境中可以出現不同的軟體缺陷，重要的是目標環境和宿主環境的測試內容有所選擇。在宿主環境中，可以進行邏輯或界面的測試、以及與硬體無關的測試。在模擬或宿主環境中的測試消耗時間通常相對較少，用調試工具可以更快地完成調試和測試任務。而與定時問題有關的白盒測試、中斷測試、硬體接口測試只能在目標環境中進行。在軟體測試周期中，基於目標的測試是在較晚的“硬體/軟體集成測試”階段開始的，如果不更早地在模擬環境中進行白盒測試，而是等到“硬體/軟體集成測試”階段進行全部的白盒測試，將耗費更多的財力和人力。
二、嵌入式軟體測試策略
在嵌入式領域目標系統的套用系統日趨複雜，而由於競爭要求產品快速上市，開發技術日新月異，同時硬體發展的日益穩定，而軟體故障卻日益突出，軟體的重要性逐漸引起人們的重視，越來越多的人認識到嵌入式系統的測試勢在必行。提到嵌入式軟體測試，首先要簡單介紹一些軟體工程的一些觀點，現在，被普遍接受的軟體的定義是：軟體(software)是計算機系統中與硬體(hardware)相互依存的另一部分，它包括程式(program)、相關數據(data)及其說明文檔(document)。其中程式是按照事先設計的功能和性能要求執行的指令序列；數據是是程式能正常操縱信息的數據結構；文檔是與程式開發維護和使用有關的各種圖文資料。
對於一般商用軟體的測試，嵌入式軟體測試有其自身的特點和測試困難。
由於嵌入式系統的自身特點，如實時性(Real-timing)，記憶體不豐富，I/O通道少，開發工具昂貴，並且與硬體緊密相關CPU種類繁多，等等。嵌入式軟體的開發和測試也就與一般商用軟體的開發和測試策略有了很大的不同，可以說嵌入式軟體是最難測試的一種軟體。
嵌入式軟體測試使用有效的測試策略是唯一的出路，它可以使開發的效率最大化，避免目標系統的瓶頸，使用線上仿真器節省昂貴的目標資源。自從出現高級語言，開發環境與最終運行環境通常都是存在差異的，嵌入式系統更是如此。開發環境被認為是主機平台，軟體運行環境為目標平台。相應的測試為host-target測試或cross-testing。
策略
討論嵌入式軟體測試首先就會遇到一個問題：為什麼不把所有測試都放在目標上進行呢？因為若所有測試都放在目標平台上有很多不利的因素：
1）測試軟體，可能會造成與開發者爭奪時間的瓶頸，避免它只有提供更多的目標環境。
2）目標環境可能還不可行。
3）比起主機平台環境，目標環境通常是不精密的和不方便的。
4）提供給開發者的目標環境和聯合開發環境通常是很昂貴的。
5）開發和測試工作可能會妨礙目標環境已存在持續的套用
從經濟上和開發效率上考慮，軟體開發周期中儘可能大的比例在主機系統環境中進行，其中包括測試。
確定host-target測試環境後，開發測試人員又會遇到以下的問題：
1）多少開發人員會捲入測試工作（單元測試，軟體集成，系統測試）?
2）多少軟體應該測試，測試會花費多長時間？
3）在主機環境和目標環境有哪些軟體工具，價格怎樣，適合怎樣?
4）多少目標環境可以提供給開發者，什麼時候?
5）主機和目標機之間的連線怎樣？
6）被測軟體下載到目標機有多快?
7）使用主機與目標環境之間有什麼限制（如軟體安全標準）?
任何人或組織進行嵌入式軟體的測試都應深入考慮以上問題，結合自身實際情況，選定合理測試策略和方案。
嵌入式測試對於嵌入式軟體測試或叫交叉測試（cross-test），在測試的各個階段有著通用的策略：
1．單元測試
所有單元級測試都可以在主機環境上進行，除非少數情況，特別具體指定了單元測試直接在目標環境進行。最大化在主機環境進行軟體測試的比例，通過儘可能小的目標單元訪問所有目標指定的界面。
在主機平台上運行測試速度比在目標平台上快的多，當在主機平台完成測試，可以在目標環境上重複作一簡單的確認測試，確認測試結果在主機和目標機上沒有被他們的不同影響。在目標環境上進行確認測試將確定一些未知的，未預料到的，未說明的主機與目標機的不同。例如，目標編譯器可能有bug，但在主機編譯器上沒有。
2．集成測試
軟體集成也可在主機環境上完成，在主機平台上模擬目標環境運行，當然在目標環境上重複測試也是必須的，在此級別上的確認測試將確定一些環境上的問題，比如記憶體定位和分配上的一些錯誤。
在主機環境上的集成測試的使用，依賴於目標系統的具體功能有多少。有些嵌入式系統與目標環境耦合的非常緊密，若在主機環境做集成是不切實際的。一個大型軟體的開發可以分幾個級別的集成。低級別的軟體集成在主機平台上完成有很大優勢，越往後的集成越依賴於目標環境。
3．系統測試和確認測試
所有的系統測試和確認測試必須在目標環境下執行。當然在主機上開發和執行系統測試，然後移植到目標環境重複執行是很方便的。對目標系統的依賴性會妨礙將主機環境上的系統測試移植到目標系統上，況且只有少數開發者會捲入系統測試，所以有時放棄在主機環境上執行系統測試可能更方便。
確認測試最終的實施舞台必須在目標環境中，系統的確認必須在真實系統之下測試，而不能在主機環境下模擬。這關係到嵌入式軟體的最終使用。
嵌入式測試包括恢複測試、安全測試、強度測試、性能測試，已超出了軟體測試的範疇，本文暫不討論。
使用有效的cross-test測試策略可極大的提高嵌入式軟體開發測試的水平和效率，當然正確的測試工具使用也是必不可少的：
總結一下，套用以上測試工具進行.Cross-test時的策略：
A)使用測試工具的插裝功能（主機環境）執行靜態測試分析，並且為動態覆蓋測試準備好一插裝好的軟體代碼。
B)使用源碼在主機環境執行功能測試，修正軟體的錯誤和測試腳本中的錯誤。
C)使用插裝後的軟體代碼執行覆蓋率測試，添加測試用例或修正軟體的錯誤，保證達到所要求的覆蓋率目標。
D)在目標環境下重複（B），確認軟體在目標環境中執行測試的正確性。
E)若測試需要達到極端的完整性，最好在目標系統上重複（C），確定軟體的覆蓋率沒有改變。
通常在主機環境執行多數的測試，只是在最終確定測試結果和最後的系統測試才移植到目標環境，這樣可以避免發生訪問目標系統資源上的瓶頸，也可以減少在昂貴資源如線上仿真器上的費用。另外，若目標系統的硬體由於某種原因而不能使用時，最後的確認測試可以推遲直到目標硬體可用，這為嵌入式軟體的開發測試提供了彈性。設計軟體的可移植性是成功進行cross-test的先決條件，它通常可以提高軟體的質量，並且度軟體的維護大有益處。以上所提到的測試工具，都可以通過各自的方式提供測試在主機與目標之間的移植，從而使嵌入式軟體的測試得以方便的執行。
使用有效的cross-test測試策略可極大的提高嵌入式軟體開發測試的水平和效率，提高嵌入式軟體的質量。
工具
用於輔助嵌入式軟體測試的工具很多，下面對幾類比較有用的有關嵌入式軟體的測試工具加以介紹和分析。
記憶體分析工具
在嵌入式系統中，記憶體約束通常是有限的。記憶體分析工具用來處理在動態記憶體分配中存在的缺陷。當動態記憶體被錯誤地分配後，通常難以再現，可能導致的失效難以追蹤，使用記憶體分析工具可以避免這類缺陷進入功能測試階段。目前有兩類記憶體分析工具——軟體和硬體的。基於軟體的記憶體分析工具可能會對代碼的性能造成很大影響，從而嚴重影響實時操作；基於硬體的記憶體分析工具價格昂貴，而且只能在工具所限定的運行環境中使用。
性能分析工具
在嵌入式系統中，程式的性能通常是非常重要的。經常會有這樣的要求，在特定時間內處理一個中斷，或生成具有特定定時要求的一幀。開發人面臨的問題是決定應該對哪一部分代碼進行最佳化來改進性能，常常會花大量的時間去最佳化那些對性能沒有任何影響的代碼。性能分析工具會提供有關的數據，說明執行時間是如何消耗的，是什麼時候消耗的，以及每個例程所用的時間。根據這些數據，確定哪些例程消耗部分執行時間，從而可以決定如何最佳化軟體，獲得更好的時間性能。對於大多數套用來說，大部分執行時間用在相對少量的代碼上，費時的代碼估計占所有軟體總量的5%-20%。性能分析工具不僅能指出哪些例程花費時間，而且與調試工具聯合使用可以引導開發人員查看需要最佳化的特定函式，性能分析工具還可以引導開發人員發現在系統調用中存在的錯誤以及程式結構上的缺陷。
GUI測試工具
很多嵌入式套用帶有某種形式的圖形用戶界面進行互動，有些系統性能測試足根掘用戶輸入回響時間進行的。GUI測試工具可以作為腳本工具有開發環境中運行測試用例，其功能包括對操作的記錄和回放、抓取螢幕顯示供以後分析和比較、設定和管理測試過程。很多嵌入式設備沒有GUI，但常常可以對嵌入式設備進行插裝來運行GUI測試腳本，雖然這種方式可能要求對被測代碼進行更改，但是節省了功能測試和回歸測試的時間。
覆蓋分析工具
在進行白盒測試時，可以使用代碼覆蓋分析工具追蹤哪些代碼被執行過。分析過程可以通過插裝來完成，插裝可以是在測試環境中嵌入硬體，也可以是在可執行代碼中加入軟體，也可以是二者相結合。測試人員對結果數據加以總結，確定哪些代碼被執行過，哪些代碼被巡漏了。覆蓋分析工具一般會提供有關功能覆蓋、分支覆蓋、條件覆蓋的信息。對於嵌入式軟體來說，代碼覆蓋分析工具可能侵入代碼的執行，影響實時代碼的運行過程。基於硬體的代碼覆蓋分析工具的侵入程度要小一些，但是價格一般比較昂貴，而且限制被測代碼的數量。
結論
嵌入式系統在人類生活中發揮著重要的作用，包括飛行控制器這樣的控制系統，以及洗衣機這樣的家用電器。日前，嵌入式系統中軟體的比重越來越大，也越來越複雜，保證嵌入式軟體的可靠性正面臨嚴峻的挑戰。
大多數軟體測試方法都可以直接或間接地用於嵌入式軟體的測試，但是由於作業系統的實時和嵌入式特性，嵌入式軟體測試也面臨一些特殊的問題。雖然日前已經有一些針對嵌入式軟體的測試和調試工具，但是在有些方面仍存在不足，包括許多任務作業系統的並發、非侵入式的測試和凋試、嵌入式系統的軟體抽象等。對於嵌入式軟體測試技術的研究人選測試工具有待開發，仍須要做很多進一步的工作。
