【ソフトウェアテスト】状態遷移テスト
何かの操作を行うと何かのアクションを実行して実行後の状態になり、実行後の状態からさらに次の操作を行うとまたアクションを返すといったように、ソフトウェアに限らず何かしらの機能を持つものは、機能を使う前と機能を使った後でそれぞれ状態が変わります。
状態が仕様想定どおりに遷移しているかどうかを確認する技法として、状態遷移テストがあります。
1. システム要件の一例
クリックされた回数を表示するボタンシステムの仕様を定義します。
◆クリックカウントボタンの仕様
・画面内にクリック回数表示部分[カウンター]を実装する・クリック回数表示部分は初期状態で0を表示する
・画面内に[カウント][リセット]ボタンを実装する
・[カウント]ボタンを1回クリックするとクリック回数表示部分の数値に＋1する
・[リセット]ボタンをクリックすると回数表示部分の数値を0にする
・カウントする数値の上限値は99として、100カウント目で[カウント]ボタンをクリックすると数値を0にする。
2. 想定されるパスと状態
上記の仕様を元に、初期状態から遷移可能なパスと状態を洗い出します。
・状態
「初期状態」 → カウンター表示は0
「カウント中(数値加算可能)」 → カウンター表示は1～98
「カウント上限」 → カウンター表示は99
・各状態から実行されるアクションとパス
① カウンターに0が表示された初期状態で[カウント]ボタンをクリックする
→ クリック回数表示部分の数値に＋1する
② クリック回数表示部分に1から98が表示されている状態で[リセット]ボタンをクリックする
→ クリック回数表示部分の数値を0にする
③ クリック回数表示部分に1から98までの数値が表示されている状態で[カウント]ボタンをクリックする
→ クリック回数表示部分の数値に＋1する
④ クリック回数表示部分に99が表示されている状態で[カウント]ボタンをクリックする
→ クリック回数表示部分の数値を0にする
⑤ クリック回数表示部分に99が表示されている状態で[リセット]ボタンをクリックする
→ クリック回数表示部分の数値を0にする。
3. 状態遷移図
4. 状態遷移のパスカバレッジ
本システムで想定される状態は、以下の3パターンです。
[初期状態(0が表示されている)]
[カウントが進行する状態(1～98以上の数字が表示されている)]
[カウントが上限に達する状態(99が表示されている)]
状態遷移図ではどの状態も確認できています。
想定される状態を全て網羅しているので、状態遷移のC0パスカバレッジは100%の状態となります。
また、各状態から遷移可能な全ての遷移を必ず1度は通っていることを確認できています。
想定される遷移を全て網羅しているので、状態遷移のC1パスカバレッジは100%の状態となります。
5. 状態遷移表
状態遷移図はあくまで想定範囲内の状態と遷移の関係を表現していますが、状態遷移図のみでは想定できていないケースもあります。
そこで、想定されるパスを元に、状態遷移表を作成します。
対象となるイベントが発生してもその状態からは何も変化が想定されていない場合は[-]、対象となる状態からは対象となるイベント自体を発生させる状況が存在し得ない状態の場合は[N/A](not applicable)と記載します。
[初期状態(数値0)]で②イベントを発生させようとした場合、②イベントは前提として"数値1～98で"と定義しており、[初期状態(数値0)]かつ②の前提条件"数値1～98で"という状態に矛盾が生じているため、再現できる状況が存在しないので[N/A]としています。
6. 関係行列
上記の状態遷移表は[状態][イベント]を行列として表にしていますが、これを[前状態][後状態]で行列に記載します。
行の[前状態]でセル内に記載しているイベントを発生させることで、列の[後状態]に遷移することを表しています。
7. Nスイッチカバレッジ
各状態は複数の遷移パスによってつながっており、一つの前状態から後状態へ移行した後に、その後状態からさらに後状態へ遷移することが考慮されます。
今回のシステム仕様から考慮した場合、
1. (開始状態)初期状態で[カウント]をクリック
→ (後状態)数値1～98(カウント進行中)
2. (後状態)数値1～98(カウント進行中)で[リセット]をクリック
→ (終了状態)初期状態
このような遷移が考えられます。
NスイッチカバレッジのNは数字であり、上記の場合は[初期状態]→[カウント進行中]→[初期状態]で、開始から終了までの間に1つの状態を経由しているので、1スイッチカバレッジとなります。
7-1. スイッチカバレッジの場合
Nスイッチの数はさらに追加することも可能ですが、スイッチの数を増やすほどテストケースも併せて増加するので、テスト工数が圧迫されます。
スイッチ数が多ければ多いほど、ユーザーとして操作可能な遷移をより多く網羅できますが、比例してテストにかかる工数も増加していくので、あくまでテストスケジュールやテストのリソースを考慮したうえで、どの程度まで詳細なテストをするかは調整する必要があります。
7-2. スイッチカバレッジの場合
8. テスト現場での状態遷移テスト技法
今回例として作成した仮のシステム要件は、非常に単純な機能と動作のみで構成しましたが、システムやサービス全体をテスト対象とした場合は、もっとさまざまな機能や動作が用意されていると想定されます。
複数機能が関連して遷移も多く想定される場合は、状態遷移図に落とし込もうとすると状態と遷移の記載が混雑して、状態遷移図に書き切れなかったり、余計にわかりにくくなったりします。
このため、状態遷移テストを元にテストケースを作成する際、複数機能が関わっている場合は、単純化できる程度に各機能を細分化して、各機能に対して状態遷移テストが必要になりそうなもののみにフォーカスして、状態遷移テスト技法を適用すると、テストケースも複雑になりすぎず効果的に使用できます。
9. 追記
状態遷移テスト適用の例としてなるべく単純なシステムを考えましたが、対象とするシステム要件と選択したテスト技法の相性があまりよくなかったような気がします。
あるいは状態遷移図設定の時点で状態と遷移の設定があまりきれいに設定できなかったような気がします。
恐らくここまでの記述の中で、[数値0(初期状態)]から[リセット]をクリックして何も変化がない状態という、ユーザーの操作想定として非常に単純で発生が容易なケースについて言及しているのが、関係行列の表で[初期状態] ✕ [初期状態]の行列のみだったと思います。
状態遷移図に上記ケースを追記するとしたら、以下のような図になりますが、[初期状態]から遷移可能なパスを後から追記したことで、遷移図的には上部に位置するパスが、状態遷移表以降の表では最後に⑥パスを確認するような配置になってしまいました。
9-1. 追記対応後の状態遷移図
9-2. 追記対応後の状態遷移表
ちなみに状態遷移表に[初期状態] ✕ ⑥イベントで[初期状態]と記載していますが、そのイベントを経由したからといって[初期状態]に変化は生じていないため、対象となるイベントが発生してもその状態からは何も変化が想定されていない場合である[-]で記載すべきでしたが、遷移図にパスの記載があるのに遷移表で[-]の記載になっていると、図と表で相違があるように見えるので、[-]ではなく[初期状態]としています。
テストケースやチェックリストを元にテストを実行する際、必ずしも上から順にテストを実施しなければならないわけではなく、類似する状態は先にまとめてテストをしたり、同じような前提条件ならば都度設定を変える手間を避けるため先に着手を進めるなどの対応も発生しますが、可能な限り上から順に確認を行うようにすれば、遷移に沿って抜け漏れなくテストを進めることができるので、テストケースやチェックリスト作成時は、確認者が項目を行き来せずに済むよう順列を整理しておくことで、テストの品質を向上させることができます。
また、上記で訂正したようなテストケースの考慮不足なども、状態遷移図や表として整理表現したものをレビューすることで検知可能になるので、テストケース作成の技法としてのみならず、仕様に対して静的テスト(レビュー)を行うための対象物としても、状態遷移図や表は有効です。