曹曉勇 王德偉 劉 希

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

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

中圖分類號:TP311.5 文獻標識碼: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

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

1 單元測試概述

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

2 單元測試關注要點

2.1 單元測試內容

在單元測試中,需要對以下五個方面的內容進行測試[5]:

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

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

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

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

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

2.2 單元測試的方法

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

2.2.1 靜態(tài)分析

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

2.2.2 黑盒測試

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

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

2.2.3 白盒測試

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

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

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

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

單元測試是針對程序最小單元的測試,單元本身通常不能單獨運行,因此在單元測試時需要為被測單元設計樁模塊和驅動模塊。

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

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

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

測試用例設計的目的是驗證程序的功能、性能和結構,找出程序中隱含的錯誤和缺陷。測試用例設計的基本原則是[9]:

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

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

(3) 設計測試用例時,應考慮到合理的和不合理的輸入條件;

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

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

3 基于實踐的測試經驗和建議

艦炮火控軟件是實時性要求較高的嵌入式軟件,其軟件與硬件具有極高的耦合度,在通用PC機平臺上常常無法運行,需要特定的專用計算機硬件平臺及專用外部設備。另外,雖然艦炮火控軟件大多數(shù)采用的是結構化設計,但近年來隨著艦炮火控軟件技術的不斷發(fā)展,面向對象的設計越來越多地被接納和采用。

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

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

通過本次測試實踐,獲得如下經驗和建議:

(1) 在結構化程序中,所謂的單元是指函數(shù),而在面向對象的程序中,單元的概念發(fā)生了變化,而是指類。從對某型號軟件產品單元測試的實踐來看,以類作為測試單位,復雜度高,可操作性較差,因此仍然主張以函數(shù)作為單元測試的基本單位,但可以用一個測試類來組織某個類的所有測試函數(shù)。需要說明的是,單元測試不應過分強調面向對象,因為局部代碼依然是結構化的。單元測試的工作量較大,簡單實用高效才是硬道理。

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

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

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

4 結 語

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

參考文獻

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

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

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

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

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

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

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

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

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

作者簡介 曹曉勇 女,1978年出生,河南漯河人,工程師,學士。研究方向為火控模型與軟件,嵌入式軟件測試。

王德偉 男,1982年出生,山西原平人,助理工程師,學士。研究方向為火控模型與軟件。

劉 希 男,1986年出生,湖北襄樊人,助理工程師,學士。研究方向為嵌入式軟件測試。