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

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

引言

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

1 什么是軟件測試

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

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

2 軟件測試的方法

2．1靜態(tài)測試和動態(tài)測試

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

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

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

2．2 黑盒測試、白盒測試和灰盒測試

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

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

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

灰盒測試，確實(shí)是介于黑盒測試和白盒測試之間的，灰盒測試關(guān)注輸出對于輸入的正確性，同時(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ò)誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率 會很低，因此需要采取這樣的一種灰盒的方法。灰盒測試結(jié)合了白盒測試盒黑盒測試的要素。它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協(xié)同性環(huán)境中評價(jià)應(yīng)用軟件的設(shè)計(jì)。

3 軟件測試過程

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

3.1 單元測試

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

3．2 組裝測試

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

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

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

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

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

4軟件測試的模型

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

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

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

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

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

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

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

參考文獻(xiàn)

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

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

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

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

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