狀態轉換測試 (State Transformation Testing)

任何事物的進行都經歷得各種各樣的狀態轉換,軟體的運行也是。
當各個狀態滿足某些條件時,就會轉換到某些狀態。(例如:販賣機投足了錢[滿足某些條件],就會有飲料的按鈕亮起可以按[轉換到某些狀態])

我們可以透過整理軟體運行的狀態圖,得知各個狀態轉換的關係,並在狀態圖的基礎上按照狀態和狀態轉換的覆蓋原則進行測試設計,可以有效的保證軟體狀態轉換的正確性。
針對各種狀態的發生和轉換的整理,我們可以透過模擬各種用戶操作場景來取得。

軟體中事務狀態間的轉換一般可分為兩類:

(1) 各個狀態之間轉換有一定的序列關係

如工作流,必須先發生 S1 狀態,才能到 S2 狀態,狀態 S1 和 S2 之間有先後順序。

狀態轉換測試_d1

(2) 各個狀態是並列關係,各個狀態間可以相互轉換

如狀態 S3 和 S4,可以由 S3 轉換成 S4​​,也可以由 S4​ 轉換成 S3。

*這兩種類型的狀態轉換,都需要注意用戶角色權限。

狀態轉換測試_d2

基本上,對狀態轉換的測試,我們設計的用例需要涵蓋以下三種:

(1) 允許的狀態轉換
(2) 不允許的狀態轉換
(3) 用戶角色權限的驗證:不僅要驗證有權限的角色能夠正常操作,也需要驗證沒有權限的角色是否能操作。

根據不同的覆蓋情況,將得到不同的測試案例
1. 覆蓋所有狀態:完全狀態巡訪(all states)
2. 覆蓋所有狀態轉換(事件):完全轉換(包含 all states)

舉例:

狀態轉換測試_d3

註:S1 是起始狀態

我們拿上面的狀態轉換圖來當做例子

覆蓋所有狀態:完全狀態巡訪(all states),也就是每一個狀態(S1, S2, S3)都有被巡訪到,S1 → S2 → S3 這樣就是一種完全狀態巡訪的測試案例。

覆蓋所有狀態轉換(事件):完全轉換(包含 all states),也就是每一條連結各個狀態的轉換線(此例子有六條線)都有被巡訪到,S1 → S2 → S2 → S3 → S3 → S2 → S3 → S1 這樣就算是一種完全轉換的測試案例,因為每一條連結的轉換線都會巡訪過,所以每一個狀態也都會巡訪到,所以才說有包含 all states。

由此我們便可以設計出盡量路徑不重複且覆蓋率夠高的測試案例,可以確保每一條轉換狀態的路徑正常。

參考文章:
1. 軟件測試中的基於狀態轉換測試
2. 讀《軟件測試設計》–狀態轉換測試(新)
3. 狀態轉換測試法(State Transition Testing)
4. 基於狀態轉換的測試

廣告

發表迴響

Please log in using one of these methods to post your comment:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s