2024.11.14
ソフトウェアテストの設計をする際に「状態遷移図」や「状態遷移表」を作成しているでしょうか？
ソフトウェアテストでバグを見逃すことなく検出するためには、バグを検出できる十分なテストを実施する必要があります。
しかし、開発仕様書は主に開発の為のドキュメントとして作成されているため、十分なテストケースを作成することを考えたときに記載が不足していることが多いです。そのため、開発仕様書からそのままテストケースを作成してしまうと、本来実施すべきテストケースに抜け漏れが発生し、バグを見逃すことに繋がってしまうことがあります。
そこで、開発仕様書に書かれている内容を整理したり、テストケースを作成するのに必要な内容を補ったりすることが必要になります。
今回は、「状態遷移テスト」の有効なツールである「状態遷移図」、「状態遷移表」の内容と使い分け、書き方について解説していきます。
- もくじ
1．状態遷移図とは
状態遷移図とは、システムの状態とその変化を図形や矢印で表したものです。
状態を四角で表し、その遷移を矢印で図示します。また、状態名を四角の中に、状態を遷移させるきっかけとなるイベントを矢印のそばに記載します。
例えば、テレビの電源がOFFの状態でリモコンの電源ボタンを押すと電源がONになり、もう一度ボタンを押すと電源がOFFになる場合、「OFF」と「ON」をそれぞれ四角で囲んで相互に矢印を引き、矢印のそばに「電源ボタン」と記します。
状態遷移図を作成することにより、仕様書に文章で個々の遷移について記載されているのを読むよりも、状態遷移全体の流れを視覚的に捉えることが可能です。
開発者とテスト担当者で完成イメージを共有するためにも、状態遷移図は役立ちます。
開発仕様書に記載されているような一つ一つの状態の動作や遷移は個々のテストを行いやすいのですが、全体の流れが適切でなかったり、必要な遷移が漏れていたりしていることがあります。状態遷移図は、そのような設計の不備を見逃すことなく発見できます。
2．状態遷移表とは
状態遷移表は、「遷移前の状態」と「遷移後の状態」、「イベント」を表形式でまとめたものです。
状態遷移表では、状態遷移図とは違い、遷移が発生しない「状態」と「イベント」の組み合わせも把握できます（上図では"－"になっている個所）。
遷移が発生しないのであればわざわざ確認する必要はないのでは？と思うかもしれません。
しかし、設計で想定していない状態とイベントの組み合わせは、何が起こるか開発者も分からないことが多いのです。そのため、あらかじめ設計時に想定されたイベントよりもバグが潜みやすい部分となっています。
そのようなバグを検出できるテストを実施するために、状態遷移表は効果を発揮します
3．状態遷移図と状態遷移表の書き方
状態遷移図と状態遷移表の書き方について簡単に解説します。
3-1 状態遷移図の書き方
状態遷移図は、まずシステムがどんな状態にあるのか、「状態名」をつけて書き出すことから始めます。
例えば、テレビの電源なら、「OFF」と「ON」という具合です。それが遷移する方向へ矢印を引きます。そして、遷移したきっかけ、いわゆる「イベント」を矢印の隣に書き込みます。
「OFF」から「ON」への矢印には、「電源ボタンを押下」となります。なお、1つの遷移に対して、矢印は1本です。
「ON」から「OFF」への遷移も、「電源ボタンを押下」という同じイベントになりますが、それは別の矢印で書き込むことになります。
3-2 状態遷移表の書き方
状態遷移表は、縦軸が「状態」、横軸が「イベント」です。
すべての「状態」、すべての「イベント」を網羅的に書き出すことが大切です。
先ほどのテレビの例では、「電源ボタンを押下」というイベントに対し、それによって起こる遷移である「ON」「OFF」の状態を下図のように書くことになります。
4．状態遷移テストとは
状態遷移テストとは、設計仕様どおりにイベントによってソフトウェアの状態が変化することを確かめるテストのことをいいます。
テレビの場合を例にとると、テレビの電源の状態が「OFF」の時に、「リモコンの電源ボタンを押す」というイベントを起こしたら、テレビの電源の状態が「ON」に変わることを確認する、あるいは表示されている番組が「１チャンネル」の状態で、「リモコンの２のボタンを押す」と「２チャンネル」が表示されることを確認するのが状態遷移テストです。
多くの開発仕様書では、テストをするのに十分な記載がされておらず、明確にソフトウェアの状態が記載されていなかったり、必要な情報がまとまっていなかったりしているため、ソフトウェアの状態遷移を正確に把握できないことがあります。
そこで、ソフトウェアの状態やイベントを開発仕様書から抽出し「状態遷移図」や「状態遷移表」として図や表にまとめます。
これらの資料を作成し、仕様を整理し見える化することで、より深く製品の仕様を把握することができ、テストの漏れ抜けを防止することができます。
また、上流工程段階で作成しておくと、仕様の漏れ抜けも開発の早い段階で検出でき、バグの作り込みを防止することにも繋がります。
5．状態遷移テストを実施する上でのポイント
状態遷移テストを実施する上で押さえておきたいポイントをご紹介します。
5-1 状態遷移図・表の両方を作成する
状態遷移図と状態遷移表はどちらも作成するようにしましょう。
なぜなら、状態遷移図と状態遷移表にはそれぞれ異なる特徴があり、相補関係にあるからです。
「状態遷移図」はシステム全体を俯瞰有効ですが、状態ごとのイベントの処理方法は分かりにくいです。
これに対して「状態遷移表」は、システム全体を俯瞰するには向いていませんが、状態ごとのイベントの処理方法を細かく漏らさず表せます。
このように状態遷移図と状態遷移表は、お互いに不足している部分を補っています。両方を作成することで、状態遷移テストの効果向上が期待できるでしょう。
5-2 人の操作以外のイベントも考慮する
状態遷移テストの際は、人の操作以外のイベントも考慮するようにしましょう。
状態遷移のイベントとして「電源をオンにする」「ボタンを押す」など人の操作によるものもありますが、一方で「一定時間が経つと電源がオフになる」「人やモノを検知するとランプが点く」などシステムの挙動がイベントになる場合もあります。
状態遷移図や状態遷移表を作成する際は、人の操作以外のタイマーやセンサーなどのイベントも考慮すると、テストのヌケモレを防ぐことに繋がるでしょう。
5-3 状態が遷移しないことにも留意する
状態遷移テストを実施する際は「状態が遷移しないこと」にも留意しましょう。
状態遷移テストでは「正常に遷移する」「異なる状態に遷移してしまう」など、「状態が遷移すること」に目がいきがちです。
しかし、「状態が遷移するか」だけでなく「状態が遷移しない」ということにも注目してテストを実施するようにしましょう。
まとめ
今回は状態遷移図と状態遷移表の内容と違いと、状態遷移テストについて解説しました。
改めてまとめると、「状態遷移図」は、システムの状態とその変化を図形や矢印で表したものです。図式によってソフトウェアの仕様を「見える化」することで、ひと目で全体像を把握することができます。
「状態遷移表」は、遷移前の状態と遷移後の状態、イベントを表形式でまとめたものです。状態遷移図だけでは分からない、細部を漏れなく拾ってくれます。
状態遷移図と状態遷移表を組み合わせることで、正しく動作しているか、間違った動作がないかをフルカバーでき、状態遷移の全体の流れの把握、開発仕様書の抜け漏れの防止を行うことができます。
それぞれの特徴を理解して、ソフトウェアのテスト設計に取り入れてみてはいかがでしょうか。
