物件導向軟體的測試案例的設計方法

12.4 設計測試案例

 

目前，物件導向軟體的測試案例的設計方法，還處於研究、發展階段。與傳統軟體測試（測試案例的設計由軟體的輸入處理輸出視圖或單個模組的演算法細節驅動）不同，物件導向測試關注於設計適當的操作序列以檢查類的狀態。

12.4.1 測試類別的方法

前面已經講過，軟體測試從“小型測試”開始，逐步過渡到“大型測試”。對物件導向的軟體來說，小型測試著重測試單個類和類中封裝的方法。測試單個類的方法主要有隨機測試、劃分測試和基於故障的測試等3種。

1. 隨機測試

下面通過銀行應用系統的例子，簡要地說明這種測試方法。該系統的account(賬戶）類有下列操作： open(開啟），setup(建立），deposit(存款），withdraw(取款），balance(餘額），summarize(清單），creditLimit(透支限額）和close(關閉）。上列每個操作都可以應用於account類的執行個體，但是，該系統的性質也對操作的應用施加了一些限制，例如，必須在應用其他動作之前先開啟賬戶，在完成了全部操作之後才能關閉賬戶。即使有這些限制，可做的操作也有許多種排列方法。一個account類執行個體的最小行為曆史包括下列操作：

open·setup·deposit·withdraw·close

這就是對account類的最小測試序列。但是，在下面的序列中可能發生許多其他行為：

open·setup·deposit·［deposit|withdraw|balance|summarize|creditLimit］n·withdraw·close

從上列序列可以隨機地產生一系列不同的操作序列，例如：

測試案例#r1:open·setup·deposit·deposit·balance·summarize·withdraw·close

測試案例#r2:open·setup·deposit·withdraw·deposit·balance·creditLimit·

withdraw·close

執行上述這些及另外一些隨機產生的測試案例，可以測試類別執行個體的不同生存曆史。

2. 劃分測試

與測試傳統軟體時採用等價劃分方法類似，採用劃分測試（partition testing）方法可以減少測試類別時所需要的測試案例的數量。首先，把輸入和輸出分類，然後設計測試案例以測試劃分出的每個類別。下面介紹劃分類別的方法。

（1） 基於狀態的劃分

這種方法根據類操作改變類狀態的能力來劃分類操作。再一次考慮account類，狀態操作包括deposit和withdraw，而非狀態操作有balance, summarize和creditLimit。設計測試案例，以分別測試改變狀態的操作和不改變狀態的操作。例如，用這種方法可以設計出如下的測試案例：

測試案例#p1:open·setup·deposit·deposit·withdraw·withdraw·close

測試案例#p2:open·setup·deposit·summarize·creditLimit·withdraw·close

測試案例#P1改變狀態，而測試案例#P2測試不改變狀態的操作（在最小測試序列中的操作除外）。

（2） 基於屬性的劃分

這種方法根據類操作使用的屬性來劃分類操作。對於account類來說，可以使用屬性balance來定義劃分，從而把操作劃分成3個類別：

. 使用balance的操作；

. 修改balance的操作；

. 不使用也不修改balance的操作。
然後，為每個類別設計測試序列。

（3） 基於功能的劃分

這種方法根據類操作所完成的功能來劃分類操作。例如，可以把account類中的操作分類為初始化操作（open,setup），計算操作（deposit, withdraw），查詢操作（balance, summarize,creditLimit）和終止操作（close）。然後為每個類別設計測試序列。

3. 基於故障的測試

基於故障的測試（fault based testing）與傳統的錯誤推測法類似，也是首先推測軟體中可能有的錯誤，然後設計出最可能發現這些錯誤的測試案例。例如，軟體工程師經常在問題的邊界處犯錯誤，因此，在測試SQRT（計算平方根）操作（該操作在輸入為負數時返回出錯資訊）時，應該著重檢查邊界情況： 一個接近零的負數和零本身。其中“零本身”用於檢查程式員是否犯了如下錯誤：

把語句if(x>=0)calculate_square_root( );

誤寫成if(x>0)calculate_square_root( );

為了推測出軟體中可能有的錯誤，應該仔細研究分析模型和設計模型，而且在很大程度上要依靠測試人員的經驗和直覺。如果推測得比較準確，則使用基於故障的測試方法能夠用相當低的工作量發現大量錯誤；反之，如果推測不準，則這種方法的效果並不比隨機測試技術的效果好。

12.4.2 整合測試方法

開始整合物件導向系統以後，測試案例的設計變得更加複雜。在這個測試階段，必須對類間協作進行測試。為了舉例說明設計類間測試案例的方法，我們擴充12.4.1小節引入的銀行系統的例子，使它包含圖12.3所示的類和協作。圖中箭頭方向代表訊息的傳遞方向，箭頭線上的標註給出了作為由訊息所蘊含的協作的結果而調用的操作。

和測試單個類相似，測試類別協作可以使用隨機測試方法和劃分測試方法，以及基於情景的測試和行為測試來完成。

1. 多類測試

Kirani和Tsai建議使用下列步驟，以產生多個類的隨機測試案例。

. 對每個客戶類，使用類操作符列表來產生一系列隨機測試序列。這些操作符向伺服器類執行個體發送訊息

. 對所產生的每個訊息，確定協作類和在伺服器對象中的對應操作符。

. 對伺服器對象中的每個操作符（已經被來自客戶對象的訊息調用），確定傳遞的訊息。

. 對每個訊息，確定下一層被調用的操作符，並把這些操作符結合進測試序列中。

. 為了說明怎樣用上述步驟產生多個類的隨機測試案例，考慮Bank類相對於ATM類（見圖12.3）的操作序列：

verifyAcct·verifyPIN·［（verifyPolicy·withdrawReq）|depositReq|acctInfoREQ］n

對Bank類的隨機測試案例可能是：

測試案例#r3:verifyAcct·verifyPIN·depositReq

為了考慮在上述這個測試中涉及的共同作業者，需要考慮與測試案例#r3中的每個操作相關聯的訊息。Bank必須和ValidationInfo協作以執行verifyAcct和verifyPIN,Bank還必須和Account協作以執行depositReq。因此，測試上面提到的協作的新測試案例是：

測試案例#r4:verifyAcctBank·［validAcctValidationInfo］·verifyPINBank·［validPINvalidationInfo］·depositReq·［depositaccount］

多個類的劃分測試方法類似於單個類的劃分測試方法（見12.4.1節）。但是，對於多類測試來說，應該擴充測試序列以包括那些通過發送給協作類的訊息而被調用的操作。另一種劃分測試方法，根據與特定類的介面來劃分類操作。12.3所示，Bank類接收來自ATM類和Cashier類的訊息，因此，可以通過把Bank類中的方法劃分成服務於ATM的和服務於Cashier的兩類來測試它們。還可以用基於狀態的劃分（見12.4.1節），進一步精化劃分。

圖12.3 銀行系統的類-共同作業圖表

2. 從動態模型匯出測試案例

在第9章中已經講過，怎樣用狀態轉換圖作為表示類的動態行為的模型。類的狀態圖可以協助我們匯出測試該類（及與其協作的那些類）的動態行為的測試案例。圖12.4給出了前面討論過的account類的狀態圖，從圖可見，初始轉換經過了empty acct和setup acct這兩個狀態，而類執行個體的大多數行為發生在working acct狀態中，最終的withdraw和close使得account類分別向nonworking acct狀態和dead acct狀態轉換。

圖12.4 account類的狀態轉換圖

設計出的測試案例應該覆蓋所有狀態，也就是說，操作序列應該使得account類執行個體遍曆所有允許的狀態轉換：

測試案例#s1:open·setupAccnt·deposit(initial)·withdraw(final)·close

應該注意，上面列出的序列與12.4.1節討論的最小測試序列相同。向最小序列中加入附加的測試序列，可以得出其他測試案例：

測試案例#s2:open·setupAccnt·deposit(initial)·deposit·balance·credit·withdraw(final)·close

測試案例#s3:open·setupAccnt·deposit(initial)·deposit·withdraw·accntInfo·withdraw(final)·close

還可以匯出更多測試案例，以保證該類的所有行為都被適當地測試了。在類的行為導致與一個或多個類協作的情況下，應該使用多個狀態圖去跟蹤系統的行為流。