軟件測(cè)試技術(shù)研究

摘要：本文介紹了軟件測(cè)試的重要性和目的，闡述了軟件測(cè)試技術(shù)的方法和軟件測(cè)試的一般過程，分析了目前常見的軟件測(cè)試模型，并提出了一種新的軟件測(cè)試模型。

關(guān)鍵詞：軟件測(cè)試；靜態(tài)測(cè)試；動(dòng)態(tài)測(cè)試；黑盒測(cè)試；白盒測(cè)試；灰盒測(cè)試；V模型；B模型

引言

20世紀(jì)60年代中期，隨著計(jì)算機(jī)硬件的迅猛發(fā)展，計(jì)算機(jī)的應(yīng)用范圍迅速擴(kuò)大，軟件開發(fā)數(shù)量急劇增長(zhǎng)，計(jì)算機(jī)系統(tǒng)應(yīng)用越來越廣泛。軟件快速的需求增長(zhǎng)使得軟件開發(fā)中的矛盾越來越突出——軟件危機(jī)出現(xiàn)了。軟件工程應(yīng)運(yùn)而生，軟件測(cè)試的作用越來越重要。

1 什么是軟件測(cè)試

1993 年IEEE 給出了軟件測(cè)試的定義: “將系統(tǒng)化的、規(guī)范的、可度量的方法應(yīng)用于軟件的開發(fā)、運(yùn)行和維護(hù)的過程， 即將工程化應(yīng)用于軟件中”。

目前，國(guó)際上已對(duì)軟件測(cè)試形成一個(gè)共識(shí): 軟件測(cè)試就是在軟件投入使用前，對(duì)軟件的需求分析、設(shè)計(jì)規(guī)格說明和系統(tǒng)編碼的最終復(fù)審。由此可見，軟件測(cè)試的對(duì)象不僅僅是程序，需求規(guī)格說明、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、源程序等都是軟件測(cè)試的對(duì)象。

2 軟件測(cè)試的方法

2．1靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試

從是否需要執(zhí)行被測(cè)軟件的角度，將軟件測(cè)試分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試。

靜態(tài)測(cè)試是指被測(cè)試程序不在機(jī)器上運(yùn)行，而是采用人工檢測(cè)和計(jì)算機(jī)輔助靜態(tài)分析的手段對(duì)程序進(jìn)行檢測(cè)，主要方法包括人工測(cè)試和計(jì)算機(jī)輔助靜態(tài)分析。相對(duì)動(dòng)態(tài)測(cè)試，靜態(tài)測(cè)試可以更早地進(jìn)行。靜態(tài)分析的查錯(cuò)和分析功能是其他方法所不能替代的，靜態(tài)分析能發(fā)現(xiàn)文檔中問題。目前，靜態(tài)測(cè)試已被當(dāng)做一種自動(dòng)化的、主要的代碼校驗(yàn)方法。但靜態(tài)測(cè)試不能檢測(cè)程序的實(shí)際執(zhí)行情況，無法得到程序的執(zhí)行結(jié)果。

動(dòng)態(tài)測(cè)試是實(shí)際運(yùn)行被測(cè)程序，輸入相應(yīng)的測(cè)試用例，判定執(zhí)行結(jié)果是否符合要求，從而檢驗(yàn)程序的正確性、可靠性和有效性。一般意義上的測(cè)試主要是指動(dòng)態(tài)測(cè)試。為了使測(cè)試發(fā)現(xiàn)更多的錯(cuò)誤，需要運(yùn)用一些有效的方法：一種是黑盒測(cè)試，即測(cè)試產(chǎn)品的功能；一種是白盒測(cè)試，即測(cè)試產(chǎn)品內(nèi)部結(jié)構(gòu)及處理過程。動(dòng)態(tài)測(cè)試是一種經(jīng)常運(yùn)用的測(cè)試方法，無論在單元測(cè)試、集成測(cè)試中，還是在系統(tǒng)測(cè)試、驗(yàn)收測(cè)試中，都是一種有效的測(cè)試方法。但動(dòng)態(tài)測(cè)試不能發(fā)現(xiàn)文檔問題，必須等待程序代碼完成后進(jìn)行，發(fā)現(xiàn)問題相對(duì)遲得多，一旦發(fā)現(xiàn)問題，必須重新設(shè)計(jì)、重新編碼，必然增大不良質(zhì)量的成本。

2．2 黑盒測(cè)試、白盒測(cè)試和灰盒測(cè)試

從測(cè)試是否針對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法的角度，將軟件測(cè)試分為黑盒測(cè)試、白盒測(cè)試和灰盒測(cè)試。

黑盒測(cè)試，也稱功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試。黑盒測(cè)試是在已知產(chǎn)品所應(yīng)具有的功能，通過測(cè)試來檢測(cè)每個(gè)功能是否都能正常使用。測(cè)試時(shí)，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測(cè)試者在程序接口進(jìn)行測(cè)試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息的完整性。“黑盒”法著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對(duì)軟件界面和軟件功能進(jìn)行測(cè)試?！昂诤小狈ㄊ歉F舉輸入測(cè)試，只有把所有可能的輸入都作為測(cè)試情況使用，才能以這種方法查出程序中所有的錯(cuò)誤。實(shí)際上測(cè)試情況有無窮多個(gè)，人們不僅要測(cè)試所有合法的輸入，而且還要對(duì)那些不合法但是可能的輸入進(jìn)行測(cè)試。

白盒測(cè)試，也稱結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。白盒測(cè)試是已知產(chǎn)品內(nèi)部工作過程，通過測(cè)試來檢測(cè)產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，主要用于軟件驗(yàn)證?！鞍缀小狈ㄈ媪私獬绦騼?nèi)部邏輯結(jié)構(gòu)、對(duì)所有邏輯路徑進(jìn)行測(cè)試?！鞍缀小狈?是窮舉路徑測(cè)試。在使用這一方案時(shí)，測(cè)試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測(cè)試數(shù)據(jù)。貫穿程序的獨(dú)立路徑數(shù)是天文數(shù)字。但即使每條路徑都測(cè)試了仍然可能有錯(cuò)誤，因?yàn)楦F舉路徑測(cè)試決不能查出程序違反了設(shè)計(jì)規(guī)范，即程序本身是個(gè)錯(cuò)誤的程序。

灰盒測(cè)試，確實(shí)是介于黑盒測(cè)試和白盒測(cè)試之間的，灰盒測(cè)試關(guān)注輸出對(duì)于輸入的正確性，同時(shí)也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細(xì)、完整，只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運(yùn)行狀態(tài)。有時(shí)候輸出是正確的，但內(nèi)部其實(shí)已經(jīng)錯(cuò)誤了，這種情況非常多，如果每次都通過白盒測(cè)試來操作，效率 會(huì)很低，因此需要采取這樣的一種灰盒的方法。灰盒測(cè)試結(jié)合了白盒測(cè)試盒黑盒測(cè)試的要素。它考慮了用戶端、特定的系統(tǒng)知識(shí)和操作環(huán)境。它在系統(tǒng)組件的協(xié)同性環(huán)境中評(píng)價(jià)應(yīng)用軟件的設(shè)計(jì)。

3 軟件測(cè)試過程

一個(gè)大型軟件系統(tǒng)通常由若干個(gè)子系統(tǒng)構(gòu)成， 每個(gè)子系統(tǒng)又由若干個(gè)模塊構(gòu)成。軟件測(cè)試過程如下:

3.1 單元測(cè)試

又稱模塊測(cè)試。它是針對(duì)軟件設(shè)計(jì)的最小單位--程序模塊， 進(jìn)行正確性檢驗(yàn)的測(cè)試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。單元測(cè)試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例。多模塊可以平行的獨(dú)立進(jìn)行單元測(cè)試。

3．2 組裝測(cè)試

又稱集成測(cè)試。通常， 在單元測(cè)試的基礎(chǔ)上， 需要將所有模塊按照設(shè)計(jì)要求組裝成為系統(tǒng)。這時(shí)需要考慮的問題是: 在把各個(gè)模塊連接起來時(shí)， 穿越模塊接口的數(shù)據(jù)是否會(huì)丟失; 一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響; 各個(gè)子功能組合起來， 能否達(dá)到預(yù)期要求的父功能; 全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題; 單個(gè)模塊的誤差累積起來， 是否會(huì)放大， 從而達(dá)到不能接受的程度。

3．3 確認(rèn)測(cè)試

又稱有效性測(cè)試。它的任務(wù)是驗(yàn)證軟件的功能和性能及其他特性是否與用戶的要求一致。首先要進(jìn)行有效性測(cè)試以及軟件配置復(fù)審， 然后進(jìn)行驗(yàn)收測(cè)試和安裝測(cè)試， 在通過了專家鑒定之后， 才能成為可交付的軟件。

3．4 系統(tǒng)測(cè)試

是將通過確認(rèn)測(cè)試的軟件， 作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素， 與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起， 在實(shí)際運(yùn)行( 使用) 環(huán)境下， 對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測(cè)試和確認(rèn)測(cè)試。系統(tǒng)測(cè)試的目的在于通過與系統(tǒng)的需求定義作比較， 發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方。

4軟件測(cè)試的模型

在20 世紀(jì)80 年代后期Paul Rook 提出了著名的軟件測(cè)試的V 模型， 旨在改進(jìn)軟件開發(fā)的效率和效果。V 模型反映出了測(cè)試活動(dòng)與分析設(shè)計(jì)活動(dòng)的關(guān)系。在圖1 中， 從左到右描述了基本的開發(fā)過程和測(cè)試行為， 非常明確的標(biāo)注了測(cè)試過程中存在的不同類型的測(cè)試， 并且清楚的描述了這些測(cè)試階段和開發(fā)過程期間各階段的對(duì)應(yīng)關(guān)系。

V 模型指出， 單元和集成測(cè)試應(yīng)檢測(cè)程序的執(zhí)行是否滿足軟件設(shè)計(jì)的要求; 系統(tǒng)測(cè)試應(yīng)檢測(cè)系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo); 驗(yàn)收測(cè)試確定軟件的實(shí)現(xiàn)是否滿足用戶需要或合同的要求。但V 模型存在一定的局限性， 它僅僅把測(cè)試作為在編碼之后的一個(gè)階段， 是針對(duì)程序進(jìn)行的尋找錯(cuò)誤的活動(dòng)， 而忽視了測(cè)試活動(dòng)對(duì)需求分析、系統(tǒng)設(shè)計(jì)等活動(dòng)的驗(yàn)證和確認(rèn)的功能。

Evolutif 公司針對(duì)V 模型的缺陷， 相對(duì)于V 模型， 提出了W模型的概念。W模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)。W模型由兩個(gè)V 字型模型組成， 分別代表測(cè)試與開發(fā)過程。

針對(duì)v模型的缺陷，我們提出B模型的概念。如下圖：

在B 模型中， 軟件開發(fā)過程中各個(gè)階段的可交付產(chǎn)品都要進(jìn)行測(cè)試，以便盡可能地使各階段產(chǎn)生的錯(cuò)誤在該階段得到發(fā)現(xiàn)和解決，防止在后期階段放置太多的問題。

測(cè)試與開發(fā)是同步進(jìn)行的，從而有利于盡早地發(fā)現(xiàn)問題。以需求為例，需求分析一完成，我們就可以對(duì)需求進(jìn)行測(cè)試，而不是等到最后才進(jìn)行針對(duì)需求的驗(yàn)收測(cè)試。測(cè)試伴隨整個(gè)開發(fā)周期.測(cè)試的對(duì)象不僅僅是程序，還包括需求和設(shè)計(jì)。

在實(shí)際工作中，我們要靈活運(yùn)用各種模型的優(yōu)點(diǎn)，在各種模型相互補(bǔ)充的框架下，尋找恰當(dāng)?shù)木途w點(diǎn)開始測(cè)試并反復(fù)迭代測(cè)試，最終保證按期完成預(yù)定目標(biāo)。

參考文獻(xiàn)

[1]佩騰.軟件測(cè)試[M].北京:機(jī)械工業(yè)出版社， 2006，4.

[2]楊崑.軟件開發(fā)管理中的溝通與協(xié)調(diào)問題研究[J].中國(guó)管理科學(xué).2004，12

[3 ] 羅國(guó)慶. 實(shí)用軟件測(cè)試方法與應(yīng)用[M] . 北京:電子工業(yè)出版社，2003.

[4 ] Paul C Jorgensen. Software Testing ，A Craftman ，sApproach[M] . 北京:機(jī)械工業(yè)出版社.

[ 5] 鄭人杰.計(jì)算機(jī)軟件測(cè)試技術(shù).北京: 清華大學(xué)出版社.1992