譚莉娟，鄭 巍，劉友林，樊 鑫，楊豐玉

1.南昌航空大學(xué) 軟件學(xué)院，南昌 330063

2.南昌航空大學(xué) 軟件測評中心，南昌 330063

機載嵌入式軟件，就是指安裝在以應(yīng)用軟件為中心、計算機技術(shù)為基礎(chǔ)，由軟硬件模塊組成能夠獨立運行的可裁剪的航空電子系統(tǒng)中，作為核心控制作用的計算機應(yīng)用軟件部分[1-2]，例如飛行控制系統(tǒng)軟件、通信導(dǎo)航系統(tǒng)軟件等。機載嵌入式系統(tǒng)中許多關(guān)鍵的功能都是由軟件支持的，隨著軟件技術(shù)在航空領(lǐng)域的廣泛應(yīng)用，影響機載嵌入式系統(tǒng)的軟件因素從3%增長到了80%[3]。機載嵌入式軟件的實時性、高可靠性是航空電子系統(tǒng)正常運行的重要因素。據(jù)統(tǒng)計，60%的機載電子設(shè)備故障問題來自于軟件缺陷，并且造成了巨大損失。例如，2004年12月，美國第四代戰(zhàn)機F-22起飛時機載制氧系統(tǒng)存在嚴(yán)重缺陷而失控發(fā)生了墜毀事故，導(dǎo)致該型戰(zhàn)機全部被迫停飛。因此，確保機載軟件質(zhì)量可靠性的關(guān)鍵工作就是對航空機載嵌入式軟件進行測試。

由于嵌入式軟件的特殊性及復(fù)雜性，目前嵌入式軟件測試技術(shù)研究進展落后于普通的軟件測試技術(shù)。自20 世紀(jì)70 年代開始，國外開始研究嵌入式軟件測試方法，研究人員試圖用專門的軟件測試技術(shù)對單嵌入式軟件系統(tǒng)進行測試。1980年Glass的一篇關(guān)于嵌入式軟件測試技術(shù)的文章Real-Time：The“Lost World”of Software Debugging and Testing[4]，得出了嵌入式實時軟件測試的進展明顯滯后于一般軟件測試的現(xiàn)狀，并針對性地提出了相應(yīng)的解決方法。之后許多研究機構(gòu)針對嵌入式軟件的特性進行更深入地測試研究，對嵌入式軟件測試的方法研究進度不明顯，轉(zhuǎn)而開發(fā)支持嵌入式軟件測試工具，例如AMC公司開發(fā)的嵌入式實時分析測試工具CodeTEST，推動了嵌入式軟件測試自動化的研究進展。我國從20世紀(jì)90年代才開始從國防電子領(lǐng)域展開對嵌入式軟件測試的研究，與國外研究水平差距較大，針對性地開發(fā)了軟件測試工具，例如北京航天航空大學(xué)為測試C 語言環(huán)境下的嵌入式軟件系統(tǒng)開發(fā)了SafePro/C測試軟件，航天204所為測試嵌入式匯編語言開發(fā)了ATEST 測試工具[5]。嵌入式軟件在航空航天機載系統(tǒng)中的比重逐漸增加，其質(zhì)量嚴(yán)重影響著系統(tǒng)的運轉(zhuǎn)，受到相關(guān)研發(fā)部門的重視，但是國內(nèi)對嵌入式軟件測試?yán)碚?、技術(shù)及工具的研究仍處于初步階段，需要后續(xù)進行大量研究學(xué)習(xí)，可借鑒面向適航標(biāo)準(zhǔn)的機載軟件測試驗證工具綜述，是針對機載軟件測試驗證的工具進行的總結(jié)，側(cè)重點不同。

在部署之前，機載嵌入式軟件必須經(jīng)過航空航天認證機構(gòu)的審核和批準(zhǔn)。DO-178C[6]標(biāo)準(zhǔn)是2011 年由美國RTCA 提出的國際民用航空行業(yè)內(nèi)及局方遵循的標(biāo)準(zhǔn)，為了滿足適航認證審定的標(biāo)準(zhǔn)，定義了軟件生存周期過程中的活動和目標(biāo)，對機載軟件生存過程提出了一系列要求，軟件驗證過程為機載軟件整個生存周期質(zhì)量提供了可靠保證?；贒O-178C的軟件測試是對軟件開發(fā)過程的驗證過程，主要目的是證明軟件是否滿足需求，并以高置信度證明可能導(dǎo)致其在系統(tǒng)安全性評估過程中確定為不可接受的失效狀態(tài)的錯誤已被消除。

為了確保機載軟件系統(tǒng)的安全保障，適航是對載人航空器飛行的最低安全性要求[7]，因此相關(guān)管理部門進行了大量的研究與實踐工作，頒布越來越完善的機載軟件適航標(biāo)準(zhǔn)體系。1982年，DO-178標(biāo)準(zhǔn)第一版發(fā)布，為開發(fā)機載軟件提供基本信息；隨之1985 年發(fā)布了關(guān)注需求的驗證和確認的DO-178A；1992 年美國航空無線電技術(shù)委員會（Radio Technical Commission for Aeronautics，RTCA）為支持數(shù)字計算機的機載系統(tǒng)和設(shè)備的研究工作提出的《機載系統(tǒng)和設(shè)備合格審查中軟件方面的考慮》（DO-178B[8]），DO-178B規(guī)定了軟件開發(fā)和驗證的原則，廣泛應(yīng)用于世界民用航空領(lǐng)域的適航審定過程，也是中國民用航空局批準(zhǔn)的民用航空機載設(shè)備和系統(tǒng)軟件的適航審查依據(jù)[9]。

然而，隨著軟件代碼復(fù)雜性的增加和新開發(fā)技術(shù)的出現(xiàn)，軟件代碼開發(fā)需要新的驗證和認證方法。因此，在2008年，業(yè)界和學(xué)術(shù)界共同建立了一套基于DO-178B的基礎(chǔ)上修訂的認證標(biāo)準(zhǔn)DO-178C，于2011 年正式發(fā)布，增加了對參數(shù)數(shù)據(jù)項的指南以及系列配套補充文檔的引用。

DO-178C標(biāo)準(zhǔn)構(gòu)建了一套基于目標(biāo)、面向過程的體系。如圖1 所示，DO-178C[6]標(biāo)準(zhǔn)把軟件生命周期分為軟件計劃過程、軟件開發(fā)過程和軟件綜合過程，針對軟件生命周期的每一個過程，定義了具體目標(biāo)、相關(guān)活動和輸出。

圖1 DO-178C軟件生命周期過程Fig.1 DO-178C software life cycle process

軟件計劃過程定義了軟件生命周期、軟件開發(fā)計劃和標(biāo)準(zhǔn)以及系統(tǒng)需求，用于指導(dǎo)軟件開發(fā)過程和軟件綜合過程。軟件開發(fā)過程策劃了軟件開發(fā)的活動過程，分為軟件需求過程、軟件設(shè)計過程、軟件編碼過程、集成過程。軟件綜合過程包括審定聯(lián)絡(luò)過程、軟件驗證過程、軟件質(zhì)量保證過程、軟件配置管理過程，貫穿軟件生存周期全過程，以此保障軟件活動過程中輸出正確并且受控可信。軟件驗證過程不僅策劃了軟件開發(fā)過程中的驗證過程，還對驗證過程的結(jié)果進行了驗證，即驗證的驗證，按照軟件計劃定義的方法和活動對軟件需求、軟件設(shè)計、軟件編碼和集成的輸出以及軟件驗證進行驗證的過程。

軟件驗證的主要方法包括評審、分析、軟件測試。評審和分析適用于軟件開發(fā)過程和軟件驗證過程的結(jié)果，測試針對軟件代碼進行動態(tài)評估，通過測試用例來運行軟件產(chǎn)品以驗證代碼是否滿足需求。當(dāng)需求無法通過測試用例測試時，可采用評審和分析的方法進行驗證。

因此根據(jù)DO-178C標(biāo)準(zhǔn)，采用各種驗證手段，以驗證的結(jié)果證明所驗證的對象是否滿足機載系統(tǒng)適航的要求，貫穿軟件生命周期的全過程，對應(yīng)于圖1 中的軟件需求過程、軟件設(shè)計過程、軟件編碼和集成過程以及軟件驗證過程，分別從基于需求、基于安全性分析、基于模型以及軟件驗證的測試四個方面，對軟件高層需求、軟件體系結(jié)構(gòu)的安全性設(shè)計和安全性需求、模型驅(qū)動的開發(fā)以及軟件驗證過程輸出結(jié)果進行測試驗證，研究了機載軟件測試驗證的方法，并對已有工作進行發(fā)展前景展望。

1 機載軟件測試環(huán)境

機載嵌入式軟件測試是一種特殊的軟件測試，旨在驗證發(fā)現(xiàn)盡可能多的機載軟件缺陷，提高機載軟件的可靠性。機載嵌入式軟件的實時性、高可靠性、嵌入式等特殊性，再加上其內(nèi)存不豐富、I/O 通道少、開發(fā)和測試環(huán)境專門化以及與硬件緊密結(jié)合的特點[10]，對其開展測試工作相對復(fù)雜且困難重重，通常在宿主機環(huán)境下開發(fā)，目標(biāo)機環(huán)境下運行，而目標(biāo)機測試環(huán)境下嚴(yán)重受到硬件的限制，難以對其進行大規(guī)模的嵌入式軟件測試，只能在條件允許的情況下通過仿真機測試發(fā)現(xiàn)盡可能多的錯誤并及時改進，這導(dǎo)致測試的工作量和難度大大提升。

嵌入式軟件測試環(huán)境需要支持交叉開發(fā)與測試，如何在開發(fā)環(huán)境（宿主機環(huán)境）和運行環(huán)境（目標(biāo)機環(huán)境）之間進行測試數(shù)據(jù)的交互成為了待解決的主要問題。通過在宿主機上運行測試管理系統(tǒng)和在目標(biāo)機上運行測試調(diào)度軟件的方式，來共同完成對機載軟件的測試，測試環(huán)境支持測試用例的加載，最終記錄和分析測試結(jié)果。

其中解決通信連接問題的方法就是宿主機和目標(biāo)機之間建立物理連接，通過串口通信或者以太網(wǎng)口進行基于TCP/IP協(xié)議的數(shù)據(jù)傳輸。如圖2所示，在宿主機方測試，根據(jù)測試用例庫以及事先制定好的測試計劃手動或自動批量加載相應(yīng)的測試用例并生成測試腳本，通過腳本解釋器實時解釋非實時生成的測試指令，將測試數(shù)據(jù)通過目標(biāo)機服務(wù)器發(fā)送至目標(biāo)機；在目標(biāo)機方測試，引入測試代理接收到指令后運行被測嵌入式軟件，將從測試代理獲取的測試結(jié)果數(shù)據(jù)進行分析顯示，最終生成相應(yīng)的測試報告[11]。

圖2 嵌入式軟件測試宿主機與目標(biāo)機總體系結(jié)構(gòu)Fig.2 Architecture of host and target machine in embedded software test

2 基于需求的測試

DO-178C聚焦于基于需求的測試，對應(yīng)于軟件開發(fā)過程中的軟件需求過程。根據(jù)需要選擇某種方式進行某項功能的測試，驗證軟件需求實現(xiàn)的正確性，以保證需求得到滿足并且只有需求得到滿足，保證沒有非預(yù)期的功能。

軟件需求測試的目的是驗證與系統(tǒng)需求的符合性、準(zhǔn)確性和一致性、與目標(biāo)機的兼容性、可驗證性、與標(biāo)準(zhǔn)的符合性以及可追蹤性。為了保證需求的質(zhì)量，航空電子軟件采用各種手段進行軟件需求驗證，包括非正式和正式的軟件需求同行評審、需求分析模型自動檢查、需求分析模型模擬仿真、需求原型確認和測試。

根據(jù)DO-178C的要求、被測軟件的重要度等級，確定測試需求，并根據(jù)項目實際情況制定詳細的測試計劃。在計劃中需要明確測試要求、測試環(huán)境、測試工作過程和內(nèi)容以及進度和人員安排；然后在計劃通過審核后設(shè)計測試用例，編寫測試說明，并進行審核，審核通過后執(zhí)行測試并記錄測試結(jié)果。

2.1 測試方法

如圖3所示，DO-178C提出了三種基于需求的測試方法：低層需求的測試、軟件集成測試、軟件/硬件集成測試。

圖3 基于需求的軟件測試過程Fig.3 Software testing process based on requirement

（1）低層需求的測試

該測試方法主要測試在宿主機上的軟件是否滿足低層需求。此方法檢查低層的功能，如算法的符合性和準(zhǔn)確性、循環(huán)操作、邏輯判定、輸入狀態(tài)的條件組合、丟失或失效的輸入數(shù)據(jù)、異常處理、計算順序等。

（2）軟件集成測試

該測試方法主要測試軟件組件之間的內(nèi)部交互關(guān)系，以及軟件體系結(jié)構(gòu)的需求實現(xiàn)的情況。此方法揭示的典型錯誤有變量和常量的初始化錯誤、參數(shù)傳遞錯誤、數(shù)據(jù)失效以及不當(dāng)?shù)氖录虿僮黜樞虻取?/p>

（3）軟件/硬件集成測試

該測試方法主要測試在目標(biāo)機上的軟件是否滿足高層需求，使用正常和異常的輸入，發(fā)現(xiàn)軟件在此執(zhí)行環(huán)境中運行時可能出現(xiàn)的問題。通過此方法可以驗證的區(qū)域包括：中斷處理、對軟硬件瞬變或失效的軟件響應(yīng)、資源占用問題、自檢測、軟硬件接口錯誤、控制回路行為、可加載軟件的機制以及軟件分區(qū)等。

針對測試標(biāo)準(zhǔn)，DO-178C 規(guī)定了必須完成的目標(biāo)，對于A級別軟件，DO-178C規(guī)定其低級測試需要滿足獨立性要求。若軟硬件集成測試和軟件集成測試已經(jīng)覆蓋軟件高層需求和軟件代碼時，則沒必要重復(fù)進行低層需求的測試。

基于需求的測試過程是遞進迭代的過程，通過測試的開發(fā)覆蓋所有的需求，運行測試覆蓋代碼并且不斷分析，如果有遺漏的需求或者代碼，則要增加相應(yīng)的測試直至所有需求和代碼都被覆蓋。

2.2 測試用例自動生成

如圖3所示，DO-178C提出了三種基于需求的測試方法：低層需求的測試、軟件集成測試、軟件/硬件集成測試。測試的關(guān)鍵環(huán)節(jié)是設(shè)計和生成有效的測試用例。測試用例是有效發(fā)現(xiàn)軟件中缺陷的最小執(zhí)行單元，為滿足特定需求目標(biāo)而編制的一組測試輸入數(shù)據(jù)、執(zhí)行條件以及預(yù)期結(jié)果的集合，以便測試某個程序是否滿足某個設(shè)定的需求。測試用例的設(shè)計需要滿足以下原則：完整性、準(zhǔn)確性、連貫性、可判定性、可操作性，通過測試用例進行測試的步驟為測試用例自動生成、測試用例執(zhí)行和結(jié)果分析[9]。測試用例的自動生成包括測試輸入數(shù)據(jù)的自動生成、預(yù)期結(jié)果、執(zhí)行步驟、前置條件等要素，目前的測試用例自動生成技術(shù)是測試領(lǐng)域的一個技術(shù)難點。測試用例自動生成技術(shù)為被測嵌入式軟件自動生成測試用例，自動生成測試輸入數(shù)據(jù)，顯著提高測試效率，實現(xiàn)測試自動化[12]。

基于需求的測試屬于黑盒測試，無需涉及程序內(nèi)部的細節(jié)，只關(guān)注軟件的規(guī)格說明的系統(tǒng)功能，不涉及程序的內(nèi)部邏輯結(jié)構(gòu)和內(nèi)部特效，是從輸入域到輸出域的一種映射，通常用于集成測試和系統(tǒng)測試。基于規(guī)格說明的測試從系統(tǒng)或模塊的需求出發(fā)來產(chǎn)生測試用例，從各個角度進行全面測試，包括基本需求功能、非法的輸入、邊界和極端情況、兼容性、用戶界面友好性、時間和空間性能等，設(shè)計方法有等價類劃分法、邊界值分析法、因果圖法、錯誤推測法。

20 世紀(jì)80 年代，Hall 等[13-14]提出了一種基于Z 規(guī)格語言的手工測試方法，需要專業(yè)和經(jīng)驗豐富的測試人員，測試效率低下；隨之蘭毓華等[15]結(jié)合Z 語言規(guī)格說明書添加預(yù)處理編譯器對輸入輸出的約束條件進行預(yù)處理，將關(guān)系線性謂詞轉(zhuǎn)換之后求解區(qū)域邊界點從而自動生成測試用例；Weyuker等[16]對形式化規(guī)格說明改進，用AND/OR表示規(guī)格說明中的條件，研究了一種基于防飛機碰撞系統(tǒng)需求布爾規(guī)格說明的測試用例數(shù)據(jù)自動生成的方法，但只適用于過程控制系統(tǒng)。

嵌入式軟件的實時性特點增加了測試用例的生成的困難，相同的輸入在不同的時間可能會有不同的輸出結(jié)果，并且嵌入式軟件是多任務(wù)并發(fā)運行的，傳統(tǒng)的軟件開發(fā)設(shè)計并不適應(yīng)此模式，因此引入了實時多任務(wù)（Design and Analysis of Real-Time Systems，DARTS）設(shè)計方法，結(jié)合規(guī)格說明的測試方法提出了一種基于DARTS 的實時嵌入式軟件的測試用例生成模型[17-18]。過程如圖4 所示，通過需求說明得到數(shù)據(jù)流圖，然后根據(jù)DARTS設(shè)計方法確定任務(wù)的規(guī)則對需求進行多任務(wù)劃分得到任務(wù)關(guān)系圖，使用Z語言對每個測試任務(wù)的需求進行形式化規(guī)格說明，產(chǎn)生每個任務(wù)的測試用例集，最終根據(jù)任務(wù)之間的關(guān)系對測試用例集進行優(yōu)化，減少冗余。

圖4 基于DART設(shè)計的嵌入式軟件測試用例生成模型Fig.4 Embedded software test case generation model based on DART design

隨著20 世紀(jì)90 年代人工智能的飛躍發(fā)展，研究傾向于將人工智能技術(shù)與自動化測試技術(shù)相結(jié)合。處于動態(tài)演化中的軟件會積累大量冗余的測試用例，在執(zhí)行回歸測試時可以復(fù)用測試用例，因此測試用例的生成問題轉(zhuǎn)化為測試用例路徑搜索的問題，大部分智能優(yōu)化搜索算法可以應(yīng)用于嵌入式軟件測試用例生成，常見的基于搜索的優(yōu)化算法例如遺傳算法、蟻群算法、粒子群算法、隨機算法和組合測試算法[19]?；谌斯ぶ悄芩惴ǖ臏y試用例自動生成中，選擇合適的元啟發(fā)式智能算法能夠大幅提高測試效率，在迭代過程中獲取反饋信息作用于生成模塊，使得測試用例的生成更加智能化，降低了時間和空間復(fù)雜度，是一個動態(tài)模型的過程。

最常用的是將遺傳算法應(yīng)用在航空機載軟件測試用例生成中。遺傳算法模仿的是自然界中生物遺傳的一個特性，將待測用例作為染色體編碼，優(yōu)勝劣汰產(chǎn)生最優(yōu)解序列。1996年Jones[20]通過實驗證明了遺傳算法在測試用例自動生成方面的有效性，所需要的測試用例數(shù)量明顯比隨機算法少。遺傳算法能夠較好地在測試用例種群中產(chǎn)生大量次優(yōu)解并且可以經(jīng)過進化后成為最優(yōu)解，但是迭代次數(shù)增加會降低解的多樣性，速度變慢而影響了算法的性能。馮廷智[21]基于遺傳算法的測試用例優(yōu)先級排序?qū)娇諜C載軟件進行測試，通過將飛機機載環(huán)控系統(tǒng)綜合控制器軟件貨艙供氣旁路調(diào)節(jié)閥控制率計算功能的UML 活動圖作為輸入，統(tǒng)一轉(zhuǎn)化為控制流圖，進行編碼后經(jīng)過選擇、交叉、變異搜索適應(yīng)度最高的個體模塊進行優(yōu)先測試，證明了該方法可被用于機載軟件測試用例的生成。

2.3 小結(jié)

機載軟件測試特殊的操作運行平臺以及嚴(yán)格的測試標(biāo)準(zhǔn)，嵌入式軟件的測試用例更是需要專業(yè)的測試人員針對性地專門設(shè)計，測試用例設(shè)計的水平對測試效率及測試結(jié)果影響重大。測試用例自動生成包括測試輸入數(shù)據(jù)的自動生成、預(yù)期結(jié)果、執(zhí)行步驟、前置條件等要素。

隨著時間推移過程中機載軟件項目功能的動態(tài)演化積累了龐大的測試文檔。大多數(shù)測試數(shù)據(jù)以文檔等非結(jié)構(gòu)化數(shù)據(jù)的形式存在，航空設(shè)備進行回歸測試或者一些類似的需求測試時，測試人員又要花費大量額外的精力來搜索和查閱原始文檔，甚至重復(fù)設(shè)計了測試用例，增加了測試用例集的管理和維護成本，極大影響了測試工作的效率和質(zhì)量。

目前測試用例自動生成技術(shù)是測試領(lǐng)域的一個技術(shù)難點，特別是根據(jù)軟件各種需求生成測試用例。大部分技術(shù)是測試輸入數(shù)據(jù)的自動生成，整個測試用例的生成主要還是依靠人工編寫，相關(guān)自動化技術(shù)和工具僅為輔助作用。

因此基于智能算法的測試用例自動生成方法應(yīng)運而生，將此問題轉(zhuǎn)化成了基于搜索的問題，通過從已有的測試用例中找出最符合當(dāng)前需求的測試用例序列，測試用例復(fù)用技術(shù)在機載軟件測試工具中應(yīng)用已經(jīng)成為目前研究的熱點，再結(jié)合智能優(yōu)化算法解決當(dāng)搜索空間的狀態(tài)爆炸式增長時搜索進程如何快速收斂的問題。

未來研究方向可著重通過人工智能技術(shù)，對機載嵌入式軟件需求文檔進行智能分析，將非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)化成結(jié)構(gòu)化數(shù)據(jù)，該領(lǐng)域需要在積累大量的經(jīng)驗下才能逐漸完善，目前該領(lǐng)域仍在不斷探索中，還沒有完全成熟的方案。

3 基于安全性分析的測試

DO-178C 中基于安全性分析的測試過程對應(yīng)于軟件開發(fā)過程中的軟件設(shè)計過程。根據(jù)軟件失效帶來的危害等級以及不同安全需求，航空電子分為A、B、C、D、E 五個等級，DO-178C 只涉及A、B、C、D 四個等級的適航要求。對于A 級軟件的定義為這類軟件的異常狀態(tài)將會導(dǎo)致系統(tǒng)功能的失效并給飛機帶來災(zāi)難性的失效狀態(tài)。

軟件的安全性，是指軟件系統(tǒng)經(jīng)過運行之后不存在引起系統(tǒng)危害行為的狀況出現(xiàn)[22]，基于安全性的機載軟件測試技術(shù)以軟件需求模型和安全性分析為基礎(chǔ)，主要分為以下5個方面：危害分析[23]、軟件安全需求的提取與分析[24]、軟件安全性設(shè)計[25]、軟件安全驗證和確認[26]、軟件安全認證及標(biāo)準(zhǔn)[27]。安全性測試旨在快速降低由軟件故障導(dǎo)致的系統(tǒng)故障風(fēng)險，并確保風(fēng)險被消除或控制在可接受的風(fēng)險水平，它主要包括安全性測試計劃、安全性測試設(shè)計、安全性測試執(zhí)行及安全性測試評估四個階段[28]。

機載軟件安全分析的框架可以分為三個部分：機載軟件安全需求的獲取和規(guī)范；面向安全標(biāo)準(zhǔn)的軟件開發(fā)過程以及機載軟件安全要求的驗證[29]。徐丙鳳等[30]使用系統(tǒng)建模語言SysML建立具有安全特征的系統(tǒng)靜態(tài)結(jié)構(gòu)模型，并將其轉(zhuǎn)化為塊依賴圖進行精確地形式化描述，驗證面向適航認證的模型驅(qū)動機載軟件構(gòu)件的安全性。

由于需求可追蹤是安全領(lǐng)域標(biāo)準(zhǔn)的基本要求，也是安全性分析與保障的重要前提，王飛等[31]提出了一種基于謂詞邏輯的需求追蹤方法，通過兩種廣泛使用的標(biāo)準(zhǔn)語言SysML 和嵌入式系統(tǒng)體系結(jié)構(gòu)分析與設(shè)計語言AADL[32]分別對系統(tǒng)需求與設(shè)計進行建模，基于語義模型得出追蹤關(guān)系的自動推導(dǎo)和檢驗規(guī)則，用以建立精確、完整的需求追蹤關(guān)系，以建立準(zhǔn)確、完整的需求跟蹤關(guān)系，有效支持嵌入式系統(tǒng)的安全分析和系統(tǒng)維護與演化；石嬌潔等[33]提出了一種基于模型驅(qū)動架構(gòu)的SysML/MARTE狀態(tài)機系統(tǒng)安全分析與驗證方法；曹德建等[34-35]提出了將故障樹分析擴展到SysML活動圖模型的方法和故障擴展SysML 活動圖的概念，統(tǒng)一了系統(tǒng)的安全需求分析模型和行為模型。

在復(fù)雜的系統(tǒng)中通常會用到表1所示的安全性方法[36]。

表1 安全性分析方法總結(jié)Table 1 Summary of safety analysis methods

3.1 功能危險分析（FHA）

功能危險分析（Functional Hazard Analysis，F(xiàn)HA）是一種安全分析方法，系統(tǒng)地、全面地檢查產(chǎn)品的各種功能，識別各種功能故障狀態(tài)，并根據(jù)其嚴(yán)重程度進行分類，用來確立系統(tǒng)安全性設(shè)計目標(biāo)，幫助決定設(shè)計方案的可接受性，發(fā)現(xiàn)潛在的問題和所需的設(shè)計更改，確定所需的進一步分析的要求及范圍。在軟件系統(tǒng)設(shè)計早期階段中FHA 提供了危險鑒別方法，目的在于減少由更改或改裝而帶來的昂貴費用，此方法不需要考慮系統(tǒng)的具體模型架構(gòu)，從功能角度分析不同形式的系統(tǒng)設(shè)備軟件。

陸中等[37]分析了在民用飛機適航符合性驗證中的應(yīng)用的各種安全性分析方法以及輸入輸出信息，主要考慮的因素包括所有工作狀態(tài)和模式下可能的功能；所有功能失效模式、危險組成部分，如失控、意外工作或不受指令地工作等；具有冗余或者被冗余影響的系統(tǒng)；每一個系統(tǒng)的工作狀態(tài)，包括在不正常狀態(tài)下的意外工作；所有功能和實際系統(tǒng)的相互關(guān)系；外部因素條件以及操作和維修中的人為差錯的人為因素[38]。

3.2 故障模式及影響分析（FMEA）

故障模式及影響分析（Failure Mode and Effects Analysis，F(xiàn)MEA）是指在產(chǎn)品設(shè)計過程中，通過分析各組成單元的潛在失效模式及其對產(chǎn)品功能的影響，從而提高產(chǎn)品可靠性的設(shè)計方法[39]。FMEA是一種系統(tǒng)的、自下而上的方法，用于識別系統(tǒng)、單元和功能的故障模式，并確定它們對上層的影響，可以在系統(tǒng)的任何級別上執(zhí)行（如零部件）。

通過FMEA 可以確保考慮周全所有零部件的各種故障模式和影響，找出對系統(tǒng)故障影響較大的部件和故障模式，分析它們的影響程度，并提出各種危險的預(yù)防措施。通常用來分析單故障的故障影響，由于FMEA分析需考慮產(chǎn)品結(jié)構(gòu)組成等因素，因此只能在系統(tǒng)的詳細設(shè)計階段進行。

3.3 故障樹分析（FTA）

故障樹分析（Fault Tree Analysis，F(xiàn)TA）關(guān)注的是導(dǎo)致系統(tǒng)失效的故障行為，以系統(tǒng)的一個具體故障為分析對象，分析可能導(dǎo)致故障的各種因素，確定發(fā)生故障的各種可能原因，并通過發(fā)現(xiàn)系統(tǒng)的設(shè)計錯誤和安全隱患，用于指導(dǎo)邏輯門等符號直觀地描述故障與故障成因之間的邏輯關(guān)系，從而提前軟件設(shè)計和后期維護。

故障樹分析主要包括定性分析和定量分析。定性分析是找出導(dǎo)致頂層事件的所有可能的失效模式，分析各類失效的風(fēng)險，定位安全薄弱環(huán)節(jié)，安排預(yù)防措施避免失效。定量分析確定了每個基本事件的發(fā)生概率，并計算出頂層事件的發(fā)生概率，作為系統(tǒng)安全評估的評分標(biāo)準(zhǔn)之一，為系統(tǒng)安全優(yōu)化提供科學(xué)依據(jù)[40]。

3.4 共因故障分析（CCA）

共因故障是由于空間環(huán)境、設(shè)計以及人的因素所造成的失誤，其中引發(fā)故障不是獨立的事件，可能由于某種單一的共同原因，造成多個同時故障，復(fù)雜系統(tǒng)通常采用余度設(shè)計來提高其可靠性，共因故障的存在使得冗余系統(tǒng)的可靠性降低，共因故障分析（Common Cause Analysis，CCA）由此產(chǎn)生。CCA 包括特殊風(fēng)險分析（Particular Risks Analysis，PRA）、共模故障分析（Common Mode Analysis，CMA）和區(qū)域安全性分析（Zonal Safety Analysis，ZSA）三種分析方法。

PRA主要分析系統(tǒng)外事件或因素對系統(tǒng)的影響，如泄漏物、飛禽撞擊、雷電、高強度輻射等，是造成共因失效的重要原因?？傮w分析過程是為待研究的具體風(fēng)險逐一建立合適的失效模式，確定受影響的區(qū)域，并審查具體風(fēng)險的后果[41]。

CMA 是一種用于復(fù)雜系統(tǒng)可靠性、安全性和風(fēng)險性評價的方法，是故障模式與影響分析和故障樹分析的補充，分析共因事件對余度設(shè)計影響的重要方法，主要分析故障樹分析中“與門”輸入事件的獨立性，CMA 分析內(nèi)容涵蓋了設(shè)計、制造和維修失誤以及相同軟硬件故障等方面。

ZSA 主要分析設(shè)備安裝和故障對相鄰系統(tǒng)或結(jié)構(gòu)的影響，避免相鄰系統(tǒng)之間的相互干擾，確保系統(tǒng)滿足安全要求。ZSA只能在詳細設(shè)計階段進行，是抑制共因失效產(chǎn)生的重要措施。主要判斷系統(tǒng)各個區(qū)域的物理功能是否相關(guān)，明確系統(tǒng)的組成和結(jié)構(gòu)[42]。

3.5 小結(jié)

目前常規(guī)的安全性分析測試流程，大多是以機載軟件適航標(biāo)準(zhǔn)體系參照的。雖然國內(nèi)的機載軟件安全性測試研究工作有一定發(fā)展，但是發(fā)展相對滯后，安全性測試框架還比較零散，尚未形成系統(tǒng)的安全性測試框架體系，指導(dǎo)單類型的測試框架居多，但指導(dǎo)流程性質(zhì)的安全性測試活動的框架較少。

很多安全性問題需要在系統(tǒng)環(huán)境中才可能會被挖掘出來，仿真測試環(huán)境并不能徹底暴露出所有隱藏風(fēng)險，而且安全性測試框架不具有普遍性，自動化測試分析技術(shù)水平遠遠達不到測試標(biāo)準(zhǔn)，對于大型復(fù)雜的機載軟件的安全性分析難度較大且繁瑣。將來可依據(jù)當(dāng)前測試框架開發(fā)出具有普適性的安全性自動化測試分析工具，使其能夠與測試用例生成模塊相關(guān)聯(lián)，提高測試效率及覆蓋率。

4 基于模型的測試

DO-178C 中基于模型的測試過程對應(yīng)于軟件開發(fā)過程中的軟件編碼和集成過程。模型是軟件生命周期數(shù)據(jù)的一種抽象描述方式，用來更好地支持軟件開發(fā)過程和軟件驗證過程。不同的軟件系統(tǒng)采用合適的方法自動生成測試用例，隨著軟件面向?qū)ο蟮拈_發(fā)思想封裝、繼承、多態(tài)性的出現(xiàn)，面向?qū)ο蟮臏y試用例也隨之而來[43]。面向?qū)ο蟮臏y試用例的生成方法根據(jù)程序的內(nèi)部結(jié)構(gòu)和形式化規(guī)范分為基于外部行為和內(nèi)部結(jié)構(gòu)，基于外部行為就是根據(jù)類與類之間的外部接口，而基于內(nèi)部結(jié)構(gòu)則是以模型為基礎(chǔ)，描述軟件的內(nèi)部作為。根據(jù)軟件結(jié)構(gòu)模型和行為模型就可以生成測試用例，基于各種測試模型的測試用例有效提高了測試的效率，典型的模型有：有限狀態(tài)機FSM（Finite State Machine）、統(tǒng)一建模語言UML（United Modeling Language）模型、系統(tǒng)建模語言SysML（System Modeling Language）模型和Markov（馬爾科夫）鏈模型。如圖5 所示為測試模型建模過程。

圖5 基于模型的測試用例設(shè)計過程Fig.5 Design process of test case

4.1 FSM測試模型

基于有限狀態(tài)機FSM 的測試模型[44]是表示有限個狀態(tài)以及在這些狀態(tài)之間的轉(zhuǎn)移和動作等行為的數(shù)學(xué)模型，當(dāng)前狀態(tài)影響可能的輸入數(shù)據(jù)，將測試輸入數(shù)據(jù)表示為一個序列的輸入，即利用圖的遍歷算法自動產(chǎn)生，是基于一個狀態(tài)轉(zhuǎn)換的前提下生成測試用例模型。但是目前機載嵌入式軟件十分復(fù)雜，所以需要表示的狀態(tài)機也很復(fù)雜，工作量比較大，而且生成的測試用例的數(shù)目也會達到一個上限值。

4.2 UML測試模型

有限統(tǒng)一建模語言UML是面向?qū)ο筌浖囊粋€通用的標(biāo)準(zhǔn)可視化建模語言，逐漸在機載軟件開發(fā)過程中應(yīng)用，侯晨光[45]針對機載設(shè)備軟硬件一體化測試剖面按照航空電子系統(tǒng)執(zhí)行任務(wù)剖面分層設(shè)計，分為任務(wù)層、狀態(tài)層和用例層，不同層次采用不同的UML 視圖可視化和編制各種開發(fā)文檔中各種復(fù)雜的說明信息，將系統(tǒng)架構(gòu)從不同角度建模從而形成豐富的視圖。UML包括靜態(tài)圖和動態(tài)圖兩大類圖，根據(jù)不同的測試目的從而選擇不同的UML 圖形，然而功能性測試關(guān)注的大部分是系統(tǒng)模塊之間進行交互的狀態(tài)信息。

Martin 等[46]提出在實時嵌入式系統(tǒng)開發(fā)中完全適合使用UML 模型，其中狀態(tài)圖作為嵌入式軟件測試中常用的模型圖，是有限狀態(tài)機的擴展，通過采用有效的動態(tài)建模描述狀態(tài)圖的狀態(tài)轉(zhuǎn)移過程生成測試用例的序列。因此殷永峰等[47]提出了一種基于UML的嵌入式軟件測試用例生成方法，選取典型的航空電子設(shè)備慣導(dǎo)系統(tǒng)軟件靜態(tài)和動態(tài)建模并將生成的測試用例采用擴展標(biāo)記語言格式存儲。然而UML在嵌入式實時系統(tǒng)上缺少一致性原則，操作性差，建模容易不完整導(dǎo)致安全缺陷問題。

4.3 SysML測試模型

系統(tǒng)建模語言SysML 是目前最新的標(biāo)準(zhǔn)建模語言，是對系統(tǒng)工程領(lǐng)域中的統(tǒng)一建模語言UML 的完善和擴展，提供了活動圖形表示，支持指定、分析、設(shè)計和驗證復(fù)雜的系統(tǒng)中的硬件、軟件、信息、人員、程序和設(shè)施。

SysML 活動圖擴展了傳統(tǒng)的UML 活動圖，2015 年黃傳林[48]在面對嵌入式實時系統(tǒng)中安全性驗證中提出了基于擴展的MARTE（Modeling and Analysis of Realtime and Embedded Systems）時鐘語義信息到SysML活動圖的方法，通過結(jié)合嵌入式實時緊急呼叫系統(tǒng)驗證了可行性，彌補了UML 系統(tǒng)建模的不足。目前關(guān)于使用SysML 活動圖生成測試用例序列的研究較少，對測試用例序列的優(yōu)先級排序方面也較少研究，需要克服SysML 半形式化語言的缺陷，并且不能自行分析和驗證。曹偉芳[49]使用SysML活動圖對IMA系統(tǒng)中的飛機導(dǎo)航系統(tǒng)和飛機著陸過程的活動圖進行建模驗證，自動化生成集成測試序列并提出最佳快速覆蓋方法對優(yōu)先級排序進行判定。

4.4 Markov鏈測試模型

馬爾科夫Markov 鏈模型基于統(tǒng)計學(xué)理論，實際上是有限狀態(tài)機的一種特殊情況，此模型通過包含的概率信息得到狀態(tài)之間的遷移概率來自動地產(chǎn)生測試用例序列，常用于衡量軟件可靠性測試，通過實例證明了將Markov鏈模型運用在嵌入式可靠性測試中可以有效地評估可靠性，Markov 過程中任何一個事件的發(fā)生都只與當(dāng)前狀態(tài)有關(guān)，一個測試用例對應(yīng)一個狀態(tài)，從而形成一個基于馬爾科夫鏈模型的完整測試用例集[50]。

在基于動態(tài)故障樹模型的測試用例設(shè)計中[51]分析動態(tài)故障樹時利用Markov對樹進行劃分從而獲取最小割集，即最終達到測試用例生成的目的，然而考慮到嵌入式系統(tǒng)的復(fù)雜性，建立動態(tài)故障樹存在一定難度。因此嵌入式軟件的實際使用狀況可以使用帶標(biāo)記的Markov鏈進行描述，測試用例和測試數(shù)據(jù)的等價類信息可以通過任務(wù)剖面模型來獲取，從而自動生成測試用例，大大減少測試人員的工作量，提高測試效率[52]。

4.5 小結(jié)

基于模型的測試是根據(jù)系統(tǒng)的設(shè)計模型的邏輯關(guān)系生成軟件測試用例，盡可能提高軟件測試的充分性，將測試工作提前到開發(fā)過程早期。

通過模型可產(chǎn)生大量的測試用例，提高軟件的易測性。因此一套高效的航空機載軟件測試模型，需要根據(jù)航空機載軟件任務(wù)書或需求規(guī)格說明文件提出的測試需求，建立需求追蹤關(guān)系模型圖，最后進行測試用例的設(shè)計，最終獲得好的測試結(jié)果和全面測試覆蓋率。

航空機載軟件的測試模型需要不斷地融合構(gòu)建其他更多的通用測試模型，推廣到各種機載嵌入式軟件系統(tǒng)中，不斷優(yōu)化使其具有通用性和可擴展性。

5 軟件驗證的測試

DO-178C 中軟件驗證的測試過程對應(yīng)于軟件綜合過程中的軟件驗證過程，此過程貫穿軟件生命周期全過程。根據(jù)對軟件驗證過程輸出結(jié)果的驗證中，列出了如下9個目標(biāo)。

（1）測試規(guī)程正確。

（2）測試結(jié)果正確，并且解釋差異性。

（3）實現(xiàn)對高級需求的測試覆蓋。

（4）完成對低級需求的測試覆蓋。

（5）完成對軟件結(jié)構(gòu)（MC/DC）的測試覆蓋。

（6）完成對軟件結(jié)構(gòu)（判定覆蓋）的測試覆蓋。

（7）完成對軟件結(jié)構(gòu)（語句覆蓋）的測試覆蓋。

（8）完成對軟件結(jié)構(gòu)（數(shù)據(jù)耦合DC和控制耦合CC）的測試覆蓋。

（9）驗證無法追溯到源代碼的附加代碼。

在機載軟件開發(fā)中，驗證活動是貫穿軟件生命周期的整體過程，而軟件測試是驗證的關(guān)鍵，劃分為靜態(tài)審查和分析，需求覆蓋測試，結(jié)構(gòu)覆蓋測試以及數(shù)據(jù)耦合和控制耦合測試，以滿足不同的軟件級別要求。

5.1 靜態(tài)審查和分析

靜態(tài)審查和分析是指針對需求說明、設(shè)計文件等文檔和源程序，不運行程序代碼的情況下，通過形式化驗證技術(shù)如模型檢測、符號執(zhí)行、定理證明、約束求解等掃描代碼達到程序分析的目的，驗證代碼是否滿足規(guī)范要求。DO-333是對機載軟件標(biāo)準(zhǔn)DO-178C中關(guān)于形式化方法的補充，為機載軟件開發(fā)過程中形式化方法的使用提供指導(dǎo)。通過形式化方法可以對機載安全等級依賴的合法性[53]進行分析。陳光穎等[54]基于DO-333使用模型檢驗對飛控系統(tǒng)中的襟縫翼控制單元進行驗證和分析，判斷其是否滿足DO-178C 的相關(guān)要求。面向適航標(biāo)準(zhǔn)采用形式化方法對機載襟縫翼控制單元進行安全性分析。黃懌豪等[55]提出了一種面向航空領(lǐng)域的機載控制軟件需求建模形式化工程方法ACSDL-MV，包含了演化形式化規(guī)約構(gòu)建和需求規(guī)約確認。

5.1.1 測試規(guī)程測試

針對DO-178C 的第一個目標(biāo)（測試規(guī)程正確），一般采用同行評審的方式對測試規(guī)程進行驗證，同行評審的對象是軟件需求文檔、模型和數(shù)據(jù)。測試用例的評審和測試規(guī)程的評審是同步進行的。

對測試用例的評審主要是檢查測試用例是否正確并且充分測試了需求，每個測試用例都應(yīng)該包含對需求的追蹤、測試目標(biāo)、測試輸入、測試條件、期望結(jié)果和通過判定準(zhǔn)則等信息。

對測試規(guī)程的評審主要檢查以下3個方面。

（1）測試配置信息是否齊全，包括測試規(guī)程版本，測試配置文件版本、所需環(huán)境配置以及對應(yīng)版本等必需信息。

（2）測試規(guī)程的測試步驟是否與測試用例相符，正確實現(xiàn)了測試用例要求。如果是可執(zhí)行的測試規(guī)程，則提交評審時最好有實際運行結(jié)果，以便檢查測試規(guī)程本身不包含語法錯誤，可以正確運行。

（3）測試規(guī)程的設(shè)計和實現(xiàn)是否和軟件驗證計劃SVP相符。

測試規(guī)程評審的步驟和其他需求評審、代碼評審類似，也需要有檢查單、評審計劃和評審記錄等。測試規(guī)程評審人員包括除了作者以外的測試人員，還應(yīng)邀請軟件開發(fā)人員和質(zhì)量保證人員參加。

5.1.2 測試結(jié)果測試

針對DO-178C 的第二個目標(biāo)（測試結(jié)果正確），一般采用同行評審的方式對測試結(jié)果進行驗證。測試規(guī)程的執(zhí)行結(jié)果放入測試結(jié)果文件中，評審主要審查以下3個方面。

（1）測試結(jié)果文件內(nèi)容是否完整，包括被測軟件、硬件和設(shè)備等信息；測試執(zhí)行人、測試時間信息。

（2）測試規(guī)程是否正確執(zhí)行，每個測試用例都被執(zhí)行并且表明是否通過。

（3）如果測試結(jié)果表明和期望不符，則要說明不符的原因。如果是代碼或需求問題，則要有說明，并指向相應(yīng)的問題報告。

王泉等[56]根據(jù)嵌入式平臺軟件的特點提出一種基于Polyspace 的靜態(tài)分析和測試方法，結(jié)合Polyspace 測試工具和人工進行靜態(tài)分析，同時借助SVN 配置管理工具進行同行評審，有效提高了軟件質(zhì)量。

5.2 需求覆蓋測試

針對DO-178C的第三、第四個目標(biāo)實現(xiàn)了軟件高、低層需求的測試覆蓋，通常采用驗證方法中的分析方法實現(xiàn)，對需求測試的覆蓋度進行進一步的驗證。

在測試規(guī)程評審階段，就包含了對測試用例是否完整覆蓋測試需求的審查，在這一階段確保測試用例所追蹤的需求被完整、充分地進行了測試。在所有測試用例開發(fā)結(jié)束后，還應(yīng)對所有需求進行一次整體的檢查，確保沒有遺漏。在這個過程中，要生成需求和測試用例之間的追蹤表，作為分析的結(jié)論依據(jù)。

5.3 結(jié)構(gòu)覆蓋測試

針對DO-178C 的第五、第六和第七個目標(biāo)實現(xiàn)了軟件結(jié)構(gòu)覆蓋測試。結(jié)構(gòu)覆蓋是針對軟件代碼的覆蓋分析，包括源代碼、目標(biāo)碼和可執(zhí)行代碼，屬于白盒測試，關(guān)注程序內(nèi)部的代碼，主要是根據(jù)程序內(nèi)部邏輯結(jié)構(gòu)來設(shè)計測試用例，通常用于單元測試。DO-178C關(guān)于不同等級的軟件有不同的軟件結(jié)構(gòu)覆蓋要求，將機載軟件分為A、B、C、D、E 五個級別，并從軟件規(guī)劃、軟件開發(fā)、軟件驗證、軟件配置管理、軟件質(zhì)量保證和軟件適航認證六個方面對不同級別機載軟件的開發(fā)過程提出了不同程度的要求[57]。在DO-178C 標(biāo)準(zhǔn)對于A 級軟件的定義為這類軟件的異常狀態(tài)將會導(dǎo)致系統(tǒng)功能的失效并給飛機帶來災(zāi)難性的失效狀態(tài)?；谛枨蟮臏y試已經(jīng)完成，并且進入配置庫以后，才可以進行結(jié)構(gòu)覆蓋分析。

測試覆蓋是指測試用例相對某個特定的覆蓋準(zhǔn)則而言的覆蓋情況，是用來度量測試完整性的手段。覆蓋率是指至少被覆蓋一次的測試對象數(shù)量占測試對象總數(shù)的比例。覆蓋分析主要評估軟件測試用例及其測試活動的完備性，間接地可用來評估軟件需求的完整性，從而保證機載軟件測試活動達到相應(yīng)等級的適航要求。

目前結(jié)構(gòu)化測試有三種測試用例生成的方法：隨機測試用例生成方法、面向目標(biāo)的測試用例生成方法和面向路徑的測試用例生成方法[58]。

隨機測試用例的生成實現(xiàn)簡單，在輸入域內(nèi)隨機選取測試用例，即利用隨機算法生成的測試數(shù)據(jù)作為輸入執(zhí)行被測軟件[59]，這種方法簡單易實現(xiàn)但是缺乏針對性，難以覆蓋到整個軟件的測試范圍。面向目標(biāo)的測試用例生成方法依據(jù)的是程序的控制流信息，測試用例生成時依據(jù)分支函數(shù)的極小化原則[60]，這種方法無關(guān)于路徑的選擇，可以達到語句覆蓋、分支覆蓋級別，但在結(jié)構(gòu)測試覆蓋準(zhǔn)則中覆蓋強度依舊是較低的，只有當(dāng)程序中每一條路徑都被測試了，才屬于全面的測試。

大部分軟件測試的研究集中在面向路徑的測試，可分為基于符號執(zhí)行和基于實際程序執(zhí)行兩類[61]。單元測試中的各種控制流測試過程中，語句覆蓋SC、分支覆蓋DC、條件覆蓋CC、條件/判定覆蓋CDC、路徑覆蓋PC、修正條件/判定覆蓋MC/DC等問題可視為面向路徑的測試用例生成問題。在程序控制流圖的基礎(chǔ)上，通過分析控制構(gòu)造的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，從而設(shè)計測試用例的方法。這種方法可以很方便地得出所需測試用例的最小值，有效地減輕測試人員的勞動強度，提高測試的效率和質(zhì)量，節(jié)省軟件開發(fā)的成本。

在航空類軟件的測試中，滿足的覆蓋率標(biāo)準(zhǔn)為最高覆蓋強度的修正條件/判定覆蓋（Modified Condition/Decision Coverage，MC/DC），百分百確保解決掉所有將導(dǎo)致航空器災(zāi)難性故障的軟件問題[62]，這需要設(shè)計足夠多的測試用例，保證判定中每個條件的所有可能結(jié)果至少出現(xiàn)一次，每個判定本身的所有可能結(jié)果也至少出現(xiàn)一次；每個程序模塊的入口和出口至少要被調(diào)用一次，并且每個條件都顯示能獨立影響判定結(jié)果[63]。然而，無論哪種結(jié)構(gòu)化測試方法，即使其覆蓋率達到100%，也不能保證暴露所有隱藏的程序缺陷。

如圖6所示，嵌入式軟件的測試用例需全面覆蓋宿主機、目標(biāo)機，首先通過插樁分析器對源代碼進行插樁，以便后續(xù)記錄測試用例覆蓋的路徑信息；然后對插樁后的程序源代碼編譯生成可執(zhí)行程序后，根據(jù)MC/DC 覆蓋補充得到的測試用例運行程序后便可采集分析覆蓋信息；最后得到相應(yīng)的覆蓋率信息并生成測試報告。在嵌入式軟件的測試過程中，由于測試所需要的信息在目標(biāo)機上才會產(chǎn)生，所以必須通過一定的物理邏輯連接傳輸?shù)剿拗鳈C上[64-65]。

圖6 嵌入式軟件覆蓋測試過程Fig.6 Coverage test process of embedded software

5.4 數(shù)據(jù)耦合和控制耦合覆蓋測試

針對DO-178C的第八個目標(biāo)實現(xiàn)DO-178C對A級軟件有數(shù)據(jù)耦合和控制耦合分析的要求，同時DO-178C對控制耦合和數(shù)據(jù)耦合進行了定義。

數(shù)據(jù)耦合是指一個軟件組件對不完全受制于自己的數(shù)據(jù)的依賴，一個模塊訪問另一個模塊時通過數(shù)據(jù)參數(shù)（不是控制參數(shù)、公共數(shù)據(jù)結(jié)構(gòu)或外部變量）交換輸入輸出信息?？刂岂詈鲜且粋€軟件組件影響另一個軟件部件運行的方式或程度，一個模塊通過傳送開關(guān)、標(biāo)志和名字等信息控制選擇另一個模塊的功能。

耦合的實質(zhì)是單一接口上選擇多功能模塊中的某項功能。模塊間的耦合越緊密，系統(tǒng)越復(fù)雜，設(shè)計、編碼、測試和維護的成本越高，因此對安全級別高的軟件進行數(shù)據(jù)耦合和控制耦合的分析，使模塊間的耦合最小化，相互依賴性最小化，保證模塊間的獨立性，模塊間聯(lián)系簡單，發(fā)生在某一處的錯誤傳播到整個系統(tǒng)的可能性越小。耦合關(guān)系是衡量軟件架構(gòu)可靠性的重要指標(biāo)，對于高安全性和高可靠性的機載軟件而言，數(shù)據(jù)耦合和控制耦合分析更尤為重要。

數(shù)據(jù)耦合和控制耦合采用評審、分析、測試三種驗證方法結(jié)合的方式，在開發(fā)過程中通過評審和分析方法確保軟件架構(gòu)的一致性，驗證源代碼與軟件架構(gòu)的符合性，通過測試方法說明數(shù)據(jù)耦合和控制耦合關(guān)系得到正確運行，分析確保所有的數(shù)據(jù)耦合和控制耦合關(guān)系得到覆蓋?；贒O-178C的數(shù)據(jù)耦合和控制耦合分析的具體步驟如下：

（1）根據(jù)軟件架構(gòu)，識別軟件部件之間的耦合關(guān)系。

（2）對每個耦合關(guān)系，分析有哪些方面的耦合內(nèi)容/覆蓋準(zhǔn)則。

（3）對每個耦合內(nèi)容/覆蓋準(zhǔn)則，列出應(yīng)該覆蓋到的覆蓋點。

（4）通過分析、插樁、運行等手段，識別有哪些覆蓋點沒有覆蓋。

（5）對沒有覆蓋到的覆蓋點，分析問題，修改代碼或給出解釋。

（6）回歸，直到所有覆蓋點全部被覆蓋（或解釋）。

（7）形成數(shù)據(jù)耦合/控制耦合覆蓋的分析報告。

上海愛韋訊信息技術(shù)股份有限公司研發(fā)了耦合覆蓋分析工具——SA-Covalyzer軟件耦合覆蓋分析工具，實現(xiàn)軟件架構(gòu)的測試覆蓋分析，提高測試充分性，提供了一套完善的解決方案，支持軟件部件的定義，自動識別部件間的耦合關(guān)系，推薦適用的覆蓋準(zhǔn)則，針對覆蓋點進行低膨脹率的插樁，在測試過程中收集、累積和統(tǒng)計覆蓋情況，對未覆蓋到的情形進行輔助分析，并自動生成覆蓋分析報告。

5.5 小結(jié)

靜態(tài)審查和分析雖然不執(zhí)行源代碼，只是進行靜態(tài)掃描，執(zhí)行速度快效率高，但是存在一定的誤報，不能僅僅依靠工具或人工，只有結(jié)合靜態(tài)分析工具和人工分析才能真正有效提升軟件質(zhì)量。

DO-178C是基于過程控制對機載軟件進行管理，對如何進行覆蓋分析只進行了簡單的指南性的描述，對覆蓋分析的過程和實現(xiàn)并未提及。國內(nèi)進行基于DO-178C 的覆蓋分析的研究和實踐才剛起步，國內(nèi)機載軟件的軟件驗證活動，測試覆蓋都是一個較難解決的問題。工程經(jīng)驗證明，覆蓋分析難度大，成本高，完成基于需求的測試后進行覆蓋分析可以有效地節(jié)約軟件驗證成本。

DO-178C中所有驗證活動都是基于需求的，基于代碼結(jié)構(gòu)的測試難以滿足適航局方的要求。對于耦合覆蓋分析，DO-178C沒有給出明確的覆蓋準(zhǔn)則甚至沒有指導(dǎo)思想，只能依據(jù)項目需求、架構(gòu)以及耦合覆蓋分析的適航審定標(biāo)準(zhǔn)才能確定覆蓋準(zhǔn)則，普遍認為數(shù)據(jù)耦合和控制耦合的覆蓋分析測試是個難題，在國內(nèi)外的適航項目中屬于普遍的薄弱環(huán)節(jié)。

現(xiàn)有大部分工具通常只能實現(xiàn)粗略的耦合分析，如函數(shù)調(diào)用（控制耦合）、全局變量的讀寫異常（數(shù)據(jù)耦合）等。而實際工程中，部件間的耦合涵蓋了更細致、更復(fù)雜的內(nèi)容，如函數(shù)調(diào)用時的參數(shù)類型一致性、數(shù)據(jù)的先讀后寫和先寫后讀、數(shù)據(jù)的輪流寫入等，針對這一方面需要研發(fā)更多追求細節(jié)的耦合覆蓋分析工具。

6 總結(jié)

本文根據(jù)美國RTCA 制定的DO-178C 標(biāo)準(zhǔn)中的軟件生命周期從基于需求、基于模型、基于安全性分析以及軟件驗證的測試研究機載軟件的測試驗證方法，并進行了小結(jié)。以下是研究過程中發(fā)現(xiàn)的一些問題。

（1）機載嵌入式軟件測試中測試用例自動方法是通過在宿主機上運行測試管理系統(tǒng)和在目標(biāo)機上運行測試調(diào)度軟件的方式，來共同完成對機載軟件的測試，測試環(huán)境支持測試用例的加載，最終記錄和分析測試結(jié)果。測試環(huán)境相對于一般商用軟件較為特殊，交叉開發(fā)軟件的測試較為困難。

（2）機載航電系統(tǒng)經(jīng)歷數(shù)字式、分布式、綜合式三大階段，對于不同的階段有不同的測試方法，目前大多數(shù)都是綜合航電系統(tǒng)IMA。大多數(shù)航電系統(tǒng)中軟件測試驗證仍然停留在傳統(tǒng)架構(gòu)下，測試過程中IMA 系統(tǒng)硬件環(huán)境資源有限，缺乏目標(biāo)機測試環(huán)境，即使存在目標(biāo)機環(huán)境也會被占用而其他人員無法使用，導(dǎo)致資源的浪費，測試效率低下。

（3）從安全性分析方面對機載軟件測試有助于發(fā)現(xiàn)軟件的隱藏風(fēng)險，采用傳統(tǒng)的安全性分析方法目前更多的是關(guān)注機載軟件的系統(tǒng)層面，僅僅分析了故障危害過程，缺乏針對機載軟件的特征而采用合適的故障危害分析方法，對于其他階段無法簡單套用此分析方法。

（4）國際標(biāo)準(zhǔn)過于抽象化不易理解，與國內(nèi)機載系統(tǒng)的結(jié)合不太匹配，國內(nèi)機載軟件測試的標(biāo)準(zhǔn)體系的制定起步較晚并且缺乏完善性，2008 年GJB5000A—2008《軍用軟件研制能力成熟度模型》才被提出，此標(biāo)準(zhǔn)適用范圍過于廣泛以至于對軟件驗證的細節(jié)方面不明確詳細，并且更注重于軟件開發(fā)過程逐步發(fā)展完善，此標(biāo)準(zhǔn)更適用于機載軟件開發(fā)過程而不適合軟件驗證審定。

在實際的測試工作中，無論采用什么樣的測試方法，都應(yīng)該盡早地進行測試，越早發(fā)現(xiàn)問題，軟件開發(fā)的成本越低。研究面向適航標(biāo)準(zhǔn)的機載軟件測試驗證方法過程中，總結(jié)了一些發(fā)展研究建議。

（1）在現(xiàn)代航空領(lǐng)域中，現(xiàn)代飛行器系統(tǒng)開始采用了綜合模塊化航電系統(tǒng)（Integrated Modular Avionics，IMA）架構(gòu)，此構(gòu)架系統(tǒng)表現(xiàn)出多任務(wù)、綜合化、模塊化、統(tǒng)一網(wǎng)絡(luò)、高度集成的特點。隨著IMA 軟件在系統(tǒng)中占比逐漸增加，分布式測試平臺可為IMA 軟件測試提供有力保障，目前平臺僅支持ARINC653 標(biāo)準(zhǔn)操作系統(tǒng)，可就提高這一平臺的通用性進行更進一步的研究。

（2）我國適航標(biāo)準(zhǔn)在未來發(fā)展上，一方面可以借鑒國外優(yōu)秀的主流適航標(biāo)準(zhǔn)，另一方面在時機成熟情況下，可以從自身航空產(chǎn)品及航空器的特點進行研究和創(chuàng)新，研制出具有中國特色的適航標(biāo)準(zhǔn)體系。

（3）目前國內(nèi)針對于機載嵌入式軟件測試的研究工作還處于初期階段，測試過程缺乏標(biāo)準(zhǔn)化管理體系，未來需要研究嵌入式軟件測試過程管理體系標(biāo)準(zhǔn)化，并且將自動化測試越來越多的應(yīng)用到嵌入式軟件測試中。