軟件測試方法的研究與應(yīng)用

武昭宇，張月琴，閻 華

(太原理工大學(xué) 信息化管理與建設(shè)中心,太原 030024)

?

軟件測試方法的研究與應(yīng)用

武昭宇，張月琴，閻 華

(太原理工大學(xué) 信息化管理與建設(shè)中心,太原 030024)

對軟件需求規(guī)格說明書的靜態(tài)測試方法、基于路徑的白盒測試方法和黑盒測試方法進(jìn)行了討論和研究。針對圖形軟件的測試提出一種可視化測試方法,并給出了以印刷電路版圖為例進(jìn)行測試的處理算法和操作步驟；通過實際案例“數(shù)字檔案系統(tǒng)”說明軟件需求規(guī)格說明書測試方法和基于路徑測試方法的應(yīng)用。該研究對于軟件開發(fā)和測試人員在選擇和應(yīng)用測試方法時提供一定的參考和幫助。

軟件質(zhì)量;軟件測試;需求規(guī)格說明;基本路徑;決策表;可視化

軟件質(zhì)量問題由來已久,軟件測試的目的是盡可能早和盡可能多的尋找軟件中存在的錯誤和缺陷。軟件測試作為軟件工程學(xué)科的分支之一,由于起步較晚,重視不夠,并且涉及的知識面也比較廣,如程序找錯、圖論應(yīng)用、軟件質(zhì)量保證、軟件管理以及軟件復(fù)雜性度量等,因此從軟件測試?yán)碚摵同F(xiàn)有的測試方法、技術(shù)和工具等來看都滿足不了現(xiàn)在軟件開發(fā)的實際要求。只有對軟件應(yīng)用的所有運行環(huán)境、執(zhí)行路徑、語句、以及判斷分支等進(jìn)行完全測試才能確保軟件測試的徹底性,但完全測試用例數(shù)和時間都是一個天文數(shù)字。想要遍歷所有的執(zhí)行路徑一般是很難做到,即使所有的路徑都測試過了,覆蓋率幾乎達(dá)到100%,但軟件在某種特定環(huán)境下仍然可能出錯。因此要在短時間內(nèi)較好的完成測試必須收集資料,仔細(xì)研究,精心設(shè)計測試用例,掌握好測試度。

科學(xué)的測試是貫穿在整個軟件開發(fā)生命周期的測試,所以應(yīng)該突破對故有測試的理解,著眼于軟件開發(fā)的整個生命周期,分析軟件開發(fā)過程中可能會出現(xiàn)的一些錯誤和錯誤源。特別注意編碼之前各個開發(fā)階段的測試工作,以此保證軟件的質(zhì)量。

1 常用軟件測試方法的討論與研究

軟件測試方法主要分為兩種:靜態(tài)測試和動態(tài)測試。在測試過程中,測試人員可將靜態(tài)測試和動態(tài)測試同時交叉使用,盡早來發(fā)現(xiàn)軟件中的錯誤和缺陷。靜態(tài)測試方法是采用人工測試和計算機(jī)輔助靜態(tài)分析來查找軟件中的錯誤和缺陷,并不在計算機(jī)上實際運行被測程序。對模塊的源代碼進(jìn)行分析、研讀、走查，對軟件產(chǎn)品的需求和設(shè)計規(guī)格說明書的評審、對代碼的復(fù)審等,是靜態(tài)測試中檢驗軟件質(zhì)量常用方法。靜態(tài)測試的查錯和分析功能是其他方法所不能替代的。

動態(tài)測試方法是通過真正運行被測程序來發(fā)現(xiàn)軟件中的錯誤和缺陷,從而來檢驗軟件的運行過程中是否符合期望要求或者運行結(jié)果是否正確。一般意義上的測試大多數(shù)指動態(tài)測試。傳統(tǒng)意義上的動態(tài)測試分為兩種：白盒方法和黑盒方法。白盒方法是能夠看清楚事物的內(nèi)部,即了解被測軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和運行機(jī)制來處理和解決問題;黑盒方法是把事物看成一個整體,來測試產(chǎn)品的外部功能。下面對幾種常用而又典型的軟件測試方法進(jìn)行討論與研究。

1.1 軟件需求規(guī)格說明書測試方法

傳統(tǒng)軟件開發(fā)中的瀑布模型,把需求和測試劃分為兩個不同的階段,而且相距較遠(yuǎn),認(rèn)為在軟件需求分析階段,測試還沒有開始,隨著軟件系統(tǒng)規(guī)模和復(fù)雜性的不斷擴(kuò)大,這個觀點得到了糾正。DOROTHY[1]指出,在軟件的需求分析階段,測試就開始介入的話,能夠使得軟件的需求分析更加詳盡。需求分析的越詳盡,到軟件驗收時功能性錯誤會越少[2]。

對于軟件需求規(guī)格說明書(Software Requirement Specfication，SRS)的測試并沒有一個系統(tǒng)的方法,一般采用靜態(tài)測試方法。為了提高軟件的質(zhì)量,可以采用比較嚴(yán)謹(jǐn)?shù)臎]有二義性的形式化方法來完成SRS,對于形式化的SRS即可采用形式化的測試方法。形式化方法的基礎(chǔ)是數(shù)學(xué)和邏輯學(xué),其結(jié)果語義清晰,無二義性[3]。但目前大部分人為了簡單方便則采用一種半形式化方法即自然語言和邏輯模型(數(shù)據(jù)流圖、數(shù)據(jù)字典)或用例模型(用例圖)來描述,因此錯誤難免。衡量SRS質(zhì)量的標(biāo)準(zhǔn)是準(zhǔn)確、全面、適宜的描述用戶的功能需求和非功能需求。對于半形式化方法描述SRS,主要采用靜態(tài)測試方法即:正式的會議評審和非正式的面對面討論、走查等方法來發(fā)現(xiàn)與用戶需求不一致、描述不完整、不正確、不清楚及書寫不規(guī)范等錯誤。

1.2 基本路徑測試方法

基本路徑測試方法是在程序控制流圖的基礎(chǔ)上,通過對程序控制流圖分析和判斷來計算環(huán)路復(fù)雜性,導(dǎo)出基本路徑集中的獨立路徑條數(shù),然后根據(jù)獨立路徑條數(shù)來設(shè)計測試用例。設(shè)計出的測試用例能保證被測程序的路徑至少能通過一次,即每條可執(zhí)行語句至少被執(zhí)行一次。 基本路徑測試方法是一種白盒測試方法[4]。

環(huán)路復(fù)雜性是定量度量程序邏輯復(fù)雜度的一種尺度[5]。從程序的環(huán)路復(fù)雜性可以計算出程序中基本路徑集中的獨立路徑條數(shù)。這是確定被測程序中每一條語句至少被執(zhí)行一次所必須的最大測試用例數(shù)。根據(jù)獨立路徑條數(shù)來設(shè)計測試用例,設(shè)計出的測試用例要保證基本路徑集中的每一條路徑必須要執(zhí)行一次。

獨立路徑是指至少引入被測程序的一個新的可執(zhí)行語句集或者一個新的條件路徑。一條獨立路徑至少應(yīng)該包含有一條在其它獨立路徑中從未有過的邊的路徑[6]。由獨立路徑組成的基本路徑集合并不唯一,但每條路徑是唯一的。對于給定的程序流程控制圖,可以得到不同的基本路徑集合。

1.3 決策表測試方法

決策表測試方法是一種黑盒測試方法也稱功能測試法[7]。決策表也叫判定表，通常判定表在需求分析階段可以描述數(shù)據(jù)流圖中的加工邏輯,也可以在詳細(xì)設(shè)計階段對模塊的算法和數(shù)據(jù)結(jié)構(gòu)進(jìn)行描述,同時還是一種動態(tài)的功能測試方法。決策表是從輸入條件的完全組合來滿足測試的覆蓋率要求,具有很嚴(yán)格的邏輯性,所以在所有功能測試方法中,基于決策表的測試用例設(shè)計方法是最嚴(yán)格的,測試用例具有很高的完整性。比較適合描述不同條件集合下采取行動的若干組合情況,即對各個條件的組合進(jìn)行分析,從而設(shè)計測試用例來覆蓋各種組合。決策表可以清晰地表明復(fù)雜的邏輯關(guān)系。一張決策表由4部分組成[8]:左上部是條件樁,列出被測程序所有的條件類別;右上部是條件項,表示條件樁中所有條件可能取值的組合;左下部是動作樁,表示所要執(zhí)行的操作即結(jié)果列表;右下部是動作項,列出在條件項(各種取值)組合情況下應(yīng)該采取的動作。在決策表中貫穿條件項和動作項的一列就是一條規(guī)則。

1.4 可視化測試方法

可視化測試方法的基本思想是將某圖形軟件處理以前的數(shù)據(jù)以及設(shè)計規(guī)則和處理以后的結(jié)果轉(zhuǎn)化成一種圖形進(jìn)行對比,這樣可以很快做出正確、直觀的判別方法。為保證充分利用有限的屏幕顯示任意復(fù)雜的圖形,在實際中要認(rèn)真考慮圖形的大小和形狀與屏幕之間的對應(yīng)關(guān)系,通過鼠標(biāo)操作對任一窗口的某一部分圖形進(jìn)行還原和放大處理,并可以自動調(diào)整該圖形顯示窗口的上下左右位置,使放大以后的圖形在比較窗口內(nèi)保持一致。窗口放大除了考慮放大比例外,還必須考慮窗口內(nèi)的圖形放大以后仍然在屏幕的視區(qū)之內(nèi),放大比例有縱向與橫向兩種,總的放大比例為:

以印刷電路版圖為例進(jìn)行測試,其處理算法為:

1) 先設(shè)圖形在x,y方向最大的外輪廓尺寸為mx和my;

2) 比較外輪廓尺寸在x軸方向和y軸方向的寬度mx和my的大小關(guān)系,以確定屏幕顯示區(qū)域上下左右劃分及最大限度地利用顯示屏來顯示更多的圖形數(shù)據(jù)信息的圖形框。具體操作步驟如下:

a.Ifmx

b.Ifmxmy則把屏幕分為上下兩個顯示區(qū)域,即為橫圖在顯示窗口的設(shè)置;

c. 把設(shè)計規(guī)則及圖形軟件處理前、后的數(shù)據(jù)文件轉(zhuǎn)換到對應(yīng)的圖形顯示窗口,然后再選擇可視區(qū)域內(nèi)的圖形進(jìn)行比較、放大和測試,進(jìn)而來測試圖形軟件的質(zhì)量。

2 “數(shù)字檔案系統(tǒng)”的測試

2.1 “數(shù)字檔案系統(tǒng)”概述

數(shù)字檔案系統(tǒng)是某校數(shù)字校園信息門戶軟件中其中一個比較復(fù)雜的子系統(tǒng),功能多、安全性要求高。數(shù)字檔案系統(tǒng)主要包括信息管理和系統(tǒng)管理,其中系統(tǒng)管理包括權(quán)限管理(角色管理、用戶管理)和信息配置管理(代碼庫、教師信息類管理);信息管理包括:教師綜合查詢、組織機(jī)構(gòu)、學(xué)歷學(xué)位和職務(wù)職級等。

這些功能相對獨立又相互聯(lián)系,必須進(jìn)行認(rèn)真細(xì)致的需求分析、評審、設(shè)計測試用例、執(zhí)行測試用例、錯誤缺陷報告,為了避免測試中產(chǎn)生新的更嚴(yán)重的錯誤則要進(jìn)行回歸測試,使軟件質(zhì)量不斷提高。

2.2 “數(shù)字檔案系統(tǒng)系統(tǒng)(SRS)”需求規(guī)格說明書的測試

對于軟件需求規(guī)格說明書(SRS)的測試屬于靜態(tài)測試[9]，評審SRS是軟件測試基礎(chǔ)性工作且是最重要的活動之一。如果沒有需求評審，那么在測試執(zhí)行階段就會發(fā)現(xiàn)比較嚴(yán)重的缺陷，還有不少缺陷會留到產(chǎn)品發(fā)布之后，那么產(chǎn)品質(zhì)量就會明顯下降[10]。如圖1所示，在需求分析階段如果有良好的需求評審，產(chǎn)品從測試階段直到遞交給用戶缺陷數(shù)量會越來越少；但如果沒有進(jìn)行需求評審，到了測試執(zhí)行階段就會發(fā)現(xiàn)多而嚴(yán)重的缺陷。缺陷發(fā)現(xiàn)的越晚系統(tǒng)成本越高，質(zhì)量就越低。

圖1 需求評審對缺陷分布的影響Fig.1 Influence of demand assessment on the distribution of defects

本系統(tǒng)采用正式的評審會議和非正式的面對面討論、走查相結(jié)合形式完成用戶需求文檔的評審。

某一次正式評審會議的記錄如下。

參加人有:1位主持人,4位作者,5位專家,1位咨詢顧問,2位具體操作人員,2位記錄員。開始時間為14∶50,結(jié)束時間為17∶35 .評審文檔的規(guī)模為42頁;會議前發(fā)現(xiàn)問題29個,會議中發(fā)現(xiàn)問題7個,合計問題36個。主要功能性需求問題記錄:a.系統(tǒng)沒有分享功能;b.檢索功能太簡單,只有關(guān)鍵詞和標(biāo)題;c.沒有用戶反饋功能;d.缺少在線咨詢、留言板等等。另外還有一些非功能性問題,比如，全校教工同時報崗,每秒能接受多少人安全登錄；大負(fù)載高峰期情況下系統(tǒng)響應(yīng)時間如何。這些在本系統(tǒng)的SRS中描述不清楚。

會議最后咨詢顧問對一些問題做了點評。

1) 對問題的描述要注意，不要有二義性,要問題準(zhǔn)確,位置準(zhǔn)確;

2) 不在一個問題上花費太多的時間;

3) 不討論個人對一些描述風(fēng)格的偏好;

4) 立項時最好能確定參與項目的評審專家;

5) 大家要心平氣和的討論問題。

通過以上對數(shù)字檔案系統(tǒng)SRS的靜態(tài)測試總結(jié)出以下幾點,供同行參考。

1) 靈活應(yīng)用正式評審和非正式評審,兩種形式相結(jié)合使用;

2) 精心挑選評審員。各個層次的人員都要有,但不易太多;

3) 功能性需求和非功能性需求要分層次評審;

4) 為了降低需求返工的風(fēng)險,可以采用分階段評審辦法,最好在需求形成的過程中進(jìn)行分階段評審;

5) 建立標(biāo)準(zhǔn)的評審流程,做好評審后的跟蹤工作。

2.3 “數(shù)字檔案系統(tǒng)”模塊的測試

下面是該系統(tǒng)中一個簡單模塊的被測代碼。

Procedure exp(a,b:real; varx,y:real);

Begin

If (a>1 ANDb=0) then

x=x/a;

end if

if (a=2 ORx>1)then

x=x+1;

end if;

y=a+b;

end;

對于系統(tǒng)模塊的測試一般由開發(fā)人員執(zhí)行,主要采用白盒方法,根據(jù)前面介紹的基本路徑測試技術(shù)生成測試用例的方法如下:

1) 根據(jù)被測代碼導(dǎo)出對應(yīng)的程序流程控制圖,如圖2所示。

圖2 程序流程控制圖Fig.2 Program flow and program control chart

2) 依據(jù)程序流程控制圖計算環(huán)形復(fù)雜度。環(huán)形復(fù)雜度的計算方法有3種,一是可以通過程序流程控制圖的邊數(shù)和節(jié)點數(shù)計算;二是通過程序流程控制圖的判斷節(jié)點個數(shù)進(jìn)行計算;三是通過程序流程控制圖的區(qū)域數(shù)目來計算。對于給定的程序流程控制圖的環(huán)形復(fù)雜度的值為環(huán)形復(fù)雜度邊數(shù)減去節(jié)點數(shù)加2或者判斷節(jié)點個數(shù)加1或者程序控制流圖區(qū)域的數(shù)目。區(qū)域是由節(jié)點和邊圍成的面積。要注意的是計算區(qū)域數(shù)目時要包括控制流圖外部并沒有被包圍進(jìn)來的區(qū)域，即實際區(qū)域加1.本例采用判斷節(jié)點個數(shù)來計算。被測代碼的程序流程控制圖有兩個判斷節(jié)點1和3再加1則得到該程序流程控制圖的環(huán)形復(fù)雜度為3.

3) 根據(jù)流程控制圖的環(huán)形復(fù)雜度確定程序的獨立路徑數(shù),通過以上分析和計算其環(huán)形復(fù)雜度為3,因此共有3條獨立路徑。下面給出一組3條獨立路徑:

路徑1:1—3—5

路徑2:1—2—3—5

路徑3:1—2—3—4—5

1—3—4—5不是獨立路徑,因為沒有新的邊加入。

4) 設(shè)計測試用例,確保基本路徑集中每一條路徑被執(zhí)行一次。只要測試用例確?；韭窂浇M的執(zhí)行,就可以說明程序中相應(yīng)的代碼和程序邏輯是正確的。測試用例如表1所示。

表1 測試用例

3 結(jié)束語

文中介紹了幾種常用而又典型的軟件測試方法,最后結(jié)合實際案例給出了系統(tǒng)需求規(guī)格說明書的測試和基本路徑測試方法的應(yīng)用,希望對軟件開發(fā)和測試人員在選擇測試方法和應(yīng)用時有一定的啟發(fā)和幫助。

隨著軟件開發(fā)的不斷更新擴(kuò)大,軟件測試方法和技術(shù)也在不斷變化,新的測試任務(wù)還很繁重,像云服務(wù)或云計算的測試,物聯(lián)網(wǎng)的測試等,都需要我們在軟件測試實踐中不斷學(xué)習(xí)不斷提高,在實際應(yīng)用中不斷完善改進(jìn)測試技術(shù)和方法,提高軟件質(zhì)量。

[1] DOROTHY GRAHAM.REQUIREMENTS:Requirements and testing:seven missing-link myths[J].IEEE Software,2002,19(5):15-17.

[2] ADITYA P MATHUR.Foundations of software testing[M].北京:機(jī)械工業(yè)出版社,2011.

[3] 劉竹林.軟件測試技術(shù)與案例實踐[M].北京:北京師范大學(xué)出版社,2011.

[4] 趙磊,倫立軍,徐士華.基于軟件體系結(jié)構(gòu)測試路徑生成方法[J].微電子學(xué)與計算機(jī),2008，25(1)：177-180.

[5] 王鐵辰.軟件測試從入門到精通[M].北京:電子工業(yè)出版社,2010.

[6] 高春艷.基本路徑測試法的應(yīng)用[J].開封大學(xué)學(xué)報,2012,26(2):81.

[7] 李金鵬.軟件測試技術(shù)理論與方法高效率化研究[J].數(shù)字技術(shù)與應(yīng)用,2012(2):203.

[8] 聶長海.關(guān)于軟件測試的幾點思考[J].計算機(jī)科學(xué),2011,38(2):1-3.

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

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

(編輯：賈麗紅)

Study and application of software test method

WU Zhaoyu,ZHANG Yueqin,YAN Hua

(CenterofInformationManagementandDevelopment,TaiyuanUniversityofTechnology,Taiyuan030024，China)

This paper discussed and researehed the static testing method,path-based white-box testing method and black-box testing method for software requirements specification.A visual test method and its application were proposed on testing graphics software.The processing algorithm and operation steps with PCB(Printed Circuit Board) for instance were proposed. Finally, the application of the testing methods based on software requirement specfication and basic path is illustrated by an actual case named “Digital File System”.This research provides some reference and help to the software development and testing personnel in the selection and application of test methods.

software quality;software testing;requirement specification;basic path;decision tables;visualization visual

1007-9432(2016)03-0379-05

2015-07-29

山西省科技基礎(chǔ)條件平臺建設(shè)資助項目：基于物聯(lián)網(wǎng)的城市智慧水務(wù)云管理平臺(2015091003-0103)

武昭宇(1985-),男,太原人,碩士生,主要從事軟件開發(fā)與測試研究，(E-mail)wuzhaoyu@tyut.edu.cn

張月琴,教授,主要從事軟件開發(fā)環(huán)境與工具及軟件測試研究，(E-mail)zhangyueqin@tyut.edu.cn

TP311

A

10.16355/j.cnki.issn1007-9432tyut.2016.03.019