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

北京郵電大學網(wǎng)絡與交換技術(shù)國家重點實驗室 北京 1000876

概述

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

靜態(tài)白盒測試主要包括缺陷檢測技術(shù)、規(guī)則審查技術(shù)和質(zhì)量度量技術(shù)。缺陷檢測技術(shù)針對源代碼中存在的一些潛在語法或語義錯誤進行檢測，如對可能為空的指針進行解引用、對已分配的內(nèi)存沒有及時釋放、使用未經(jīng)過初始化的數(shù)據(jù)等問題，其難點在于需要準確地計算出復雜的執(zhí)行語義，典型的工具有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ù)針對一些特定的開發(fā)規(guī)范進行檢查，如版式規(guī)范、命名規(guī)范、書寫規(guī)范等，該技術(shù)在語法層面上進行檢測難度不大，典型工具有Parasoft的Jtest和C++test[8]、Rational的Software Analyzer[9]、MicroFocus公司DevPartner中的Source Code Review[10]功能、Telelogic公司Logiscope中的RuleChecker[11]功能和馬里蘭大學的FindBugs[12]；質(zhì)量度量技術(shù)首先定義若干個度量元，通過度量元的組合形成質(zhì)量標準，最后通過組合質(zhì)量標準形成質(zhì)量因素，該技術(shù)也是在語法層面展開的，典型的工具是Telelogic公司Logiscope中的Audit功能。

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

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

1 缺陷檢測技術(shù)

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

1.1 技術(shù)特點

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5) 分析部分。基于檢測到的缺陷及其相關(guān)信息，利用工具分析界面對測試結(jié)果的正確性進行分析，并將確認的結(jié)果導出。

1.3 缺陷模式

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

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

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

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

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

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

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

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

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

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

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

2 單元測試技術(shù)

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

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

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

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

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

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

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

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

2.2 覆蓋準則

測試覆蓋準則是指覆蓋測試的標準，包括語句覆蓋、分支覆蓋、謂詞覆蓋、MC/DC覆蓋、路徑覆蓋、定義使用覆蓋等，不同的準則對應要測試的對象或程序元素不同。典型的幾種覆蓋準則如下。

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

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

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

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

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

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

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

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

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

3 工具應用

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

3.1 測試Android4.0

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

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

3.2 測試開源程序

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

表2 對開源程序的缺陷檢測結(jié)果

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

對3個開源工程進行測試數(shù)據(jù)生成的測試，3個工程的屬性如表3。

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

表3 3個開源工程屬性

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

3.4 國際工具對比

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

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

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

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

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

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

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

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

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

3.5 國內(nèi)應用情況

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

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

4 結(jié)束語

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

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

參考文獻

[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]中國測試平臺[EB/OL].[2015-04-20].http://www.chinatesting.cn/331/12585331.shtml

[7]庫博[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ù)值型測試用例自動生成的抽象內(nèi)存建模技術(shù)研究[D].北京郵電大學,2013

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

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

[19]凱樂軟件[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