機載航電軟件配置項測試

文/朱文釗

（中國直升機設(shè)計研究所 江西省景德鎮(zhèn)市 333001）

1 引言

嵌入式軟件具有“高實時性”、“開發(fā)和測試環(huán)境專門化”等特點，有別于運行于Windows上的軟件，嵌入式軟件在運行中對操作者是“不可見”的，由于嵌入式軟件的這種特殊性，導(dǎo)致針對它的測試與普通的軟件測試有著很大的不同。在測試過程中測試者要設(shè)法將軟件運行的軌跡和動作以字符串的形式輸出到系統(tǒng)之外，供測試者或者測試系統(tǒng)觀測和分析[1]。傳統(tǒng)上，嵌入式軟件開發(fā)流程一般為需求分析、處理流程與數(shù)據(jù)流的分析、設(shè)計系統(tǒng)結(jié)構(gòu)、定義軟件間接口、軟件設(shè)計與實現(xiàn)、單元測試、配置項測試、集成測試以及系統(tǒng)測試[2]。其中配置項測試主要針對軟件功能的實現(xiàn)的測試和驗證[3]。

軟件配置項是一組能獨立編譯、運行和管理并能滿足用戶最終需求的軟件集合，具有獨立的功能、性能、接口和人機界面等軟件特性[4]，因此在進行配置項測試時需選取多種測試類型進行驗證。

2 航電軟件特性

航電軟件是直升機機載軟件中負責(zé)顯示飛機飛行狀態(tài)、與超短波電臺、導(dǎo)航等設(shè)備進行信息交互，與駕駛員進行交互并且駐留在任務(wù)機的軟件。軟件架構(gòu)為嵌入式系統(tǒng)架構(gòu)。要求實時性較高。對于飛機的飛行姿態(tài)、高度信息、設(shè)備情況等信息的顯示要及時迅速可靠。航電軟件按照功能的不同，基本分為多功能顯示器顯示軟件和飛行操作軟件兩類，它們共同完成機載航電軟件的工作任務(wù)。多功能顯示器顯示軟件側(cè)重于信息的顯示，而飛行操作軟件側(cè)重于控制類功能的實現(xiàn)。在對這兩個軟件進行測試時，要著重注意它們之間的區(qū)別。

3 配置項測試

目前直升機機載軟件一般為嵌入式軟件，工作環(huán)境為VxWorks，對系統(tǒng)延時的要求高，與硬件平臺結(jié)合緊密。在對其進行配置項測試時不僅需要考慮功能上的實現(xiàn)，還需要對其相關(guān)性能進行考察。

白盒測試在測試過程中測試者可以看到被測的源程序,根據(jù)其內(nèi)部結(jié)構(gòu)設(shè)計測試用例。而黑盒測試在測試過程中測試者完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特征,根據(jù)需求規(guī)格說明來設(shè)計測試用例。配置項測試并不是完全的黑盒測試，需要結(jié)合接口協(xié)議等文檔來完成測試用例的設(shè)計,配置項測試對白盒測試和黑盒測試進行了有效的結(jié)合，進行了所謂的“灰盒測試”，使得測試更為完善。

在配置項測試開始前，應(yīng)對需求規(guī)格說明及其他相關(guān)文檔進行文檔審查工作,特別是項目時間較為緊急的情況下，文檔中經(jīng)常存在各文檔間說法不一致等問題，在進行文檔審查時需特別注意。測試項目負責(zé)人以需求規(guī)格說明為準繩，將整體軟件需求分解。一般而言，可以將需求規(guī)格說明中的需求劃分為數(shù)據(jù)控制相關(guān)、顯示控制相關(guān)、性能測試等幾部分。這樣劃分的好處是數(shù)據(jù)控制相關(guān)的需求與接口協(xié)議關(guān)系較為密切,而顯示控制相關(guān)的需求則偏向于設(shè)備的畫面切換等，這樣測試人員在編寫測試用例時就有了側(cè)重點。劃分后的測試項與需求中的每一項都要保一一對應(yīng)關(guān)系,以滿足測試需求的全覆蓋。

3.1 航電軟件測試用例的設(shè)計

在軟件測試的多個階段，測試人員根據(jù)需求規(guī)格說明等文檔設(shè)計出大量的測試用例來滿足測試覆蓋率的要求。在測試過程中會發(fā)現(xiàn)存在用例未覆蓋到的需求，而且還需要對軟件進行回歸測試，軟件測試用例集的規(guī)模變得越來越大。在編寫測試用例時，并沒有清晰明確的方法來指導(dǎo)測試人員對測試用例的編寫。因此編寫出的用例有時會不滿足需求的100%覆蓋，有時卻會增加冗余的測試用例，導(dǎo)致時間和成本的浪費。在軟件測試過程中，用戶需求時有變更，在頻繁的需求變更和軟件回歸測試過程中，也會產(chǎn)生大量的測試用例，很多的測試用例由于對需求點的理解不充分而導(dǎo)致冗余,影響測試執(zhí)行的有效性。當用戶的某些需求發(fā)生變更時，則需要對需求的變更進行影響性分析，編寫新的測試用例，以替換受到影響的測試需求和對應(yīng)用例。

測試用例編寫者拿到測試計劃后，找到由自己負責(zé)的那一部分需求，根據(jù)需求說明、軟件的接口協(xié)議書等相關(guān)文檔，編寫測試用例。設(shè)計測試用例時要充分考慮每一條測試需求的輸入、輸出及二者間的關(guān)系,在測試用例中設(shè)計滿足條件或不滿足條件的測試輸入，以驗證軟件的設(shè)計是否滿足需求。

編寫測試用例中的功能測試時要依據(jù)需求規(guī)格說明,并參照相關(guān)設(shè)備的接口協(xié)議，明確在實現(xiàn)相應(yīng)功能時數(shù)據(jù)的發(fā)送和接收是否也保持一致。關(guān)于邊界測試的用例編寫,比如某類溫度值區(qū)間為0°C ～100°C,畫面的顯示精度為0.1°C，那么對于0°處的測試用例,應(yīng)當考慮-0.1°/0°/0.1 °這三個值進行測試。如果是接口中的數(shù)據(jù)，那么可以考慮使用邊界值±一個LSB值（某個參數(shù)數(shù)據(jù)最低有效位的權(quán)值）來進行測試。

由于測試環(huán)境的不具備或處于對人員、設(shè)備安全等方面的考慮，某些測試用例可能無法執(zhí)行，此時可以采用代碼走查的方式進行驗證。如果在設(shè)計測試用例時發(fā)現(xiàn)存在需求無法進行測試,那么需要提供對該需求的后續(xù)測試方法或處理意見。編寫的測試用例達到需求全覆蓋后也可以再次進行約減。很多直升機的型號是由軍轉(zhuǎn)民,若存在之前相似型號項目的經(jīng)驗,則可以考慮測試用例的復(fù)用，用以減少重復(fù)工作。

3.2 保證對需求的全覆蓋

設(shè)計測試用例時,當需求表述為文字時可以采用提取關(guān)鍵詞的辦法。每條需求中都包含若干個關(guān)鍵字，每個關(guān)鍵詞都有若干個狀態(tài),提取這些狀態(tài)積的集合，即達成需求的全覆蓋。若需求是公式的形式表述，則將公式中的每一個變量作為一個關(guān)鍵詞。關(guān)鍵詞的狀態(tài)積見圖1所示。W1、W2、W3為原始需求。其中W2和W3需求可以進一步拆解細化為W21、W22、W23和W31、W32、W33子需求。經(jīng)過梳理，可以得到子需求列表W1-W21-W31、W1-W21-W32、W1-W21-W33、W1-W22-W32、W1-W23-W32，通過這5條子需求就能寫出相應(yīng)的測試用例，從而得到完整的需求追蹤矩陣。原本復(fù)雜的需求經(jīng)過狀態(tài)積的拆解，分解成為若干個簡易明了的需求狀態(tài)積，此時可以按照拆解出的需求狀態(tài)積進行測試。使得測試過程結(jié)構(gòu)清晰，易于追蹤。

如某型機的機裁軟件需求規(guī)格說明中描述了電臺和任務(wù)機的握手流程。駕駛員執(zhí)行數(shù)據(jù)加載握手操作，任務(wù)機向超短波電臺發(fā)送數(shù)據(jù)加載握手指令，超短波電臺收到握手指令后回復(fù)是否準備好數(shù)據(jù)加載。從中可以提取“任務(wù)機向超短波電臺發(fā)送數(shù)據(jù)加載指令”和"超短波電臺回復(fù)是否淮備好"兩個關(guān)鍵詞句，其中第二句有兩種形式分別為"電臺回復(fù)已準備好”、“電臺回復(fù)尚未淮備好”及“電臺無應(yīng)答''，由此可以編寫出三個測試用例。

但是隨著測試的深入，當遇到復(fù)雜任務(wù)流程時，分解得出的狀態(tài)積也會膨脹，導(dǎo)致得出的測試用例集也隨之膨脹，影響測試效果和效率。在這種情況下，測試人員應(yīng)當適當?shù)膶δ玫降男枨鬆顟B(tài)積進行篩選，剔除一些不必要的選項，精化測試用例集，以便降低測試人員的工作強度。

表1：測試用例執(zhí)行單表頭

表2：配置項測試問題列表

圖1：多個關(guān)鍵詞的狀態(tài)積

在拿到需求后對需求進行分解時可以使用思維導(dǎo)圖來幫助測試人員設(shè)計測試用例，首先使用思維導(dǎo)圖對需求進行拆解，形成條目化的需求，然后在每一條需求后面都設(shè)計相應(yīng)的測試用例，這樣形成的測試用例集就比較的完整清晰。在實際使用中，由于測試用例的格式較多，我們在實際操作中可以僅挑選其中關(guān)鍵的部分作為測試用例的描述來追蹤相應(yīng)的需求，這樣后期使用自動化的工具可以直接將簡略的思維導(dǎo)圖格式的測試用例轉(zhuǎn)化為測試用例集的形式，節(jié)約了測試人員的時間。注意到測試用例中關(guān)鍵條目為測試描述、測試步驟、預(yù)期結(jié)果。當我們在思維導(dǎo)圖中每條需求后對應(yīng)的測試用例都按照這些條目填入相應(yīng)的內(nèi)容后，即可使用工具將這些簡略的測試用例轉(zhuǎn)換為合乎規(guī)格的測試用例集。

3.3 編寫測試用例執(zhí)行單

隨著測試工作經(jīng)驗的積累，測試人員會發(fā)現(xiàn)軟件測試用例表在實際測試中實用度不高，在執(zhí)行完測試用例后需要花費很長一部分時間用于填寫測試用例表，因此在測試時可以考慮采取測試用例執(zhí)行單的形式，將測試用例形成Excel表格，見表1，測試人員在測試用例執(zhí)行單上設(shè)計測試用例時，主要填寫測試說明、用例描述、測試步驟和預(yù)期結(jié)果四欄[5]。這樣在編寫測試用例時可以著重關(guān)注對需求的覆蓋和如何設(shè)計用例以暴露問題，而不必將太多時間花在格式上，在全部的測試用例執(zhí)行完成后，將其余欄目內(nèi)容補全，再由自動化工具將用例執(zhí)行單轉(zhuǎn)換為測試用例表以存檔和復(fù)用。表1為一般測試用例執(zhí)行單的表頭部分。

在測試用例的執(zhí)行過程中，由于機載軟件的特殊性，需要交替使用真實設(shè)備和仿真器來進行測試，這是由于很多機載設(shè)備的故障是無法通過真實設(shè)備來實現(xiàn)，只能在仿真器中作相應(yīng)的設(shè)置來模擬故障信息，或者使用真實設(shè)備模擬某些狀態(tài)的效費比不高。如果需要使用仿真軟件，則需要額外說明仿真的輸入和輸出與真實設(shè)備具有同樣的使用效果。當測試用例執(zhí)行單設(shè)計完成后，測試人員應(yīng)當確認測試環(huán)境已經(jīng)準備充分。則可以按照測試用例執(zhí)行單執(zhí)行相應(yīng)的測試用例，以開展測試工作。

3.4 填寫配置項測試問題記錄單

在測試過程中發(fā)現(xiàn)的問題記錄在配置項測試問題列表上（表2）。在測試現(xiàn)場可以簡略記錄，待時間充裕時再行整理。當配置項測試用例執(zhí)行工作完成時，存在未執(zhí)行的用例，則需說明未執(zhí)行的原因和處理意見。

在測試過程中發(fā)現(xiàn)的問題經(jīng)由軟件開發(fā)方的確認后將相應(yīng)問題歸零，如有對軟件的改動則需要進行影響性分析，并編寫回歸測試用例，供回歸測試時使用。

對于通過執(zhí)行配置項測試發(fā)現(xiàn)的問題的處理方式，有下面的幾種處理方式的分類。新建：一個問題由測試人員發(fā)現(xiàn)并提交，我們將狀態(tài)標注為新建；開發(fā)人員接收了該問題，將問題的狀態(tài)修改為已分配（Assigned）表示已認可；如果開發(fā)人員對于問題不認可，開發(fā)人員的解釋得到我們的認可，那么我們將問題的狀態(tài)標注為關(guān)閉；開發(fā)人員解決了該問題后，就將該問題的狀態(tài)修改為解決，并發(fā)給測試人員進行回歸測試；測試人員對問題進行回歸測試后，如果問題已經(jīng)解決，則問題的狀態(tài)修改為關(guān)閉，否則的話則發(fā)給開發(fā)人員重新修改。如果以前版本已經(jīng)關(guān)閉的問題，在新版本中重新出現(xiàn)，那么其狀態(tài)應(yīng)修改為重新打開。

3.5 編寫測試計劃、測試說明和測試報告

前面已經(jīng)提到在配置項測試開始前需對照相應(yīng)需求文檔編寫測試計劃，整個測試過程根據(jù)測試計劃來進行。測試計劃是整個測試過程的策劃，是需要在測試過程開展前完成的，而在測試策劃前期，我們將需求分解得出需求追蹤矩陣，按照整個需求追蹤矩陣，編寫出相應(yīng)的測試用例，形成測試用例集，這些工作是需要在前期完成的，而測試計劃文檔的編寫可以在測試工作完成后在測試追蹤矩陣和測試用例集等證據(jù)的基礎(chǔ)上補完，以避免在測試過程中有變動的地方導(dǎo)致文檔反復(fù)修改。

測試報告用以整個測試過程進行總結(jié)，測試說明側(cè)重于對測試用例的描述。在配置項測試結(jié)束后，統(tǒng)計編寫的測試用例情況，匯總集結(jié)成測試用例集，并編寫測試說明和測試報告文檔，在整個測試過程中，可以優(yōu)先完成測試說明和測試報告中重點注意的證據(jù)材料，待測試完成后在這些證據(jù)的基礎(chǔ)上補充完成文檔的編寫工作。

4 結(jié)束語

經(jīng)過以上測試流程后，即完成了機載軟件的配置項測試的工作。根據(jù)筆者多個型號的軟件測試項目的經(jīng)驗，在整個軟件測試的幾個階段中，往往在配置項測試這一環(huán)節(jié)能夠暴露被測軟件的諸多問題。這反映了在機載軟件的開發(fā)過程中，開發(fā)人員常常為了追趕項目進度，只追求軟件功能的有和無，而對代碼質(zhì)量不夠重視。而軟件測試人員的工作就在于此，通過我們的測試，找出軟件潛在的缺陷，提高軟件質(zhì)量，增強軟件的可靠性。