李 磊

(中國船舶重工集團公司第七一〇研究所，湖北 宜昌 443000)

浮力調(diào)節(jié)軟件的單元測試技術(shù)研究

李 磊

(中國船舶重工集團公司第七一〇研究所，湖北 宜昌 443000)

為了提高嵌入式軟件的單元測試效率，同時能達到很好的測試效果，針對嵌入式軟件制定單元測試充分性準則和單元測試策略，并使用測試工具對嵌入式軟件進行單元測試具有實際意義；以浮力調(diào)節(jié)軟件為例，通過研究基于控制流的單元測試充分性準則，結(jié)合浮力調(diào)節(jié)軟件的單元測試需求，提出了針對浮力調(diào)節(jié)軟件的單元測試充分性準則；同時，考慮到圈復(fù)雜度和函數(shù)節(jié)點數(shù)對函數(shù)正確實現(xiàn)的影響，制定了基于優(yōu)先級的單元測試策略；利用自動化單元測試工具Testbed搭建了浮力調(diào)節(jié)軟件動態(tài)測試環(huán)境，通過代碼覆蓋率分析，幫助創(chuàng)建測試用例以達到單元測試充分性要求，從而實現(xiàn)了浮力調(diào)節(jié)軟件單元測試自動化；在自動化測試工具的幫助下，結(jié)合單元測試充分性準則和單元測試策略，最終實現(xiàn)嚴格而高效的單元測試。

浮力調(diào)節(jié)軟件；單元測試；單元測試充分性準則；單元測試策略；Testbed

0 引言

近年來，嵌入式系統(tǒng)的發(fā)展異常迅速，深入滲透到航空、航天、核電、汽車、電子等關(guān)鍵領(lǐng)域，導(dǎo)致嵌入式系統(tǒng)復(fù)雜度越來越高，安全性要求也越來越高。出于成本及安全性等多方面的考慮，原來用硬件實現(xiàn)的功能現(xiàn)在都盡可能地改用軟件來實現(xiàn)?，F(xiàn)在嵌入式系統(tǒng)中的增值功能也主要靠軟件完成，導(dǎo)致軟件所占的比重越來越大。在軟件生命周期中隨著軟件開發(fā)的進行，發(fā)現(xiàn)錯誤以及修正錯誤的成本越來越大。經(jīng)驗表明，對代碼開發(fā)早期進行集中測試可以減少測試的工作量與開發(fā)成本。單元測試在初始編碼階段提供了識別和改正錯誤的方法，從而降低了開發(fā)軟件的風險，幫助開發(fā)人員優(yōu)化設(shè)計并鼓舞了軟件開發(fā)團隊的士氣[1]。

由于時間和成本的約束，需要明確應(yīng)該對哪些模塊進行重點測試，通過分析和計算影響模塊的復(fù)雜度的度量元，建立單元測試的優(yōu)先級，合理劃分單元測試的時間，使單元測試更加具有針對性。窮舉的單元測試是不可能的，需要確定合理的單元測試充分性準則，并根據(jù)該準則決定何時停止設(shè)計更多的測試用例。

當前，軟件已成為嵌入式系統(tǒng)的重要部分，由于軟件自身的發(fā)展和市場成本的壓力，軟件必然是越來越復(fù)雜，要求軟件的開發(fā)時間卻越來越短，以至于對測試產(chǎn)生巨大壓力。充分結(jié)構(gòu)化的測試過程已無法獨立在短時間內(nèi)滿足質(zhì)量要求，因此必須使用測試工具，以保證測試進度和質(zhì)量[2]。使用自動化測試工具可以降低我們對驅(qū)動模塊的需求，流程分析工具可以列舉出程序中的路徑、找出從未被執(zhí)行的語句，以及找出變量在賦值前被使用的實例[3]，從而使測試過程中的枯燥勞動減至最小，測試效率和效果得到提升。

本文以浮力調(diào)節(jié)軟件為例，研究并實踐了控制流單元測試充分性準則，并且根據(jù)不同函數(shù)的復(fù)雜度，制定了基于優(yōu)先級的單元測試策略。最后，結(jié)合Testbed自動化測試工具，針對浮力調(diào)節(jié)軟件，設(shè)計并完成了嚴格而高效的單元測試。

1 浮力調(diào)節(jié)軟件單元測試充分性準則

單元測試就是驗證軟件單元的實現(xiàn)是否和單元的說明完全一致的相關(guān)聯(lián)的測試活動組成的。根據(jù)軟件單元的說明文檔(在實踐環(huán)境中，該文檔可能是一種說明語言，或者是一種自然語言或是狀態(tài)轉(zhuǎn)換圖)編寫測試用例，對重要的接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、獨立路徑和錯誤處理路徑，通過代碼檢查或執(zhí)行測試用例有效地進行測試[4]。

單元測試充分性準則被用來判斷設(shè)計的測試用例是否有效，并決定何時停止設(shè)計更多的測試用例，從而使得單元測試過程嚴格而高效。此處描述的單元測試充分性準則實質(zhì)上是設(shè)計測試用例時常用的白盒測試方法，即邏輯覆蓋準則。在使用Testbed自動化測試工具進行代碼覆蓋率測試時，每完成一個測試用例，都會直觀的反映在各種覆蓋率變化上，如果設(shè)計的測試用例沒有導(dǎo)致覆蓋率的任何變化，則該測試用例無效，當符合該模塊單元測試充分性準則對應(yīng)的覆蓋率達到100%時，就不需要再增加新的測試用例。根據(jù)實際進行單元測試所使用的單元測試充分性準則，僅介紹最常用的3種基于控制流的單元測試充分性準則。

1.1 基于控制流的單元測試充分性準則

語句覆蓋(Statement Coverage, SC)：設(shè)計足夠的測試用例，使被測試程序中每條語句至少執(zhí)行一次。語句覆蓋是較弱的準則，對于組合邏輯判斷條件，某些判斷條件出錯不會被發(fā)現(xiàn)。

判定覆蓋(Decision Coverage, DC)：設(shè)計足夠的測試用例，使得每一個判斷至少有一個為真和為假的輸出結(jié)果，或者說每條分支路徑都必須至少遍歷一次。判定覆蓋通常可以滿足語句覆蓋，但并不是所有情況都滿足。判定覆蓋是較強一些的準則，但仍然相當不足，其原因是“與”和“或”表達式中某些條件的結(jié)果可能會屏蔽掉或阻礙其他條件的判斷。比如，如果“與”表達式中有個條件為“假”，則無須計算該表達式中的后續(xù)條件。同樣，如果“或”表達式中有個條件為“真”，那么后續(xù)條件也無須計算。因此判定覆蓋準則不一定會發(fā)現(xiàn)邏輯表達式中的錯誤。

修正條件/判定覆蓋(Modified Condition/Decision Coverage, MC/DC)：該準則要就設(shè)計足夠多的測試用例，使入口和出口的每個點至少被調(diào)用一次，從而每個判定到所有可能的結(jié)果值都要至少轉(zhuǎn)換一次，判定中的每個條件可以獨立地顯示出它對判定結(jié)果的影響。該準則能夠部分解決判定覆蓋的問題，滿足多重條件覆蓋準則的測試用例集，同樣滿足語句覆蓋和判定覆蓋。

1.2 浮力調(diào)節(jié)軟件單元測試充分性準則

軟件測試領(lǐng)域存在2-8原則，即80%的錯誤是由20%的錯誤引起的，80%的測試成本和時間花在20%的模塊中[5]。所以根據(jù)單元測試充分性準則合理分配測試投入，才能達到更快的進度，更低的成本，更高的質(zhì)量。

根據(jù)軟件的要求程度，設(shè)計滿足覆蓋率要求的測試用例。對于嵌入式應(yīng)用中的一些要求可靠性極高的關(guān)鍵模塊，需要滿足修正條件/判定覆蓋。開展修正條件/判定覆蓋測試難度很大，會占用大量成本，所以對于一般模塊，只需要滿足語句覆蓋和判定覆蓋即可。

浮力調(diào)節(jié)控制器包括主、從控制器兩部分，控制器架構(gòu)為一主二從模式，主控制器包括主控制板和從控制板，從控制器只包含一個從控制板。浮力調(diào)節(jié)控制器主控制板和從控制板處理器均采用TI公司單片機MSP430F5438A單片機，設(shè)計上考慮兼容性，以單片機自帶的串口通信模塊、定時器模塊等為基準，軟件基于TI公司單片機的IAR編譯環(huán)境開發(fā)。浮力調(diào)節(jié)控制器主控軟件主要實現(xiàn)與自動駕駛儀通信、從控軟件通信、CTD數(shù)據(jù)采集、受控模式、浮力自適應(yīng)模式、定深模式及系統(tǒng)狀態(tài)信息合成反饋等功能，主控軟件程序流程圖如圖1所示。

圖1 主控軟件程序流程圖

根據(jù)軟件規(guī)格說明中描述的各模塊實現(xiàn)功能的重要性，得到浮力調(diào)節(jié)軟件單元測試充分性準則詳見下表1。

表1 浮力調(diào)節(jié)軟件單元測試充分性準則

2 基于優(yōu)先級的浮力調(diào)節(jié)軟件單元測試策略

2.1 浮力調(diào)節(jié)軟件關(guān)鍵模塊優(yōu)先級的度量元

經(jīng)驗表明，程序中一個模塊越復(fù)雜，其存在缺陷的可能性也就越大。根據(jù)浮力調(diào)節(jié)軟件各個模塊的復(fù)雜程度，可以對所有模塊進行優(yōu)先級排序，并以此建立基于優(yōu)先級的單元測試策略。程序模塊的復(fù)雜程度主要體現(xiàn)在以下兩個方面。

2.1.1 環(huán)路復(fù)雜性

環(huán)路復(fù)雜性可以采用McCabe復(fù)雜性度量法[6]來計算，一般用圈復(fù)雜度描述，記為V(G)。圈復(fù)雜度用來衡量一個程序模塊所包含的判定結(jié)構(gòu)的復(fù)雜程度，如果一個程序模塊的圈復(fù)雜度較大，則說明該模塊的代碼質(zhì)量可能較低，對其進行測試和維護的難度也較大。經(jīng)驗也表明，程序可能存在的缺陷數(shù)量，與圈復(fù)雜度有著很大相關(guān)性[7]。

圈復(fù)雜度計算公式如下：

V(G)=e-n+2

其中：e表示程序控制流圖中邊的數(shù)量，n表示程序控制流圖中節(jié)點的數(shù)量。圈復(fù)雜度還有更直觀的計算方法，因為圈復(fù)雜度所反映的是“判定條件”的數(shù)量，所以圈復(fù)雜度實際上就是等于判定節(jié)點的數(shù)量再加1，也即控制流圖的區(qū)域數(shù)。其對應(yīng)的計算公式如下：

V(G)=區(qū)域數(shù)=判定節(jié)點數(shù)+1

2.1.2 控制流節(jié)點數(shù)

在程序中，當兩個控制流跳轉(zhuǎn)發(fā)生交叉時，就產(chǎn)生了控制流節(jié)點?？刂屏鞴?jié)點的數(shù)量可以用來衡量程序模塊的復(fù)雜程度，記為Hknots。如果程序中一個模塊的控制流節(jié)點數(shù)越多，則意味著該模塊的復(fù)雜度可能越高。通過對代碼結(jié)構(gòu)進行重構(gòu)可以減少控制流節(jié)點數(shù)目，從而使該模塊的復(fù)雜程度得以降低。

2.2 浮力調(diào)節(jié)軟件單元測試模塊優(yōu)先級度量數(shù)學模型

浮力調(diào)節(jié)軟件單元測試模塊優(yōu)先級度量數(shù)學模型如下：

Hpriority=V(G)+Hknots

可以看出，Hpriority是被測模塊復(fù)雜度度量元的加權(quán)值，Hpriority越大，意味著該模塊的代碼復(fù)雜性越大，存在缺陷的可能性也就越大。通過計算程序中各模塊的優(yōu)先級度量Hpriority，并按該度量值大小進行排序，建立基于優(yōu)先級的單元測試策略，從而合理地分配各個模塊的測試資源。

2.3 基于優(yōu)先級的浮力調(diào)節(jié)軟件單元測試策略應(yīng)用

2.3.1 基于優(yōu)先級的浮力調(diào)節(jié)軟件單元測試策略應(yīng)用過程

(1)首先利用Testbed測試工具對將要進行單元測試的所有函數(shù)進行靜態(tài)分析，得到每一個被測函數(shù)的圈復(fù)雜度V(G)和節(jié)點數(shù)Hknots；

(2)根據(jù)浮力調(diào)節(jié)軟件單元測試模塊優(yōu)先級度量數(shù)學模型公式計算得到每一個函數(shù)的加權(quán)值Hpriority，然后按加權(quán)值Hpriority大小進行優(yōu)先級排序，得到浮力調(diào)節(jié)軟件代碼的復(fù)雜度分布；

(3)合理分配各個函數(shù)的測試工作量和時間，保證測試的進度，盡可能多的對重要并且復(fù)雜度高的函數(shù)進行測試。

2.3.2 基于優(yōu)先級的浮力調(diào)節(jié)軟件單元測試策略應(yīng)用實例

經(jīng)過Testbed自動化測試工具對浮力調(diào)節(jié)軟件進行靜態(tài)分析，在軟件質(zhì)量分析報告中，可以看到每一個要進行單元測試的函數(shù)圈復(fù)雜度和節(jié)點數(shù)[8]，如圖2所示。

根據(jù)前面提出的浮力調(diào)節(jié)軟件單元測試模塊優(yōu)先級度量數(shù)學模型公式，加權(quán)確定每一個函數(shù)單元測試的優(yōu)先級，并按優(yōu)先級排序，得到浮力調(diào)節(jié)軟件各函數(shù)優(yōu)先級順序如表2所示。

表2 浮力調(diào)節(jié)軟件各函數(shù)優(yōu)先級順序

3 浮力調(diào)節(jié)軟件自動化單元測試實施過程

根據(jù)浮力調(diào)節(jié)軟件設(shè)計說明，該軟件基于TI公司單片機的IAR編譯環(huán)境，其單元測試實施過程如下：

(1)首先需要使用TBconfig來配置IAR編譯環(huán)境下的仿真單元測試環(huán)境，然后再Testbed上設(shè)置編譯器為IAR；

(2)打開單元/集成級測試工具TBrun，該工具可以自動生成軟件測試驅(qū)動和樁模塊，從而節(jié)省時間，使測試人員將重點放在設(shè)計測試用例上，提高軟件測試效率，同時提高軟件測試人員積極性[9-10]。針對要測試的函數(shù)生成測試用例，再對測試用例中調(diào)用的函數(shù)進行打樁操作。

圖2 函數(shù)圈復(fù)雜度和節(jié)點數(shù)

(3)查看被測函數(shù)的控制流圖，結(jié)合程序規(guī)格說明并根據(jù)控制流圖設(shè)計對應(yīng)的測試用例，得到輸入值以及預(yù)計輸出值。以函數(shù)fzxqwaterbak(void)為例，該函數(shù)代碼如下所示：

void fzxqwaterbak(void)

{

comandconflict=1;

Seepage_num=0;

CreateState();

if (((cong1_state.dta[1] & 0x1F)==0x00) && (cong2_state.dta[1] & 0x1F)==0x00))

{

fzxqstart=0x00;

}

cana_sendMessage(cong_state);

cana_sendMessage(cong_state2);

cana_sendMessage(cong_state3);

}

在輸入輸出窗口中僅留下對測試結(jié)果有影響的變量，并將前面得到的輸入和輸出值填入到相應(yīng)位置。執(zhí)行該測試用例，最終會顯示該測試用例是否通過，測試用例輸入輸出及測試結(jié)果如圖3所示。

圖3 測試用例輸入輸出及測試結(jié)果

(4)在File View窗口中查看覆蓋率，通過覆蓋率變化可以直觀了解對該函數(shù)的測試是否已經(jīng)達到充分性準則的要求，如果沒有達到，則查看當前的控制流圖，查看有哪個分支沒有覆蓋到，控制流圖覆蓋情況如圖4所示。

圖4 控制流圖覆蓋情況

實心表示已經(jīng)覆蓋到的語句和分支，線段面積表示未覆蓋的部分。如果未覆蓋到的原因是缺少相應(yīng)測試用例，則新增測試用例，重復(fù)步驟2～4，否則分析原因并記錄；

(5)分析測試結(jié)果，記錄相關(guān)問題，完成測試報告。

4 總結(jié)

單元測試技術(shù)對大型程序尤其有用，通過這種技術(shù)來測試程序的組件如子程序、子函數(shù)、類以及過程。單元測試和其它類型的測試有著同樣的目標：找出程序不滿足規(guī)格說明書的地方。

單元測試中測試用例的設(shè)計過程應(yīng)該是，使用一種或多種白盒測試方法分析模塊的邏輯結(jié)構(gòu)，然后使用黑盒測試方法對照模塊的規(guī)格說明以補充測試用例。

一個測試用例除了需要對輸入數(shù)據(jù)進行描述外，還需要對在相應(yīng)輸入數(shù)據(jù)下的正確輸出結(jié)果做出精確描述。這樣才能避免某個似是而非、實際上是錯誤的結(jié)果可能會被解釋成正確的結(jié)論的事情發(fā)生。

當測試用例造成模塊輸出的實際結(jié)果與預(yù)期結(jié)果不匹配的情況時，存在兩個可能的解釋：要么該模塊存在錯誤，要么預(yù)期的結(jié)果不正確。為了將這種混亂降低到最小程度，應(yīng)在測試執(zhí)行之前對測試用例集進行審核或檢驗。

在進行單元測試之前，需要仔細閱讀程序規(guī)格說明書和模塊的源代碼。對測試系統(tǒng)有了一個大致了解以后，提前針對各個模塊制定對應(yīng)的單元測試充分性準則和基于優(yōu)先級的單元測試策略，從而更為合理地分配單元測試工作量，達到很好的測試效果。

5 結(jié)束語

通過應(yīng)用本文所論述的單元測試充分性準則和基于優(yōu)先級的單元測試策略，并借助自動化測試工具Testbed，測試人員目標性更強，人員分配和時間分配更為合理，單元測試的效果得到了提升，從而高效而嚴格的完成了對浮力調(diào)節(jié)軟件進行的單元測試。

[1] 冷知見.軟件自動化測試方法的研究與應(yīng)用[D].武漢:武漢理工大學,2011.

[2] 楊一波.無人機飛行控制軟件測試技術(shù)研究[D].南京:南京航空航天大學,2008.

[3] Glenford J.Myers, Tom Badgett, Corey Sandler.軟件測試的藝術(shù)[M].北京:機械工業(yè)出版社,2012.

[4] 袁玉宇.軟件測試與質(zhì)量保證[M].北京:北京郵電大學出版社,2008.

[5] 肖利瓊.軟測之魂:核心測試設(shè)計精解[M].北京:電子工業(yè)出版社,2011.

[6] 金維佳,施小敏.基于嵌入式軟件的覆蓋測試問題研究[J].信息技術(shù),2011(4):117-120.

[7] 劉媛媛.飛行控制軟件單元測試的實施[D].北京:北京郵電大學,2010.

[8] 胡丹瑞.基于LDRA Testbed的軟件靜態(tài)測試研究與實現(xiàn)[J].計算機安全,2012(6):69-71.

[9] 朱昭俊,蔣文丹,蘇 賽.TBrun在單元測試中的應(yīng)用[J].信息安全與技術(shù),2013(2):85-96.

[10] 徐潤德,陳 亞,趙慕奇.基于LDRA Testbed的軟件單元測試[J].海軍航空工程學院學報,2011,26(3):356-360.

Research on Unit Testing Techniques of Buoyancy Adjusting Software

Li Lei

(No.710 Research Institute of CSIC, Yichang 443000, China)

In order to improve the efficiency of embedded software unit testing, and achieve good testing result in the meantime. It has practical significance to make adequacy criteria and strategy of unit testing and use automatic unit testing tool to accomplish unit testing. Take the buoyancy adjusting software for example, by studying the adequacy criteria of unit testing based on control flow and unit testing requirement of the buoyancy adjusting software, the unit testing adequacy criteria of buoyancy adjusting software has been put forward. Meanwhile, considering the influence of cyclomatic complexity and knots on realizing functions correctly, the unit testing strategy based on priority has been made. The dynamic testing environment is established by Testbed, which is an automatic unit testing tool. By analyzing code coverage, Testbed helped to create test cases to meet the adequacy criteria requirements, thereby realized the automatic unit testing of the buoyancy adjusting software. With the help of automatic unit testing tool, adequacy criteria and strategy of unit testing, rigorous and efficient unit testing has been accomplished in the end.

buoyancy adjusting software; unit testing; adequacy criteria of unit testing; unit testing strategy; Testbed

2016-09-18；

2016-11-21。

李 磊(1987-)，男，湖北宜昌人，碩士，主要從事軟件測試方向的研究。

1671-4598(2017)03-0119-04

10.16526/j.cnki.11-4762/tp.2017.03.033

TP311.5

A