機(jī)載航電軟件配置項(xiàng)測(cè)試

文/朱文釗

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

1 引言

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

軟件配置項(xiàng)是一組能獨(dú)立編譯、運(yùn)行和管理并能滿足用戶最終需求的軟件集合，具有獨(dú)立的功能、性能、接口和人機(jī)界面等軟件特性[4]，因此在進(jìn)行配置項(xiàng)測(cè)試時(shí)需選取多種測(cè)試類型進(jìn)行驗(yàn)證。

2 航電軟件特性

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

3 配置項(xiàng)測(cè)試

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

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

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

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

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

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

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

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

3.2 保證對(duì)需求的全覆蓋

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

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

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

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

表2：配置項(xiàng)測(cè)試問題列表

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

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

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

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

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

3.4 填寫配置項(xiàng)測(cè)試問題記錄單

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

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

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

3.5 編寫測(cè)試計(jì)劃、測(cè)試說明和測(cè)試報(bào)告

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

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

4 結(jié)束語

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