テスト技法解説「状態遷移テスト」

状態遷移テストとは、状態遷移モデルに基づきテストケースを作成するためのテスト技法です。この技法を使うことで、テスト対象であるソフトウェアやシステムに状態遷移によって生じる不具合がないかどうかを確認できます。

記事[GIHOZの使い方：状態遷移テストのテストケースの作成方法]でご紹介した状態遷移テストからさらに技法の説明を加え、別の事例を交えてGIHOZによる状態遷移テストの流れをご紹介します。

状態遷移モデルとは？

テスト対象の状態の変化を図や表などを用いてモデリングしたものを指します。例えば、状態遷移図や状態遷移表が挙げられます。状態遷移図は、状態や状態の変化を図形や矢印などで表現したものです（図表1）。

状態遷移表は状態の変化をマトリクス表で整理したものです。状態遷移表にはさまざまな形式がありますが、よく使用される形式として「状態（※1）」と「イベント（※2）」の2軸で整理する形式（図表2）と、「遷移（※3）前の状態」と「遷移後の状態」の2軸で整理する形式（図表3）があります。

※1　状態とは、ソフトウェアやシステムの状況や特性を表すものです。ソフトウェアやシステムは必ず特定の状態にあります。例えば、ソフトウェアで制御する自動ドアで考えると、「閉じている」という状態や「開いている」という状態があります。

※2　イベントとは、状態の遷移を引き起こすトリガーとなるものです。例えば、ドアの状態が「開いている」状態から「閉じている」状態に遷移するに当たって、「ドアを閉じる」ことがイベントに当たります。

※3　状態の遷移とは、一つの状態から別の状態（または同じ状態）へと変化することを表します。例えば、ドアの状態が「開いている」状態から「閉じている」状態に変化することが遷移に当たります。

状態遷移には、ある状態から別の状態に遷移する場合もあれば、ある状態から元の状態に戻る自遷移もあります。図表1を例にすると、状態0からイベント2によって状態1に遷移するのは前者、状態0からイベント1によって状態0に戻るのは後者に該当します。

テスト設計全般についてはこちらのページもご覧ください。

https://www.veriserve.co.jp/service/detail/testdesign.html

ソフトウェアやシステムは特定のイベントが起きると、その状態が変化する場合があります。状態遷移が複雑になると、ソフトウェアの全体像や動作の流れを直感的に理解することが難しくなります。これはテストを行う際に大きな問題となり、テスト設計での抜け漏れの発生につながります。ここで役立つのが状態遷移図と状態遷移表です。

これらを用いると、テスト対象の状態遷移を網羅的に整理できます。状態遷移図はテスト対象の状態遷移を可視化し、全体像を視覚的に把握することが可能です。一方、状態遷移表では、遷移することのみではなく、遷移しないことについても考慮することができ、想定しない不具合の検出に役立ちます。

また、状態遷移テストではテストの目的に合わせてカバレッジ基準を選択できます。例えば、全状態カバレッジでは、状態遷移モデル内のすべての状態を網羅します。

0スイッチカバレッジでは、状態遷移モデル内の有効な単一の遷移（状態遷移図のすべての矢印）を網羅します。全遷移カバレッジでは、0スイッチカバレッジに加えて「遷移しない」ことも網羅します。

Nスイッチカバレッジでは、状態遷移モデルにおけるN+1回の遷移可能な経路を網羅します。状態遷移に関わる不具合の中には、複数の遷移を伴う特定の経路を通った時にだけ検出できる不具合もあり得ます。これは0スイッチカバレッジでは見つけられない可能性があるため、N=1以上のスイッチも網羅する場合があります。

状態遷移テストの利用シーン

ソフトウェアやシステムは同じ入力であれば、基本的に同じ出力結果が得られます。しかし状態が異なると、同じ入力であっても異なる出力結果が得られる場合があります。このような場合に状態に応じた振る舞いの違いを漏れなくテストするには、状態遷移テストが有効です。

ここからは以下の仕様を例として、状態遷移モデルとテストケースの作成手順について説明します。

・家庭用の照明機器の仕様

照明機器は消灯中にスイッチをONにすると点灯し、点灯中にスイッチをOFFにすると消灯します。明るさが強・中・弱の3段階あり、点灯中に明るさ切り替えボタンを押すと、明るさを切り替えられます。明るさが強の時に明るさ切り替えボタンを押すと、中に切り替わり、中の時に押すと弱、弱の時に押すと強に切り替わります。スイッチをONにした時、明るさは必ず強になります。

状態遷移テストを適用する際、専用のツールを使わずに状態遷移図を用いようとすると作図に時間を取られたり、状態遷移モデルから手動でテストケースを洗い出すとミスが起きたりします。さまざまなテスト技法を手軽に利用してテスト設計に役立てられるGIHOZを使うと、状態遷移図の作図を簡単に行え、状態遷移表やさまざまなカバレッジ基準に対応したテストケースがワンクリックで出力できます。以下では、GIHOZを使った状態遷移モデルとテストケースの作成手順を説明します。

ステップ1　状態とイベントを識別する

仕様から状態とイベントを識別します。上記の例では消灯中と点灯中という状態があり、点灯中には、明るさが強・中・弱の3つの状態があることから、全部で4つの状態があることが分かります。イベントは、上記の例では照明機器のスイッチON・OFFと、明るさ切り替えボタンの押下があることが分かります。

ステップ2　状態遷移モデルを作成する

状態遷移モデルとして状態遷移図や状態遷移表を作成します。どちらかのみ作成することもできますし、前述したように両方を作成すれば「図で整理すること」と「表で整理すること」のそれぞれのメリットを得ることもできます。以下で、状態遷移図と状態遷移表の作成手順を説明します。

状態遷移図を作成する

ステップ１で識別した状態とイベントを状態遷移図で作成します（図表4）。まずは、識別した状態を表記します。GIHOZでは、状態を角の丸い四角で表現しています。上記の例だと、「消灯中」「点灯中（明るさ：強）」「点灯中（明るさ：中）」「点灯中（明るさ：弱）」の4つを図形で表記します。その次に、状態と状態を矢印でつないで、状態の遷移を表現します。「点灯中（明るさ：強）」→「点灯中（明るさ：中）」のように、遷移前の状態から遷移後の状態に矢印が向くようにつないでいきます。状態を矢印でつなぎ終えたら、矢印上にその状態への遷移を引き起こすきっかけとなるイベントの名称を記載します。「消灯中」→「点灯中（明るさ：強）」であれば、「スイッチ：ON」のようにイベント名称を記述します。

GIHOZでは、マウスのドラッグ＆ドロップなどの操作だけで状態遷移図が作成できます。

状態遷移表を作成する

ステップ1で識別した状態とイベントでの状態遷移表を作成します。初めにマトリクス表を、遷移前の状態×遷移後の状態とするか、状態×イベントとするかを決定します。今回は行が状態、列がイベントの状態遷移表を作成します。

識別した状態とイベントを漏れなく行と列に記述します。上記の例だと「消灯中」「点灯中（明るさ：強）」「点灯中 （明るさ：中）」「点灯中 （明るさ：弱）」の4つの状態を行に、「スイッチ：ON」「明るさ切り替えボタン押下」「スイッチ：OFF」の3つのイベントを列に記述します。

行と列を記述したら、行と列が交差する位置に、その状態（行）でイベント（列）が発生した時に遷移する状態を記述します。例えば、「消灯中」に「スイッチ：ON」が発生した時に遷移する状態は「点灯中（明るさ：強）」になるため、「消灯中」と「スイッチ：ON」が交差する位置に「点灯中（明るさ：強）」と記述します。

交差する位置に記載すべき状態が存在しない場合は、ignore（当該イベントを無視する）または、can’t happen（当該イベントが起こりえない）を記載できます。例えば、「消灯中」の時に「明るさ切り替えボタン押下」は無視する仕様であれば、これらの状態とイベントが交差する位置に ignoreと記載します。このように特定の状態に遷移する場合だけではなく、遷移しない場合も考慮し、表を埋めます（図表5）。

ステップ3　状態遷移モデルからテストケースを作成する

状態遷移モデルを作成したら、それを元にテストケースを作成します。状態遷移図・状態遷移表から状態の遷移の経路を洗い出してテストケースとします。例えば、1スイッチカバレッジ100%のテストケースを作成する場合、イベントが2回発生する経路を網羅するようにテストケースを洗い出します。

「消灯中」→「スイッチ：ON」→「点灯中（明るさ：強）」→「明るさ切り替えボタン押下」→「点灯中（明るさ：中）」などが、1スイッチカバレッジでのテストケースに該当します。今回の例で1スイッチカバレッジ100%のテストケースを作成すると、11件のテストケースになります（図表6）。

また遷移しないことについても確認できるようにテストケースを作成すると、12件のテストケースになります（図表7）。

カバレッジ基準には、Nスイッチカバレッジだけでなく、状態だけをすべて網羅する全状態カバレッジなどもあります。どのカバレッジ基準を適用するかは、プロジェクトごとにリスク等を考慮して選択する必要があります。

GIHOZでは、状態遷移図から2つの状態遷移表（状態×イベント、遷移前の状態×遷移後の状態）と遷移しないことを含めた全遷移テストケースの生成がワンクリックで行えます。また、Nスイッチカバレッジとして0～3スイッチまでのカバレッジ基準のテストケースを生成することも可能です。

状態やイベントが多くなり複雑な状態遷移モデルになると、状態や遷移の整理において抜け漏れが発生する可能性が高くなります。特に手動でテストケースを作成する場合、抜け漏れが発生する可能性がさらに高くなります。

そのような場合、ソフトウェアの設計としての状態遷移モデルそのものをよりシンプルに設計し直すことも検討してください。また、状態遷移モデルからテストケースを洗い出す作業は、GIHOZなどのツールを用いて自動化することで抜け漏れを防止できます。

状態遷移モデルをシンプルな設計にしない場合、テストケース数が膨大になる可能性があります。そのような場合には、リスクを把握した上で実行可能なテストケース数に落とし込む工夫が必要です。

例えば、同値分割法のアプローチで、同値パーティションと見なせる状態がないかどうかを検討することや、1スイッチのすべてをテストするのではなく、0スイッチカバレッジ100%と特定の1スイッチの経路をテストするなどの対策があります。

また、Nスイッチカバレッジを用いる場合、Nスイッチカバレッジ100％を達成しても、N-1スイッチ100％を満たさない場合があります。例えば、状態遷移モデルに、開始状態（状態遷移モデルの始点となる状態）から直接、終了状態（この状態に遷移すると、それ以降遷移が発生しない状態）に遷移する経路があった場合、その経路は0スイッチでしか通れないことになります。この場合、1スイッチカバレッジ100％を達成しても、0スイッチカバレッジ100％を満たしません。

このように、包含関係（Nスイッチカバレッジ100％を達成した場合に、Nより小さいスイッチカバレッジ100％も同時に達成する関係）が成り立たない場合があり得ることに注意が必要です。加えて、Ｎスイッチカバレッジでは、特定の状態において特定のイベントによって遷移することのみにフォーカスしているため、特定の状態において特定のイベントによって遷移しないことはテストされないことにも注意が必要です。

状態の遷移に着目して状態遷移モデルからテストケースを作成する技法である、状態遷移テストについてご紹介しました。状態遷移テストは、ソフトウェアやシステムの状態に応じた振る舞いの違いを漏れなくテストしたい場合に有効です。

GIHOZを使うと、状態遷移図の作成からワンクリックで状態遷移表やテストケースの自動生成ができるため、簡単に状態遷移テストを行えます。また、GIHOZでテストケースを自動生成することで、漏れなくテストケースを洗い出せます。漏れのないテストケースを効率よく作成するために、状態遷移テストやGIHOZをぜひご活用ください。

テスト技法ツールGIHOZ

https://www.veriserve.co.jp/helloqualityworld/service/gihoz/