軟件代碼測(cè)試技術(shù)

北京郵電大學(xué)網(wǎng)絡(luò)與交換技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室 北京 1000876

概述

軟件測(cè)試技術(shù)可以從多種角度進(jìn)行分類，如按開(kāi)發(fā)階段可分為單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、確認(rèn)測(cè)試和驗(yàn)收測(cè)試，按是否需要程序執(zhí)行可分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試，按是否需要源代碼可分為白盒測(cè)試和黑盒測(cè)試，按程序運(yùn)行特性可分為功能測(cè)試和性能測(cè)試，按功能測(cè)試類型可分為邏輯功能測(cè)試、安裝卸載測(cè)試、易用性測(cè)試、兼容性測(cè)試、安全性測(cè)試、圖形界面測(cè)試等，按性能測(cè)試類型可分為一般性能測(cè)試、壓力測(cè)試、負(fù)載測(cè)試、穩(wěn)定性測(cè)試，另外，還有回歸測(cè)試、冒煙測(cè)試、隨機(jī)測(cè)試等等。基于以上測(cè)試分類，對(duì)于白盒測(cè)試可根據(jù)是否需要程序運(yùn)行進(jìn)一步劃分為靜態(tài)白盒測(cè)試和動(dòng)態(tài)白盒測(cè)試。

靜態(tài)白盒測(cè)試主要包括缺陷檢測(cè)技術(shù)、規(guī)則審查技術(shù)和質(zhì)量度量技術(shù)。缺陷檢測(cè)技術(shù)針對(duì)源代碼中存在的一些潛在語(yǔ)法或語(yǔ)義錯(cuò)誤進(jìn)行檢測(cè)，如對(duì)可能為空的指針進(jìn)行解引用、對(duì)已分配的內(nèi)存沒(méi)有及時(shí)釋放、使用未經(jīng)過(guò)初始化的數(shù)據(jù)等問(wèn)題，其難點(diǎn)在于需要準(zhǔn)確地計(jì)算出復(fù)雜的執(zhí)行語(yǔ)義，典型的工具有Klocwork的Klocwork Insight[1]、Coverity的Coverity Static Analysis[2]、Fortify的Static Code Analyzer[3]，GIMPEL SOFTWARE的PC-Lint[4]、北郵的DTS[5]、北航的QESAT[6]和北大的COBOT[7]；規(guī)則審查技術(shù)針對(duì)一些特定的開(kāi)發(fā)規(guī)范進(jìn)行檢查，如版式規(guī)范、命名規(guī)范、書(shū)寫(xiě)規(guī)范等，該技術(shù)在語(yǔ)法層面上進(jìn)行檢測(cè)難度不大，典型工具有Parasoft的Jtest和C++test[8]、Rational的Software Analyzer[9]、MicroFocus公司DevPartner中的Source Code Review[10]功能、Telelogic公司Logiscope中的RuleChecker[11]功能和馬里蘭大學(xué)的FindBugs[12]；質(zhì)量度量技術(shù)首先定義若干個(gè)度量元，通過(guò)度量元的組合形成質(zhì)量標(biāo)準(zhǔn)，最后通過(guò)組合質(zhì)量標(biāo)準(zhǔn)形成質(zhì)量因素，該技術(shù)也是在語(yǔ)法層面展開(kāi)的，典型的工具是Telelogic公司Logiscope中的Audit功能。

動(dòng)態(tài)白盒測(cè)試主要包括單元技術(shù)、測(cè)試評(píng)估技術(shù)和運(yùn)行監(jiān)控技術(shù)。單元技術(shù)基于被測(cè)單元的代碼及邏輯結(jié)構(gòu)產(chǎn)生并執(zhí)行測(cè)試用例，其難點(diǎn)在于如何對(duì)復(fù)雜結(jié)構(gòu)及路徑進(jìn)行求解，典型的數(shù)據(jù)生成工具有斯坦福大學(xué)的KLEE[13]、貝爾實(shí)驗(yàn)室的DART[14]、伯克利大學(xué)的CUTE[15]和北郵最新研發(fā)的CTS[16]；測(cè)試評(píng)估技術(shù)針對(duì)程序結(jié)構(gòu)的覆蓋情況對(duì)測(cè)試充分度進(jìn)行評(píng)估，如語(yǔ)句覆蓋、分支覆蓋、MC/DC覆蓋、基本路徑覆蓋、定義/使用覆蓋等，典型工具有Parasoft系列test工具的覆蓋功能、MicroFocus公司DevPartner中的Code Coverage Analysis功能、Telelogic公司Logiscope中的TestChecker功能、IBM公司PurifyPlus[17]中的PureCoverage、北航QESAT中的覆蓋統(tǒng)計(jì)功能、北郵CTS中的覆蓋統(tǒng)計(jì)功能、深圳領(lǐng)測(cè)科技有限公司的VcTester[18]、廣州凱樂(lè)軟件技術(shù)有限公司的Visual Unit[19]；運(yùn)行監(jiān)控技術(shù)采用插樁或變異的方法對(duì)源程序進(jìn)行一定的修改，在運(yùn)行過(guò)程中收集并監(jiān)控錯(cuò)誤執(zhí)行狀態(tài)，典型的工具有Agitar公司的AgitarOne[20]、Parasoft公司的Insure++、IBM公司PurifyPlus下的Purify。

在以上基于代碼的軟件測(cè)試技術(shù)中，涉及復(fù)雜程序執(zhí)行語(yǔ)義的缺陷檢測(cè)技術(shù)和涉及復(fù)雜邏輯結(jié)構(gòu)的單元測(cè)試技術(shù)具有相當(dāng)?shù)碾y度，目前得到國(guó)內(nèi)外眾多高校及科研機(jī)構(gòu)的研究，本文就這兩個(gè)方面的相關(guān)內(nèi)容進(jìn)行介紹。

1 缺陷檢測(cè)技術(shù)

針對(duì)缺陷檢測(cè)技術(shù)的研究，本文概括為如下四個(gè)部分：技術(shù)特點(diǎn)、技術(shù)架構(gòu)、缺陷模式和關(guān)鍵技術(shù)。

1.1 技術(shù)特點(diǎn)

傳統(tǒng)軟件測(cè)試基于軟件的某些性質(zhì)，如功能、覆蓋、性能等，這些測(cè)試雖然是必要的，但由于不是對(duì)軟件中的缺陷直接測(cè)試，因此就檢測(cè)缺陷的能力而言，基于代碼的缺陷檢測(cè)技術(shù)具有一定的優(yōu)勢(shì)，主要包括如下6點(diǎn)。

1) 覆蓋范圍廣。傳統(tǒng)方法要達(dá)到較高的測(cè)試覆蓋范圍，依賴于測(cè)試用例的數(shù)量及質(zhì)量，這將帶來(lái)大量的測(cè)試開(kāi)銷。而缺陷檢測(cè)技術(shù)不需要執(zhí)行程序，采用靜態(tài)的方法覆蓋程序結(jié)構(gòu)及路徑，這樣可以覆蓋到更多的問(wèn)題。

2) 測(cè)試效率高。傳統(tǒng)方法需要設(shè)計(jì)并執(zhí)行大量測(cè)試用例，這個(gè)開(kāi)銷在整個(gè)測(cè)試過(guò)程中占有極大的比例。缺陷檢測(cè)技術(shù)采用靜態(tài)方法分析及計(jì)算，其效率相對(duì)于動(dòng)態(tài)方法要高出許多。

3) 故障定位準(zhǔn)。對(duì)于有些動(dòng)態(tài)方法發(fā)現(xiàn)的問(wèn)題，其根源可能來(lái)自于多種情況，對(duì)其進(jìn)行準(zhǔn)確的定位具有一定的困難。而靜態(tài)方法在發(fā)現(xiàn)問(wèn)題的同時(shí)，可以對(duì)相關(guān)信息進(jìn)行準(zhǔn)確的定位。

4) 小概率故障檢測(cè)能力。對(duì)于某些小概率事件，依賴于執(zhí)行測(cè)試用例的動(dòng)態(tài)方法是很難覆蓋到的，而通過(guò)分析程序結(jié)構(gòu)得到路徑的靜態(tài)方法卻相對(duì)容易實(shí)現(xiàn)，盡管有些復(fù)雜條件是很難計(jì)算的。

5) 非顯性故障檢測(cè)能力。對(duì)于某些沒(méi)有明確現(xiàn)象的故障，如內(nèi)存泄漏或無(wú)沖突的內(nèi)容使用等，動(dòng)態(tài)方法即使覆蓋到了也難以發(fā)現(xiàn)。而靜態(tài)方法卻可以直接發(fā)現(xiàn)問(wèn)題，盡管其可能沒(méi)有直接的后果。

6) 測(cè)試人員要求低。傳統(tǒng)測(cè)試方法要得到較好的效果，需要完成一定的測(cè)試設(shè)計(jì)及測(cè)試開(kāi)發(fā)工作，甚至還需要熟悉系統(tǒng)業(yè)務(wù)流程，這對(duì)測(cè)試人員有著較高的要求。而面向故障的測(cè)試技術(shù)僅需要流程化的工具使用，對(duì)人員的要求較前者要低得多。

1.2 技術(shù)架構(gòu)

缺陷檢測(cè)技術(shù)架構(gòu)可劃分為輸入、基礎(chǔ)、計(jì)算、測(cè)試及分析5個(gè)部分，具體內(nèi)容如圖1所示。

圖1 缺陷檢測(cè)技術(shù)架構(gòu)

1) 輸入部分。測(cè)試文件指被測(cè)程序源代碼或經(jīng)過(guò)頭文件展開(kāi)、條件編譯及宏替換等預(yù)處理后的中間代碼；配置文件中包括為使系統(tǒng)正?；蛴行н\(yùn)行所提供的一些參數(shù)；模式文件中包含故障模式的相關(guān)描述及配置信息。

2) 基礎(chǔ)部分。此部分針對(duì)輸入的程序文件，構(gòu)建出一些基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，在分析、計(jì)算及測(cè)試過(guò)程中使用。

3) 計(jì)算部分。采用靜態(tài)方法計(jì)算出動(dòng)態(tài)運(yùn)行時(shí)的狀態(tài)，包括計(jì)算不同類型對(duì)象在運(yùn)行時(shí)的取值信息、分析過(guò)程中的可達(dá)及不可達(dá)路徑、采用函數(shù)摘要替代被調(diào)函數(shù)完全展開(kāi)等內(nèi)容。

4) 測(cè)試部分。針對(duì)輸入的配置文件及模式文件解析缺陷模式，構(gòu)建相應(yīng)狀態(tài)機(jī)；針對(duì)輸入文件中不同分析對(duì)象，創(chuàng)建狀態(tài)機(jī)實(shí)例；基于基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)運(yùn)行狀態(tài)機(jī)實(shí)例，并在其執(zhí)行過(guò)程中發(fā)現(xiàn)故障。

5) 分析部分?；跈z測(cè)到的缺陷及其相關(guān)信息，利用工具分析界面對(duì)測(cè)試結(jié)果的正確性進(jìn)行分析，并將確認(rèn)的結(jié)果導(dǎo)出。

1.3 缺陷模式

軟件缺陷模式有很多，目前常用的就有數(shù)百種，本文將其歸納為故障、安全、疑問(wèn)及規(guī)則4類模式。

1)故障模式。該類模式可能引起運(yùn)行異?；蝈e(cuò)誤，如被分配的內(nèi)存在使用后沒(méi)有正確釋放、訪問(wèn)可能為空的指針內(nèi)容、訪問(wèn)超過(guò)有效邊界的數(shù)組內(nèi)容、使用非法操作數(shù)進(jìn)行運(yùn)算、使用未經(jīng)過(guò)正常初始化的數(shù)據(jù)、使用已經(jīng)釋放的指針內(nèi)容等，該類缺陷被觸發(fā)后將引起較為嚴(yán)重的后果，如異常退出或系統(tǒng)宕機(jī)，因此應(yīng)盡量避免此類問(wèn)題。

2) 安全模式。該類模式導(dǎo)致軟件中存在安全隱患及漏洞，如對(duì)從外部獲取的不安全數(shù)據(jù)未經(jīng)驗(yàn)證即使用、對(duì)緩沖區(qū)的使用超過(guò)其規(guī)定的安全范圍、使用了不安全的API函數(shù)、密碼相關(guān)操作不安全等，該類模式對(duì)應(yīng)的代碼在正常操作下并沒(méi)有問(wèn)題，但對(duì)其異常操作卻可能造成嚴(yán)重的后果，如拒絕服務(wù)或數(shù)據(jù)丟失，因此應(yīng)謹(jǐn)慎對(duì)待此類問(wèn)題。

3) 疑問(wèn)模式。該類模式可能影響執(zhí)行效率或?qū)е逻壿嬪e(cuò)誤，如循環(huán)中的低效操作、字符串的低效操作、冗余的對(duì)象方法、無(wú)意義的比較、相同的條件分支等，該類缺陷容易使人產(chǎn)生質(zhì)疑，影響對(duì)程序真實(shí)意圖的判斷。

4) 規(guī)則模式。該類模式旨在統(tǒng)一編碼規(guī)范，避免程序員的不良習(xí)慣造成的錯(cuò)誤，如聲明定義規(guī)則、版面書(shū)寫(xiě)規(guī)則、分支控制規(guī)則、運(yùn)算處理規(guī)則、過(guò)程調(diào)用規(guī)則、語(yǔ)句使用規(guī)則等。

1.4 關(guān)鍵技術(shù)

在各類缺陷模式中，對(duì)疑問(wèn)模式及規(guī)則模式的檢測(cè)僅需要利用抽象語(yǔ)法樹(shù)等基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，這類模式的檢測(cè)精度相對(duì)較高。對(duì)故障模式及部分安全模式的檢測(cè)需要程序執(zhí)行語(yǔ)義信息，這就可能會(huì)遇到對(duì)某些特殊的情況，如對(duì)復(fù)雜的路徑條件、過(guò)程間數(shù)據(jù)傳播及對(duì)象表達(dá)式的分析及計(jì)算，由于缺少程序動(dòng)態(tài)執(zhí)行信息可能造成誤報(bào)及漏報(bào)的情況。為了更好地提高缺陷檢測(cè)精度，作者將相關(guān)技術(shù)總結(jié)如下。

1) 抽象解釋。抽象解釋技術(shù)用抽象對(duì)象域上的計(jì)算替代具體對(duì)象域上的計(jì)算，本質(zhì)上是在計(jì)算效率和計(jì)算精度之間取得均衡。抽象域用于程序變量取值信息的近似表示，可分為關(guān)系型和非關(guān)系型兩類：非關(guān)系型抽象域假設(shè)變量之間相互獨(dú)立，如區(qū)間抽象域；關(guān)系型抽象域考慮變量之間的關(guān)聯(lián)關(guān)系，如八邊形抽象域、八面體抽象域和區(qū)間多面體域等。關(guān)系型抽象域相對(duì)于非關(guān)系型來(lái)說(shuō)更精確，但其計(jì)算也相對(duì)復(fù)雜。

2) 路徑分析。從路徑抽象和近似的角度，靜態(tài)分析方法可以劃分為路徑敏感和路徑不敏感兩種方法。路徑不敏感方法不考慮程序控制流程中的不可達(dá)路徑，會(huì)引入較多的誤報(bào)，而完整路徑分析又會(huì)產(chǎn)生無(wú)限狀態(tài)空間。既能避免完整路徑分析帶來(lái)的組合爆炸，對(duì)給定缺陷來(lái)說(shuō)又足夠精確的路徑分析方法，是提高準(zhǔn)確性和實(shí)用性的重要手段。

3) 過(guò)程分析。精確的分析方法應(yīng)包括過(guò)程內(nèi)分析和過(guò)程間分析，過(guò)程間分析可以分為上下文敏感和上下文不敏感。最精確的上下文敏感方法是完整程序分析，但該方法無(wú)疑將要求大量的時(shí)間和內(nèi)存開(kāi)銷，在大型程序的分析過(guò)程中無(wú)法實(shí)現(xiàn)。在復(fù)雜度和精度之間達(dá)到合適平衡的上下文敏感函數(shù)間分析方法，是提高靜態(tài)缺陷檢測(cè)準(zhǔn)確性的重要內(nèi)容。

4) 缺陷檢測(cè)。若采用有限狀態(tài)機(jī)來(lái)描述缺陷模式，缺陷檢測(cè)基本過(guò)程可轉(zhuǎn)化為一個(gè)傳統(tǒng)的數(shù)據(jù)流問(wèn)題。在分析過(guò)程中首先根據(jù)每類缺陷的不同狀態(tài)機(jī)創(chuàng)建條件，創(chuàng)建一系列的缺陷狀態(tài)機(jī)實(shí)例，然后沿著控制流計(jì)算各缺陷狀態(tài)機(jī)實(shí)例在每個(gè)程序位置上的可能狀態(tài)集合，如發(fā)現(xiàn)可能狀態(tài)集合中包含錯(cuò)誤狀態(tài)即報(bào)告一個(gè)潛在的缺陷。

2 單元測(cè)試技術(shù)

針對(duì)單元測(cè)試技術(shù)的研究，本文概括為如下3個(gè)部分：技術(shù)架構(gòu)、覆蓋準(zhǔn)則和關(guān)鍵技術(shù)。

2.1 技術(shù)架構(gòu)

測(cè)試用例生成架構(gòu)可劃分為以下4個(gè)部分，具體內(nèi)容如圖2所示。

圖2 單元測(cè)試技術(shù)架構(gòu)

1) 程序預(yù)處理。對(duì)被測(cè)程序進(jìn)行預(yù)處理，其目的是生成獨(dú)立運(yùn)行的被測(cè)單元，主要工作包括靜態(tài)分析、單元?jiǎng)澐?、插裝、打樁、重命名main函數(shù)、建立測(cè)試用例框架、建立測(cè)試結(jié)果框架等。

2) 測(cè)試用例生成。隨機(jī)測(cè)試用例生成方法包括：基于區(qū)間運(yùn)算結(jié)果、基于輸入域劃分、基于路徑劃分、基于邊界值劃分等；基于分支限界的測(cè)試用例生成方法包括：路徑自動(dòng)生成和基于分支限界的測(cè)試用例自動(dòng)生成；人工輔助測(cè)試用例生成方法基于自動(dòng)生成的部分結(jié)果，結(jié)合人工干預(yù)來(lái)實(shí)現(xiàn)用例的生成。

3) 測(cè)試執(zhí)行、故障定位與結(jié)果分析。測(cè)試執(zhí)行：可單步、連續(xù)執(zhí)行被測(cè)單元的測(cè)試用例，執(zhí)行結(jié)果生成結(jié)果矩陣；故障定位：一旦測(cè)試執(zhí)行發(fā)現(xiàn)故障，可依據(jù)結(jié)果矩陣和啟發(fā)算法對(duì)故障快速定位；測(cè)試效果分析：對(duì)覆蓋率進(jìn)行統(tǒng)計(jì)。

4) 結(jié)果呈現(xiàn)。軟件性質(zhì)顯示：函數(shù)調(diào)用圖、控制流圖、軟件代碼性質(zhì)(代碼行、文件個(gè)數(shù)、函數(shù)個(gè)數(shù)、變量數(shù)、注析率、McCabe數(shù)等)；測(cè)試結(jié)果顯示：反相顯示被覆蓋的代碼、故障定位輔助支持顯示、人工輔助測(cè)試用例生成、測(cè)試用例庫(kù)顯示。

2.2 覆蓋準(zhǔn)則

測(cè)試覆蓋準(zhǔn)則是指覆蓋測(cè)試的標(biāo)準(zhǔn)，包括語(yǔ)句覆蓋、分支覆蓋、謂詞覆蓋、MC/DC覆蓋、路徑覆蓋、定義使用覆蓋等，不同的準(zhǔn)則對(duì)應(yīng)要測(cè)試的對(duì)象或程序元素不同。典型的幾種覆蓋準(zhǔn)則如下。

1) 語(yǔ)句覆蓋。語(yǔ)句覆蓋測(cè)試是最簡(jiǎn)單的結(jié)構(gòu)性測(cè)試方法之一。它要求在測(cè)試中，程序中的每條語(yǔ)句都得到執(zhí)行。在控制流圖中，要求所有語(yǔ)句都被運(yùn)行的充分必要條件是覆蓋圖中的所有節(jié)點(diǎn)。

2) 分支覆蓋。語(yǔ)句覆蓋測(cè)試是最基本的覆蓋測(cè)試技術(shù)，雖然它能保證所有語(yǔ)句都被執(zhí)行，但并不能保證每條分支都被執(zhí)行到；因此，分支測(cè)試要求程序中的每個(gè)取“真”分支和取“假”分支都至少經(jīng)歷一次。在控制流圖中，分支表現(xiàn)為圖中的一條有向邊。

3) 謂詞覆蓋。一個(gè)分支的條件是由謂詞組成的，單個(gè)謂詞稱為原子謂詞，原子謂詞通過(guò)邏輯運(yùn)算符可以構(gòu)成復(fù)合謂詞。原子謂詞覆蓋要求每個(gè)原子謂詞都至少獲得一次“真”值和一次“假”值；分支—謂詞覆蓋不僅要求每個(gè)原子謂詞都至少獲得一次“真”值和一次“假”值，還要求每個(gè)復(fù)合謂詞本身也至少獲得一次“真”值和一次“假”值；復(fù)合謂詞覆蓋要求復(fù)合謂詞中每個(gè)原子謂詞的各種組合情況都至少出現(xiàn)一次。

4) 數(shù)據(jù)流覆蓋。與控制流的覆蓋思想不同，數(shù)據(jù)流覆蓋面向程序中的變量。定義覆蓋要求每個(gè)變量的定義至少被覆蓋一次，引用覆蓋要求每個(gè)變量的所有引用都至少被覆蓋一次?？紤]到回路中有無(wú)窮的引用情況，定義-引用覆蓋為消除回路后的引用覆蓋。

2.3 關(guān)鍵技術(shù)

在自動(dòng)化單元測(cè)試中，主要涉及如下幾個(gè)方面的技術(shù)。

1) 數(shù)據(jù)生成。數(shù)據(jù)生成可分解為4個(gè)部分。預(yù)處理部分：提供支持的部分，要面向任何類型的程序；回退部分：對(duì)一個(gè)表達(dá)式中的某個(gè)變量而言，選擇合理的賦值使之能滿足求解的需要；回溯部分：當(dāng)發(fā)生矛盾時(shí)改變前面某個(gè)變量的賦值；加速部分：非數(shù)值類型變量處理的加速、復(fù)雜表達(dá)式處理的加速、等式處理的加速、小區(qū)間有限回退技術(shù)等。

2) 故障定位。通過(guò)分析計(jì)算各程序語(yǔ)句發(fā)生故障的可疑度得到定位結(jié)果。針對(duì)測(cè)試用例對(duì)應(yīng)的執(zhí)行路徑集冗余問(wèn)題，消除重復(fù)的執(zhí)行路徑以及與失敗執(zhí)行路徑最不相似的成功執(zhí)行路徑，將約簡(jiǎn)后的執(zhí)行路徑集作為可疑空間，通過(guò)路徑邊元素的可疑度計(jì)算語(yǔ)句塊可疑度，最終得到根據(jù)可疑度大小進(jìn)行排序的語(yǔ)句塊序列，實(shí)現(xiàn)對(duì)故障的自動(dòng)定位。

3) 回歸測(cè)試。單元回歸測(cè)試的優(yōu)化工作在于構(gòu)造一個(gè)合理的測(cè)試用例集合，使得既能對(duì)軟件修改所影響的范圍進(jìn)行充分測(cè)試，又能盡量避免冗余測(cè)試，排除與修改內(nèi)容無(wú)關(guān)的測(cè)試用例。

3 工具應(yīng)用

缺陷測(cè)試系統(tǒng)(DTS)由北京郵電大學(xué)、北京博天院信息技術(shù)有限公司聯(lián)合研發(fā)，是國(guó)內(nèi)第一套面向代碼缺陷的測(cè)試工具。CTS是由北京郵電大學(xué)和北京博天院信息技術(shù)有限公司聯(lián)合研發(fā)的一款面向C語(yǔ)言的單元覆蓋測(cè)試工具。

3.1 測(cè)試Android4.0

Android4.0的代碼由三個(gè)部分構(gòu)成，其底層有5 919 784行C代碼，中間層有6 158 454行C++代碼，部分上層有5 336 619行Java代碼。DTS累積測(cè)試時(shí)間為219小時(shí)，分析及確認(rèn)的工作量為5人月。缺陷檢測(cè)結(jié)果見(jiàn)表1，平均故障類缺陷密度為2/KLOC，平均安全類缺陷密度為9.6/KLOC，平均疑問(wèn)類缺陷密度為20/KLOC，平均規(guī)則類缺陷密度為74.5/KLOC。

表1 Android4.0的缺陷檢測(cè)結(jié)果

3.2 測(cè)試開(kāi)源程序

對(duì)于開(kāi)源程序的測(cè)試，從Sourceforge中選取排名靠前的20個(gè)工程，Java代碼總計(jì)1 344 179行，C代碼總計(jì)100 725行，C++代碼總計(jì)111 918行。對(duì)其中故障類缺陷的分析結(jié)果見(jiàn)表2，平均故障密度為4.5/KLOC。

表2 對(duì)開(kāi)源程序的缺陷檢測(cè)結(jié)果

3.3 測(cè)試數(shù)據(jù)生成

對(duì)3個(gè)開(kāi)源工程進(jìn)行測(cè)試數(shù)據(jù)生成的測(cè)試，3個(gè)工程的屬性如表3。

利用CTS分別對(duì)其進(jìn)行語(yǔ)句覆蓋、分支覆蓋、MC/DC覆蓋3種覆蓋準(zhǔn)則下的測(cè)試數(shù)據(jù)自動(dòng)生成，測(cè)試結(jié)果如表4，工程aa200c中有77個(gè)被測(cè)單元，有40個(gè)單元能夠達(dá)到100%覆蓋，平均覆蓋率在80%以上，完成三種覆蓋準(zhǔn)則的測(cè)試數(shù)據(jù)生成總用時(shí)為108分鐘。工程qlib中有365個(gè)被測(cè)單元，平均有177個(gè)單元能夠達(dá)到100%覆蓋，平均覆蓋率為68%，完成3種覆蓋準(zhǔn)則的測(cè)試數(shù)據(jù)生成總用時(shí)為444分鐘。工程deco中有319個(gè)被測(cè)單元，平均有41個(gè)單元能夠達(dá)到100%覆蓋，平均覆蓋率為38%，由于deco工程中存在大量的復(fù)雜數(shù)據(jù)類型(例如函數(shù)指針、字符串結(jié)構(gòu)等)，所以有很多覆蓋率為0的情況，導(dǎo)致平均覆蓋率效果不如前兩個(gè)工程，完成3種覆蓋準(zhǔn)則的測(cè)試數(shù)據(jù)生成總用時(shí)為484分鐘。

表3 3個(gè)開(kāi)源工程屬性

表4 測(cè)試數(shù)據(jù)生成結(jié)果

3.4 國(guó)際工具對(duì)比

國(guó)際上典型的缺陷檢測(cè)工具有Klocwork、Coverity、Fortify和Logiscope等，DTS與其對(duì)比結(jié)果分別見(jiàn)圖3～圖6。

針對(duì)表2中的20個(gè)開(kāi)源工程，圖3中為Klocwork的K9與DTS針對(duì)故障類缺陷的對(duì)比結(jié)果。圖3中交集部分為雙方共同檢測(cè)出，最外側(cè)部分為雙方的誤報(bào)，其余部分為比對(duì)方多報(bào)的缺陷。其中K9的準(zhǔn)確率為73.9%，DTS的準(zhǔn)確率為75.9%；K9的相對(duì)漏報(bào)率為59%，DTS的相對(duì)漏報(bào)率為11.6%。

圖3 DTS與K9的對(duì)比結(jié)果

針對(duì)表2中的4個(gè)開(kāi)源程序(Playa、dgvideo、spgateway、bwchess)和3個(gè)軍工程序，圖4中為L(zhǎng)ogiscope與DTS的所有缺陷類型對(duì)比結(jié)果。Logiscope的規(guī)則側(cè)重于質(zhì)量度量，分為建議類和強(qiáng)制類。DTS的1317個(gè)故障類缺陷Logiscope均沒(méi)有覆蓋，其它類型的缺陷與Logiscope的交集有5 407個(gè)，而Logiscope的45 055個(gè)建議類缺陷DTS也沒(méi)有覆蓋。

圖4 DTS與Logiscope的對(duì)比結(jié)果

針對(duì)表2中的UUCP工程，圖5中為Coverity與DTS針對(duì)故障類缺陷的對(duì)比結(jié)果。圖5中各部分的含義與圖3中一致。其中Coverity的準(zhǔn)確率為80.72%，DTS的準(zhǔn)確率為71.68%；Coverity的相對(duì)漏報(bào)率為90.7%，DTS的相對(duì)漏報(bào)率為6.24%。

圖5 DTS與Coverity的對(duì)比結(jié)果

針對(duì)表2中的spell和barcode工程，圖6中為Fortify與DTS的對(duì)比結(jié)果。雙方共同測(cè)出內(nèi)存泄漏和緩沖區(qū)溢出問(wèn)題15個(gè)，而Fortify的269個(gè)安全缺陷DTS沒(méi)有測(cè)出，而DTS的1491個(gè)其它缺陷Fortify沒(méi)有測(cè)出。

圖6 DTS與Fortify的對(duì)比結(jié)果

3.5 國(guó)內(nèi)應(yīng)用情況

自2006年以來(lái)，DTS在4個(gè)國(guó)家863項(xiàng)目及2個(gè)自然科學(xué)基金項(xiàng)目資助下完成，主要技術(shù)指標(biāo)達(dá)到國(guó)際先進(jìn)、國(guó)內(nèi)領(lǐng)先的水平?；谙嚓P(guān)研究成果，發(fā)表論文70余篇，申請(qǐng)專利30余項(xiàng)(授權(quán)10余項(xiàng))，獲得軟件著作權(quán)登記17項(xiàng)。

DTS目前已經(jīng)在全國(guó)發(fā)行近500多個(gè)試用版，在美國(guó)、日本、歐洲、香港、澳門有零星使用，在國(guó)內(nèi)航天、航空、造船、銀行、證券、電信、電力、交通、冶金等領(lǐng)域廣泛應(yīng)用，擁有50多個(gè)商用單位，成功應(yīng)用于神舟、嫦娥及天宮等航空航天工程。

4 結(jié)束語(yǔ)

在基于代碼的軟件測(cè)試技術(shù)中，缺陷模式檢測(cè)和測(cè)試數(shù)據(jù)生成是效率很高的測(cè)試方法，具有其它測(cè)試無(wú)法替代的地位。隨著此技術(shù)的逐步成熟，相應(yīng)測(cè)試工具必然會(huì)在市場(chǎng)上廣泛流行。

在美國(guó)，面向缺陷模式的測(cè)試服務(wù)是軟件測(cè)試市場(chǎng)的主流方向之一。在我國(guó)，該技術(shù)的研究及應(yīng)用雖然剛剛起步，但已收到了很好的效果。在單元測(cè)試方面已經(jīng)得到廣泛應(yīng)用，但對(duì)復(fù)雜結(jié)構(gòu)對(duì)象、循環(huán)結(jié)構(gòu)和函數(shù)調(diào)用的處理仍存在較大的困難，這將是未來(lái)幾年的研究趨勢(shì)。

參考文獻(xiàn)

[1]Domain Market.com[EB/OL].[2015-04-20].http://www.klocwork.com

[2]Code Advisor on Demand[EB/OL].[2015-04-20].http://www.coverity.com

[3]Application Security[EB/OL].[2015-04-20].http://www.fortify.com

[4]Gimpel Software[EB/OL].[2015-04-20].http://www.gimpel.com

[5]北京博天院信息技術(shù)有限公司[EB/OL].[2015-04-20].http://www.dtstesting.com

[6]中國(guó)測(cè)試平臺(tái)[EB/OL].[2015-04-20].http://www.chinatesting.cn/331/12585331.shtml

[7]庫(kù)博[EB/OL].[2015-04-20].http://cobot.net.cn

[8]PARASOFT[EB/OL].[2015-04-20].http://www.parasoft.com

[9]Rational Software Analyzer Developer Edition[EB/OL].[2015-04-20].http://www-03.ibm.com/software/products/zh/rsade

[10]Software Testing[EB/OL].[2015-04-20].http://www.borland.com/Products/Software-Testing

[11]Elelogic Logiscope[EB/OL].[2015-04-20].ftp://public.dhe.ibm.com/software/rationalsdp/documentation/archive/Logiscope/version_6-5/ReviewerJava.pdf

[12]FindBugs[EB/OL].[2015-04-20].http://sourceforge.net/projects/f i ndbugs/

[13]Cadar C,Dunbar D,Engler D.KLEE:Unassisted and automatic generation of high-coverage tests for complex systems programs[C]//USENIX Symposium on Operating Systems Design and Implementation(OSDI 2008),San Diego,CA,USA,2008

[14]Koushik S,Darko M,Gul A.CUTE:a concolic unit testing engine for C[C]//The 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering,2005:263-272

[15]Godefroid P,Klarlund P,Sen P.DART:directed automated random testing[C]//The 2005 ACM SIGPLAN conference on Programming language design and implementation(PLDI),2005:213-223

[16]唐容.支持非數(shù)值型測(cè)試用例自動(dòng)生成的抽象內(nèi)存建模技術(shù)研究[D].北京郵電大學(xué),2013

[17]使用IBM Rational PurifyPlus[EB/OL].[2015-04-20].http://www.ibm.com/developerworks/cn/rational/07/0306_chitale/

[18]經(jīng)典的單元測(cè)試工具VcTester介紹[EB/OL].[2015-04-20].http://www.ltesting.net/html/30/n-161730.html

[19]凱樂(lè)軟件[EB/OL].[2015-04-20].http://www.kailesoft.com

[20]Agitar Technologies[EB/OL].[2015-04-20].http://www.agitar.com/solutions/products/agitarone.html