艦炮火控軟件單元測試研究

曹曉勇 王德偉 劉 希

摘 要:針對艦炮火控軟件單元測試工作量大、效率低的問題及現(xiàn)狀,基于軟件單元測試的理論,分析研究了單元測試所關(guān)注的測試內(nèi)容、測試方法、測試環(huán)境搭建以及測試用例設(shè)計(jì)等要點(diǎn),同時(shí)結(jié)合某型號產(chǎn)品艦炮火控軟件單元測試的實(shí)踐,總結(jié)了艦炮火控軟件單元測試的經(jīng)驗(yàn),并在此基礎(chǔ)上提出了有效提高單元測試效率,從而提高艦炮火控軟件質(zhì)量的方法和途徑。

關(guān)鍵詞:艦炮火控軟件;單元測試;靜態(tài)分析;白盒測試;黑盒測試

中圖分類號:TP311.5 文獻(xiàn)標(biāo)識碼:A

文章編號:1004-373X(2009)21-013-03

Research on Unit Testing for the Software of Shipborne Gunnery Fire Control System

CAO Xiaoyong,WANG Dewei,LIU Xi

(Jiangsu Automation Research Institute,China Shipbuilding Industry Corporation,Lianyungang,222006,China)

Abstract:Aimed at the problem and actuality of mass workload and low efficiency in unit testing for the software of shipborne gunnery fire control system.Based on the fundamental theory of software testing,the essential points of unit testing,such as testing content,testing methods,testing environment building and testing cases designing are researched,the 〆xperience of unit testing for the software of shipborne gunnery fire control system is summarized.Some means and approaches to improve the efficiency of unit testing and the quality of software are proposed.

Keywords:shipborne gunnery fire control system Software;unit testing;static analysis;white box testing;black box testing

隨著艦炮火控技術(shù)的不斷發(fā)展,艦炮火控軟件的精確度和復(fù)雜度越來越高,繼而對火控軟件的質(zhì)量和可靠性要求也就相應(yīng)提高。而軟件測試不僅是保證軟件可靠性的必要和有效手段,更是軟件質(zhì)量保證的關(guān)鍵步驟。從軟件生命周期全過程來看,測試可分為單元測試、集成測試、確認(rèn)測試、系統(tǒng)測試等階段[1]。其中,單元測試是整個(gè)測試過程中最基礎(chǔ)、最核心的一個(gè)環(huán)節(jié),單元測試不僅要針對每一個(gè)模塊進(jìn)行,而且每個(gè)模塊的每條語句至少要遍歷一次,其工作量之大也是可想而知的[2]。那么,艦炮火控軟件單元測試到底該如何進(jìn)行,才能有效地提高測試效率,逐漸成為大家日益關(guān)注的問題。

1 單元測試概述

單元測試是針對軟件設(shè)計(jì)的最小單位——模塊進(jìn)行的,其測試依據(jù)是軟件的詳細(xì)設(shè)計(jì)說明[3]。測試者根據(jù)詳細(xì)設(shè)計(jì)說明和源程序,了解模塊的輸入、輸出條件和邏輯結(jié)構(gòu),并通過測試來發(fā)現(xiàn)編碼是否有誤、程序邏輯結(jié)構(gòu)是否合理、模塊的功能實(shí)現(xiàn)是否正確、與詳細(xì)設(shè)計(jì)文檔要求是否一致等。單元測試主要包括功能測試和結(jié)構(gòu)覆蓋測試,針對有性能(運(yùn)行時(shí)間或占用空間)要求的模塊和單元,還有必要做性能測試。單元測試通常采用白盒測試為主,黑盒測試為輔的策略[4]。

2 單元測試關(guān)注要點(diǎn)

2.1 單元測試內(nèi)容

在單元測試中,需要對以下五個(gè)方面的內(nèi)容進(jìn)行測試[5]:

(1) 模塊接口測試。測試模塊的數(shù)據(jù)流,主要指模塊的形式參數(shù)與實(shí)際參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配;全局變量的定義在各模塊中是否一致等。

(2) 局部數(shù)據(jù)結(jié)構(gòu)測試。模塊的局部數(shù)據(jù)結(jié)構(gòu)是常見的錯(cuò)誤來源,這些錯(cuò)誤主要體現(xiàn)在數(shù)據(jù)類型說明不正確或不一致;局部變量未初始化就被使用;初始值或默認(rèn)值錯(cuò)誤等。

(3) 路徑測試。對執(zhí)行路徑和循環(huán)進(jìn)行測試,通常采用白盒測試方法來設(shè)計(jì)測試用例,用以查找由于錯(cuò)誤的計(jì)算、不正確的比較或不正常的控制流而導(dǎo)致的錯(cuò)誤。

(4) 錯(cuò)誤處理測試。對模塊的容錯(cuò)能力進(jìn)行測試,比較完善的設(shè)計(jì)要求模塊能夠預(yù)見出錯(cuò)的條件,并設(shè)置適當(dāng)?shù)某鲥e(cuò)處理對策,以便在程序出錯(cuò)時(shí),能對出錯(cuò)程序進(jìn)行安排,保證其邏輯上的正確性。

(5) 邊界測試。重在檢測以下問題:如在n次循環(huán)的第0次、1次、n次是否有錯(cuò);運(yùn)算或判斷中取最大最小值時(shí)是否有錯(cuò);數(shù)據(jù)流、控制流中剛好等于、大于、┬∮諶范ǖ謀冉現(xiàn)凳筆欠裼寫淼取

2.2 單元測試的方法

單元測試的方法一般有三種:靜態(tài)分析、黑盒測試、白盒測試。其中靜態(tài)分析又稱為靜態(tài)測試,黑盒測試和白盒測試被稱為動(dòng)態(tài)測試

2.2.1 靜態(tài)分析

靜態(tài)分析是指不執(zhí)行被測代碼,人工或借助專用工具審查軟件設(shè)計(jì)文檔和程序源代碼,對軟件單元或模塊的控制流、數(shù)據(jù)流、接口特性及表達(dá)式等進(jìn)行分析,從而保證代碼正確性、清晰性、規(guī)范性、一致性、算法高效性,并盡可能地發(fā)現(xiàn)程序中隱含的錯(cuò)誤的過程[6]。通常,程序源代碼的靜態(tài)分析,包括從命名規(guī)則檢查、寄存器使用、編碼格式、出/入口連結(jié)、編程語言使用、存儲(chǔ)器使用、測試和轉(zhuǎn)移、可維護(hù)性、邏輯和程序多余物等十個(gè)方面對代碼進(jìn)行審查。按軟件質(zhì)量模型規(guī)定的相關(guān)度量指標(biāo)對源代碼的文本、注釋、扇入/扇出數(shù)、圈復(fù)雜度等指標(biāo)進(jìn)行度量。

2.2.2 黑盒測試

黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動(dòng)測試。它是在已知軟件單元所具有的功能的前提下,不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性,把程序看作一個(gè)不能打開的黑盒子,檢查程序功能是否按照軟件詳細(xì)設(shè)計(jì)的規(guī)定正確實(shí)現(xiàn)、程序是否能正確地接收輸入數(shù)據(jù)從而產(chǎn)生正確的輸出信息,并且保持外部信息(如數(shù)據(jù)庫或文件)的完整性[7]。

黑盒測試從原則上講應(yīng)是窮舉輸入測試,只有把所有可能的輸入都作為測試情況使用,才能以這種方法查出程序中的所有錯(cuò)誤。實(shí)際測試情況有無窮多個(gè),而且測試人員不僅要測試所有合法的輸入,還要對那些不合法但是可能的輸入進(jìn)行測試。顯然,把輸入數(shù)據(jù)的所有可能取值都進(jìn)行測試,是不可能也是無意義的。設(shè)計(jì)黑盒測試的測試用例有很多種方法,例如等價(jià)類劃分法、邊界值分析法、錯(cuò)誤推測法等。最常用的方法是等價(jià)類劃分法。這種方法將測試空間的輸入數(shù)據(jù)分為三類,即正常輸入、邊界輸入和非法輸入,每種輸入還可進(jìn)行更詳細(xì)的劃分,在設(shè)計(jì)測試用例時(shí)取每類的若干個(gè)數(shù)據(jù)作為輸入數(shù)據(jù),如果測試通過,可以肯定同類的其他輸入也是可以通過的。這種方法不僅有助于提高測試用例的有效性,而且有助于提高黑盒測試的效率。

2.2.3 白盒測試

除黑盒測試以外,單元測試還需要從另一個(gè)角度即程序的邏輯結(jié)構(gòu)來設(shè)計(jì)測試用例,并用邏輯覆蓋率來衡量測試的完整性,即所謂的白盒測試[8]。對于白盒測試的邏輯覆蓋率,一般有專門的覆蓋率測試工具來完成。

白盒測試用例的設(shè)計(jì)方法是畫出程序的邏輯結(jié)構(gòu)圖(如程序流程圖或控制流圖),并根據(jù)邏輯結(jié)構(gòu)圖設(shè)計(jì)測試用例。白盒測試的邏輯單位主要有語句、分支、條件、條件值、條件值組合、路徑等。

一般來講,與條件直接有關(guān)的錯(cuò)誤主要是邏輯操作符錯(cuò)誤,例如:將“||”寫成“&&”,或在“!=”中漏了寫“!”等,所以在具體的白盒測試中,只要采用分支覆蓋與條件覆蓋的組合,基本上可以發(fā)現(xiàn)這些錯(cuò)誤,另一方面,要全部完成語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋的成本和代價(jià)是很高的,其工作量更是難以估計(jì),僅條件值覆蓋與條件值組合覆蓋往往就需要設(shè)計(jì)和執(zhí)行大量的測試用例。因此,從測試的投入和產(chǎn)出角度來說,進(jìn)行白盒測試時(shí),并不是覆蓋的邏輯單位越多越好,不同關(guān)鍵等級的模塊應(yīng)采用不同的邏輯覆蓋單位,這樣才能最好地體現(xiàn)測試的有效性。

2.3 單元測試的環(huán)境搭建和用例設(shè)計(jì)

單元測試是針對程序最小單元的測試,單元本身通常不能單獨(dú)運(yùn)行,因此在單元測試時(shí)需要為被測單元設(shè)計(jì)樁模塊和驅(qū)動(dòng)模塊。

(1) 驅(qū)動(dòng)模塊:相當(dāng)于所測模塊的主程序。它接收測試數(shù)據(jù),將這些數(shù)據(jù)傳送給被測模塊,最后再輸出實(shí)際測試結(jié)果。

(2) 樁模塊:用于代替被測模塊所調(diào)用的下層模塊,其作用是返回被測模塊所需要的數(shù)據(jù)和信息。

驅(qū)動(dòng)模塊、被測模塊、樁模塊三者共同構(gòu)成了單元測試“測試環(huán)境”,如圖1所示。

測試用例設(shè)計(jì)的目的是驗(yàn)證程序的功能、性能和結(jié)構(gòu),找出程序中隱含的錯(cuò)誤和缺陷。測試用例設(shè)計(jì)的基本原則是[9]:

(1) 一個(gè)好的測試用例在于它能發(fā)現(xiàn)至今未能發(fā)現(xiàn)的錯(cuò)誤或缺陷;

(2) 測試用例至少由測試輸入和測試輸出兩部分組成;

(3) 設(shè)計(jì)測試用例時(shí),應(yīng)考慮到合理的和不合理的輸入條件;

(4) 窮舉測試是不可能的,但可以通過設(shè)計(jì)測試用例,覆蓋所有的條件;

(5) 對發(fā)現(xiàn)錯(cuò)誤和缺陷較多的程序段,應(yīng)著重進(jìn)行更深入的測試。

3 基于實(shí)踐的測試經(jīng)驗(yàn)和建議

艦炮火控軟件是實(shí)時(shí)性要求較高的嵌入式軟件,其軟件與硬件具有極高的耦合度,在通用PC機(jī)平臺(tái)上常常無法運(yùn)行,需要特定的專用計(jì)算機(jī)硬件平臺(tái)及專用外部設(shè)備。另外,雖然艦炮火控軟件大多數(shù)采用的是結(jié)構(gòu)化設(shè)計(jì),但近年來隨著艦炮火控軟件技術(shù)的不斷發(fā)展,面向?qū)ο蟮脑O(shè)計(jì)越來越多地被接納和采用。

針對艦炮火控軟件的這些特點(diǎn),選擇了LDRA公司的TestBed/Tbrun系列測試工具作為某型號軟件產(chǎn)品單元測試的基本工具,并進(jìn)行了靜態(tài)分析、黑盒測試和白盒測試。

根據(jù)要完成的測試任務(wù),采用了如圖2所示的基于目標(biāo)機(jī)的交叉測試環(huán)境。宿主機(jī)是通用Windows平臺(tái),安裝Tornado 2.0開發(fā)環(huán)境以及測試工具LDRA Testbed,完成被測模塊的插裝及編譯鏈接,產(chǎn)生可執(zhí)行的目標(biāo)代碼。宿主機(jī)與目標(biāo)機(jī)之間通過網(wǎng)絡(luò)完成代碼下載、測試數(shù)據(jù)獲取以及覆蓋率分析。

通過本次測試實(shí)踐,獲得如下經(jīng)驗(yàn)和建議:

(1) 在結(jié)構(gòu)化程序中,所謂的單元是指函數(shù),而在面向?qū)ο蟮某绦蛑?單元的概念發(fā)生了變化,而是指類。從對某型號軟件產(chǎn)品單元測試的實(shí)踐來看,以類作為測試單位,復(fù)雜度高,可操作性較差,因此仍然主張以函數(shù)作為單元測試的基本單位,但可以用一個(gè)測試類來組織某個(gè)類的所有測試函數(shù)。需要說明的是,單元測試不應(yīng)過分強(qiáng)調(diào)面向?qū)ο?因?yàn)榫植看a依然是結(jié)構(gòu)化的。單元測試的工作量較大,簡單實(shí)用高效才是硬道理。

(2) 靜態(tài)分析能夠有效地發(fā)現(xiàn)30%~70%的語法錯(cuò)誤和編碼錯(cuò)誤,但很難挖掘出程序代碼中的隱性錯(cuò)誤和缺陷,尤其是需要軟件動(dòng)態(tài)運(yùn)行才能暴露出來的錯(cuò)誤。黑盒測試能夠動(dòng)態(tài)檢查并較好地發(fā)現(xiàn)軟件單元的功能性錯(cuò)誤,但其測試的完整性卻難于測量。而白盒測試不僅能夠動(dòng)態(tài)運(yùn)行檢查軟件單元的邏輯錯(cuò)誤,而且其

覆蓋率測試恰恰具有易于衡量測試完整性的優(yōu)點(diǎn)。所以對于單元測試來講,三者之間具有極好的互補(bǔ)性,通常推薦的單元測試步驟和過程是,先進(jìn)行靜態(tài)分析,然后進(jìn)行黑盒的功能測試,黑盒測試后統(tǒng)計(jì)覆蓋率,如果覆蓋未達(dá)到測試計(jì)劃中所規(guī)定的標(biāo)準(zhǔn),那么針對未被覆蓋的語句部分代碼進(jìn)行邏輯分析,并結(jié)合白盒測試的測試用例再次對軟件單元進(jìn)行測試,直到滿足覆蓋要求。同時(shí),對無法覆蓋的語句或分支也要給出說明和理由。

(3) 對于白盒測試的幾種邏輯單位的測試,通常推薦的步驟和方法是“先簡單后復(fù)雜”。例如,進(jìn)行黑盒測試后統(tǒng)計(jì)覆蓋率,先檢查是否有語句未覆蓋,若有則設(shè)計(jì)測試用例覆蓋它,然后用同樣方法完成條件覆蓋、分支覆蓋和路徑覆蓋,這樣既檢驗(yàn)了黑盒測試的完整性,又避免了重復(fù)的工作,用較少的時(shí)間成本獲得了較高的測試效率。

4 結(jié) 語

隨著火控技術(shù)不斷發(fā)展,艦炮火控軟件的工程化水平也在不斷改進(jìn),對軟件測試的要求也在進(jìn)一步提高,在這種情況下如何更好地開展軟件測試工作,如何將軟件測試的理論和方法更好地運(yùn)用到軟件產(chǎn)品的測試實(shí)踐中去,是很有意義和價(jià)值的問題。本文論述了軟件單元測試的理論和方法,介紹了單元測試在實(shí)際工作中的實(shí)踐和經(jīng)驗(yàn),希望對艦炮火控軟件的測試工作能夠有進(jìn)一步的推動(dòng)和提高。

參考文獻(xiàn)

[1] 朱少民.軟件測試方法和技術(shù)[M].北京:清華大學(xué)出版社,2005.

[2]John D Musa.軟件可靠性工程[M].北京:機(jī)械工業(yè)出版社,2003.

[3]何永軍.聲納嵌入式軟件的單元測試及結(jié)構(gòu)覆蓋率測試方法[J].聲學(xué)與電子工程,2004(4):45-47.

[4]Roger S Pressman.軟件工程——實(shí)踐者的研究方法[M].梅宏,譯.北京:機(jī)械工業(yè)出版社,2004.

[5]張猛,毛亮.航天嵌入式軟件的單元測試方法探討[J].航天器工程,2006,15(2):32-35.

[6]Dirk Huberty.軟件質(zhì)量與軟件測試[M].馬博,趙云龍,譯.北京:清華大學(xué)出版社,2003.

[7]Shari Lawrence Pfleeger.軟件工程——理論與實(shí)踐[M].北京:高等教育出版社,2001.

[8]宮云戰(zhàn).軟件測試[M].北京:國防工業(yè)出版社,2006.

[9]Ron Patton.軟件測試[M].北京:機(jī)械工業(yè)出版社,2000.

作者簡介 曹曉勇 女,1978年出生,河南漯河人,工程師,學(xué)士。研究方向?yàn)榛鹂啬Ｐ团c軟件,嵌入式軟件測試。

王德偉 男,1982年出生,山西原平人,助理工程師,學(xué)士。研究方向?yàn)榛鹂啬Ｐ团c軟件。

劉 希 男,1986年出生,湖北襄樊人,助理工程師,學(xué)士。研究方向?yàn)榍度胧杰浖y試。