孫月寧，肖文洪，石璐璐

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

0 引言

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

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

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

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

1 測試模型

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

圖1 V模型

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

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

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

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

圖2 W模型

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

2 測試工具

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

圖3 測試設備交聯(lián)圖

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

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

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

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

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

3 基于W模型和Testbed的機電管理系統(tǒng)軟件測試

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

3.1 開發(fā)前期測試設計

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

3.1.1 需求測試設計

1)需求文檔審查[4]

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

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

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

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

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

④軟件需求文檔中的需求在實現(xiàn)上是否可行；

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

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

⑦所開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結構是否足夠、確定；

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

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

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

2)制定測試計劃

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

3)需求測試用例設計

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

3.1.2 設計測試

1)設計審查

軟件設計分為概要設計和詳細設計，它依據(jù)需求規(guī)格說明書對系統(tǒng)的具體實現(xiàn)進行描述。

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

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

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

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

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

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

⑥軟件設計的可驗證性；

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

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

⑨數(shù)據(jù)設計說明的完備性、一致性的和易理解性；

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

2)測試計劃細化

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

3)設計測試用例設計

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

3.2 代碼測試

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

3.2.1 靜態(tài)測試

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

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

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

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

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

3.2.2 動態(tài)測試和覆蓋率測試

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

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

3.2.3 其它類測試

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

圖4 覆蓋率圖

4 總結

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

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

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

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

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