基於模組化設計的嵌入式軟體測試方法

 基於模組化設計的嵌入式軟體測試方法

    摘要：分析嵌入式軟體的特點，綜述傳統的軟體測試方法；針對嵌入式軟體的特點，提出嵌入式軟體的四級測試流程和整合測試的測試模型，並結合開發數控系統的執行個體進行分析。

    關鍵詞：模組化設計　嵌入式軟體　軟體測試　測試方法　測試模型　數控系統

    嵌入式設計已經成為工業現代化、智能化的必經之路，嵌入式產品已經深入到各行各業。嵌入式系統的專用程度較高，系統的整體繼承性相對較小，為了保證系統的穩定性，軟體的測試成為嵌入式開發的一個重要環節。由於嵌入式軟體自身的特點，傳統的軟體測試理論不能直接用於嵌入式軟體的測試，因此，研究嵌入式軟體的測試有重要意義。

1 基本概念簡述
1.1 模組化設計
    軟體的設計是以一定的方法為基礎的。面對越來越複雜的軟體開發工作單位，人們提出了各種軟體設計的模型。從使用者需求和系統要實現的任務功能出發，把大型的軟體劃分為相對較小的模組。為了減少模組與模組之間的關聯性，模組之間的邏輯結構相對獨立，無函數的交叉調用，資料傳遞由全域變數完成，這就是模組化設計的基本思想。模組化設計的核心是模組的獨立性，主要包括功能獨立性和結構獨立性，這使得軟體開發的分工易於實現。軟體測試是軟體開發中的關鍵環節，基於模組化設計的軟體測試模型簡單，查錯和錯誤修正都易於實現。下面以單鏈路資料傳遞的軟體模型說明模組化軟體設計的軟體測試的基本原則。

    在圖１中，函數Ｆ（Ｘ－Ｙ）定義為軟體模組Ｘ到軟體模組Ｙ的介面函數，用來通過終端顯示由模組Ｘ進入模組Ｙ的資料。如果模組Ｃ執行後發生錯誤，則由模組Ｂ和模組Ｃ的資料介面函數Ｆ（Ｂ－Ｃ）判斷是否是模組Ｂ出來的資料就是錯誤的。如果Ｆ（Ｂ－Ｃ）不錯，則證明模組Ｃ存在錯誤；如果Ｆ（Ｂ－Ｃ）傳遞資料錯誤，再察看Ｆ（Ａ－Ｂ）傳出的資料是否錯誤，如果不錯則證明模組Ｂ存在錯誤。用此依次前推孤立錯誤的方法，即可以很容易地定位錯誤所在的模組。這就是模組化設計時軟體測試的基本原則。

1.2 嵌入式系統
    嵌入式系統開發有其自身的特點。一般先進行硬體部分的開發，主要包括形成裸機平台，根據需要移植即時作業系統，開發底層的硬體驅動程式等。硬體平台測試通過後，應該軟體的開發調試是基於該硬體平台進行的，這同時也是對硬體平台的一個測試。整個嵌入式系統開發流程２所示。

    因此可以說，嵌入式系統的開發過程是一個軟硬體互相協調，互相反饋和互相測試的過程。一般來說，在嵌入式系統軟體中，底層驅動程式、作業系統和應用程式的界線是不清晰的，根據需要甚至混編在一起。這主要是由於嵌入式系統中軟體對硬體的依賴性造成的。嵌入式軟體對硬體的依賴性要求，軟體測試時必須最大限度地類比被測軟體的實際運行環境，以保證測試的可靠性。底層程式和應用程式界限的不清晰增加了測試時的難度，測試時只有確認嵌入式系統平台及底層程式正確的情況下才能進行應用程式的測試，而且在系統測試時，錯誤的定位較為困難。軟體的專用性也是嵌入式軟體的一個重要特點。由於嵌入式軟體設計是以一定的目標硬體平台為基礎的、面向固定的任務進行的，因此，一旦被載入到目標系統上，功能必須完全確定。這個特點決定了嵌入式應用軟體的繼承性較差，延長的系統的測試時間，增加了測試費用。嵌入式軟體的另外一個重要特點就是即時性。這是從軟體的執行角度出發說明的，也就是說嵌入式軟體的執行要滿足一定的時間約束。嵌入式系統中，應用軟體自身演算法的複雜度和作業系統任務調度，決定了系統資源的分配和消耗，因此，對系統即時性進行測試時，要藉助一定的測試載入器對應用程式演算法複雜度和作業系統任務調度進行分析測試。可見嵌入式軟體與傳統的物件導向和面向過程的軟體相比有其自身的特點。針對這些特點對嵌入式軟體的測試進行研究是必要的，有意義的。

1.3 嵌入式軟體測試
    軟體測試是從經濟、效率的角度出發，對軟體代碼進行品質、正確性保證的一個過程。軟體測試是軟體開發中的一個重要環節，也是軟體從開發過程到應用過程的關鍵一環。嵌入式軟體也不例外，圖３給出了嵌入式軟體測試的統一測試模型。軟體測試逐漸成為一門成熟的學科，前人針對物件導向和面向過程的非即時軟體的測試作了大量的研究，其中大部分方法可以用到嵌入式軟體的測試。

    根據不同的指標，軟體測試方法有不同的劃分方法。從軟體開發過程中測試所處的不同階段可分為模組測試、整合測試和系統測試。根據是否需要運行目標代碼分為動態測試和靜態測試；根據目標代碼的可見度可分為白盒測試（結構測試）和黑箱測試（功能測試）。在軟體的測試中，每種測試方法都不是孤立的。為了最經濟最有效地達到測試的目的，各種測試方法往往是互相嵌套的。例如，在軟體的單元測試階段，可以用黑箱測試和白盒測試的方法分別進行動態測試。

    值得一提的是，近年來軟體測試中，測試代碼的覆蓋率逐漸成為軟體測試的統一標準，因此不管採用何種測試方法，儘可能地提高軟體測試中的程式碼涵蓋範圍是必需的。軟體測試程式碼涵蓋範圍是基於白盒測試方法的，因此，為了提高軟體測試的程式碼涵蓋範圍，測試人員必須清楚原始碼的結構，擁有程式設計文檔，以便設計測試案例使測試儘可能地覆蓋程式內部結構的每條語句，提高代碼的覆蓋率。

2 基於模組化設計的嵌入式軟體四級測試流程
    根據嵌入式系統的開發流程，為了最經濟地實現系統的功能，採用自頂向下、層層推進的方法對嵌入式系統進行測試，提出了４所示的基於模組化設計的嵌入式軟體四級測試流程。在四級測試中，本測試階段以前的測試完成後，當發現錯誤時，可排隊此測試階段以前的錯誤，在本測試階段內尋找錯誤。這並不是一個絕對準確的方法，但最大限度地節了錯誤定位的時間。

2.1 系統平台測試
    這部分包括硬體電路測試、作業系統及底層驅動程式的測試等。硬體電路的測試需要用專門的測試載入器進行測試。這裡不再多述。作業系統和底層驅動程式的測試主要包括測試作業系統的任務調度、即時效能、通訊連接埠的資料轉送率。該階段測試完成後，系統應為一個完整的嵌入式系統平台，使用者只需添加應用程式即可完成特定的任務。

2.2 模組測試
    把大型的嵌入式軟體系統劃分為若干個相對較小的任務模組，由不同的程式員分別同時對其進行編碼。編碼完成後，把各個模組整合起來前，必須對單個模組進行測試。由於沒有其它資料模組進行資料傳遞的支援，該階段測試一段是在宿主機上進行的（宿主機有豐富的資源和方便的調試環境）。此階段主要是進行白盒測試，儘可能地測試每一個函數、每一個條件分支、每一個程式語句，提高代碼測試的覆蓋率。由於只有單個模組正確才有整體整合的必要性，因此，單個模組測試時測試一定要充分、完整。模組測試階段，測試案例的構造不但要測試系統正常的運行情況，還要進行邊界測試。邊界測試就是進行某一資料變數的最大值和最小值的測試，同時進行越界測試，即輸入不該輸入的資料變數測試系統的運行情況。理想的嵌入式系統是不應該由使用者的資訊互動導致死機的，這也是嵌入式設計的一個基本要求。因此，不論進行何種測試，系統死機都該被作為測試錯誤處理。在模組測試階段，由模組化編程的基本思想，根據模組內部的緊湊程式，也可以把大的模組劃分成小的模組。在程式內部，小模組之間資料傳遞的入口設計介面函數，用於快速地定位錯誤。用此模組嵌套的思想進行軟體測試，需要模組內部結構清晰，資料鏈路簡單。

2.3 整合測試
    單個軟體模組測試正確之後，將所有模組整合起來進行測試。本階段主要是找出各模組之間資料傳遞和系統組成後的邏輯結構的錯誤。在宿主機上採用黑盒與白盒相結合的方法進行測試，要最大限度地類比實際運行環境，可以屏蔽掉一些不影響系統執行的和資料傳遞的難以類比的函數。整合測試是模組化設計軟體的測試優點充分體現的階段。整合測試前，應該由程式員根據模組之間的資料的輸入輸出編寫模組介面函數，這需要負責不同軟體模組的程式員共同協調完成，然後將模組介面函數整合到接收資料模組的入口處。由前面的分析可知，單鏈路資料傳遞的軟體模組整合測試時容易定位錯誤所在的軟體模組。一個軟體模組的資料不一定只有另外一個模組提供，即軟體模組的資料鏈路不一定只是單鏈路的，測試時可以把複雜鏈路結構的資料傳遞劃分為單鏈路結構資料傳送進行錯誤定位。修改輸出資料的軟體模組時，可能導致輸入資料的軟體模組引入新的錯誤，因此在這裡引入關聯矩陣確定修改某一模組後需要重要測試的模組。

    假定模組化設計的嵌入式系統軟體由軟體模組Ａi(i=1,2,…，m,n)組成，m表示矩陣的行號，n表示矩陣的列號。圖５所示的矩陣即為其關聯矩陣。

    在關聯矩陣中，Aij=1表示Aj接受了Ai輸出的資料，故修改了Ai重新測試Ai的同時也需重新測試Aj。

    整合測試是在擁有程式設計文檔、程式結構和資料結構時，對軟體模組在整合中出現的錯誤進行測試。整合測試時，根據模組介面函數定位錯誤修改代碼，根據關聯矩陣確定重新測試的軟體模組。圖６給出了模組化設計的嵌入式軟體整合測試模型。

2.4 系統測試
    整合測試完成後，退出宿主機測試環境，把系統移植到目標機上來，完成應用到現場環境中，從使用者的角度對系統進行黑箱測試，驗證每一項具體的功能。由於測試者對程式內容程式執行情況一無所知，因此本測試階段的錯誤定位比較困難。系統測試階段應該進行意外測試和破壞性測試，即測試系統正常執行情況下不該發生的激發活動和人為的破壞性的測試，進一步驗證系統效能。系統測試階段不應該確定錯誤後立即修改代碼，應根據一定的錯誤發生頻率，確定測試周期，在每個測試周期結束時修改代碼，進行反覆測試；否則，不但增加了完全測試的任務量，而且降低了測試的可信度。

2.5 測試結果分析
    測試結果的分析可以定位錯誤，指導程式員修改代碼，同時指出測試進行的程式並進一步指明測試方向。測試結果的分析是一個由測試結果和測試預得結果進行分析、比較和定位錯誤的過程。測試結果的分析是一次測試的最後環節，分析時應該考慮軟體的運行環境和實際運行環境的差異以及各種外界因素的影響等。

2.6 測試案例的構造與管理
    測試案例是為了測試目標程式設計的包括輸入項和預得結果的一種檔案，根據測試環境和測試目標程式的不同，可分為某種格式的文檔或某種輸入行為（如一次按鍵）等。測試案例的構造要儘可能覆蓋所有可能的取值範圍，使測試儘可能地覆蓋所有程式碼，提高代碼的測試覆蓋率，同時又不作多餘、重複和無意義的測試。在嵌入式軟體測試的不同階段，要構造不同的測試案例；在系統平台測試階段，要構造針對系統任務調度、即時效能和底層驅動程式的測試案例；在模組測試階段，應構造針對某一模組進行測試的測試案例；在整合測試階段，針對系統整合時資料傳遞、結構斜接的問題構造相應的測試案例；在系統測試階段，要構造針對某項功能的或多項功能結合在一起的測試案例，或使用已經在同類產品上已經驗證正確的測試案例。測試案例是可複用的。此外大型的軟體開發過程中，測試案例的種類繁多，應該按一定的方法進行管理。用資料庫的來管理測試案例是一個很好的選擇。根據測試階段將測試案例進行劃分，然後用關鍵字唯一確定。這樣在使用、修改和儲存測試案例時都很方便，直接用查詢的方式就可以調出測試案例。

3 數控系統軟體測試
    本數控系統採用ＡＲＭ７處理器，作業系統採用μＣ／ＯＳ即時作業系統，是一個典型的嵌入式系統。由於數控系統較為複雜，開發過程中將任務進行了詳細的劃分，軟體的開發採用模組化開發。模組的劃分及資料流向７所示。

    根據圖７所示的軟體模組和資料流向可構造關聯矩陣，８所示。

    開發過程中，幾個模組由不同的程式員分別進行編碼，分別由程式員進行模組測試，並按白盒測試的方法進行覆蓋測試。最後整合測試前，根據關聯矩陣，程式員協作編寫了模組介面函數Ｆ（A1-A2）、Ｆ（Ａ１－Ａ４）、Ｆ（Ａ１－Ａ５）、Ｆ（Ａ１－Ａ６）、Ｆ（Ｆ２－Ａ３）、Ｆ（Ａ３－Ａ４）、Ｆ（Ａ４－Ａ５）、Ｆ（Ｆ５－Ａ６）、Ｆ（Ａ６－Ａ２），然後根據圖６所示的測試模型和圖８所示的關聯矩陣對系統進行了整合測試。分析可知，一些關鍵模組，如解碼模組和刀補模組的測試程式碼涵蓋範圍達到９０％之上。圖９所示的整個系統經過系統測試之後效能穩定，圖１０為其加工的零件，目前該系統已經小批量生產。

 

4 結論
    文章對嵌入式軟體的特點和傳統的測試方法作了分析之後，提出了四級測試流程和整合測試的模型。此測試方法用於工程機械控制器和數控系統開發的測試。測試的效率和可靠性滿足要求。文中的單鏈路資料傳遞的錯誤定位、模組介面函數、關聯矩陣等方法也可以用於物件導向的和物件導向的軟體系統。

歡迎轉載此文，轉載時請註明文章來源：文斯測試技術研究中心 http://blog.csdn.net/vincetest