李曉雪,丁佐華,胡覺亮
(浙江理工大學(xué)科學(xué)計算與軟件工程實驗室,杭州310018)
測試方法對軟件失效數(shù)據(jù)影響的實驗分析
李曉雪,丁佐華,胡覺亮
(浙江理工大學(xué)科學(xué)計算與軟件工程實驗室,杭州310018)
失效數(shù)據(jù)常被用于評估軟件的質(zhì)量、監(jiān)測和預(yù)測軟件的運行情況,不同的測試方法對失效數(shù)據(jù)的影響是研究的重點。采用隨機測試、分支覆蓋測試和分塊覆蓋測試這3種不同的測試方法選取測試用例集,運用Daikon動態(tài)地獲取程序不變量,再從這些不變量中提取失效數(shù)據(jù),比較分析哪種方法可以獲取更多的失效數(shù)據(jù)。通過實驗得出結(jié)論:在3種測試方法中,隨機測試方法可以獲得更多的失效數(shù)據(jù)。
失效數(shù)據(jù);測試方法;隨機測試;測試用例集;程序不變量
軟件測試是證明一個軟件實現(xiàn)預(yù)期目標(biāo)的最常用方法,其主要的目標(biāo)有兩個,一是對質(zhì)量或可接受性做出評判,二是發(fā)現(xiàn)存在的問題。它利用測試用例來操作軟件[1-2],通過測試比較實際輸出結(jié)果與期望輸出結(jié)果,從而得到失效數(shù)據(jù)。在實際的測試中,由于成本的限制,不可能用太多的測試用例對軟件進行測試,這就需要采取有效的測試方法,用最少的測試用例發(fā)現(xiàn)最多的軟件缺陷。目前,軟件的測試方法有很多種,不同的方法有不同的特點,有各自的優(yōu)缺點。在本文中,隨機測試方法可以節(jié)約成本,但是所選測試用例集不能完全地覆蓋程序;分支覆蓋測試方法的測試用例集可以覆蓋程序的每一個分支,分塊覆蓋測試方法的測試用例集可以覆蓋程序的每個出口和入口,通過這兩種方法可以有目的的選取測試用例,使得每個測試用例對程序的覆蓋范圍都不一樣,這樣就可以認(rèn)為測試用例集中每個測試用例都是有效的,而兩者的區(qū)別在于選取測試用例時前一個測試用例對后一個測試用例的影響不同。
通常情況下,通過測試得到的失效數(shù)據(jù)是靜態(tài)的,不能把握軟件的整體行為,只能獲得軟件的部分行為。當(dāng)測試方法不同或者測試用例集不同時,獲得的失效數(shù)據(jù)就會不一樣,為軟件質(zhì)量的評估(如軟件可靠性的評估)增添了復(fù)雜性[3]。正如Chen M H等[4]提到的,當(dāng)用不同的測試方法選取測試用例時,得到了不同的失效數(shù)據(jù)。軟件質(zhì)量的評估一直是軟件用戶和軟件開發(fā)人員都十分關(guān)心的問題,如何能更準(zhǔn)確地評估軟件的質(zhì)量好壞,與軟件測試有著密切的關(guān)系,而失效數(shù)據(jù)是軟件測試的產(chǎn)物之一。
因為不同的測試方法只能得到程序的不同行為,這些行為之間可能有交叉,但是也有不同的方面。實際上一個軟件寫好后,它的內(nèi)部缺陷是固定了的,不會因為測試方法的不同而改變,不同測試方法只能從不同的角度來揭示軟件對不同環(huán)境的反應(yīng)。希望能得到某些測試數(shù)據(jù)可以反映程序的整體行為,進而提出以下方法:選取任一個測試方法,運行測試用例,得到程序不變量,提取失效數(shù)據(jù),因為不變量是指程序在運行時保持不變的屬性的量,刻畫了程序的動態(tài)性質(zhì),體現(xiàn)了軟件的整體行為。這樣可以更準(zhǔn)確地反應(yīng)程序的內(nèi)部行為,從程序的內(nèi)部行為這一層次去評估它的質(zhì)量。
程序不變量常被用于追蹤軟件缺陷[5]、硬件錯誤[6]和軟件評估[7]。如Pietrantuono R等[8]通過程序不變量來監(jiān)測和預(yù)測在線軟件可靠性。程序不變量揭示了程序在運行過程中保持不變的狀態(tài),這些狀態(tài)對軟件的發(fā)展、測試和維護有重要的意義。
1.1 如何獲取程序不變量
目前有很多種提取程序不變量的工具,常用的有Daikon[7]和DIDUCF[5]。本文采用Daikon作為提取不變量的工具。
Daikon作為動態(tài)不變量提取工具,利用程序執(zhí)行來發(fā)現(xiàn)可能的不變式[9-10]。它通過修改目標(biāo)程序來跟蹤感興趣的域,通過一組測試套件來運行修改以后的程序,從而利用跟蹤得來的結(jié)果推導(dǎo)不變式。這些推導(dǎo)出來的不變式也可以作為形式化的規(guī)格說明插入到代碼中作為注釋,幫助提高程序的可理解性。
下面通過一個計算器例子(圖1)來說明如何得到程序不變量。
a)生成測試用例集。用原先已有的測試用例生成技術(shù)[10]來生成一個測試用例集,該技術(shù)將輸入域分成若干個等價類,再從每一個等價類中選取測試用例。為了更好的提取不變量,還采用Gupta N[11]提出的方法進一步提煉測試用例集。在計算器例子中,測試用例集包括80個測試用例。
圖1 計算器例子
b)定義不變量類型。Daikon不變量類型有很多種,如常數(shù)x=a、非零值x≠0、取值范圍a≤x≤b、線性關(guān)系y=ax+b、大小關(guān)系x≤y、函數(shù)關(guān)系x=fn(y)、包含關(guān)系x∈y等,其中a,b是常數(shù),x,y是變量。如果還需要更多的不變量類型,可以自定義。
c)運行程序和測試用例得到軌跡文件。
d)得到程序不變量。在該例子中得到的不變量如圖2。通過上述例子得到12個程序不變量,例如第二個不變量‘size(this.b[])==size(this.s[])’是指數(shù)組b的長度等于數(shù)組s的長度,第五個不變量this.b!=nuLL指參數(shù)b的取值不能為空。
圖2 通過原程序得到的不變量
1.2 如何得到不正確的不變量
本節(jié)描述如何得到不正確的程序不變量,即失效數(shù)據(jù)。所謂不正確的不變量指的是實際輸出與期望輸出不同的不變量。原程序C1改為程序C2,如圖3所示,即將JButton b[]=new JButton[16]中的16改為17,同時調(diào)換String s[]={“0”,“1”,“2”,“3”,“4”,“5”,“6”,“7”,“8”,“9”,“+”,“-”,“*”,“/”,“C”,“=”}中‘+’和‘-’的位置。得到新的不變量集T2,如圖4。通過對比發(fā)現(xiàn)1)、3)、4)、5)、7)、10)、11)、12)與圖2中一樣,而2)、6)、8)、9)卻發(fā)生了變化。如原先的2)是size(this.b[])==size(this.s[]),意為數(shù)組b的長度等于數(shù)組s的長度,而改變后的是size(this.b[])-1==size(this.s[]),意為數(shù)組b的長度減1才等于數(shù)組s的長度。這樣,就認(rèn)為2)、6)、8)、9)是失效數(shù)據(jù)。
圖3 修改后程序C2
圖4 通過程序C2得到的程序不變量
2.1 實驗來源
采用的實驗程序來源于the Software-artifact Infrastructure Repository[12]。The Siemens set包含7個C程序,如表1,它們常用于錯誤定位和軟件可靠性計算。
表1描述了實驗所需要的7個程序。第一列是程序名稱。第二列是該程序的錯誤版本,每個錯誤版本只包含一個錯誤,而在本實驗中,需要把所有的錯誤整合在一起,構(gòu)成一個包含多個錯誤的版本。第三列是每個程序包含的測試用例個數(shù)。第四列是程序的描述,即主要實現(xiàn)的功能。
表1 Siemens set
2.2 測試方法
測試方法有很多種,從3種不同角度分類為[13]。
a)從是否需要執(zhí)行被測軟件的角度可以分為靜態(tài)測試和動態(tài)測試。
靜態(tài)測試方法是不利用計算機運行被測程序,而通過其他手段達(dá)到測試目的的方法。相反,動態(tài)測試方法是指計算機真正運行被測程序的方法,需要輸入測試用例,判斷輸出結(jié)果是否滿足要求,以此來預(yù)測程序的可靠性、正確性及有效性。
b)從軟件測試用例設(shè)計方法的角度可以分為黑盒測試和白盒測試。
黑盒測試方法是一種從用戶角度出發(fā)的測試,也稱其為功能測試。當(dāng)用這種方法測試時,被測程序就相當(dāng)于一個黑盒,忽略了程序內(nèi)部的結(jié)構(gòu),只需要關(guān)心程序的輸入和輸出之間的關(guān)系即可。白盒測試方法是基于程序內(nèi)部的結(jié)構(gòu)來測試的,檢查內(nèi)部的操作是否按照規(guī)定執(zhí)行,軟件的各個部分能否得到充分的利用。
c)從軟件測試的策略和過程的角度可以分為單元測試、集成測試、確認(rèn)測試、系統(tǒng)測試和驗收測試。
單元測試是軟件測試的最小的單位,它是針對系統(tǒng)每個單元的測試。它確保每個模塊能夠正常的工作。集成測試是對已測試過的模塊進行組裝,其目的主要是檢驗程序的結(jié)構(gòu)問題。確認(rèn)測試是檢驗開發(fā)的軟件是否滿足所有需求和所有功能的最后的手段。系統(tǒng)測試是檢測軟件與系統(tǒng)其它部分的協(xié)調(diào)性。驗收測試主要從用戶的角度著手,是保證產(chǎn)品質(zhì)量的最后一關(guān)。
本文采用3種不同的測試方法從測試用例集中選取測試用例,這3種方法分別是:隨機測試方法、基于分塊覆蓋的測試方法和基于分支覆蓋的測試方法。
隨機測試[14]即從程序的輸入域中隨機的選取一個測試用例。每一個測試用例都有其被選中的概率。在實驗中,根據(jù)預(yù)先定義的發(fā)生概論,從程序的規(guī)格說明書中隨機的選取至少一個功能進行隨機測試以及隨機的選取一個合適的測試用例來對這個說明書進行測試。
只有一個入口和一個出口的順序語句稱為一個塊[4]。分塊覆蓋測試方法要求至少有一個測試用例覆蓋一個塊和所有的測試用例要覆蓋所有的程序塊。首先根據(jù)程序的規(guī)格說明書構(gòu)建一個測試用例集C,如果測試用例集C不能覆蓋所有的塊,那么選取至少一個未被覆蓋的程序塊來決定新的測試用例集,然后重新執(zhí)行新的測試用例集,直到所有的程序塊被覆蓋。
按分支覆蓋準(zhǔn)則進行測試是指[15],設(shè)計若干測試用例,運行被測程序,使得程序中每個判斷的取真分支和取假分支至少經(jīng)歷一次,及判斷的真假值均曾被滿足。在該試驗中,采用gcov來得到程序的覆蓋信息[16]。
通過3種不同的方法,選取測試用例集T1(隨機測試方法)、T2(基于分塊覆蓋測試方法)、T3(基于分支覆蓋測試方法)。分別運行正確版本程序C與T1、C與T2、C與T3得到程序不變量TI1、TI2和TI3,運行錯誤版本程序F與T1、F與T2、F與T3得到程序不變量FI1、FI2和FI3。比較TI1與FI1、TI2與FI2和TI3與FI3分別得到失效數(shù)據(jù)F1、F2和F3。
表2 3種方法得到的失效數(shù)據(jù)與程序不變量
表2是3種方法得到的7個程序的不變量。Random表示隨機選取測試用例得到的程序不變量,Block表示基于分塊覆蓋選取測試用例得到的程序不變量,Branch表示基于分支覆蓋選取測試用例得到的程序不變量。Fi(i=1,2,3)表示失效數(shù)據(jù),TIi(i=1,2,3)表示總的程序不變量,Percentage表示失效數(shù)據(jù)占總的程序不變量的百分比。
觀察表2:
程序print_tokens:5.77%(Random)>5.69%(Block)>5.66%(Branch);
程序print_tokens2:8.75%(Branch)>8.32%(Random)>8.24%(Block);
程序replace:13.18%(Random)>12.98%(Block)>11.62%(Branch);
程序schedule:10.77%(Block)>10.53%(Random)>7.25%(Branch);
程序schedule2:10.20%(Random)>10.16%(Block)>8.70%(Branch);
程序tcas:10.54%(Random)>9.94%(Block)>9.26%(Branch);
程序tot_info:9.50%(Random)>9.22%(Block)>9.02%(Branch)。
在上述結(jié)論中,除了print_tokens2和schedule的結(jié)論外,其余的均表明隨機測試方法可以選取較多的失效數(shù)據(jù)。而在print_tokens2的結(jié)論中,3種方法得到的失效數(shù)據(jù)占比相差較少,在schedule的結(jié)論中,隨機和分塊覆蓋方法可以得到比分支覆蓋較多的失效數(shù)據(jù)占比。另外,通過計算3種方法發(fā)現(xiàn)失效數(shù)據(jù)百分比的期望random是9.72%、Block是9.57%和Branch是8.6%。這樣,可以得出結(jié)論,通過隨機選取測試用例的方法會得到較多的失效數(shù)據(jù)。
本文從程序不變量的角度來評價軟件測試方法。通過實驗說明隨機測試能夠提取更多的失效數(shù)據(jù)。從程序不變量的角度來分析不同的測試方法對失效數(shù)據(jù)的影響,可用于錯誤定位的研究,有利于評估軟件的質(zhì)量好壞,可以更準(zhǔn)確的監(jiān)測和評估軟件的運行情況。實驗中用到的程序?qū)儆谛蛄谢绦?,在程序運行的某個時間點只可能有一個BUG出現(xiàn),靜態(tài)失效數(shù)據(jù)和動態(tài)失效數(shù)據(jù)都可能揭示該BUG。對于并發(fā)性程序,在同一個時間點有可能同時出現(xiàn)兩個或者多個BUG,而靜態(tài)的失效數(shù)據(jù)最多揭示其中的一個BUG,本文提出的方法有可能揭示兩個或者多個BUG。所以接下來的工作是:a)驗證該方法是否適用于并發(fā)程序;b)去掉不正確的不變量之間的相關(guān)性,分析測試方法對失效數(shù)據(jù)的影響;c)比較更多的測試方法,分析不同測試方法對軟件失效數(shù)據(jù)的影響;d)利用本實驗得到的失效數(shù)據(jù)去評估軟件的質(zhì)量。
[1]Rapps S,Weyuker F J.Selecting software test data using data flow information[J].IFFF Transactions on Software Fngineering,1985(4):367-375.
[2]劉繼華,陳 策.軟件測試技術(shù)的研究進展[J].微計算機信息,2012,10(28):16-20.
[3]陳 明.軟件測試[M].北京:機械工業(yè)出版社,2011.
[4]Chen M H,Mathur A P,Rego V J.Fffect of testing techniques on software reliability estimates obtained using a time-domain model[J].IFFF Transactions on Reliability,1995,44(1):97-103.
[5]Hangal S,Lam M S.Tracking down software bugs using automatic anomaly detection[C]//Proceedings of the 24th International Conference on Software Fngineering.ACM,2002:291-301.
[6]Sahoo S K,Li M L,Ramachandran P,et al.Using likely program invariants to detect hardware errors[C]//Dependable Systems and Networks with FTCS and DCC.IFFF,2008:70-79.
[7]Frnst M D,Cockrell J,Griswold W G,et al.Dynamically discovering likely program invariantts to support program evolution[J].IFFF Transactions on Software Fngineering,2001,27(2):99-123.
[8]Pietrantuono R,Russo S,Trivedi K S.Online monitoring of software system reliability[C]//Dependable Computing Conference(FDCC).IFFF,2010:209-218.
[9]Frnst M D,Perkins J H,Guo PJ,et al.The Daikon system for dynamic detection of likely invariants[J].Science of Computer Programming,2007,69(1):35-45.
[10]Ding Zuo-hua,Zhang Kao,Hu Jue-liang.A rigorous approach towards test case generation[J].Information Sciences,2008,178(21):4057-4079.
[11]Gupta N.Generating test data for dynamically discovering likely program invariants[C]//Proceedings of ICSF 2003 Workshop on Dynamic Analysis.2003:21-24.
[12]Do H,F(xiàn)lbaum S,Rothermel G.Supporting controlled experimentation with testing techniques:an infrastructure and its potential impact[J].Fmpirical Software Fngineering,2005,10(4):405-435.
[13]朱少明.軟件測試方法和技術(shù)[M].北京:清華大學(xué)出版社,2010.
[14]李海峰,馬 琳.軟件測試[M].3版.北京:人民郵電出版社,2011.
[15]張曉明,黃 琳.軟件測試的藝術(shù)[M].3版.北京:機械工業(yè)出版社,2012.
[16]王立新.軟件測試數(shù)據(jù)的高效生成及測試方法研究[D].上海:東華大學(xué),2010.
EmpiricaI Study on Effects of Testing Methods on Software FaiIure Data
LI Xiao-xue,DINGZuo-hua,HU Jue-Liang
(Lab of Intelligent Computing and Software Fngineering,Zhejiang Sci-Tech University,Hangzhou 310018,China)
Failure data are often used to evaluate the quality of software,monitor and predict the operation situation of software.The effect of different testing methods on failure data is the focus of the current studies.Firstly,this paper adopts three different testing methods:random testing,branch-coverage testing and block-coverage testing to select test case set,respectively.Secondly,program invariants for each method are obtained dynamically by Daikon tool,and the failure data are then extracted from program invariants.Finally,the number of failure data gotten from each method is compared.It comes to the conclusion that random testing can get the most failure data among the three methods.
failure data;testing methods;random testing;test case set;program invariant
TP311.55
A
(責(zé)任編輯:陳和榜)
1673-3851(2014)04-0429-05
2013-12-05
國家自然科學(xué)基金(61210004)
李曉雪,女,山西呂梁人,碩士研究生,主要從事軟件測試方面的研究。
胡覺亮,F(xiàn)-mail:hujhz@163.com