1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

GIHOZを用いて状態遷移テストを実践していきます.

状態遷移テスト

状態遷移テストとは,「状態遷移図を用いたテスト」や「状態遷移表を用いたテスト」の総称です.

状態遷移テストでは,ソフトウェアの動作中の状態に着目します.

状態遷移図のメリット

状態遷移図を作成すると,状態遷移の流れが容易に把握できます.

また,図示することで状態遷移に関する仕様の不備に気づくこともあります.
スクリーンショット 2024-12-17 131455.png

状態遷移表のメリット

状態遷移表を作成すると,すべての状態をすべてのイベントの組み合わせを一覧表示できるので,使用があいまいな箇所を特定できます.

これにより,欠陥を発見する可能性を高めることができます.

状態遷移テストの例

次のコピー機の仕様に対して状態遷移テストを考えます.

  • 電源を入れると停止中になり,いつでもコピーできる状態になる
  • 停止中に設定ボタンを押すと設定中になり,コピー枚数やコピー倍率などを指定可能
    設定を終え,コピーボタンを押すとコピーが始まりコピー中になる
  • 毎度設定をしなくても停止中にコピーボタンを押すと標準設定(コピー枚数:1枚,コピー倍率:等倍)でのコピーが始まりコピー中となる
  • コピー終了を検知すると停止中になる
  • コピー中に停止ボタンを押すとコピーが中断され停止中になる
    用紙トレイのセンサーが用紙無しを検知しても停止中になる
  • 停止中に用紙トレイを開けると用紙交換中になる
    コピー中や設定中に用紙トレイを開ける場合も用紙交換中になる
  • 用紙補充後,用紙トレイを占めると停止中になる

状態

状態の候補は以下があげられます.

  • 停止中
  • 設定中
  • コピー中
  • 用紙交換中

イベント

イベントの候補は以下があげられます.

  • 電源を入れる
  • 設定ボタンを押す
  • コピーボタンを押す
  • コピー終了を検知
  • 停止ボタンを押す
  • 用紙無しを検知
  • 用紙トレイを空ける
  • 用紙トレイを閉める

状態遷移図の準備

GIHOZで状態遷移図に,状態を記入していきます.
状態遷移図において,状態の追加はダブルクリックで行えます.

状態遷移図に状態を記入

スクリーンショット 2024-12-18 012942.png

イベントの記入

仕様をもとにして,状態遷移図にイベントを記入していきます.

状態遷移図にイベントを記入

スクリーンショット 2024-12-18 014554.png

状態遷移表とテストケースの生成

状態遷移図を作ったら,「状態遷移表とテストケースを更新」をクリックすることでそれらが生成されます.

また,テストケースを作成する場合には全遷移テストだけでなく,設定により途中に何個の状態を経由するか,というスイッチを設定することで0 ~ 3スイッチのテストケースが生成できます.

状態遷移図を作るだけで適切な状態遷移表とテストケースを得られました.

状態遷移表

スクリーンショット 2024-12-18 014726.png

テストケース(全遷移)

スクリーンショット 2024-12-18 014738.png

テストケース(0スイッチ)

スクリーンショット 2024-12-18 015043.png

テストケース(1スイッチ)

スクリーンショット 2024-12-18 015035.png

状態遷移表の解釈

状態遷移図だけでは,「できないはずのこと」が本当に実行できないことを確認することができません.

「できないはずのこと」を網羅的に書き表すために状態遷移表は存在します.

また,基本的に状態遷移図と状態遷移表は相互に確認しながら,同時に生成を進めていくので,
GIHOZの状態遷移表にも状態とイベントは記入していきましょう.

以下の状態遷移表にイベントを記入するようにする

スクリーンショット 2024-12-18 013002.png

スクリーンショット 2024-12-18 012957.png

状態とイベントの状態遷移表

ここで,生成された状態とイベントの状態遷移表に注目してみます.

この状態遷移表は,状態とイベントの数に比例して表が大きくなってしまいますが,状態やイベントを漏れなく確認することができます.

仮に状態の抽出が不十分でも関係するイベントが抽出できていれば,状態の不足に気づくことができます.

状態とイベントの状態遷移表

スクリーンショット 2024-12-18 015637.png

前状態と後状態の状態遷移表

さらに,生成された前状態と後状態の状態遷移表にも注目していきます.

この例では同じ状態→同じ状態になるような遷移はありませんが,場合によっては,何らかのイベントが起きて同じ状態に戻ることもあります.

このとき,「停止→停止となるようなイベントは本当にないのか」という思考を働かせる(できないことの確認)ことで,仕様書に対する訂正を行ったりすることができます.

ただし,最初に行う状態とイベントの抽出が不十分だと状態遷移に漏れが生じる場合があるので注意は必要です.

前状態と後状態の状態遷移表

スクリーンショット 2024-12-18 015640.png

最後に

GIHOZで状態遷移テストをしてみましたが,状態遷移図を書くだけで状態遷移表も生成してくれたり,考えるべきテストケースも考えてくれるというのは非常に効率的であると感じました.

次回は,組み合わせテストを何らかのツールを用いてやってみたいと思います.

参考

ソフトウェアテストの教科書

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?