C語言軟件錯誤定位的測試用例庫構建

王 瑾

(北京航空航天大學 計算機學院,北京 100191)

C語言軟件錯誤定位的測試用例庫構建

王 瑾

(北京航空航天大學 計算機學院,北京 100191)

文章主要開發(fā)一個用于軟件錯誤定位的測試用例庫.該測試用例庫具有標準化、復用性、版本管理和統(tǒng)一管理這幾個特性，構建過程首先是確立了分類的標準，這里采用了三級分類的模式進行管理，通過分類產生了樹形管理結構.然后對測試用例中的源代碼文件進行了編碼以及說明標簽的填寫，從而生成標準化的測試用例，不斷完善測試用例庫.同時，根據(jù)系統(tǒng)的更新對測試用例進行修改和維護，保持測試用例庫的版本與當前系統(tǒng)版本的一致性.

C語言軟件;錯誤定位;測試用例庫

1 設計需求

傳統(tǒng)人工調試工具，譬如GDB和DBX提供基于主控臺的命令提示接口，而其他調試器前端應用普遍是提供給集成式開發(fā)工具(IDE)作為調試引擎，具有動態(tài)化、可視化等特點，但它們是命令行式工具，沒有圖形界面，不方便用戶使用.Visual Studio 調試器是一個功能強大的工具，能夠觀察程序的運行時行為并確定邏輯錯誤的位置，該調試器可用于所有的 Visual Studio 編程語言及其關聯(lián)的庫，但它僅實現(xiàn)了傳統(tǒng)的斷點調試等功能，依然在很大程度上依賴人工調試.WinDbg是在windows平臺下，強大的用戶態(tài)和內核態(tài)調試工具，但是它的大多數(shù)調試功能還是以手工輸入命令的方式來工作的.Eclipse CDT 作為Eclipse的面向C和C++語言的插件，它的存在使得Eclipse 可以完成許多C/C++ IDE一樣的功能，但它主要是在Eclipse功能上進行了C/C++語言程序調試的改進，依賴于Eclipse調試模式.KDevelop是一款功能強大的集成開發(fā)環(huán)境應用程序.它的研發(fā)最初是為了給KDE提供一個便于使用的集成開發(fā)環(huán)境，但它并不支持跨平臺，并且易用性不強.另外，目前(半)自動化調試工具采用的錯誤定位技術可以劃分為輕量級和重量級錯誤定位兩大類.輕量級錯誤定位通常是對測試的覆蓋信息或者執(zhí)行軌跡進行收集并分析，算法一般會在此基礎上采用統(tǒng)計方法或數(shù)據(jù)挖掘等方法進行數(shù)據(jù)信息處理，代表工具有Tarantula,SOBER和Crosstab等等.重量級錯誤定位主要是對程序依賴關系分析，這里依賴關系主要指數(shù)據(jù)依賴和控制依賴，其代表技術為程序切片.此外還有關注錯誤修復的調試工具，BugFix[10]和PACHIKA[11]都是其中的代表.但是在實際的軟件開發(fā)中自動化調試的應用技術仍舊不成熟，這是因為調試任務自身都具有其復雜性和特殊性，所以針對不同的調試任務想要尋找一種通用的調試方法是一件比較困難的事情.此外，在調試任務中，錯誤語句的定位結果往往具有不唯一性，因此調試方法需要對其定位結果具有較強的解釋能力.此外，如何提高定位結果的可靠性和精確度，這也是目前自動化程序調試領域熱點的研究問題.我們課題組正在研究和構建一個有機高效的軟件測試、調試和驗證環(huán)境，基本完成了面向C語言的半自動化調試系統(tǒng)的實現(xiàn).而本文主要研究軟件錯誤定位的測試用例庫，測試用例的設計與編碼，主要是為了檢查程序執(zhí)行的正確性和驗證執(zhí)行結果，進行對于測試程序的源代碼的編碼，用戶反饋信息的輸入設計，以及預期的定位結果等等的集合.測試用例庫的構建使得軟件錯誤定位的測試變得更加條理化和專業(yè)化.雖然在構建測試用例庫的過程中，該庫的設計需要耗費一定的成本，但是考慮到測試用例庫的可重復性很高，這樣可以極大地減少測試人員花費大量時間進行重復設計的成本，降低在系統(tǒng)開發(fā)過程中的各個測試活動的成本，縮短軟件測試的生命周期，提高測試的效率，因此構建測試用例庫是值得研究和開發(fā)的.

對于錯誤定位系統(tǒng)，軟件的測試用例經(jīng)常涉及到多重循環(huán)和復雜結構嵌套，不同的結構不同的執(zhí)行路徑都會產生不同的測試用例，并且對于每個測試的源代碼程序，“錯誤”的設計不同也會形成類型不同的測試用例，這些測試用例都是構成測試用例庫的基礎.

在構建測試用例庫的初始階段，是對測試用例庫的需求進行相應的分析，得到測試用例庫在設計和實現(xiàn)的時候所要遵循和實現(xiàn)的幾點要求.

1.1 標準化

要建立標準化的測試用例庫，則需要對于每個測試用例都要求測試用例的內容完整性.測試程序的源代碼程序需要根據(jù)本系統(tǒng)所定義的C語言核心子集的規(guī)則，進行編寫，測試用例中不可出現(xiàn)規(guī)則以外的語言.

測試用例的編寫以及描述需要規(guī)范化，也即測試用例要有標準格式.每個測試用例需要有源代碼程序和說明標簽.說明標簽的內容主要有測試用例的編號、測試名稱、測試功能，測試標題、測試級別、前置條件、測試輸入、操作步驟、預期結果等.

測試用例編號：主要是由數(shù)字組成，這里編號具有唯一性，易識別性.

測試名稱：主要是對該測試用例的簡單描述.用概括性的語言來描述該測試用例的測試點.

測試功能：主要是這個測試用例所測試的系統(tǒng)的功能模塊名稱.

測試級別：主要是根據(jù)測試的重要性劃分幾個等級，測試級別則表示該測試用例的重要程度屬于哪個級別.通常會分為三個等級，即高、中、低三個等級.高等級是指保證系統(tǒng)的基本功能的正確實現(xiàn)、系統(tǒng)特性的顯示的測試用例，通常使用頻率較高，測試的功能模塊也是系統(tǒng)的核心.低等級是指對系統(tǒng)的關鍵功能影響不大的測試用例，通常使用頻率也較低.中等級是重要程度介于高等級和低等級之間的測試用例.

前置條件：是執(zhí)行該測試用例的前提條件，如果不滿足這些條件，則無法進行測試.

測試輸入：主要是測試用例執(zhí)行時，需要輸入的數(shù)據(jù)信息.

測試步驟：是測試用例在執(zhí)行過程中所需的操作步驟，這里需要給出測試操作每一步的具體描述，使得測試人員并不需要對系統(tǒng)的實現(xiàn)方法進行了解即可進行測試工作，完成測試.

預期結果：對測試用例的執(zhí)行結果進行預期，得到預期結果，可用來與實際執(zhí)行結果對比，如果結果一致，則測試用例通過，如果不一致則測試用例失敗.

1.2 復用性

對于測試用例庫而言，測試用例的復用性可以在日后的測試工作中節(jié)約大量成本，測試工作人員不必耗費精力編寫相似的測試，因此復用性對于測試用例庫而言顯得尤為重要.

1.3 版本管理

測試用例庫通過不斷地維護，對于測試用例可能會出現(xiàn)多個版本，對其進行版本管理也是測試用例庫在設計過程中需要考慮的一點.并且系統(tǒng)在研發(fā)過程中可能會出現(xiàn)版本更替，如何將測試用例的版本與當前系統(tǒng)版本一致，根據(jù)系統(tǒng)的新版本，如何修改或者創(chuàng)建新的測試用例，也都是測試用例庫構建的重點.

1.4 統(tǒng)一管理

系統(tǒng)構建測試用例庫，而不是簡簡單單設計幾個測試用例，就是系統(tǒng)對于測試用例的組織化的需求，系統(tǒng)需求一個系統(tǒng)性的有組織的測試用例庫，從而能夠達到對系統(tǒng)的各個功能模塊的覆蓋，減少重復性測試，擴展測試的覆蓋范圍.針對系統(tǒng)的不同的功能模塊，不同的測試階段，測試用例所實現(xiàn)的目的有所不同，這需要不同的測試用例來對其進行測試，而大量的測試用例需要有組織性的管理.通常測試用例庫都是采用樹形化結構管理，這種方式對于測試工作來說結構清晰易于管理.

系統(tǒng)對于測試用例庫的構件會根據(jù)上述幾點用例庫的要求來進行設計和維護，形成系統(tǒng)化有組織結構的錯誤定位的測試用例庫，提供各種測試用例來完成本系統(tǒng)的測試工作，提高測試的效率.

2 測試用例庫構建

測試用例庫在設計的時候主要針對本自動化調試系統(tǒng)進行分析設計，編寫具有一定針對性的測試用例.考慮到測試用例庫的組織結構，這里采用樹形結構化管理，因此需要多級分類.

2.1 分類標準

首先，本測試用例庫主要采用了三級分類的形式來進行測試用例的設計，然后確定三級分類的標準.本系統(tǒng)的基礎部分也就是程序解析部分，定義了C語言的核心子集，系統(tǒng)主要是針對該核心子集進行功能實現(xiàn)，因此測試用例的源代碼所包含的數(shù)據(jù)類型作為第一級分類.

而包含相同數(shù)據(jù)類型的源代碼程序由于程序的語法結構的不同，也會產生多種不同的測試用例，因此在一級分類下根據(jù)程序的語法結構不同進行分類，作為二級分類標準.

考慮到錯誤定位是本系統(tǒng)所實現(xiàn)的最核心的功能，因此系統(tǒng)首要考慮的就是所需要定位出的錯誤是哪種類型，本系統(tǒng)所采用的錯誤定位算法是否能夠檢測出這類錯誤.因此錯誤類型的分類作為第三級分類標準.

2.2 樹形管理結構

根據(jù)上一小節(jié)的三級分類標準，對每一個分類標準都進行類別選擇，通過三級分類類別選擇，則可以形成測試用例庫的樹形管理結構.

首先，根據(jù)分類標準進行每一級的類別選擇.根據(jù)第一級的分類標準，針對源代碼包含的數(shù)據(jù)類型的不同進行分類，可以分為int-tests(1)array-tests(2)pointer-tests(3)struct-tests(4)等等；根據(jù)第二級的分類標準，針對源代碼程序的語法結構的不同進行分類，可以分為assgin-tests(1)if-else-tests(2)for-tests(3)while-tests(4)switch-tests(5)nest-tests(6)等，這里的數(shù)據(jù)結構主要是以源代碼程序中包含的復雜度比較高的語法結構進行歸類；根據(jù)第三級的分類標準，針對錯誤類型的不同進行分類，這里考慮到現(xiàn)階段系統(tǒng)主要采用的是形式化的錯誤定位算法，該算法主要在定位賦值語句錯誤以及條件表達式錯誤等情況下效果良好，可以分為assginerror-tests(1)和conditionerror-tests(2)等.對于具體的測試用例，其編號為三位數(shù)字，每一位數(shù)字分別代表了第一級類別、第二級類別、第三級類別屬性，比如某個測試用例的編號為2421，則它屬于array-tests里for-tests中的assginerror-tests類里第一個測試用例，因此它的源代碼程序是包含數(shù)組類型的，語法結構包含while循環(huán)語句的程序，并且它是用來測試對條件表達式錯誤定位的測試用例.

2.3 測試用例設計

根據(jù)測試用例庫的管理結構，針對第三級下的每個類別，可以進行其測試用例的設計和編碼，需要符合這個測試用例所在的三級分類各級的類別屬性.比如說對于編號2421的測試用例源代碼的編寫，考慮其源代碼的特性是包含數(shù)組類型的，語法結構包含while循環(huán)語句的程序.因此可以進行如下編碼(這里以一個簡單的源代碼程序舉例)以及其說明標簽.

圖1 1源代碼編碼

表1 說明標簽填寫

如此根據(jù)分類類別，來進行源代碼的編碼，以及說明標簽的填寫.本測試用例庫中相對簡單的程序均為自動手動編寫，有較多復雜結構的測試源程序是由西門子測試用例集中的測試用例改編而來，將其結構修改為本系統(tǒng)所支持的數(shù)據(jù)類型及程序結構，從而形成系統(tǒng)的測試用例庫，這個過程花費了大量的時間，但是為之后系統(tǒng)的各個功能測試奠定了基礎.

3 測試用例庫維護

一個軟件系統(tǒng)在研發(fā)的過程中，會經(jīng)過多個版本的更替，系統(tǒng)會不斷地進行改動，功能或者模塊均可能產生變化，而隨著這些改變，很多測試用例可能會失去其針對性和有效性，而有些測試用例會產生不同的執(zhí)行結果，對結果分析也會有相應的影響，這就需要不斷地對測試用例庫進行維護，來保證測試用例庫功能的完善以及測試結果的準確性.根據(jù)系統(tǒng)的改動，對于新增加的功能編寫相應的測試用例，如果已有的測試用例與新增加的功能有所關聯(lián)，則相應的修改已有的測試用例.

隨著系統(tǒng)的不斷完善，測試用例的不斷增加，可能會不斷出現(xiàn)新的分類類別，這原有的三級分類的基礎上分別進行補充，使得測試用例庫的規(guī)模逐漸擴大，逐步形成系統(tǒng)級的測試用例庫.

4 總結

本文主要對系統(tǒng)的測試用例庫的構建進行了詳細闡述.第一小節(jié)主要是對測試用例庫構建的需求，主要是要求測試用例庫具有標準化、復用性、版本管理和統(tǒng)一管理這幾個特性，因此在設計和構建測試用例庫的過程中都需要遵循這些要求.第二小節(jié)主要就是描述了測試用例庫構建的過程，首先是確立了分類的標準，這里采用了三級分類的模式進行管理，通過分類產生了樹形管理結構.然后對測試用例中的源代碼文件進行了編碼以及說明標簽的填寫，從而生成標準化的測試用例，不斷完善測試用例庫.第三小節(jié)描述了跟據(jù)系統(tǒng)的更新對測試用例進行修改和維護，保持測試用例庫的版本與當前系統(tǒng)版本的一致性.

[1] STALLMAN R,PESCH R,SHEBS S.Debugging with gdb-the gnu source-level debugger.GNU Press,2006

[2] LINTON M A.The Evolution of Dbx//In:Proceedings of the Summer USENIX Conference,1990,6:211-220

[3] DEBUGGER M V S.Microsoft Visual Studio Debugger.Network Dictionary,2007

[4] 車叔平.基于Eclipse的嵌入式開發(fā)平臺的研究與實現(xiàn).成都:電子科技大學,2007

[5] 王 倩.基于Android端到端實時無線視頻傳輸系統(tǒng).南京:南京郵電大學,2013

[6] NOLDEN R.Developing C/C++Applications with the KDEvelop IDE.Linux Journal,2002,95:11-15

[7] 賀 韜,王欣明,周曉聰,等.一種基于程序變異的軟件錯誤定位技術.計算機學報,2013(11):2236-2244

[8] LIU C,YAN X,FEI L,et al.SOBER:statistical model-based bug localization.Sigsoft Softw.eng.notes,2005,30(5):286-295

[9] WONG W E,WEI T,QI Y,et al.A Crosstab-based Statistical Method for Effective Fault Localization//Software Testing,Verification,and Validation,2008 1st International Conference on.IEEE,2008:42-51

[10] JEFFREY D,FENG M,GUPTA N,et al.BugFix:a learning-based tool to assist developers in fixing bugs//Program Comprehension,2009.ICPC'09.IEEE 17th International Conference on.IEEE,2009:70-79

[11] DALLMEIER V,LINDIG C,ZELLER A.Lightweight defect localization for java..Lecture Notes in Computer Science,2005,3586:528-550

Test Case Library Building for Wrong Positioning of C Language Software

WANG Jin

(School of Computer and Engineering, Beihang University, Beijing 100191, China)

This paper mainly studies and develops a test case library for wrong positioning. It is some characteristics of standardization, reusability, version management and unified management, the building process includes two stages, the first stage decides the criterion which adopts three-level classification model and produces the three management structure by the three-level classification mode, the second stage encodes the source code file in the test case library to generate the standardized the cases and improve the test case library. Meanwhile, to modify and maintain the library according to system updating maintains the test case library version the consistency with the current system.

C language software; wrong positioning;test case library

2015-10-14

王 瑾(1991-)，女，山西太原人，北京航空航天大學在讀研究生，主要從事軟件理論研究.

1672-2027(2015)04-0058-05

TP391

A