面向對象軟件的測試用例的設計方法(2)

　　把語句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節)，進一步精化劃分。

　　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

原文轉自：http://www.uml.org.cn/Test/201501295.asp