準則: 狀態圖和流程圖的測試觀念
測試觀念的基礎是表面上看起來可信的軟體錯誤,以及如何以最佳方式來彰顯這些錯誤。這個準則顯示如何從狀態圖及其他圖形式設計結構中識別測試觀念。
關係
相關元素
主要說明

簡介

這個準則顯示如何從狀態圖和其他設計結構中識別測試觀念,這些其他設計結構主要是由弧連接的節點所組成,且會顯示可能的程式控制流程的相關事項。這項測試的主要目標是在某些測試中遍歷每一個弧。如果您不曾用過弧,您憑什麼認為客戶使用時,它能夠運作?

測試實作

請考量這個狀態圖:

標題所說明的圖。

Fig1: HVAC 狀態圖

以下是一份初步的測試觀念清單:

  • 「閒置」狀態收到「太熱」事件
  • 「閒置」狀態收到「太冷」事件
  • 「冷卻/啟動」狀態收到「壓縮機運轉中」事件
  • 「冷卻/備妥」狀態收到「風扇運轉中」事件
  • 「冷卻/運轉中」狀態收到「確定」事件
  • 「冷卻/運轉中」狀態收到「故障」事件
  • 「故障」狀態收到「清除故障」事件
  • 「加熱」狀態收到「確定」事件
  • 「加熱」狀態收到「故障」事件

這些測試觀念可以全部在單一測試中進行,您也可以建立許多項測試,每項測試各執行一小部分。如同所有測試設計一樣,請在輕易實作許多簡單的測試和進行複雜測試來獲得其他找出問題的能力之間,努力取得平衡。(請參閱概念:測試觀念清單頁面中的「利用清單測試設計」。) 如果您有使用案例情境是利用狀態圖來說明特定路徑,您應該會偏好採用這些路徑的測試。

不論任何情況,這些測試都應該檢查是否實際執行了狀態圖所需要的所有動作。例如,在進入「故障」狀態時,警報是否啟動,在結束時,警報是否停止?

測試也應該確認轉換會導向下一個正確的狀態。當從外部見不到狀態時,這可能是很困難的問題。偵測不正確的狀態,唯一方法是注入某個事件序列,使它導出不正確的輸出。更精確地說,您必須建構一個後續事件序列,它的正確狀態在外部的可見結果,必須不同於每個可能的 不正確狀態所引起的外部可見結果。

在上述範例中,您怎麼知道「故障」狀態中「消除故障」事件正確導出「閒置」狀態,而不是停在「故障」狀態? 您也許相信「警報」停止代表已經轉換,但比較好的檢查方式,是將溫度降到夠低,以啟動加熱器,或將溫度升到夠高,以啟動冷卻。如果情況發生了,您便比較能夠確信轉換是正確的。如果沒有動靜,裝置就可能仍在「故障」狀態中。

判斷結果狀態是否正確,至少會使測試設計複雜化。一般而言,最好是使狀態機明確,使測試能夠見到它的各個狀態。

其他狀態圖建構

狀態圖不只是由弦和箭頭組成。以下是狀態圖的各項建構清單,及它們對測試觀念清單的影響。

事件動作、進入動作、跳出動作

這些東西本身並不會產生測試觀念。相反地,測試還應該檢查這些動作是否依照指定來運作。如果動作代表真實的程式,就必須測試這些程式。這些程式的測試觀念可以和狀態圖的測試觀念結合起來,但分開會比較好管理。請根據所花的工夫及您關於各個事件可能互動的推斷來做決策。也就是說,如果一個弧的特定動作不可能與另一個弧的動作共用資料,就表示沒有理由在相同測試中執行這兩個動作 (如同它們在狀態圖測試中是相同路徑的一部分時,您所採取的方式)。

警戒條件

警戒條件是布林表示式。警戒條件的測試觀念是依照工作成果準則:布林和界限的測試觀念所說明而衍生的。

在上述範例中,從「閒置」狀態轉換到「太冷」狀態是利用 [restart time >= 5 mins] 來警戒的。這會導出兩個不同的測試觀念:

  • 當重新啟動時間是五分鐘時,「閒置」狀態收到「太冷」事件(進行轉換)
  • 當重新啟動時間正好小於五分鐘時,「閒置」狀態收到「太冷」事件(阻斷轉換)

在這兩種情況中,任何使用測試資料的測試都應該確認已達到正確的狀態。

內部轉換

內部轉換會依照外部轉換的相同方式,將同一種觀念加到測試觀念清單中。這只表示下一個狀態與原始狀態相同。將測試設定成進入和跳出狀態的動作,在不正確觸發的情況下,會造成可觀察的效果,是一種很審慎的作法。

巢狀狀態

當建構測試時,請將它們建構成組合狀態的進入和跳出事件具有可觀察的效果。如果它們被跳過,您會發現。

並行子狀態

並行測試在開發人員測試範圍之外。

延遲事件

如果您推斷事件可能是取決於它是延遲及排入佇列中,而不是當程式實際在接收狀態時所產生,而用不同的方式來處理,您可以測試這兩個情況。

如果接收狀態的事件有警戒條件,請考慮在產生事件和接收事件之間,將變更分派給條件的變數。

如果多個狀態可以處理延遲事件,請考慮每個可能接收狀態的測試延遲。也許實作假設「明顯」狀態會處理這個事件。

歷程狀態

以下是歷程狀態的範例:

標題所說明的圖。

Fig2: 歷程狀態範例

轉換到歷程狀態代表三項真實的轉換,因而會有三個測試觀念:

  • 「指令」狀態中的「備份」事件會導致「收集中」狀態
  • 「指令」狀態中的「備份」事件會導致「複製中」狀態
  • 「指令」狀態中的「備份」事件會導致「清除」狀態
鏈狀態

鏈狀態除非引進了其他必須檢查的動作,否則,它們似乎不會有任何測試設計上的連帶作用。

測試設計

先前的討論焦點在檢查實作是否符合設計。但設計也可能出錯。當檢查設計來尋找測試觀念時,也要檢查兩類問題:

遺漏事件。 狀態圖顯示狀態對於設計者預期可能進入這個狀態之事件的回應。設計者會忽略事件是已知之事。例如,在這個狀態圖(從頁面頂端開始重複)中,設計者可能忘了,不只是風扇在執行時可能出現故障,冷卻的備妥子狀態也可能出現故障。

標題所說明的圖。

Fig3: HVAC 狀態圖

因此,最好要針對每個狀態來詢問,是否有任何適合其他狀態的事件也適合這個狀態。如果您發現這個情況,請更正您的設計。

警戒條件不完整或遺漏。 同樣地,一項轉換的警戒條件可能會建議其他轉換的警戒條件。例如,上述狀態圖處理不要太經常重新啟動加熱器,但對於冷卻系統則沒有這樣的限制。應該有嗎?

有可能一個警戒條件所用的變數會建議其他警戒條件太簡單。

測試互動

只是測試圖中的每個弧,絕不是完整測試。例如,假設啟動狀態將變數起始設定成 0,狀態 Setter 將它設成 5,狀態 Divider 將它分成 100(100/變數)。如果有從起始狀態到 Divider 的路徑不會通過 Setter,您便會有除以零的異常狀況。如果狀態圖有許多狀態,只執行每個弦,仍可能遺漏這個路徑。

除了非常簡單的狀態圖,測試每一條路徑並不可行。實際上,只要複雜又對應於使用案例情境的測試,通常就夠了。如果您想要更強的測試,請考慮要求從每個已有資料值的狀態到每個使用這個資料的狀態的路徑。