物件導向的軟體測試

物件導向的軟體測試
摘 要: 物件導向程式的結構不再是傳統的功能模組結構，作為一個整體，原有整合測試所要求的逐步將開發的模組搭建在一起進行測試的方法已成為不可能,傳統的測試模型對物件導向軟體已經不再適用。
本文總結出著實有效物件導向的軟體測試技術。首先，闡明物件導向軟體測試的基本概念；然後，分別討論分析和設計模型測試技術、類測試技術、對象互動測試技術、類階層測試技術、物件導向系統測試技術；最後，對物件導向軟體測試的實施進行小結。
關鍵詞：物件導向；軟體測試；類測試；對象互動；測試案例
1. 分析和設計模型測試技術　
物件導向軟體開發的起始步驟是開發分析和設計模型。UML（整合模組化語言）能在物件導向技術開發中廣泛應用，也是因為構建模型能協助開發人員理解正在解決的問題；構建模型能協助管理正在開發的系統的複雜性；分析和設計階段建構的模型最後將對具體地實現起指導作用。如果模型的品質很高對項目來說就很有價值；但是如果模型有錯誤，那麼它對項目的危害就無可估量。
1.1.分析和設計模型測試的內容
分析和設計模型測試的重點是測試模型的完整性和一致性,其主要內容有：
1. 對確定的對象的測試；
2. 對確定的結構的測試；
3. 對確定的主題的測試；
4. 對定義的屬性和執行個體關聯的測試；
5. 對定義的服務和訊息關聯的測試。
1.2.分析和設計模型測試的方法
分析與設計模型的測試主要是對分析與設計模型進行測試，找出模型中的錯誤，其採用的方法是指導性審查(guided inspection)。指導性審查技術通過使用明確的測試案例為尋找工作成果中的缺陷提供了客觀的、系統的方法。是一種增強了的專為檢驗模型的檢測技巧，也可用來驗證模型是否能符合項目的需求。其基本步驟如下：
1. 定義測試位置。
2. 使用特定的策略從測試位置選擇測試值。
3. 將測試值應用到被測試的產品中。
4. 對測試結果以及對模型的測試覆蓋率（基於某中標準）進行評估。
　
採用指導性審查技術對分析和設計產生的文本進行正確性驗證,是軟體開發前期的關鍵性測試。
2. 類測試技術
類測試是由那些與驗證類的實現是否和該類的說明完全一致的相關聯的活動組成的。該類測試的對象主要是指能獨立完成一定功能的原始類。如果類的實現正確，那麼類的每一個執行個體的行為也應該是正確的。
2.1. 類測試的內容
類測試的目的主要是確保一個類的代碼能夠完全滿足類的說明所描述的要求．對一個類進行測試以確保他只做規定的事情，對此給與關注的多少，取決於提供額外的行為的類相關聯的風險．在運行了各種類的測試後，如果代碼的覆蓋率不完整，這可能意味著該類包含了額外的文檔支援的行為．需要增加更多的測試案例來進行測試。
2.2. 類測試的時間
類測試的開始時間一般在完全說明這個類，並且準備對其編碼後不久，就開發一個測試計劃——至少是確定測試案例的某種形式。如果開發人員還負責該類的測試，那麼尤其應該如此。因為確定早期測試案例有利於開發人員理解類說明，也有助於獲得獨立代碼檢查的反饋。

2.3. 類測試的測試人員
類測試通常由他的開發人員測試，讓開發人員起到測試人員的作用，就可使得必須理解類說明的人員數量減至最少。
2.4. 類測試的方法
類測試的方法有代碼檢查和執行測試案例。在某些情況下，用代碼檢查代替基於執行的測試方法是可行的，但是，和基於執行的測試相比，代碼檢查有以下兩個不利之處：
1． 代碼檢查易受人為因素影響。
2． 代碼檢查在迴歸測試方面明顯需要更多的工作量，常常和原始測試差不多。
一旦確定了一個類的可執行測試案例，就必須執行測試驅動程式來運行每一個測試案例，並給出每一個測試案例的結果。
2.5. 構建類測試案例
構建類的測試案例的方法有：根據類說明（用OCL表示）確定測試案例和根據類的狀態轉換圖來構建類的測試案例。
根據類的說明確定測試案例 用OCL表示的類的說明中描述了類的每一個限定條件條件。在OCL條件下分析每個邏輯關係，從而得到由這個條件的結構所對應的測試案例。這種確定類的測試案例的方法叫做根據前置條件和後置條件構建測試案例。其總體思想是：為所有可能出現的組合情況確定測試案例需求。在這些可能出現的組合情況下，可滿足前置條件，也能夠到達後置條件。根據這些需求，建立測試案例；建立擁有特定輸入值（常見值和特殊值）的測試案例；確定它們的正確輸出——預期輸出值。
根據前置條件和後置條件建立測試案例的基本步驟如下：
1． 確定在表1中與前置條件形成相匹配的各個項目所指定的一系列前置條件的影響。
2． 確定在表2中與後置條件形成相匹配的各個項目所指定的一系列前置條件的影響。
3． 根據影響到列表中各個項目的所有可能的組合情況從而構造測試案例需求。一種簡單的方法就是：用第一個列表中的每一個輸入約束來代替第二個列表中每一個前置條件。
4． 排除表中產生的所有無意義的條件。

表1 前置條件對測試系列的影響
前置條件 影 響
True (true 、post)
A (A、post)
(not A、exception) *
Not A (not A、post)
(A、exception) *
A and B (A and B、post)
(not A and B、exception) *
(A and not B、exception) *
(not A and not B、exception) *
A or B (A、post)
(B、post)
(A and B、post)
(not A and not B、post)
A xor B (not A and B、post)
(A and not B、post)
(A and B、exception) *
(not A and not B、exception) *
A implies B (not A、post)
(B、post)
(not A and B、post)
(A and not B、exception) *
if A then B
else C endif (A and B、post)
(not A and C、post)
(A and not B、exception) *
(not A and not C、exception) *
註：①．A、B、C代表用OCL表示的組件。
②．假如類說明中的保護性設計方法是隱式的，那麼也必須對那些標記有*的測試案例進行闡述。如果保護性設計方法在類的說明中是顯式出現的，那麼測試案例也就確定了。

表2 後置條件對測試系列的影響
後置條件 影 響
A (pre ；A)
A and B (pre ；A and B)
A or B (pre ；A)
(pre ；B)
(pre ；A or B)
A xor B (pre ；not A or B)
(pre ；A or not B)
A implies B (pre ；not A or B)
if A then B
else C endif (pre and * ；B)
(pre and not * ；C)
註：①．A、B、C代表用OCL表示的組件。
②．對於“if A then B else C endif” 這個後置條件，假如測試案例不會對錶達式A產生影響那麼在用這個後置條件時，* = A else * 就是使得A為真的一個條件

根據狀態轉換圖構建測試案例 狀態轉換圖以圖例的形式說明了與一個類的執行個體相關聯的行為。狀態轉換圖可用來補充編寫的類說明或者構成完整的類說明。狀態圖中的每一個轉換都描述了一個或多個測試案例需求。因而，可以用過在轉換的每一端選擇有代表性的值和邊界來滿足這些需求。如果轉換是受保護的，那麼也應該為這些保護條件選擇邊界。狀態的邊界值取決於狀態相關屬性值的範圍，可以根據屬性值來定義每一個狀態。

3.2 抽象類別測試
對類基於執行的測試時，需要建構一個類的執行個體。然而，一個繼承體系的根類通常是抽象的，許多程式設計語言在語義上不允許建構抽象類別的執行個體。這位抽象類別的測試帶來了很大的困難。在此，提出三種測試抽象類別的方法：
1． 需要測試的抽象類別單獨定義一個具體的子類。通過對具體子類建立的執行個體測試，來完成對抽象類別的測試。這種方法的缺點是，如果不是用多層繼承，抽象類別的方法的實現就不能輕易的傳遞給抽象子類。但是大部分物件導向的程式設計語言都不支援多重繼承，而且不提倡將多重繼承用在這些方面。
2． 將抽象類別作為測試第一個具體子孫的一部分進行測試。這種方法不需要開發額外的用於測試的目的類，但需要考慮到為每一個祖先提供恰當的、正確的測試案例和測試指令碼方法，而增加了測試具體類的複雜性。
3． 以對用於測試目的的抽象類別的具體版本作直接實現，嘗試找到一種為類編寫原始碼的方法，從而使得該類可以做為一個抽象或具體類而很容易編譯。然而，不管是基於編輯遺產方案還是基於條件編譯的方案都沒有產生好的結果。應為合成代碼都很複雜，而且難以閱讀，很容易出錯。
4．對象互動測試技術
物件導向的軟體是由若干對象組成的，通過這些對象的相續協作來解決某些問題。對象的互動和寫作方式決定了程式能作什麼，從而決定了這個程式執行的正確性。也許可信任的原始類的執行個體可能不包含任何錯誤，但是如果那個執行個體的服務部被其他程式組件正確的使用的話，那麼這個程式也就包含了錯誤。因此，程式中對象的正確協作——即互動——對於程式的正確性是非常關鍵的。
根據類的類型可以將對向互動測試分為彙集類測試和協作類測試。
4.1．彙集類測試
彙集類指的是這樣的一種類，這些類在他們的說明中使用對象，但是實際上從不和這些對象中的任何一個進行協作——即他們從不請求這些對象的服務。相反，他們會表現出以下的一個或多個行為：
1. 存放這些對象的引用（或指標），通常表現程式中的對象之間一對多的關係。
2. 建立這些對象的執行個體。
3. 刪除這些對象的執行個體。
可以使用測試原始類的方法來測試彙集類，測試驅動程式要建立一些執行個體，作為訊息中的參數被傳送給一個正在測試的集合。測試案例的中心目的主要是保證那些執行個體被正確加入集合和被正確的從集合中移出，以及測試案例說明的集合對其容量有所限制。因此，每個對象的準確的類（這些對象是用在彙集類的測試中）在確定彙集類的正確操作是不重要的，因為在一個集合執行個體和集合中的對象之間沒有互動。假如在實際應用中可能要加入40到50條資訊，那麼產生的測試案例至少要增加50條資訊。如果無法估計出一個有代表性的上限，就必須使用集合中大量的對象進行測試。
4.2．協作類的測試
凡不是彙集類的非原始類（原始累即一些簡單的，獨立的類，這些類可以用類測試方法進行測試）就是協作類。這種類在它們的一個或多個操作中使用其它的對象並將其作為他們的實現中不可缺少的一部分。當介面中的一個操作的某個後置條件引用了一個協作類的對象的執行個體狀態，則說明那個對象的屬性別使用或修改了。由此可見，寫作類的測試的複雜性遠遠高於彙集類或者原始類測試的複雜性。鑒於協助類的測試需要根據具體的情況來定，而具體情況複雜多變，在此，就方便不論述了。
5．物件導向系統測試技術
通過單元測試和整合測試，僅能保證軟體開發的功能得以實現。但不能確認在實際運行時，它是否滿足使用者的需要。為此，對完成開發的軟體必須經過規範的系統測試。系統測試應該盡量搭建與使用者實際使用環境相同的測試平台，應該保證被測系統的完整性，對臨時沒有的系統裝置組件，也應有相應的類比手段。系統測試時，應該參考OOA分析的結果，對應描述的對象、屬性和各種服務，檢測軟體是否能夠完全"再現"問題空間。系統測試不僅是檢測軟體的整體行為表現，從另一個側面看，也是對軟體開發設計的再確認。
物件導向測試的整體目標——以最小的工作量發現最多的錯誤——和傳統軟體測試的目標是一致的，但是OO測試的策略和戰術有很大不同。測試的視角擴大到包括複審分析和設計模型，此外，測試的焦點從過程構件(模組)移向了類。
物件導向軟體測試仍處於發展階段。本論文根據物件導向開發方法過程和特點討論了物件導向的軟體測試，提出了一系列實用的面向軟體測試技術。如，分析和設計模型測試技術、類測試技術、對象互動測試技術、類階層測試技術、物件導向系統測試技術等。，儘管上面說得很輕鬆，軟體測試是一項非常麻煩的工作。
不論是傳統的測試方法還是物件導向的測試方法，我們都應該遵循下列的原則：
1.應當把“儘早和不斷地測試”作為開發人員的座右銘。
2.程式員應該避免檢查自己的程式，測試工作應該由獨立的專業的軟體測試機構來完成。
3.設計測試案例時，應該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要製造極端狀態和意外狀態，比如網路異常中斷、電源斷電等情況。
4.一定要注意測試中的錯誤集中發生現象，這和程式員的編程水平和習慣有很大的關係。
5.對測試錯誤結果一定要有一個確認的過程。一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。
6.制定嚴格的測試計劃，並把測試時間安排得盡量寬鬆，不要希望在極短的時間內完成一個高水平的測試。
7.迴歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現的現象並不少見。
8.妥善儲存一切測試過程文檔，意義是不言而喻的，測試的重現性往往要靠測試文檔。
參 考 文 獻
[1] McGregor．J．D.等著；楊文宏等譯．《物件導向的軟體測試》[M]．機械工業出版社，2002.8.
[2]　張海藩．軟體工程導論[Ｍ]．北京：清華大學出版社，1998．
[3]　張毅坤．物件導向軟體測試的特點及方法[Ｊ]．西安理工大學學報，2002，18(4)：361 365．