面向適航標(biāo)準(zhǔn)的機(jī)載軟件測試驗(yàn)證方法綜述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 基于需求的測試

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

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

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

2.1 測試方法

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

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

（1）低層需求的測試

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

（2）軟件集成測試

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

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

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

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

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

2.2 測試用例自動(dòng)生成

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

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

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

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

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

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

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

2.3 小結(jié)

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

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

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

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

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

3 基于安全性分析的測試

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

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

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

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

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

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

3.1 功能危險(xiǎn)分析（FHA）

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

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

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

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

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

3.3 故障樹分析（FTA）

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

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

3.4 共因故障分析（CCA）

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

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

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

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

3.5 小結(jié)

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

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

4 基于模型的測試

DO-178C 中基于模型的測試過程對應(yīng)于軟件開發(fā)過程中的軟件編碼和集成過程。模型是軟件生命周期數(shù)據(jù)的一種抽象描述方式，用來更好地支持軟件開發(fā)過程和軟件驗(yàn)證過程。不同的軟件系統(tǒng)采用合適的方法自動(dò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)機(jī)FSM（Finite State Machine）、統(tǒng)一建模語言UML（United Modeling Language）模型、系統(tǒng)建模語言SysML（System Modeling Language）模型和Markov（馬爾科夫）鏈模型。如圖5 所示為測試模型建模過程。

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

4.1 FSM測試模型

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

4.2 UML測試模型

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

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

4.3 SysML測試模型

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

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

4.4 Markov鏈測試模型

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

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

4.5 小結(jié)

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

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

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

5 軟件驗(yàn)證的測試

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

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

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

（3）實(shí)現(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）驗(yàn)證無法追溯到源代碼的附加代碼。

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

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

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

5.1.1 測試規(guī)程測試

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

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

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

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

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

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

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

5.1.2 測試結(jié)果測試

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

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

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

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

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

5.2 需求覆蓋測試

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（4）通過分析、插樁、運(yùn)行等手段，識別有哪些覆蓋點(diǎn)沒有覆蓋。

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

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

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

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

5.5 小結(jié)

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

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

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

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

6 總結(jié)

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

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

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

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

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

在實(shí)際的測試工作中，無論采用什么樣的測試方法，都應(yīng)該盡早地進(jìn)行測試，越早發(fā)現(xiàn)問題，軟件開發(fā)的成本越低。研究面向適航標(biāo)準(zhǔn)的機(jī)載軟件測試驗(yà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ò)、高度集成的特點(diǎn)。隨著IMA 軟件在系統(tǒng)中占比逐漸增加，分布式測試平臺可為IMA 軟件測試提供有力保障，目前平臺僅支持ARINC653 標(biāo)準(zhǔn)操作系統(tǒng)，可就提高這一平臺的通用性進(jìn)行更進(jìn)一步的研究。

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

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