航空機(jī)載軟件測試工具鏈設(shè)計(jì)與應(yīng)用

(成都飛機(jī)設(shè)計(jì)研究所，成都 610091)

0 引言

隨著航空飛行器研制發(fā)展，航空機(jī)載軟件呈現(xiàn)出了數(shù)量多，代碼量大，邏輯復(fù)雜等特點(diǎn)。航空機(jī)載軟件的研發(fā)也采用了基于模型的系統(tǒng)工程方法，系統(tǒng)設(shè)計(jì)能力得到了較大提升；多個(gè)型號飛機(jī)并行研制增加了機(jī)載系統(tǒng)數(shù)量，需要同時(shí)開發(fā)、測試和維護(hù)的軟件產(chǎn)品數(shù)量多、軟件狀態(tài)復(fù)雜。傳統(tǒng)的軟件測試的模式已經(jīng)難以適應(yīng)當(dāng)前的航空機(jī)載軟件的研發(fā)。如何提前發(fā)現(xiàn)問題，保障軟件質(zhì)量對傳統(tǒng)模式下的軟件測試提出了挑戰(zhàn)。

1 背景

近年來，隨著科學(xué)技術(shù)的迅速發(fā)展以及高新技術(shù)在新一代戰(zhàn)斗機(jī)中的大規(guī)模運(yùn)用，航空機(jī)載系統(tǒng)的能力不斷提升，系統(tǒng)的綜合化和復(fù)雜度也越來越高[1]。航空機(jī)載軟件是實(shí)現(xiàn)飛機(jī)功能的重要載體，與以往三代飛機(jī)相比，新一代飛機(jī)除了軟件規(guī)模及復(fù)雜度呈指數(shù)上升以外，機(jī)載軟件的研制主要發(fā)生了以下兩大變化：

首先，系統(tǒng)設(shè)計(jì)模式發(fā)生了變化?；谀Ｐ偷南到y(tǒng)工程(Model-Based Systems Engineering，MBSE)方法在型號中逐步推廣及實(shí)踐。MBSE主張以模型的形式支撐系統(tǒng)和軟件設(shè)計(jì)，持續(xù)貫穿整個(gè)系統(tǒng)研制過程。MBSE的使用，軟件設(shè)計(jì)人員基于系統(tǒng)模型，在完成軟件需求分解、軟件架構(gòu)與功能設(shè)計(jì)后，代碼可通過模型驅(qū)動(dòng)的開發(fā)手段自動(dòng)生成，大大提高了軟件開發(fā)的效率。

其次，多個(gè)型號并行研制，需要并行開發(fā)、測試和維護(hù)的軟件產(chǎn)品數(shù)量多、軟件狀態(tài)復(fù)雜。隨著機(jī)載軟件在飛機(jī)所占功能比例越來越大，重要度越來越高，軟件從原來附屬于成品設(shè)備，剝離出來作為產(chǎn)品來進(jìn)行管理，相應(yīng)的技術(shù)管理要求更為嚴(yán)格；企業(yè)在承擔(dān)型號任務(wù)上，從原有一兩型飛機(jī)研制向多型號并行研制轉(zhuǎn)變，同時(shí)承擔(dān)的有人飛機(jī)、無人飛機(jī)達(dá)到十多個(gè)，軟件產(chǎn)品研制呈型號多、產(chǎn)品多、技術(shù)狀態(tài)多的“三多”特點(diǎn)。

新的系統(tǒng)設(shè)計(jì)模式采用及軟件多項(xiàng)目并行的現(xiàn)狀，對現(xiàn)有以人工方式為主的機(jī)載軟件測試提出了巨大的挑戰(zhàn)，需要與之適配的軟件測試手段。挑戰(zhàn)主要包括以下兩個(gè)方面：

首先，MBSE方法的引入，帶來了測試工作的“左移”和“右移”，如圖1所示。測試左移是指測試向軟件研制的早中期移動(dòng)，測試模式將向測試驅(qū)動(dòng)開發(fā)(TDD)模式轉(zhuǎn)變。在軟件研制的早中期，軟件版本發(fā)布頻繁，需求變更范圍大，要求版本迭代周期為1～2周完成一個(gè)版本的軟件測試工作，對測試效率要求非常高；測試右移是指測試向軟件研制的驗(yàn)收、維護(hù)階段移動(dòng)。系統(tǒng)及軟件設(shè)計(jì)人員很重視軟件驗(yàn)收測試的效果，要求測試人員對系統(tǒng)功能進(jìn)行完整的功能覆蓋測試。針對系統(tǒng)、外場試飛反饋的故障，要求測試人員能夠?qū)收线M(jìn)行分析，對系統(tǒng)、軟件問題快速復(fù)現(xiàn)和定位。

圖1 測試“左移”和“右移”

其次，由于軟件多產(chǎn)品線并行，軟件測試工作量十分巨大。在型號進(jìn)度要求相近的情況下，各個(gè)軟件需要同時(shí)開展軟件測試，按照傳統(tǒng)的手工執(zhí)行測試的方式，存在測試人員瓶頸的問題。

近年來，DevOps理念在互聯(lián)網(wǎng)企業(yè)取得廣泛的推廣和應(yīng)用。DevOps(Development和Operations的組合詞)可以看作開發(fā)、技術(shù)運(yùn)營和質(zhì)量保證三者的交集，是一種重視“軟件開發(fā)人員(Dev)”和“IT運(yùn)維技術(shù)人員(Ops)”之間溝通合作的文化、運(yùn)動(dòng)或慣例。透過自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程，來使得構(gòu)建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠[2]。DevOps強(qiáng)調(diào)團(tuán)隊(duì)協(xié)作，自動(dòng)化，虛擬化以及軟件開發(fā)、測試及運(yùn)營活動(dòng)的新工具的橋接，目標(biāo)是縮短反饋周期和開發(fā)周期，幫助軟件企業(yè)通過頻繁和自動(dòng)化的軟件發(fā)布來提高對需求變更的響應(yīng)能力。

我們不難找到系統(tǒng)工程與DevOps之間的對應(yīng)關(guān)系。開發(fā)(Dev)過程被描述為涉及需求分析、設(shè)計(jì)、實(shí)現(xiàn)以及系統(tǒng)集成和測試的一系列活動(dòng)，而操作(Ops)過程通常與維護(hù)活動(dòng)一起，主要集中在軟件的部署及使用階段。之所以沒有單獨(dú)把質(zhì)量保證(QA)活動(dòng)單獨(dú)出來，并不是因?yàn)椴恢匾且驗(yàn)橘|(zhì)量保證活動(dòng)包括評審、測試、度量等活動(dòng)，貫穿于整個(gè)軟件過程的活動(dòng)。

打破部門之間的“豎井”是提高團(tuán)隊(duì)協(xié)作的有效途徑。大部分航空企業(yè)的軟件開發(fā)、維護(hù)保障和質(zhì)量保證部門為各自獨(dú)立的部門，不同部門之間的目標(biāo)是有差異的，比如，軟件開發(fā)部門目標(biāo)是盡快將變更后的軟件版本部署到系統(tǒng)，它希望測試工作能夠迅速完成；軟件測試部門目標(biāo)是排查軟件隱藏的問題，它希望測試輸入足夠充分，并且需要預(yù)留充足的時(shí)間完成軟件測試，保證測試的高覆蓋率。當(dāng)相互依賴的工作被分開時(shí)，會(huì)存在大量的信息延遲或者丟失，從而延長了整個(gè)軟件研制周期。

自動(dòng)化測試是持續(xù)集成思想的重要實(shí)踐。持續(xù)集成是指一種軟件工程流程，是將所有軟件設(shè)計(jì)人員對于軟件的工作副本持續(xù)集成到公用主線的一種方法[3]。通過頻繁的自動(dòng)化的構(gòu)建(包括編譯、發(fā)布、自動(dòng)化測試)來，可以盡快地發(fā)現(xiàn)集成錯(cuò)誤。比如，在測試驅(qū)動(dòng)開發(fā)(TDD)的實(shí)踐中，通常配置自動(dòng)化的單元測試和代碼運(yùn)行時(shí)錯(cuò)誤檢查來發(fā)現(xiàn)軟件缺陷。

要開展自動(dòng)化測試，光靠持續(xù)集成框架和測試工具，也許在互聯(lián)網(wǎng)企業(yè)是可行的，但并不適用于航空企業(yè)。有兩方面原因：一是，機(jī)上軟件大多數(shù)為嵌入式軟件，難以脫離目標(biāo)系統(tǒng)單獨(dú)運(yùn)行，需要有真實(shí)目標(biāo)系統(tǒng)。但是航空企業(yè)都為研發(fā)驅(qū)動(dòng)測試模式，軟件測試部門無獨(dú)立的硬件目標(biāo)系統(tǒng)用于軟件測試。二是，在自動(dòng)化測試實(shí)踐中，硬件難以支持設(shè)置、控制，要想完全測試自動(dòng)化，需要對目標(biāo)系統(tǒng)進(jìn)行定制。芬蘭奧盧大學(xué)Lucy Ellen Lwakatare在一項(xiàng)關(guān)于DevOps在嵌入式領(lǐng)域應(yīng)用的研究指出，對硬件依賴性，以及缺乏在特定環(huán)境中自動(dòng)、可靠和反復(fù)部署軟件新功能的技術(shù)是阻礙DevOps在嵌入式領(lǐng)域應(yīng)用的主要最大挑戰(zhàn)[4]。

為突破DevOps在嵌入式領(lǐng)域的最大挑戰(zhàn)，需引入全系統(tǒng)仿真技術(shù)。全系統(tǒng)仿真技術(shù)是對真實(shí)目標(biāo)系統(tǒng)的虛擬化，解決了對測試硬件環(huán)境依賴的問題。全系統(tǒng)仿真系統(tǒng)是一套虛擬平臺(tái)，能夠完全仿真目標(biāo)系統(tǒng)中對應(yīng)的實(shí)際硬件[5]。開發(fā)、測試人員在這套虛擬平臺(tái)上運(yùn)行被測試軟件，例如固件、操作系統(tǒng)、中間件或應(yīng)用軟件時(shí)，可以獲得在實(shí)際目標(biāo)系統(tǒng)上運(yùn)行這些軟件的效果。

商用、開源的軟件開發(fā)、測試工具是軟件測試工具鏈的執(zhí)行模塊。這里所說的工具鏈?zhǔn)侵妇幾g、構(gòu)建、測試所使用到的開發(fā)集成環(huán)境和測試工具。通過對市場上面向嵌入式軟件的商用、開源軟件開發(fā)、測試工具(主要為國外工具)進(jìn)行調(diào)研，主流的測試工具都提供了開發(fā)接口，能夠滿足與持續(xù)集成框架的二次開發(fā)集成的需要。

因此，為突破企業(yè)現(xiàn)有軟件測試手段和人力資源的瓶頸，基于DevOps理念，從如何有效開展嵌入式軟件自動(dòng)化測試作為切入點(diǎn)，測試團(tuán)隊(duì)提出了一種基于DevOps的航空機(jī)載軟件測試工具鏈設(shè)計(jì)方案。設(shè)計(jì)方案主要從業(yè)務(wù)、架構(gòu)、技術(shù)三個(gè)方面展開闡述[6]。

在業(yè)務(wù)視角，提出了企業(yè)內(nèi)敏捷、協(xié)同的軟件測試流程。目標(biāo)打破企業(yè)內(nèi)軟件開發(fā)、測試之間的“豎井”，通過該流程實(shí)現(xiàn)在開發(fā)、測試各個(gè)團(tuán)隊(duì)之間的密切合作。

在架構(gòu)視角，提出了軟件測試工具鏈的架構(gòu)思路。

在技術(shù)視角，提出了持續(xù)集成環(huán)境、全系統(tǒng)仿真環(huán)境、測試工具環(huán)境的搭建方案。持續(xù)集成環(huán)境是測試流程中各個(gè)環(huán)節(jié)的鏈條。實(shí)現(xiàn)了軟件每日構(gòu)建(Nightly Build)，以及自動(dòng)化測試中待構(gòu)建代碼、測試用例、目標(biāo)系統(tǒng)仿真模型庫、測試執(zhí)行結(jié)果的獲取和推送的功能。全系統(tǒng)仿真環(huán)境是自動(dòng)化測試的運(yùn)行載體。實(shí)現(xiàn)了目標(biāo)系統(tǒng)的模擬仿真，仿真目標(biāo)系統(tǒng)的容器化及測試云化部署。測試工具環(huán)境是測試流程的執(zhí)行單元。測試工具環(huán)境選擇松耦合方式的方式進(jìn)行設(shè)計(jì)，便于測試流水線按照項(xiàng)目進(jìn)行個(gè)性化配置。測試工具環(huán)境的集成開發(fā)考慮了先進(jìn)性、繼承性、成本三方面的因素，主要有三個(gè)做法：一是充分借鑒國外軟件測試經(jīng)驗(yàn)，引入優(yōu)秀的開源工具。發(fā)揮開源工具靈活、可配置強(qiáng)的特點(diǎn)；二是整合企業(yè)已有的軟件測試工具，使測試技術(shù)保持繼承性；三是采購具有關(guān)鍵技術(shù)的商用工具，保證測試過程的穩(wěn)定和可靠。

2 工具鏈設(shè)計(jì)

2.1 業(yè)務(wù)流程

航空機(jī)載軟件的研制階段分為F(設(shè)計(jì)方案)、C(初樣設(shè)計(jì))、S(試樣試制)、D(設(shè)計(jì)鑒定)、P(批型)階段。軟件測試主要集中在C、S、D階段，各階段測試業(yè)務(wù)需求如下：

在C階段，軟件需求、軟件架構(gòu)功能代碼已經(jīng)確定，硬件目標(biāo)系統(tǒng)仍未設(shè)計(jì)完成。應(yīng)采用測試驅(qū)動(dòng)開發(fā)方式，盡早考慮，有利于保證后續(xù)自動(dòng)化軟件測試的開展。該階段軟件測試的主要工作參與軟件需求的討論，進(jìn)行測試需求分解；根據(jù)測試需求，搭建軟件單元、配置項(xiàng)自動(dòng)化測試框架。

在S階段，由于系統(tǒng)設(shè)計(jì)變更和軟件功能設(shè)計(jì)更改，軟件需求、代碼變更十分頻繁。該階段的軟件研制具有以下兩個(gè)特點(diǎn)：一是機(jī)載系統(tǒng)狀態(tài)批次增多，軟件狀態(tài)復(fù)雜，測試人員要清楚識別、區(qū)分軟件版本狀態(tài)；二是機(jī)載軟件研制S階段周期較長，軟件開發(fā)以增量迭代的方式進(jìn)行，待測試軟件較上一版本變化量小，但累計(jì)發(fā)放版本多，每個(gè)版本均需要保證軟件測試質(zhì)量。針對S階段的軟件研制特點(diǎn)，該階段軟件測試的主要工作為建立測試流水線機(jī)制，一條測試流水線對應(yīng)一項(xiàng)軟件的測試環(huán)境配置，保證軟件版本及測試受控；根據(jù)軟件需求、設(shè)計(jì)文檔，進(jìn)行測試設(shè)計(jì)，使用測試流水線驅(qū)動(dòng)自動(dòng)化單元、配置項(xiàng)測試；根據(jù)軟件變更單，進(jìn)行軟件變更影響域分析工作，進(jìn)行回歸測試。

在D階段，該階段軟件已通過設(shè)計(jì)鑒定，文檔、代碼狀態(tài)穩(wěn)定。該階段飛機(jī)各項(xiàng)科研試飛工作仍在繼續(xù)，軟件仍需排故、升級及維護(hù)保障[7]。該階段軟件測試為保證與真實(shí)環(huán)境一致性，以確認(rèn)測試為主，主要在系統(tǒng)綜合試驗(yàn)臺(tái)進(jìn)行；另外，全系統(tǒng)仿真環(huán)境配合進(jìn)行補(bǔ)充功能驗(yàn)證，可幫助問題的定位、排查。

通過對軟件研制階段測試業(yè)務(wù)需求進(jìn)行分析，機(jī)載軟件測試的瓶頸在于兩個(gè)地方：一是測試與開發(fā)協(xié)同的問題。即如何建立開發(fā)測試的協(xié)作機(jī)制，保證多技術(shù)狀態(tài)、多版本軟件測試情況下保證測試狀態(tài)準(zhǔn)確；二是測試效率的問題。即在測試人力資源相對有限的情況下，如何構(gòu)建自動(dòng)化測試框架，并利用自動(dòng)化測試框架，提高測試效率，完成測試任務(wù)。

因此在考慮軟件測試工具鏈架構(gòu)設(shè)計(jì)時(shí)，需要考慮以上的因素。結(jié)合軟件測試業(yè)務(wù)需求，工具鏈業(yè)務(wù)架構(gòu)如圖2所示。

圖2 測試工具鏈業(yè)務(wù)架構(gòu)

在對軟件測試業(yè)務(wù)流程分解后，得到業(yè)務(wù)、工具鏈功能、操作對象、工具集成技術(shù)的對應(yīng)關(guān)系。如表1所示。

表1 業(yè)務(wù)流程與工具鏈的對應(yīng)關(guān)系

2.2 工具鏈架構(gòu)

工具鏈定義：多個(gè)工具結(jié)合使用時(shí)，可以支持和構(gòu)建領(lǐng)域工程的工作流。[8]結(jié)合企業(yè)內(nèi)機(jī)載軟件測試業(yè)務(wù)需求，對工具技術(shù)架構(gòu)進(jìn)行了規(guī)劃，工具鏈構(gòu)建應(yīng)當(dāng)求精而不追求面面俱到，設(shè)計(jì)準(zhǔn)則歸納為4個(gè)字：“小”、“獨(dú)”、“輕”、“松”。“小”是指粒度小，只關(guān)注某個(gè)任務(wù)的實(shí)現(xiàn)。在構(gòu)建測試流水線時(shí)，要細(xì)分流水線的環(huán)節(jié)步驟。最好一個(gè)環(huán)節(jié)對應(yīng)到一個(gè)工具；“獨(dú)”是指每個(gè)微服務(wù)是單獨(dú)的進(jìn)程。減少甚至不做工具之間的集成，降低調(diào)用服務(wù)的復(fù)雜度；“輕”是指輕量級的通信機(jī)制，盡量使用HTTP接口。在不要求實(shí)時(shí)性前提下，減少中間件的使用，降低系統(tǒng)復(fù)雜性；“松”是指工具鏈層間、工具之間要松耦合，可獨(dú)立部署。

基于“小、獨(dú)、輕、松”的設(shè)計(jì)原則，將軟件工具鏈設(shè)計(jì)為四層：服務(wù)、調(diào)度、集群及數(shù)據(jù)管理。測試工具鏈架構(gòu)如圖3所示。

圖3 航空機(jī)載軟件測試工具鏈架構(gòu)

其中，服務(wù)層是將軟件測試業(yè)務(wù)流程中使用的開發(fā)和測試工具環(huán)境，封裝為服務(wù)的形式提供測試人員使用。包括代碼構(gòu)建、靜態(tài)分析、代碼審查、單元測試和配置項(xiàng)測試工具。

調(diào)度層內(nèi)建一套驅(qū)動(dòng)服務(wù)層、集群層的持續(xù)集成環(huán)境。調(diào)度層負(fù)責(zé)測試任務(wù)的創(chuàng)建、調(diào)度、管理，并根據(jù)測試任務(wù)需要，進(jìn)行測試過程數(shù)據(jù)的自動(dòng)抽取和推送。調(diào)度層包括流程引擎、分布式版本控制工具和配置管理遠(yuǎn)程倉庫。

集群層是配置項(xiàng)測試的交叉測試環(huán)境。利用全系統(tǒng)仿真技術(shù)構(gòu)建目標(biāo)系統(tǒng)的仿真系統(tǒng)，負(fù)責(zé)測試腳本和目標(biāo)代碼的運(yùn)行及結(jié)果輸出。為解決調(diào)度層所創(chuàng)建測試任務(wù)自動(dòng)化并發(fā)執(zhí)行的問題，先使用容器技術(shù)對仿真系統(tǒng)封裝為微服務(wù)，通過測試云部署將容器虛擬化部署。

數(shù)據(jù)管理層負(fù)責(zé)測試過程數(shù)據(jù)、測試問題的收集和展示。包括測試管理、工程管理兩部分。包括測試管理和工程管理模塊，負(fù)責(zé)提供接口將上述數(shù)據(jù)推送到企業(yè)已有的軟件測試管理平臺(tái)和工程管理平臺(tái)。該部分將不作為本文描述的重點(diǎn)。

接下來，本節(jié)的其他內(nèi)容將重點(diǎn)描述調(diào)度、集群、服務(wù)之間的關(guān)系。主要包括持續(xù)集成環(huán)境、交叉測試環(huán)境、工具環(huán)境。

2.3 持續(xù)集成環(huán)境

2.3.1 流程引擎

流程引擎是一個(gè)持續(xù)集成的框架，可以按照時(shí)間、事件方式驅(qū)動(dòng)任意的Shell腳本和Windows批處理命令的執(zhí)行。構(gòu)建流程引擎的目標(biāo)是為不同的被測軟件建立專門的自動(dòng)化測試流程，并且監(jiān)控軟件測試流程，便于快速發(fā)現(xiàn)問題，提高測試效率。

流程引擎主要包括作業(yè)構(gòu)建、作業(yè)流水線、分布式構(gòu)建、構(gòu)建后操作4個(gè)部分的功能：第一，作業(yè)構(gòu)建功能分為串行構(gòu)建、并行構(gòu)建兩種方式，需要根據(jù)測試任務(wù)復(fù)雜度情況及效率要求決定采用哪一種方式來進(jìn)行作業(yè)構(gòu)建。一個(gè)測試任務(wù)由若干個(gè)測試作業(yè)組成，要考慮過程數(shù)據(jù)監(jiān)控、構(gòu)建后數(shù)據(jù)采集的難易程度，合理進(jìn)行測試作業(yè)劃分時(shí)顆粒度。比如，對于代碼靜態(tài)分析任務(wù)，可以創(chuàng)建一個(gè)測試作業(yè)來進(jìn)行構(gòu)建，因?yàn)榇a可以作為整體來進(jìn)行分析評估，獲取分析結(jié)果；對于單元測試任務(wù)，如果只是創(chuàng)建一個(gè)測試作業(yè)就顯得顆粒太粗，不便于測試過程出錯(cuò)的故障排查，因此需要按照軟件模塊、單元進(jìn)行結(jié)構(gòu)化劃分，構(gòu)建為許多個(gè)測試作業(yè)；第二，構(gòu)建好的測試作業(yè)是孤立的、無方向的，需要流水線將測試作業(yè)進(jìn)行串聯(lián)。作業(yè)流水線功能提供了流程建模的功能，將代碼提取、代碼構(gòu)建、代碼分析、測試等一系列測試任務(wù)串聯(lián)起來。通過流水線功能，可根據(jù)不同的測試要求，快速的將已有測試作業(yè)組合在一起，形成針對某個(gè)版本軟件的自動(dòng)化測試流程；第三，分布式構(gòu)建主要目的是為了并發(fā)構(gòu)建，提高測試執(zhí)行效率。將服務(wù)器定義為主節(jié)點(diǎn)，其他的計(jì)算機(jī)定義為從節(jié)點(diǎn)，分布式構(gòu)建功能定義了主節(jié)點(diǎn)與從節(jié)點(diǎn)協(xié)同構(gòu)建的策略。也就是主節(jié)點(diǎn)根據(jù)每個(gè)從節(jié)點(diǎn)的忙閑狀態(tài)，動(dòng)態(tài)的將測試作業(yè)分配到從節(jié)點(diǎn)來執(zhí)行，由從節(jié)點(diǎn)將執(zhí)行結(jié)果返回；第四，構(gòu)建后操作功能完成測試作業(yè)執(zhí)行后所產(chǎn)生的數(shù)據(jù)的采集及存儲(chǔ)。數(shù)據(jù)的采集是通過Python爬蟲的方式實(shí)現(xiàn)，從結(jié)果文件中抽取數(shù)據(jù)，并進(jìn)行數(shù)據(jù)整合，形成結(jié)構(gòu)化的測試結(jié)果。

流程引擎與其他系統(tǒng)之間的交互關(guān)系如圖4所示。

圖4 流程引擎與其他系統(tǒng)的交聯(lián)關(guān)系

流程引擎使用分布式版本控制工具的SSH權(quán)限，配置測試作業(yè)對配置管理遠(yuǎn)程倉庫的訪問權(quán)限；流程引擎從配置管理遠(yuǎn)程倉庫獲取代碼、測試模型，向遠(yuǎn)程倉庫推送測試過程數(shù)據(jù)；測試引擎通過分布式構(gòu)建功能，分配測試作業(yè)到交叉測試環(huán)境進(jìn)行測試執(zhí)行，從交叉測試環(huán)境讀取測試結(jié)果；作業(yè)流水線執(zhí)行完成后，通過構(gòu)建后操作功能，推送測試結(jié)果到測試管理平臺(tái)和工程管理平臺(tái)。

前期對市場常用的流程引擎進(jìn)行了調(diào)研，主流的流程引擎工具有Jenkins、Teamcity、Travis CI、Bamboo等。目前開源的流程引擎擁有廣泛的社區(qū)基礎(chǔ)，具有版本迭代快，功能穩(wěn)定的特點(diǎn)，因此考慮開源工具進(jìn)行流程引擎的集成開發(fā)。

2.3.2 分布式版本控制工具

由于工具鏈涉及到軟件開發(fā)人員、測試人員、工具之間的信息交互和協(xié)同，要求之間的交互是簡單而敏捷，因此考慮輕量級的配置管理解決方案,使用分布式版本控制工具作為測試過程的配置管理工具。分布式版本控制工具與集中式版本控制工具的區(qū)別是分布式版本控制系統(tǒng)沒有中央服務(wù)器，每臺(tái)計(jì)算機(jī)都擁有一個(gè)完整的版本庫。就算服務(wù)機(jī)宕機(jī)，也可以正常進(jìn)行版本的變更和提交，不會(huì)影響當(dāng)前的開發(fā)、測試工作。

以往企業(yè)內(nèi)測試團(tuán)隊(duì)要同時(shí)解決測試用例版本之間、測試用例與代碼版本，測試用例版本與環(huán)境配置之間對應(yīng)的難題，這往往是十分繁瑣且工作量巨大！分布式版本控制對測試團(tuán)隊(duì)非常有效，采用分支機(jī)制、集成管理者工作流和配置管理遠(yuǎn)程倉庫，使得人、工具之間的協(xié)作變得高效。

目前世界上最主流的分布式配置管理工具是Git，具有速度快，設(shè)計(jì)簡潔，完全分布式設(shè)計(jì)的特點(diǎn)。因此考慮使用Git作為測試團(tuán)隊(duì)的版本控制工具。

2.3.3 配置管理遠(yuǎn)程倉庫

配置管理遠(yuǎn)程倉庫是代碼、測試用例、測試模型及文檔配置管理服務(wù)器軟件。遠(yuǎn)程倉庫在工具鏈中具有兩個(gè)作用：1)測試版本控制協(xié)同。測試人員通過分布式版本控制工具，將測試數(shù)據(jù)提交到遠(yuǎn)程倉庫，提交版本分支合并的變更請求；通過遠(yuǎn)程倉庫獲取最新的測試數(shù)據(jù)版本，在本地進(jìn)行工作；2)作為流程引擎的輸入和輸出。流程引擎通過鉤子機(jī)制，監(jiān)聽遠(yuǎn)程倉庫的版本變更情況。如果發(fā)生版本變更，自動(dòng)觸發(fā)從遠(yuǎn)程倉庫抽取數(shù)據(jù)，驅(qū)動(dòng)測試作業(yè)的執(zhí)行。業(yè)務(wù)流水線執(zhí)行完畢后，通過構(gòu)建后操作，將測試結(jié)果推送到遠(yuǎn)程倉庫進(jìn)行保存市面上的配置管理遠(yuǎn)程倉庫軟件比較多，主流的有GitHub、GitLab，Bitbucket，Coding，這里面既有開源的自托管項(xiàng)目，也有商業(yè)軟件。

2.4 交叉測試環(huán)境

交叉測試環(huán)境是指嵌入式軟件在通用計(jì)算機(jī)環(huán)境(相對真實(shí)目標(biāo)系統(tǒng))中運(yùn)行測試的環(huán)境。在本文所指的交叉測試環(huán)境，是用于支持航空機(jī)載配置項(xiàng)測試執(zhí)行的全系統(tǒng)仿真系統(tǒng)、仿真系統(tǒng)部署環(huán)境(容器化環(huán)境和測試云)。

交叉測試環(huán)境在測試工具鏈的應(yīng)用，是利用全系統(tǒng)仿真、軟件容器、云技術(shù)，在軟件配置項(xiàng)級開展并發(fā)式的功能測試及快速的回歸測試，加快問題定位和排查故障的效率。

2.4.1 全系統(tǒng)仿真系統(tǒng)

全系統(tǒng)仿真系統(tǒng)是一套仿真嵌入式目標(biāo)系統(tǒng)的虛擬平臺(tái)，能夠完全仿真目標(biāo)系統(tǒng)中的CPU、寄存器、內(nèi)存、外設(shè)接口，全系統(tǒng)仿真系統(tǒng)示意圖如圖5所示。開發(fā)、測試人員在這套虛擬平臺(tái)上運(yùn)行被測軟件，可以獲得在實(shí)際目標(biāo)系統(tǒng)上運(yùn)行這些軟件的效果。在全系統(tǒng)仿真系統(tǒng)進(jìn)行軟件測試，與實(shí)際目標(biāo)系統(tǒng)相比，具有以下兩個(gè)特點(diǎn)：1)支持檢查點(diǎn)分析。通過插入檢查點(diǎn)，全系統(tǒng)仿真系統(tǒng)把軟件運(yùn)行狀態(tài)保存下來，支持運(yùn)行狀態(tài)回放分析，便于軟件問題定位；2)支持訪問目標(biāo)系統(tǒng)狀態(tài)。例如在真實(shí)硬件上，很難去跟蹤控制寄存器、狀態(tài)寄存器的內(nèi)容，但通過全系統(tǒng)仿真系統(tǒng)，目標(biāo)系統(tǒng)就像一個(gè)白盒，可以清楚看到內(nèi)部的狀態(tài)，這對軟硬件問題的排查十分有幫助。[9]

圖5 全系統(tǒng)仿真系統(tǒng)示意圖

全系統(tǒng)仿真系統(tǒng)要在機(jī)載軟件測試使用，除要有CPU仿真模型外，還需要進(jìn)行外圍設(shè)備仿真建模。外圍設(shè)備仿真建模主要指對目標(biāo)系統(tǒng)外圍器件、接口的建模仿真，包含各種器件如內(nèi)存、寄存器、外部定時(shí)器、FLASH等，各種標(biāo)準(zhǔn)的通信接口，如RS422、RS232、CAN、1553B、1394B以及FC總線。

由于CPU仿真模型的構(gòu)建難度大，這類工具廠家數(shù)量在國內(nèi)外并不多。適合航空航天選型芯片的工具主要有美國風(fēng)河公司的Simics和上海創(chuàng)景公司的VDVP產(chǎn)品。其中Simics以支持Power PC芯片系列為主，VDVP主要側(cè)重DSP芯片系列。

2.4.2 仿真系統(tǒng)部署

使用軟件容器技術(shù)和云技術(shù)進(jìn)行仿真系統(tǒng)部署。

軟件容器是一種應(yīng)用程序的封裝技術(shù)。軟件容器在Linux操作系統(tǒng)上，提供了一個(gè)額外的軟件抽象層以及操作系統(tǒng)虛擬化的自動(dòng)管理機(jī)制，為應(yīng)用程序的運(yùn)行提供所需資源。[10]創(chuàng)建一個(gè)容器，將全系統(tǒng)仿真系統(tǒng)封裝在容器中，可以實(shí)現(xiàn)全系統(tǒng)仿真系統(tǒng)從Windows向Linux的移植。軟件容器對計(jì)算機(jī)資源占用較少，在同等配置的服務(wù)器上，可以保證性能的情況下，運(yùn)行多個(gè)容器。

云技術(shù)是指在廣域網(wǎng)或局域網(wǎng)內(nèi)將硬件、軟件、網(wǎng)絡(luò)等系統(tǒng)資源統(tǒng)一，實(shí)現(xiàn)數(shù)據(jù)的計(jì)算、存儲(chǔ)、處理和共享的一種托管技術(shù)。把交叉測試環(huán)境看作為提供測試服務(wù)的測試資源池，軟件容器就是可共享的提供測試服務(wù)的資源。云技術(shù)負(fù)責(zé)提供軟件容器的動(dòng)態(tài)創(chuàng)建，應(yīng)用程序裝載，與流程引擎的調(diào)度機(jī)制。

基于軟件容器、云技術(shù)，提出了一種仿真系統(tǒng)的部署方案。仿真系統(tǒng)部署方案如圖6所示。

圖6 仿真系統(tǒng)部署方案

2.5 工具環(huán)境

工具環(huán)境是將軟件測試業(yè)務(wù)流程中使用的開發(fā)和測試工具，封裝為服務(wù)的形式提供測試人員使用。工具環(huán)境包括代碼構(gòu)建、靜態(tài)分析、代碼審查、單元測試和配置項(xiàng)測試工具。

工具環(huán)境的構(gòu)建思路是整合現(xiàn)有的軟件測試，將現(xiàn)有脫機(jī)使用的測試工具往服務(wù)器進(jìn)行遷移，形成企業(yè)內(nèi)部測試資源池；引入優(yōu)秀的開源工具，特別是在代碼級、單元級測試，往通用軟件測試思路轉(zhuǎn)變；開發(fā)、測試工具在與調(diào)度層進(jìn)行集成時(shí)，要保持“獨(dú)”和“松”的原則，開發(fā)、測試工具之間不做集成開發(fā)，通過流程引擎進(jìn)行調(diào)度。

3 工具鏈應(yīng)用

根據(jù)以上工具鏈設(shè)計(jì)方案，進(jìn)行航空機(jī)載軟件測試工具鏈的搭建?，F(xiàn)已完成持續(xù)集成環(huán)境、靜態(tài)分析環(huán)境、協(xié)同代碼審查環(huán)境、單元測試自動(dòng)化環(huán)境的搭建，并在某機(jī)電系統(tǒng)軟件的軟件測試中應(yīng)用，達(dá)到了預(yù)期的效果，實(shí)現(xiàn)方案如圖7所示；完成了基于Linux系統(tǒng)嵌入式軟件的交叉測試環(huán)境的搭建工作，為后續(xù)機(jī)載軟件交叉測試環(huán)境的搭建奠定了基礎(chǔ)。

某機(jī)電系統(tǒng)軟件測試工具鏈的實(shí)現(xiàn)技術(shù)如表2所示。

表2 某機(jī)電系統(tǒng)軟件測試工具鏈實(shí)現(xiàn)技術(shù)

圖7 某型號機(jī)電系統(tǒng)軟件工具鏈實(shí)現(xiàn)方案

3.1 持續(xù)集成環(huán)境構(gòu)建

采用Jenkins、Git及GitLab方案搭建持續(xù)集成環(huán)境，界面如圖8所示。其中Jenkins作為主節(jié)點(diǎn)部署，GitLab作為配置管理遠(yuǎn)程倉庫部署在從節(jié)點(diǎn)，測試工具部署在另外的從節(jié)點(diǎn)。

圖8 持續(xù)集成環(huán)境界面

測試數(shù)據(jù)版本控制采用分支機(jī)制、集成管理者工作流進(jìn)行管理，也就是將工作分支分為master、develop兩條分支，測試人員使用Git克隆遠(yuǎn)程倉庫的master分支版本到本地倉庫，在完成變更后，提交到遠(yuǎn)程倉庫的develop分支，并在GitLab中向項(xiàng)目組長提出合并master分支的請求，由項(xiàng)目組長審核完成后將合并后的變更推送到遠(yuǎn)程倉庫的master分支。

3.2 靜態(tài)分析

采用Jenkins、Git、GitLab、Tornado、TestBed、Covertiy工具集成方案配置靜態(tài)分析測試作業(yè)流水線，如圖9所示。開發(fā)人員通過Git在本地倉庫提交代碼，流程引擎會(huì)根據(jù)測試作業(yè)流水線配置，自動(dòng)化完成被測軟件的自動(dòng)提取、編譯構(gòu)建、運(yùn)行時(shí)錯(cuò)誤檢查、代碼規(guī)則檢查、代碼質(zhì)量度量，并自動(dòng)推送測試結(jié)果給開發(fā)測試人員查看，實(shí)現(xiàn)對軟件的每日構(gòu)建能力，如圖10所示。

圖9 靜態(tài)分析流程

圖10 推送Jenkins的運(yùn)行時(shí)錯(cuò)誤檢查報(bào)告

3.3 代碼審查

采用Git、GitLab、Upsource工具集成方案配置代碼審查協(xié)同工作環(huán)境。以往在項(xiàng)目中使用單機(jī)版的代碼審查、比對工具(Source Insight、Beyond Compare)進(jìn)行代碼審查，這種方式存在兩個(gè)問題：一是開發(fā)、測試人員缺少協(xié)同的審查環(huán)境。代碼審查要求組織正式的評審會(huì)，以走讀代碼邏輯的方式來進(jìn)行，但項(xiàng)目實(shí)際不允許這樣的實(shí)踐。二是代碼與問題對應(yīng)關(guān)系不直觀。問題記錄單與代碼分開存放，時(shí)間長了關(guān)系不容易維護(hù)。通過代碼審查協(xié)同工作環(huán)境，開發(fā)、測試人員可以約定在一定時(shí)間周期內(nèi)開展審查工作，測試人員在線質(zhì)疑代碼中存在的問題，問題會(huì)自動(dòng)推送給開發(fā)人員來進(jìn)行解決。代碼與問題的對應(yīng)關(guān)系在系統(tǒng)中進(jìn)行維護(hù)，十分方便版本之間的問題比較、分析。

4 結(jié)論

本文從軟件測試角度作為切入點(diǎn)，研究航空機(jī)載嵌入式軟件的結(jié)合方式，提出了一種航空機(jī)載軟件測試工具鏈設(shè)計(jì)方案，完成了工具鏈技術(shù)架構(gòu)的搭建，持續(xù)集成環(huán)境與靜態(tài)分析、代碼審查、單元測試工具環(huán)境的集成開發(fā)，并在某飛機(jī)的機(jī)電系統(tǒng)軟件測試中進(jìn)行應(yīng)用，達(dá)到了提高測試效率的效果。測試人員在工具鏈的應(yīng)用過程中，收集開發(fā)人員的反饋，作為測試工具鏈下一步優(yōu)化的建議。

通過在企業(yè)內(nèi)部開展航空機(jī)載軟件測試工具鏈設(shè)計(jì)與應(yīng)用的探索，深切感覺工具鏈的實(shí)質(zhì)是讓工具環(huán)境、自動(dòng)化能力成為軟件研制的一部分，以技術(shù)能力解決過去用人工加流程要解決的問題。但工具鏈只是人、機(jī)、料、法、環(huán)的其中一環(huán)，代表著一種新的思考方式和文化。相信隨著國內(nèi)機(jī)載軟件研制能力的持續(xù)進(jìn)步，更多的理念能夠融入研制流程，提高軟件研制水平！