(中國人民解放軍91404部隊42分隊 秦皇島 066001)
軟件測試是提高軟件質(zhì)量的重要手段。軟件測試的質(zhì)量與最終交付的軟件質(zhì)量有著直接的關(guān)系[1]。因此,如何對軟件測試的質(zhì)量給出合理有效的評價,成為目前需要關(guān)注的重要問題[2~3]。許多學(xué)者分別給出了各種軟件測試質(zhì)量評價模型和方法,其中測試質(zhì)量模型的大多應(yīng)用了綜合層次模型[4],主要關(guān)注要點包括測試過程、測試管理、測試環(huán)境、測試效率、測試有效性、測試人員等[5];評價方法包括模糊決策法[6]、灰色關(guān)聯(lián)分析法[7]、雷達圖法[8]、框圖評估法[9]、模糊偏序法[10]等。這些學(xué)者的研究雖然關(guān)注重點不同,但對測試用例的評價均在這些模型和方法中占有一席之地,但是對測試用例的評價沒有統(tǒng)一的標(biāo)準(zhǔn)。
測試用例的設(shè)計和執(zhí)行是軟件測試過程中的核心工作,測試用例直接決定著測試結(jié)果[11]。根據(jù)測試類型的不同,對測試用例的評價會有不同的標(biāo)準(zhǔn)。主要針對軟件系統(tǒng)測試/驗收測試中的軟件測試用例評價行研究,使用目標(biāo)-問題-度量(Goal Question Metric,GQM)范式[12],從測試質(zhì)量管理者和軟件用戶關(guān)注的方向,構(gòu)造了一種能夠廣泛適用的測試用例評價指標(biāo)體系;針對測試用例評價因素多且不確定的特點,提出了一種基于模糊理論的評價方法,并在工程實踐中進行可行性驗證。
對于測試用例的評價,我們主要關(guān)注兩個方面。
1)測試用例設(shè)計。
2)測試用例執(zhí)行。
參考被廣泛應(yīng)用的GQM范式,將測試用例評價自下而上分為三層,即目標(biāo)、問題、度量元[13]。
指標(biāo)體系第一層對應(yīng)的是目標(biāo),即如何評價測試用例的質(zhì)量。第二層是問題,即測試用例設(shè)計情況如何?測試用例執(zhí)行情況如何?第三層為度量元,可通過直接或間接采集數(shù)據(jù),對第二層的問題給出定量的度量結(jié)果。度量元我們將在下一節(jié)進行詳細描述。
需要注意的是,我們的研究關(guān)注的是軟件系統(tǒng)測試/驗收測試,通過測試的軟件需要直接交付用戶。因此,我們將度量指標(biāo)采集過程延伸至軟件交付之后,將用戶使用反饋作為度量元之一。這與以往的研究只關(guān)注軟件測試過程本身有所不同[14]。
圖1 測試用例評價指標(biāo)體系框架
1)測試用例覆蓋率(Test Case Coverage,TCC)
軟件測試用例應(yīng)覆蓋軟件需求規(guī)格說明中所描述的所有功能、性能指標(biāo)。需要注意的是,通過軟件需求規(guī)格說明析出的隱含需求也應(yīng)包含在內(nèi)。計算方法為
式中,Reqcovered表示所有測試用例已覆蓋的軟件需求,Reqall表示所有軟件需求規(guī)格說明中所有軟件需求。
2)測試用例執(zhí)行率(Test Case Execution Rate,TCER)
設(shè)計的測試用例應(yīng)盡可能全部執(zhí)行。如果有未執(zhí)行的測試用例,應(yīng)當(dāng)給出理由。計算方法為
式中TestCaseexecuted代表所有被執(zhí)行的測試用例,TestCasedesigned代表所有設(shè)計的測試用例。
3)測試用例規(guī)模(Test Case Size,TCS)
測試用例規(guī)??梢元M義的理解為一次測試中的測試用例總數(shù)。根據(jù)以代碼行描述的軟件規(guī)模大小,對測試用例規(guī)模進行評價。計算方法為
式中LOC代表被測軟件代碼行數(shù),Adj為軟件規(guī)模調(diào)整系數(shù),其取值見表1。
表1 軟件規(guī)模調(diào)整系數(shù)(Adj)取值
4)測試用例的易理解性(Test Case Understandability,TCU)
設(shè)計的測試用例應(yīng)易于理解,對測試環(huán)境的要求、前提和約束、操作步驟、測試輸入、測試輸出、預(yù)期結(jié)果等要素[15]。測試用例對這些要素應(yīng)描述清晰,易于被其他測試工程師理解和執(zhí)行。這是一個主觀的度量元,只能通過主觀評價打分取值。
5)靜態(tài)測試覆蓋范圍(Static Test Coverage,STC)
對被測件的靜態(tài)測試一般采用測試工具軟件實現(xiàn),靜態(tài)測試應(yīng)覆蓋所有代碼,包括所有的源代碼文件、類文件、頭文件等。計算方法為
式中LOCcovered為靜態(tài)分析覆蓋的代碼行數(shù)。
6)覆蓋率(Coverage,COV)
覆蓋率一般包括語句覆蓋、判斷覆蓋、條件/判斷覆蓋[16~17]。常通過邏輯測試類型,使用測試工具對軟件代碼插樁的方式實現(xiàn)。計算方法為
式中SC為語句覆蓋率,MC為判斷覆蓋率,MCDC為條件/判斷覆蓋率。
7)檢錯率(Error Detection Rate,EDR)
執(zhí)行未通過的測試用例可標(biāo)記為一個未確認的軟件缺陷,由于測試人員對軟件的理解可能有偏差,這些未確認的軟件缺陷需要與軟件開發(fā)方或者軟件用戶確認后才可以標(biāo)記為確認的軟件缺陷。計算方法為
式中Bugmarked為未確認的軟件缺陷,Bugconfirmed為確認的軟件缺陷。
8)用例效率(Test Case Efficiency,TCE)
對測試用例發(fā)現(xiàn)軟件缺陷的效率進行描述,計算方法為
9)用戶缺陷率(User Defect Rate,UDR)
當(dāng)軟件交付后,最終用戶也可能發(fā)現(xiàn)軟件缺陷,這說明軟件測試是不充分的。根據(jù)軟件測試經(jīng)典理論,軟件測試只能證明軟件有缺陷而不能證明軟件沒有缺陷。但如果測試用例設(shè)計水平較高,可以盡可能減少用戶發(fā)現(xiàn)的缺陷。計算方法為
UDR=(Bugcustomer/(Bugcustomer+Bugconfirmed))×100%式中Bugcustomer為用戶發(fā)現(xiàn)的缺陷數(shù)。
為便于計算,將上述度量元的計算結(jié)果進行歸一化處理,即將度量元得分映射至[0,1]區(qū)間。方法參見表2。
表2 度量元歸一化計算方法
模糊綜合評判法是模糊數(shù)學(xué)理論中針對多個因素影響問題的有效的多因素決策方法[18]。根據(jù)上一節(jié)的論述可以發(fā)現(xiàn),軟件測試用例的評價由多個因素組成,而且這些指標(biāo)大部分帶有一些不確定性,因此本節(jié)將模糊綜合評判法應(yīng)用于對測試用例的評價,分別建立因素集、評語集和權(quán)重集,對測試用例給出定性評價。
步驟1:建立因素集。顯然,對測試用例的評價由前述9個因素組成,即
步驟2:建立評語集。對測試用例的評價盡量使用自然語言,即
步驟3:建立權(quán)重集。應(yīng)用層次分析法(AHP),建立權(quán)重向集,即
步驟4:建立單因素評判矩陣。由于因素集中的每個因素的分值均已映射至[0,1]區(qū)間內(nèi),故可使用隸屬度函數(shù)來確定每個因素的得分。根據(jù)具體問題,建議隸屬度函數(shù)取拋物分布。通過映射,可以得到單因素評判結(jié)果向量R1~R9,將它們拼接起來,即可得到單因素評判矩陣
步驟5:多指標(biāo)綜合評價。以利用權(quán)重向量進行多指標(biāo)綜合評價并得到結(jié)果向量,評價模型為
式中的°為某種模糊算子[19],建議使用加乘算子M(×,⊕ ) 。
步驟6:對評價結(jié)果向量B應(yīng)用最大隸屬度原則,即找出max(b1,b2,b3,b4),并找到評語集中對應(yīng)的評語,即為測試用例評價結(jié)果。
1)建立因素集、評語集和權(quán)重集。
因素集、評語集與前述一致,應(yīng)用層次分析法建立的權(quán)重集為
2)進行單因素評判并得到評判矩陣。某型軟件完成第三方測評后,通過數(shù)據(jù)采集和專家打分,得到了足夠的度量元數(shù)據(jù),可得到單因素評價結(jié)果向量為:
將它們拼接為單因素評判矩陣,可得到
3)進行多指標(biāo)評價。
4)得到評價結(jié)果。
根據(jù)最大隸屬度原則,max(0.676,0.309,0.10575,0.0175)=0.676 ,對應(yīng)的評語為“優(yōu)”,故本次測試用例的評價為“優(yōu)”。
提出了軟件系統(tǒng)測試/驗收測試中對軟件測試用例的評價指標(biāo)體系,并參考比較成熟的層次分析法和模糊綜合評判法進行測試用例評價,通過具體項目驗證,指標(biāo)體系合理,方法可行,可以對測試用例給出定性的評價。
在特定的條件下,模糊綜合評判法中的最大隸屬度原則可能會失效[20],因此,下一步研究中需要對其有效性進行判斷,并研究應(yīng)用其他方法給出評判結(jié)果。