軟硬體結合的嵌入式系統正越來越多地應用到我們常見的儀器裝置中，嵌入式領域目標系統的應用系統也日趨複雜，開發技術日新月異。同時，隨著硬體技術發展的日趨穩定，而軟體故障卻日益突顯，由此軟體的重要性已逐漸引起人們的重視，越來越多的研究人員認識到嵌入式系統，優化其測試技術已勢在必行，研究出合適的嵌入式軟體系統測試方法，正是本課題的意義所在。
嵌入式系統是以應用為中心，以計算機技術為基礎，並且軟硬體可裁剪，是專為應用系統量身打造、是對功能、可靠性、成本、體積、功耗有嚴格要求的專用的計算機系統。
嵌入式系統一般指非pc類標配系統，它也包括硬體和軟體兩部分。硬體包括處理器/微處理器、儲存器及外設器件和i/o埠、圖形控制器等。軟體部分包括作業系統軟體(os)(要求實時和多工操作)和應用程式。有時設計人員把這兩種軟體組合在一起。應用程式控制著系統的運作和行為，而作業系統控制著應用程式程式設計與硬體的互動作用。
嵌入式系統開發有其自身的特點。一般先進行硬體部分的開發，主要包括形成裸機平台，根據需要移植實時作業系統，開發底層的硬體驅動程式等。硬體平台測試通過後，應用軟體的開發除錯是基於該硬體平台進行的，這同時也是對硬體平台的乙個測試。
嵌入式系統的開發過程是乙個軟硬體互相協調，互相反饋和互相測試的過程。一般來說，在嵌入式系統軟體中，底層驅動程式、作業系統和應用程式的介面是不清晰的，根據需要甚至混編在一起。這主要是由於嵌入式系統中軟體對硬體的依賴性造成的。基於嵌入式軟體對硬體的依賴性，其要求軟體測試時必須最大限度地模擬被測軟體的實際執行環境，以保證測試的可靠性，而底層程式和應用程式界限的不清晰又增加了測試的難度。測試時只有確認嵌入式系統平台及底層程式是正確的情況下才能進行應用程式的測試，而且在系統測試時，錯誤的定位較為困難。
軟體的專用性也是嵌入式軟體的乙個重要特點。由於嵌入式軟體設計是以一定的目標硬體平台為基礎的，面向固定的任務進行的，因此，一旦被載入到目標系統上，功能必須完全確定。這個特點決定了嵌入式應用軟體的繼承性較差，也延長系統的測試時間和增加了測試費用。
嵌入式軟體的另外乙個重要特點就是實時性。這是基於軟體的執行角度而言的，也就是說嵌入式軟體的執行要滿足一定的時間約束。嵌入式系統中，應用軟體自身演算法的複雜度和作業系統任務排程，決定了系統資源的分配和消耗。因此，對系統實時性進行測試時，要借助一定的測試工具對應用程式演算法複雜度和作業系統任務排程進行分析測試。可見嵌入式軟體與傳統的物件導向和面向過程的軟體相比有其自身的特點。所以嵌入式軟體的開發和測試也就與一般商用軟體的開發和測試策略有了很大的不同，可以說嵌入式軟體是最難測試的一種軟體。針對這些特點對嵌入式軟體的測試進行研究是必要的和有意義的。
軟體測試是軟體質量保證的關鍵因素，代表了規約、設計和編碼的最終檢查。是從經濟、效率的角度出發，對軟體**進行質量、正確性保證的乙個過程。軟體測試是軟體開發中的乙個重要環節，也是軟體從開發過程到應用過程的關鍵一環，嵌入式軟體也不例外。
討論嵌入式軟體測試首先就會遇到乙個問題：為什麼不把所有測試都放在目標上進行呢?因為若所有測試都放在目標平台上有很多不利的因素：
可能會造成與目標環境開發者爭奪時間的瓶頸，避免提供更多的目標環境;
目標環境可能還不可行;
比起主機平台環境，目標環境通常是不精密的和不方便的;
提供給開發者的目標環境和開發環境通常是很昂貴的;
開發和測試工作可能會妨礙目標環境已存在持續的應用。
確定目標主機(host-target)測試環境後，開發測試人員又會遇到以下的問題：
1)多少開發人員會進行測試工作?
2)多少軟體應該測試，測試會花費多長時間?
3)主機環境和目標環境有哪些軟體工具，**怎樣?
4)多少目標環境可以提供給開發者?
5)主機和目標主機之間的連線怎樣?
7)使用主機與目標環境之間有什麼限制?
進行嵌入式軟體的測試都應深入考慮以上問題，結合自身實際情況，選定合理測試策略和方案。
根據不同的指標，軟體測試有不同的劃分方法。
從軟體開發過程中測試所處的不同階段可分為模組測試、整合測試和系統測試;根據是否需要執行目標**又可分為動態測試和靜態測試;根據目標**的可見性還可分為白盒測試(結構測試)和黑盒測試(功能測試)。
在軟體測試中，每種測試方法都不是孤立的。為了最經濟最有效地達到測試的目的，各種測試方法往往是互相巢狀的。例如，在軟體的單元測試階段，可以用黑盒測試和白盒測試的方法分別進行動態測試。
近年來，在軟體測試中，測試**的覆蓋率逐漸成為軟體測試的統一標準，因此不管採用何種測試方法，盡可能地提高軟體測試中的**覆蓋率是必需的。軟體測試**覆蓋率是基於白盒測試方法的，因此，為了提高軟體測試的**覆蓋率，測試人員必須清楚源**的結構，擁有程式設計文件，以便設計測試用例，使測試盡可能地覆蓋程式內部結構的每條語句，提高**的覆蓋率。
根據嵌入式系統的開發流程，為了最經濟地實現系統的功能，採用自頂向下、層層推進的方法對嵌入式系統進行測試，採用如下圖所示的測試流程。
平台測試：這部分包括硬體電路測試、作業系統及底層驅動程式測試等。
硬體電路測試需要用專門的測試工具進行測試，這裡不再多述。作業系統和底層驅動程式的測試主要包括測試作業系統的任務排程、實時效能、通訊埠的資料傳輸率。該階段測試完成後，系統應為乙個完整的嵌入式系統平台，使用者只需新增應用程式即可完成特定的任務。
模組測試：把大型的嵌入式軟體系統劃分為若干個相對較小的任務模組，由不同的程式設計師分別同時對其進行編碼。編碼完成後，把各個模組整合起來前，必須對單個模組進行測試。由於沒有其它資料模組進行資料傳遞的支援，該階段測試一般是在宿主機上進行的(宿主機有豐富的資源和方便的除錯環境)。此階段主要是進行白盒測試，盡可能地測試每乙個函式、每乙個條件分支、每乙個程式語句，提高**測試的覆蓋率。由於只有單個模組正確才有整體整合的必要性，因此，單個模組測試一定要充分、完整。模組測試階段，測試用例的構造不但要測試系統正常的運**況，還要進行邊界測試。邊界測試就是進行某一資料變數的最大值和最小值的測試，同時進行越界測試，即輸入不該輸入的資料變數測試系統的運**況。理想的嵌入式系統是不應該由於使用者的資訊互動而導致宕機的，這也是嵌入式設計的乙個基本要求。因此，不論進行何種測試，系統宕機都該被作為測試錯誤處理。
在模組測試階段，也可以把大的模組劃分成小的模組。在程式內部，小模組之間資料傳遞的入口設計介面函式，要用於快速地定位錯誤。用模組巢狀的思想進行軟體測試，需要模組內部結構清晰，資料鏈路簡單。
整合測試：單個軟體模組測試正確之後，將所有模組整合起來進行測試。本階段主要是找出各模組之間資料傳遞和系統組成後的邏輯結構的錯誤。在宿主機上採用黑盒與白盒相結合的方法進行測試，要最大限度地模擬實際執行環境，可以遮蔽掉一些不影響系統執行的和資料傳遞難以模擬的函式。
整合測試是嵌入式軟體測試優點充分體現的階段。整合測試前，應該由程式設計師根據模組之間的資料的輸入輸出編寫模組介面函式，這需要負責不同軟體模組的程式設計師共同協調完成，然後將模組介面函式整合到接收資料模組的入口處。單鏈路資料傳遞的軟體模組整合測試時容易定位錯誤所在的軟體模組。乙個軟體模組的資料不一定只有另外乙個模組提供，即軟體模組的資料鏈路不一定只是單鏈路的，測試時可以把複雜鏈路結構的資料傳遞劃分為單鏈路結構資料傳送進行錯誤定位。
整合測試是在擁有程式設計文件、程式結構和資料結構時，對軟體模組在整合**現的錯誤進行測試。
系統測試：整合測試完成後，退出宿主機測試環境，把系統移植到目標機上來，完成應用到現場環境中的移植，從使用者的角度對系統進行黑盒測試，以驗證每一項具體的功能。由於測試者對程式內容、程式執**況一無所知，因此本測試階段的錯誤定位比較困難。系統測試階段應該進行意外測試和破壞性測試，即測試系統正常執**況下不該發生的活動和人為的破壞性的測試，進一步驗證系統效能。系統測試階段不應該確定錯誤後立即修改**，應根據一定的錯誤發生頻率，確定測試週期，在每個測試週期結束時修改**，進行反覆測試;否則，不但增加了完全測試的任務量，而且降低了測試的可信度。
測試結果分析：測試結果分析可以定位錯誤，指導程式設計師修改**，同時指出進行測試的程式進一步測試的方向。測試結果分析是乙個由測試結果和測試預得結果進行分析、比較和定位錯誤的過程。測試結果分析是一次測試的最後環節，分析時應該考慮軟體的執行環境與實際執行環境的差異，以及各種外界因素的影響等。
白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都能按預定要求正確工作的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。「白盒」法要求全面了解程式內部邏輯結構、對所有邏輯路徑進行測試。「白盒」法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程式的內部結構，從檢查程式的邏輯著手，得出測試資料。
黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用。在測試時，把程式看作乙個不能開啟的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試。它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數鋸而產生正確的輸出資訊，並且保持外部資訊(如資料庫或檔案)的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因果圖、錯誤推測等，主要用於軟體確認測試。「黑盒」法著眼於程式外部結構、不考慮內部邏輯結構、針對軟體介面和軟體功能進行測試。「黑盒」法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程式中所有的錯誤。
測試用例是為了測試目標程式設計的，包括輸入項和預得結果的一種檔案。根據測試環境和測試目標程式的不同，可分為某種格式的文件或某種輸入行為(如一次按鍵)等。測試用例的構造要盡可能覆蓋所有可能的取值範圍，使測試盡可能地覆蓋所有程式**，提高**的測試覆蓋率，同時又不作多餘、重複和無意義的測試。在嵌入式軟體測試的不同階段，要構造不同的測試用例;在系統平台測試階段，要構造針對系統任務排程、實時效能和底層驅動程式的測試用例;在模組測試階段，應構造針對某一模組進行測試的測試用例;在整合測試階段，針對系統整合時資料傳遞、結構連線的問題構造相應的測試用例;在系統測試階段，要構造針對某項功能的或多項功能結合在一起的測試用例，或使用已經在同類產品上已經驗證正確的測試用例，測試用例是可復用的。
嵌入式設計已經成為工業現代化、智慧型化的必經之路，嵌入式產品已經深入到各行各業。嵌入式系統的專用程度較高，系統的整體繼承性相對較小，為了保證系統的穩定性，軟體測試成為嵌入式開發的乙個重要環節。由於嵌入式軟體自身的特點，傳統的軟體測試理論不能直接用於嵌入式軟體的測試。文章對嵌入式軟體的特點作了分析，總結了嵌入式軟體測試的策略和方案設計，提出了嵌入式軟體測試流程和測試方法。本文的研究內容對嵌入式軟體的測試有重要意義。
本文**：
嵌入式軟體測試策略
在嵌入式領域目標系統的應用系統日趨複雜，而由於競爭要求產品快速上市，開發技術日新月異，同時硬體發展的日益穩定，而軟體故障卻日益突出，軟體的重要性逐漸引起人們的重視，越來越多的人認識到嵌入式系統的測試勢在必行。提到嵌入式軟體測試，首先要簡單介紹一些軟體工程的一些觀點，現在，被普遍接受的軟體的定義是 軟...
嵌入式軟體測試
嵌入式軟體測試 嵌入式軟體測試 嵌入式測試或叫交叉測試 cross test 的日的與非嵌入式軟體是相同的。但是，在嵌入式系統設計中，軟體正越來越多地取代硬體，以降低系統的成本，獲得更大的靈活性，這就需要使用更好的測試方法和工具進行嵌入式和實時軟體的測試。通常嵌入式系統對可靠性的要求比較高。嵌入式系...
嵌入式軟體測試
如何在目標板上實時測試應用程式 為什麼嵌入式系統測試困難？在目標板上測試面臨的系列問題 2 如何累積可重複自動執行的測試 3 如何盡可能減少人工工作 4 如何減少記憶體不夠的問題 這些都是經常碰到但難以解決的問題。隨著專案 越來越大，開發人員數量和 數量都變多，完全懂得目標硬體和軟體工作原理的可能僅...