面向對象軟件測試綜述

面向對象軟件測試綜述

摘要:面向對象的軟件測試是面向對象軟件開發的不可缺少的一環,是保證軟件質量、提高軟件可靠性的關鍵。結合傳統軟件測試的方法和技術,並針對面向對象軟件所具有的特徵,將面向對象軟件測試層次 劃分爲三層:類測試、類簇測試和系統測試。本文闡述了面向對象軟件測試的基本原理及意義以及它與傳統軟件測試的區別,討論了幾種已有的面向對象的軟件測試工具。

關鍵詞:軟件測試;類測試;測試工具;

Abstract:Object-oriented software testing is indispensable to the development of object-oriented software,and is the key to software quality and reliability.Combining with the method and technique of traditional testing,and according to the characteristics of object-oriented software,divides hiberarchy of object-oriented software testing into three layers: class

testing,class cluster testing,system testing. This paper describes the basic principles and the significance of object-oriented software testing.It also says the distinction of the traditional software testing and the object-oriented software testing.,and it discusses several existing object-oriented software testing tools.

Keywords:software testing;class testing;testing tools;

1、引言

軟件測試在軟件生存期中佔有非常突出的重要位置。測試的目的就是在軟件投入生產性運行之前,儘可能多地發現軟件中的錯誤。 隨着軟件的質量和可靠性越來越受到人們的關注,軟件測試作與之相應的重要保障手段之一也越來越得到重視。自20世紀80年代以來,面向對象方法和技術的研究已遍及計算機軟件、硬件和應用各領域,在軟件工程領域更是得到了廣泛的重視,但研究的重點和成果主要集中於面向對象分析與技術方法學領域(即軟件的開發前期),而面向對象軟件測試技術的研究還比較薄弱。面向對象軟件的封閉性、繼承性、多態性和動態連接等特性使面向對象軟件測試不能完全採用傳統的測試思想和方法,面向對象軟件測試的研究成爲十分緊迫的任務。

國內外面向對象軟件測試目前還處於探索性的研究階段,其層次的劃分還未達成共識,但一般地,從面向對象程序的結構出發,將面向對象軟件的測試分爲四個層次:方法測試、類測試、類簇測試、系統測試。其中方法測試和系統測試可採用傳統的測試進行測試,但類測試和類簇測試是面向對象測試過程所特有的,不能直接使用傳統測試方法。目前,有關類簇測試的研究還很少,面向對象軟件測試的研究主要集中於類測試。 2 、軟件測試技術

軟件測試就是“爲了發現程序中的錯誤而執行程序的過程”,所以爲了發現程序中的錯誤,力求設計出最能暴露錯誤的測試方案。所以軟件測試決不能證明程序是正確的。即使經過了最嚴格的測試之後,仍然可能還有沒被發現的錯誤潛藏在程序中。測試只能查找出程序中的錯誤,不能證明程序中沒有錯誤。

2.1軟件測試的方法

2.2.1 黑盒測試

黑盒測試又稱爲功能測試,是一種面向設計的測試。這種測試在完全不考慮測試對象內部結構的情況下,把被測程序當作一個黑盒,根據程序的功能和外部特性得到測試數據。進行黑盒測試在所必須具備的文檔有產品描述、用戶文檔及安裝指令。軟件的黑盒測試被用來證實軟件功能的正確性和可操作性。

2.2.2 白盒測試

白盒測試是假定測試對象的內部是已知的,允許測試者檢查測試對象的內部結構,並使用其結構信息來設計測試安全和測試對象是否滿足規範的要求,測試者可以完全不考慮測試對象的功能。進行白盒測試所具備的文檔有設計文檔和程序文檔。

2.2 傳統軟件測試的步驟

傳統的軟件測試過程可以按四個步驟進行,即單元測試、集成測試、確認測試和系統測試。

2.3.1 單元測試

單元測試是完成對最小軟件設計單位—程序模塊,進行正確性檢驗的測試工作,其目的在於發現各模塊內部可能存在的各種錯誤。單元測試需要從程序的內部結構出發設計測試用例,即採用白盒測試方法,而且多個模塊並行地進行單元測試。

2.3.2 集成測試

在每個模塊完成單元測試以後,需要按照設計時畫出的結構圖,把它們連接起來,進行集成測試。

2.3.3 確認測試

確認測試的任務就是進一步檢查軟件的功能和性能是否與用戶要求的一樣。它通過一系列證明軟件功能和需求一致的黑盒測試來完成。

2.3.4 系統測試

系統測試是將已經通過確認測試的軟件,作爲整個基於計算機系統的一個元素,與計算機硬件、外設、某些支持軟件、數據和人員等其它系統元素結合在一起,在實際運行環境下,對計算機系統進行一系列的集成測試和確認測試。系統測試的目的在於通過與系統的需求定義作比較,發現軟件與系統定義不符合或與之矛盾的地方。

3 、面向對象的軟件測試

在面向對象分析設計方法中,基本的構成是類和對象。對象是封裝了描述其屬性的數據(對象的狀態)以及可以對這些數據實施的操作,對象之間通過改善消息相互協作。類是一組相似對象的描述,描述了該類對象所具有的共同特徵。面向對象的程序設計又提供了信息隱蔽、繼承、金礦和動態綁定等機制。這種軟件開發方法固有的特性,給軟件測試理論、技術、方法等方面帶來了巨大的影響,使得傳統的軟件測試方法以及測試工具已不能爲面向對象的軟件提供良好的支持。

3.1 面向對象軟件測試的特點

面向對象程序結構不再是傳統的功能模塊結構,作爲一個整體,原有集成測試所要求的逐步將開發的模塊搭建在一起進行測試的方法已成爲不可能。面向對象軟件拋棄了傳統的開發模式,對每個開發階段都有不同以往的要求和結果,已經不可能用功能細化的觀點來檢測面向對象分析和設計的結果。傳統的測試模型對面向對象軟件已經不再適用。

3.2面向對象的特點對軟件測試的影響

3.2.1基本構造模塊

在面向對象系統中,系統的基本構造模塊是封裝了數據和方法的類和對象,而不再是一個個能完成特定功能的功能模塊。每個對象有自己的生存週期,有自己的狀態。消息是對象之間相互請求或協作的途徑,是外界使用對象方法及獲取對象狀態的唯一方式。對象的功能是在消息的觸發下,由對象所屬類中定義的方法與相關對象的合作共同完成的,且在不同狀態下對消息的響應可能完全不同。工作過程中對象的狀態可能被改變,產

生新的狀態。對象中的數據和方法是一個有機的整體,測試過程中不能僅僅檢查輸入數據產生的輸出結果是否與預期的吻合,還要考慮對象的狀態。模塊測試的概念已不適用於對象的測試。

3.2.2系統功能實現

在面向對象系統中,系統的功能體現在對象間的協作上,而不再是簡單的過程調用關係,面向對象程序的執行實際上是執行一個由消息連接起來的方法序列,方法的實現與所屬對象本身的狀態有關,各方法之間可能有相互作用。爲實現某一特定的功能,有可能要激活調用屬於不同對象類的多個成員函數,形成成員函數的啓用鏈。顯然,基於功能分解的自頂向下或自底向上的集成測試策略並不適用於以面向對象方法構造的軟件。

3.2.3信息隱蔽與封裝性

類的重要特徵之一是信息隱蔽與封裝性。它把數據和操縱數據的方法封裝在一起,限制對象屬性對外的可見性和外界對它的操作權限,這在一定程度上避免了不合理的操作並能有效地阻止錯誤的擴散,也減輕了維護工作量,但卻給測試帶來了困難。爲了檢查私有(private)和模塊處理對象類處理保護(Protected)的函數及數據,測試時往往要在類定義中添加一些專門的函數。

另一方面,面向對象軟件系統運行時由一組協調工作的對象組成,對象具有一定的狀態,測試應涉及對象的初態、輸人、輸出、對象的終態,信息隱蔽機制給對象狀態的觀察、測試用例的生成、測試點的選取等帶來了障礙,測試者往往要添加一些表明對象內部狀態的函數。因此,信息隱蔽與封裝性加大了測試的難度。

3.2.4繼承

繼承也是面嚮對象語言中的一個本質特徵。繼承可用於一般與特殊關係,並目方便 編碼。但繼承削弱了封裝性,產生了類似於非面嚮對象語言中全局數據的錯誤風險。由 於繼承的作用,一個函數可能被封裝在具有繼承關係的多個類中,子類中還可以對繼承 的特徵進行覆蓋或重定義。

3.2.5多態性和動態綁定

多態性和動態綁定是面向對象方法的關鍵特性之一。同一消息可以根據接收消息對象的不同採用多種不同的行爲方式,這就是多態的概念。如根據當前指針引用的對象類型來決定使用正確的方法,這就是多態性行爲操作。運行時系統能自動爲給定消息選擇合適的實現代碼、這給程序員提供了高度柔性、問題抽象和易於維護。但多態性和動態綁定所帶來的不確定性,使得傳統測試實踐中的靜態分析法遇到了不可逾越的障礙。而且它們也增加了系統運行中可能的執行路徑,加大了測試用例的選取難度和數量。

3.2面向對象的測試與傳統測試的比較

傳統軟件測試技術是面向過程的測試,是從輸入/處理/輸出的角度檢驗一個函數或過程能否正確工作。而面向對象軟件測試是針對相互協作而又彼此獨立的對象的測試。面向對象軟件開發的測試目標與傳統的軟件開發方法相同,都是爲了確保軟件能正確地和一致地解決待解決的問題,但由於過程性測試方法沒有考慮到面向對象軟件的測試所要涉及的類、繼承和多態性,因此這兩者是有很大不同的。

3.2.1測試單元的不同

傳統軟件的基本構成單元爲功能模塊,每個功能模塊一般能獨立地完成一個特定的功能。而在面向對象的軟件中,基本單元是封裝了數據和方法的類和對象。對象是類的實例,有自己的角色,並在系統中承擔特定的責任。對象有自己的生存週期和狀態,狀態可以演變。對象的功能是在消息的觸發下,實現對象中若干方法的合成以及與其它對象的合作。對象中的數據和方法是一個有機整體,功能測試的概念不適用於對象的測試。

3.2.2系統構成不同

傳統的軟件系統是由一個個功能模塊通過過程調用關係組合而成的。而在面向對象的系統中,系統的功能體現在對象間的協作上,相同的功能可能駐留在不同的對象中,操作序列是由對象間的消息傳遞決定的。傳統

意義上的功能實現不再是靠子功能的調用序列完成的,而是在對象之間合作的基礎上完成的。不同對象有自己不同狀態,而且,同一對象在不同狀態下對消息的響應可能完全不同。因此,面向對象的集成測試已不屬於功能集成測試。

3.3面向對象軟件測試的層次劃分

軟件測試層次是基於測試複雜性分解的思想,是軟件測試的一種基本模式。面向對象程序的結構不再是傳統的功能模塊結構,作爲一個整體,原有集成測試所要求的逐步將開發的模塊組裝在一起進行測試的方法已成爲不可能。而且,面向對象軟件拋棄了傳統的開發模式,對每個開發階段都有不同以往的要求和結果,已經不可能用功能細化的觀點來檢測面向對象分析和設計的結果。因此,傳統的測試模型對面向對象軟件已經不再適用。

目前,對面向對象軟件測試的層次劃分尚未達成共識。一般地,將面向對象軟件的測試分爲3個層次:類測試、類簇測試、系統測試。

3.3.1類測試

面向對象軟件的類測試與傳統的單元測試相對應,但和傳統的單元測試不一樣。類包含一組不同的操作,並且某特殊操作可能作爲一組不同類的一部分存在。同時,一個對象有它自己的狀態和依賴於狀態的行爲,對象操作既與對象的狀態有關,但也可能改變對象的狀態。所以,類操作時不僅要將操作作爲類的一部分,同時要把對象與其狀態結合起來,進行對象狀態行爲的測試。類測試可以分爲以下三個部分:

(1) 基於方法的測試:測試類中的每個方法。

(2) 基於狀態的測試:考察類的實例在其生命週期各個狀態下的情況。

(3) 基於響應的狀態測試:從類和對象的責任出發,以外界向對象改善特定的消息序列來測試對象。

基於服務的類測試主要考察封裝在類中的一個方法對數據進行的操作。Kung等人提出的塊分支圖(Block Branch Diagram,簡稱BBD)是一種比較好的方法測試模型(如圖1所示)。 [1]


方法f的BBD是一個一元組,BBD={Du,Dd,P,Fe,G};Du={di|di∈f引用的全局數據或類數據};Dd={di|di∈f修改的全局數據或類數據};P={X1θ1,X2θ2,⋯,Xnθn,Xn+1θn+1∈f的參數表和函數返回值,θi爲↓ 輸入 、↑ 輸出 ,或↓(輸入、輸出);若Xn+1缺省,則無返回值};F={fi|fi∈被f調用的其他服務};G是一個有向圖,叫做塊體。它是按照控制流圖的思想修改f的程序流程圖而來的,表示f的控制結構中的符合條件判斷被分解,每個判斷框只有單個條件。

3.3.2類簇測試


類簇是一組相互合作的類。類簇測試主要考察一組協同操作的類之間的相互作用,測試重點在類之間的邏輯關係—關聯、繼承、聚合、多態,檢驗類之間的相互配合。其測試用例可由多種方案結合生成。如根據類的繼承關係圖來縱向檢查類,同時又根據對象之間方法的相互作用來模量檢查類的關係。

(1) 關聯和聚合關係的測試:將具有關聯和聚合關係的類組裝在一起,選擇其中主動發送消息的類的測試用例

爲此測試的用例,加載驅動程序運行測試用例,檢驗類間的傳遞與響應。

(2) 繼承關係的測試:D.E.Perry和G.e.Kaiser根據Weyuker的測試充分性公理對該問題進行了討論,認爲子

類中方法和重定義的方法都必須在子類的環境中重新測試,對被繼承的方法是充分的測試數據集,對重定義的方法未必是充分的。對繼承關係的測試主要是對派生類繼承部分的測試,它可重用父類的測試用例,利用迴歸測試進行,對派生類的非繼承部分需重新設計測試用例進行類測試。

(3) 多態/動態綁定的測試:多態/動態綁定顯著增加了系統運行中可能的執行路徑。由於多態/動態綁定所帶

來的不確定性,使得涉及多態實例變量的測試用例大幅度增長。多態/動態綁定實例變量的每一種可能取值應至少在測試用例中出現一次。

3.3.3系統測試

系統測試是對所有類和主程序構成的整個系統進行整體測試,以驗證軟件系統的正確性和性能指標等滿足規格說明書和任務書所指定的要求。它與傳統的系統測試一樣,可套用傳統的系統測試方法,區別僅豐於測試用例的形式有所不同,測試用例可以從對象—行爲模型和作爲對象分析的一部分的事件流圖中導出。

3.4 面向對象軟件的測試方法

3.4.1基於狀態的測試

基於狀態的測試以類的有限狀態機模型 ( F S M ) 和其狀態轉換圖爲依據, 這種模型可以由軟件的代碼或規約生成, 也可採用如UM L 的狀態圖 。採用此方法進行測試時, 主要檢查由初態是否能正確地到達圖中的各個狀態, 以及各個狀態之間的遷移是否能正確實現 。這種方法可以充分測試類中的各個方法和可能的狀態, 符合類測試的特點, 因此是當前類測試中用得較多 、 研究得也較多的方法之一, 但其難點主要在於如何確定被測對象是否達到了正確的狀態 。基於狀態的測試可以很容易地推廣到類簇測試, 只要我們能夠爲類簇建立這樣的狀態模型 。

3.4.2基於方法序列的測試

面向對象程序中方法的調用是有一定次序的, 如果違反了這個次序就會產生錯誤 。方法序列規範

Mtss(Method Sequence Specification)就是這樣一種規範, 它規定了類或類簇中方法的執行順序, 如哪些方法必須按先後次序執行, 哪些方法可以併發執行等等 。 依據這樣的規約, 我們可以爲類或類簇產生一些消息序列, 檢驗這些類或類簇中的方法是否能夠正確地交互 。 文[2] 中較爲詳細地介紹了Mtss產生測試用例的原理, 並根據一定的準則對所產生的消息序列進行了劃分, 另外還採用顛倒次序 、 遺漏和冗餘等方法由正確的消息序列生成錯誤的消息序列, 以測試程序的健壯性 。 由於該方法沒有能夠考慮類的狀態, 因此採用它進行的測試是不完全的 。 這種方法常常與別的測試方法結合使用 。

3.4.3基UML的測試

UML爲面向對象軟件提供了強大的建模工具, 同時它也可以作爲測試的依據.下面介紹的是幾種已被應用於面向對象軟件測試的UML模型:

(1) 類圖: 類圖描述了組成面向對象程序的各個類之間的關係, 包括聯繫、聚集、重數、子類型和遞歸包含等.依據類圖可以確定各個類之間的層次關係,從而決定對類進行測試的順序。 另外, 採用類圖可以生成檢驗類之間關係是否正確實現的測試用例。 [3][5]

及個性化。 具有提供動態輸入到測試的功能(包括 JavaScript)。 支持腳本變成的取樣器(在1.9.2 及以上版本支持 BeanShell)。  4.5 TestDirector

基於WEB的測試管理工具,他能夠讓你係統地控制整個測試過程,並創建整個測試工作流的框架和基礎,使整個測試管理過程變得更爲簡單和有組織。他能夠幫助你維護一個測試工程數據庫,並且能夠覆蓋你的應用程序功能性的各個方面。T並且還爲你提供了直觀和有效的方式來計劃和執行測試集、收集測試結果並分析數據。還專門提供了一個完善的缺陷跟蹤系統。並可以同Mercury公司的測試工具、第三方或者自主開發的測試工具、需求和配置管理工具、建模工具的整合功能。你可以通過他進行需求定義、測試計劃、測試執行和缺陷跟蹤,即整個測試過程的各個階段。  4.6 Bugzilla

Buzilla 是一個 BUG 管理工具。作爲一個產品缺陷的記錄及跟蹤工具,它能夠爲你建立一個完善的 Bug 跟蹤體系,包括報告 Bug、查詢 Bug 記錄併產生報表、處理解決、管理員系統初始化和設置四部分。並具有如下特點:

1、基於Web 方式,安裝簡單、運行方便快捷、管理安全。

2、有利於缺陷的清楚傳達。本系統使用數據庫進行管理,提供全面詳盡的報告輸入項,產生標準化的 Bug 報告。 提供大量的分析選項和強大的查詢匹配能力,能根據各種條件組合進行 Bug 統計。當錯誤在它的生命週期中變化時,開發人員、測人員、及管理人員將及時獲得動態的變化信息,允許你獲取歷史紀錄,並在檢查錯誤的狀態時參考這一記錄。

3、系統靈活,強大的可配置能力。Buzilla工具可以對軟件產品設定不同的模塊,並針對不同的模塊設定製定的開發人員和測試人員;這樣可以實現提交報告時自動發給指定的責任人;並可設定不同的小組,權限也可劃分。設定不同的用戶對 Bug 記錄的操作權限不同,可有效控制進行管理。允許設定不同的嚴重程度和優先級可以在錯誤的生命其中管理錯誤,從最初的報告到最後的解決,確保了錯誤不會被忽略,同時可以使注意力集中在優先級和嚴重程度高的錯誤上。

4、自動發送 Email,通知相關人員。根據設定的不同責任人,自動發送最新的動態信息,有效的幫助測試人員和開發人員進行溝通。  4.7各種測試工具的比較


5、總結

在軟件工程領域中,面向對象軟件測試是一個重要的研究方向,面向對象方法與傳統順序結構式方法在開發思想上有着根本的不同,尤其是面向對象所具有的類、封裝、繼承、動態連接等特性,使得面向對象測試在測試層次及測試方案的選擇上有別於傳統的測試思想,也增加了測試用例的設計難度。面向對象開發方法問世的時間較短,所以在測試理論上還存在諸多分歧,在測試技術上也有侷限,並且面向對象軟件測試尚有許多難題需要解決。今後,應該在而向對象軟件的開發過程中不斷探索,更深入地研究上述各方面,克服軟件測試的盲目性和侷限性,保證測試的質量,提高軟件的可靠性。 參考文獻

[1]Binder R V.Testing Object-Oriented Software:A Survey[J].Journal of Software   Testing,Verification and Reliability,1996(6):225-252.

[2]郭健強,蔡希堯.基於方法序列規範的測試用例生成[J].計算機科學,2000(1):44~47.

[3](美)Binder Robert V.面向對象系統的測試[M].華慶一,王斌君,陳莉譯.北京:人民郵電出版社,2001.

[4]Peter Froehlich,JohannesLink.Automated test case generation from dynamicmodels[A].14 European Conference on Object-Oriented Programming,Sophia Antipolis and Cannes,France,2000.

[5]張毅坤,左詠露.面向對象軟件測試的特點及方法[j].西安理工大學學報,2002:361~365.

th

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章