軟件測試技術研究

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

關鍵詞：軟件測試；靜態測試；動態測試；黑盒測試；白盒測試；灰盒測試；V模型；B模型

引言

20世紀60年代中期，隨著計算機硬件的迅猛發展，計算機的應用范圍迅速擴大，軟件開發數量急劇增長，計算機系統應用越來越廣泛。軟件快速的需求增長使得軟件開發中的矛盾越來越突出——軟件危機出現了。軟件工程應運而生，軟件測試的作用越來越重要。

1 什么是軟件測試

1993 年IEEE 給出了軟件測試的定義: “將系統化的、規范的、可度量的方法應用于軟件的開發、運行和維護的過程， 即將工程化應用于軟件中”。

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

2 軟件測試的方法

2．1靜態測試和動態測試

從是否需要執行被測軟件的角度，將軟件測試分為靜態測試和動態測試。

靜態測試是指被測試程序不在機器上運行，而是采用人工檢測和計算機輔助靜態分析的手段對程序進行檢測，主要方法包括人工測試和計算機輔助靜態分析。相對動態測試，靜態測試可以更早地進行。靜態分析的查錯和分析功能是其他方法所不能替代的，靜態分析能發現文檔中問題。目前，靜態測試已被當做一種自動化的、主要的代碼校驗方法。但靜態測試不能檢測程序的實際執行情況，無法得到程序的執行結果。

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

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

從測試是否針對系統的內部結構和具體實現算法的角度，將軟件測試分為黑盒測試、白盒測試和灰盒測試。

黑盒測試，也稱功能測試或數據驅動測試。黑盒測試是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用。測試時，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，并且保持外部信息的完整性。“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。

白盒測試，也稱結構測試或邏輯驅動測試。白盒測試是已知產品內部工作過程，通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，主要用于軟件驗證。“白盒”法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。“白盒”法 是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤，因為窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。

灰盒測試，確實是介于黑盒測試和白盒測試之間的，灰盒測試關注輸出對于輸入的正確性，同時也關注內部表現，但這種關注不象白盒那樣詳細、完整，只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態。有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率 會很低，因此需要采取這樣的一種灰盒的方法。灰盒測試結合了白盒測試盒黑盒測試的要素。它考慮了用戶端、特定的系統知識和操作環境。它在系統組件的協同性環境中評價應用軟件的設計。

3 軟件測試過程

一個大型軟件系統通常由若干個子系統構成， 每個子系統又由若干個模塊構成。軟件測試過程如下:

3.1 單元測試

又稱模塊測試。它是針對軟件設計的最小單位--程序模塊， 進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。單元測試需要從程序的內部結構出發設計測試用例。多模塊可以平行的獨立進行單元測試。

3．2 組裝測試

又稱集成測試。通常， 在單元測試的基礎上， 需要將所有模塊按照設計要求組裝成為系統。這時需要考慮的問題是: 在把各個模塊連接起來時， 穿越模塊接口的數據是否會丟失; 一個模塊的功能是否會對另一個模塊的功能產生不利的影響; 各個子功能組合起來， 能否達到預期要求的父功能; 全局數據結構是否有問題; 單個模塊的誤差累積起來， 是否會放大， 從而達到不能接受的程度。

3．3 確認測試

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

3．4 系統測試

是將通過確認測試的軟件， 作為整個基于計算機系統的一個元素， 與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起， 在實際運行( 使用) 環境下， 對計算機系統進行一系列的組裝測試和確認測試。系統測試的目的在于通過與系統的需求定義作比較， 發現軟件與系統定義不符合或與之矛盾的地方。

4軟件測試的模型

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

V 模型指出， 單元和集成測試應檢測程序的執行是否滿足軟件設計的要求; 系統測試應檢測系統功能、性能的質量特性是否達到系統要求的指標; 驗收測試確定軟件的實現是否滿足用戶需要或合同的要求。但V 模型存在一定的局限性， 它僅僅把測試作為在編碼之后的一個階段， 是針對程序進行的尋找錯誤的活動， 而忽視了測試活動對需求分析、系統設計等活動的驗證和確認的功能。

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

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

在B 模型中， 軟件開發過程中各個階段的可交付產品都要進行測試，以便盡可能地使各階段產生的錯誤在該階段得到發現和解決，防止在后期階段放置太多的問題。

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

在實際工作中，我們要靈活運用各種模型的優點，在各種模型相互補充的框架下，尋找恰當的就緒點開始測試并反復迭代測試，最終保證按期完成預定目標。

參考文獻

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

[2]楊崑.軟件開發管理中的溝通與協調問題研究[J].中國管理科學.2004，12

[3 ] 羅國慶. 實用軟件測試方法與應用[M] . 北京:電子工業出版社，2003.

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

[ 5] 鄭人杰.計算機軟件測試技術.北京: 清華大學出版社.1992