直升機機電管理系統軟件測試方法研究

孫月寧，肖文洪，石璐璐

(中國直升機設計研究所，江西 景德鎮 333001)

0 引言

直升機機電管理系統(機電公共設備管理系統)是保障飛行必不可少的系統，機電管理系統不僅要對各個機電設備(或者系統)進行監視和告警，同時作為飛機管理的一部分要負責管理和控制整個機電設備。由于機電設備與飛機安全密切相關，作為一個核心管理系統，機電管理系統的工作狀態和安全保證是全系統的核心，決定著系統的功能和性能[1]。

機電管理系統軟件是一個嵌入式實時多任務程序嵌入式機載軟件，它具有接口復雜，實時性強，安全性、可靠性要求高，開發與測試驗證過程同步進行，測試環境復雜等特點。其質量和可靠性是整個機電管理系統正常運行的基礎，保證軟件質量和可靠性的重要途徑是對軟件進行充分的測試。

軟件測試技術快速發展，取得了許多成果，但由于機電管理系統軟件的復雜性和特殊性，軟件的測試仍存在許多困難和不足，比如傳統機電管理系統軟件測試使用不是很成熟的V模型，而且依然進行手動測試，未使用專業的測試工具，使得測試花費時間較長，整個項目的研發進度緩慢。

針對機電管理系統軟件測試目前存在的問題，本文根據自己的測試經驗和對嵌入式機載軟件測試的認識，使用成熟的W模型[2]和專業的Testbed[3]測試工具，對某型機機電管理系統軟件進行測試，并取得了良好的效果。

1 測試模型

鑒于機電管理系統軟件及其開發、測試的特點，需要對在軟件的文檔審查、代碼審查、單元測試、配置項測試等各個層面上的測試工作進行規劃，制訂合理的測試策略，選擇適用的測試方法和模型，盡可能及時地消除軟件的缺陷。目前常見的軟件測試模型有V模型、W模型、H模型、X模型等，傳統的機電管理系統軟件測試采用V模型，如圖1。

圖1 V模型

V模型描述了一些不同的測試級別，并說明了這些級別所對應的生命周期中不同的階段。V模型揭示了軟件測試活動分層和分階段的本質特性,非常明確地標明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發過程中各階段的對應關系。

但V模型也存在一些問題，比如容易讓人形成“測試是開發之后的一個階段”以及“測試的對象就是程序”之類的誤解。由于V模型把系統開發過程劃分為具有固定邊界的不同階段，這使得人們很難跨過這些邊界來采集測試所需要的信息。有些測試應該執行得更早些，有些測試則需要延后進行。不僅如此，V模型也阻礙了從系統描述的不同階段中取得信息進行綜合。所以，近年來，一種改進過的軟件測試模型——W模型被提了出來，如圖2所示。

圖2所示，W模型由兩個“V”字重疊形成，其中一個“V”字代表開發過程，包括用戶需求、需求規格說明書編寫，軟件設計說明，編碼，集成，實施，交付。另一個V字代表軟件測試過程，包括文檔評審(用戶需求評審、需求規格評審、設計說明評審)、代碼測試(單元測試、集成測試、確認測試、驗收測試)。

W模型是眾多測試模型中相對比較成熟的一種測試模型。該模型強調測試并不是在代碼編寫完成之后才開展的工作，測試與開發是兩個相互依存的并行的過程，軟件測試貫穿于軟件生命周期的所有階段，軟件的需求分析和設計階段都會出現錯誤，所以測試活動應在開發活動的前期已經開展。測試人員早期參與軟件項目，及時開展測試的準備工作，包括編寫測試計劃、制定測試方案以及準備測試用例；一旦代碼模塊完成就應該及時開展單元測試，一旦代碼模塊被集成為相對獨立的子系統，便可以開展集成測試，一旦有BUILD提交，便可以開展系統測試工作。

圖2 W模型

W模型中另一個重要的思想是“全面測試”。即應對軟件的所有產品進行全面的測試，包括需求、設計文檔、代碼、用戶文檔以及測試進度和測試策略的調整、需求變更等；軟件開發及測試人員(有時包括用戶)全面地參與到測試工作中，并且對測試過程進行全面跟蹤，例如對需求的驗證和確認活動，就需要開發、測試人員及用戶的全面參與，畢竟測試活動并不僅僅是保證軟件運行正確，同時還要保證軟件滿足用戶的需求。

2 測試工具

以往我們使用機電系統模擬綜合裝置對機電管理系統軟件進行測試。機電系統模擬綜合裝置是在試驗室中建立起來的上下接口模擬環境，它能模擬真實的機電系統和航空電子系統的工作狀態以及控制邏輯。可以模擬被測設備的工作環境，逼真地表現出真實運行環境的各種特性，并實現測試用例的輸入；也可以通過自動的循環測試，進行設備的穩定性測試；通過故障注入系統實現對子系統間信號的故障注入，在物理層、電氣層、鏈路層、協議層以及應用層進行故障模擬，在信號接口上模擬設備內部的運行異常，以實現對被測設備的逆向測試和容錯性測試。在試驗室開發、綜合調試以及測試時，機電管理系統被測設備與目標機的連接如圖3所示。

圖3 測試設備交聯圖

利用機電系統模擬綜合裝置雖然可以進行基本的測試，但是測試主要依賴于測試人員的經驗，使測試的有效性和效率受到極大的影響，使我們對產品開發的各個階段的質量無法把握，對產品的最終質量無法控制。所以機電管理系統軟件迫切需要專業的嵌入式軟件測試工具來輔助軟件測試。

通過比較多種測試工具，發現LDRA Testbed是一款非常好的嵌入式開發和進行高可靠性軟件開發設計的軟件測試工具，適合用于機電管理系統軟件的測試。它具備以下優點：

①在編程階段可檢測和修改軟件的錯誤與缺點。

②在測試階段，Testbed/TBrun可以和機電管理系統軟件的開發工具-Tornado很好地集成到一起，通過目標平臺配置工具TBconfig能夠很方便地完成TBrun和Tornado的集成配置，并可自動產生軟件測試驅動、樁模塊，從而節省時間，測試人員可將重點放在設計測試用例上，提高軟件測試效率。可對測試對象進行靜態分析，包括質量度量、內存資源使用等，還可以對測試對象進行動態覆蓋率測試。

③在軟件維護階段，提供了理解軟件的逆向工程工具。

3 基于W模型和Testbed的機電管理系統軟件測試

由于V模型的不成熟和測試的低效性，本文選擇較成熟的W模型，并使用Testbed測試工具，對某型機機電管理系統軟件進行測試，驗證此方案的測試優勢。

3.1 開發前期測試設計

W模型在V模型的基礎上增加需求測試和設計測試，即軟件開發前期的測試，目的是確保需求的完整性、一致性、準確性、可實現性和可測試性等，以及設計對需求的可追蹤性、正確性、規范性和可測試性等。針對機電管理系統的特點，開展了需求測試和設計測試工作。

3.1.1 需求測試設計

1)需求文檔審查[4]

需求文檔不僅是系統測試和用戶文檔的基礎，也是所有子系統項目規劃、設計和編碼的基礎，因此，它的描述的準確性至關重要，對其評審即靜態測試活動是不可掉以輕心的,它可以消除需求工作中的缺陷,使解決缺陷的花費降至最低。

為了更好地對機電管理系統軟件模塊進行測試，首先需要測試人員熟悉該軟件的工程需求，包括功能性能需求、接口需求、容量時間需求、安全需求等。主要依據以下10條原則來對其進行文檔審查。

①軟件需求文檔是否按照相關的文檔標準格式編制；

②軟件需求文檔是否滿足軟件研制任務書的各項要求(可追蹤性)；

③系統需求分析階段提供的文檔資料是否齊全；

④軟件需求文檔中的需求在實現上是否可行；

⑤軟件需求文檔的功能、性能指標是否完整、明確、無二義性；

⑥軟件需求文檔所描述的需求是否完整、可證實、可測試；

⑦所開發項目的數據流與數據結構是否足夠、確定；

⑧軟件需求文檔所描述的系統預期的外部行為和可視化行為是否完整；

⑨有沒有遺漏、重復或不一致的地方；

⑩軟件需求文檔中影響分析安全關鍵軟件的安全性需求是否完整、明確。

2)制定測試計劃

當測試需求被確定后，則進入測試設計階段，該階段的主要任務是基于已定義的需求，根據項目開發計劃，創建項目的測試計劃。項目的測試計劃由多個計劃組成，各測試計劃對應到各模塊、測試主題或是軟件版本。測試計劃的測試內容通過測試任務來體現。

3)需求測試用例設計

在需求文檔通過審查的基礎上，開始進入功能測試用例設計，首先列出測試項及測試特征，然后根據這些內容確定測試方法和測試所需要的軟硬件環境、制定測試通過與失敗的標準、風險和意外情況應對措施、估算測試所需人力以及整個項目規劃的大致測試周期并搭建測試環境。在此基礎上制定詳細的用戶的驗收測試以及系統測試計劃。

3.1.2 設計測試

1)設計審查

軟件設計分為概要設計和詳細設計，它依據需求規格說明書對系統的具體實現進行描述。

主要依據以下11條原則來對其進行文檔審查：

①軟件設計是否覆蓋需求規格書中用戶提出的每個功能點；

②軟件設計中的每個函數流程或偽代碼的邏輯和語句是否正確；

③軟件設計中使用的數據結構、函數執行率、資源訪問沖突風險是否合理；

④軟件設計的準確性和一致性；

⑤軟件設計與目標機的兼容性；

⑥軟件設計的可驗證性；

⑦軟件設計與編寫標準的符合性；

⑧軟件設計到軟件需求的可追蹤性；

⑨數據設計說明的完備性、一致性的和易理解性；

⑩軟件具有健壯性，軟件劃分的完整性；

2)測試計劃細化

將需求分析階段建立的系統測試計劃加以細化更新，進行系統測試設計；將確認測試計劃加以細化，進行確認測試設計。在概要設計階段完成集成測試計劃，并且在詳細設計階段加以細化更新，進行集成測試設計。在詳細設計階段也要完成單元測試計劃。模塊測試計劃不需要非常正規，只是簡單解釋程序員計劃如何測試這個模塊。單元測試的測試計劃應該根據被測單元的性質而制定，如對系統控制單元應主要采用結構測試；對復雜的計算單元應主要采用算法分析測試用例；對界面單元就應該測試各種選項的組合等等。

3)設計測試用例設計

在機電管理系統的模塊進行設計實現后，根據詳細設計的具體內容，設計出測試用例模板，以等價類劃分、邊界值分析、錯誤推測法為主要方法來設計具體的測試用例，為每個測試用例規定測試規程，包括運行測試用例的準備、初始化、中間步驟、前提和約束，把測試用例寫入“軟件測試說明”。

3.2 代碼測試

在前期測試設計中共生成用例406個，使用Testbed工具和機電系統模擬綜合裝置相結合的方式，按照測試計劃，根據測試用例對機電管理系統軟件進行逐一的、詳細的測試，并根據各階段測試結果完成測試報告。測試內容主要包括：靜態測試、動態測試和覆蓋率測試、功能測試、性能測試、接口測試、可安裝測試、強度測試、安全性測試等測試類別。

3.2.1 靜態測試

首先導入機電管理系統程序代碼，當然被測試程序必須是已經通過編譯沒有錯誤的源代碼，選擇代碼審查所遵循的規則，可以使用Testbed所列舉的標準或自定義的標準。例如針對此型號的機電管理系統軟件，我們可以按照《軍用軟件測試指南》中的有關規定制訂生成代碼審查標準。Testbed的靜態分析功能很強大，我們選擇其中的主要靜態分析、復雜度分析和靜態數據流分析對被測程序進行分析，就可以達到靜態測試要求。

Testbed分析完成后，得到三種主要分析結果報告，報告結論如下：

①代碼評審報告：代碼和設計一致；代碼執行標準正確；代碼邏輯表達正確；代碼結構合理；代碼可讀性符合要求。

②質量評審報告：軟件質量符合各項標準。

③設計評審報告：對軟件的接口進行測試，源代碼和最初的設計需求一致。

3.2.2 動態測試和覆蓋率測試

對軟件進行動態測試，利用Testbed對代碼進行編譯，生成目標代碼，通過裝入目標代碼就可以對軟件進行動態測試。從Testbed中啟動運行單元動態測試軟件Tbrun，選擇要測試的軟件單元，通過初始化被測對象運行所需的測試用例，運行機電管理系統軟件，利用Testbed可以觀察程序的運行情況、語句和分支覆蓋是否滿足測試要求,如圖4。

可以借助于LDRA Testbed來監控原代碼按測試數據的執行情況。當測試數據都用完了，察看動態覆蓋率分析報告，可以得到程序中哪些部分沒有被完全測試。每個測試數據集合的動態覆蓋率分析結果是累加的，也可以觀察到每個測試數據集合對應于程序中的執行部分。這些信息是通過執行動態數據集得到的。

3.2.3 其它類測試

對機電管理系統軟件進行功能測試、性能測試、接口測試、可安裝測試、強度測試、安全性測試，測試結果均符合相關文件規定的要求。

圖4 覆蓋率圖

4 總結

針對目前直升機機電管理系統軟件測試的不足，采用W模型，使用Testbed測試工具和機電系統模擬綜合裝置相結合的方式進行代碼測試，保證了軟件的質量、性能和可靠性，減少了總體的測試時間。此方法不僅提高了軟件生產效率及其質量，而且完整地體現了軟件測試的工程化思想，為嵌入式軟件測試提供了一個全面和高效的測試方法。

[1] 王占林，裘麗華.機載公共設備的統一控制與綜合管理[J].工程設計學報2003.10(2):84-88．

[2] 黃龍水，黃誠學.軟件模型介紹[J].船舶電子工程，2004(3):35-38.

[3] 李中萍，岳 海，薛 靜．LDRA TESTBED在航天軟件測試中的應用[J]．航天控制，2007，25(2)：73-77．

[4] 黃怡強，郭欽祥，黃怡勝.淺談軟件開發需求分析階段的主要任務[J].中山大學學報，2002.02(22):262-265.