テストでバグ発見！（8）状態遷移モデルで扇風機シミュレーターのバグを摘出せよ【解答編】：山浦恒央の“くみこみ”な話（150）（2/4 ページ）

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。今回は、扇風機シミュレーターをテーマとする問題の解答編。状態遷移モデルをベースにしたデバッグに取り組もう。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

4. 解答

4.1 状態遷移に着目したテスト設計のポイント

　状態遷移に着目したテストのポイントを以下に示します。

• 状態遷移表の各項目をテストしているか
• 状態遷移図のパス（矢印の線）をテストしているか
• 状態遷移を複数回テストしているか

4.1.1 状態遷移表の各項目をテストしているか

　厳しいスケジュールでも最低限テストしたいのは、状態遷移表の各項目（各マスのこと）を通るテストです。

表1　問題で提示した状態遷移表［クリックで拡大］

　表1は、問題で提示した状態遷移表です。オレンジが、最低限テストしたいマス目です。全てのマス目をテストしたいところですが、黄色に示す通り、テストできない項目もありますので、そこは無視しますね。このケースでは、中速モードでモーター停止イベントを起こすことはできないためテストしません。

4.1.2 状態遷移図のパス（矢印の線）をテストしているか

　状態遷移図の「パス」をテストすることは非常に重要です。これを全て網羅すると、状態遷移におけるC1カバレッジが100％とみなせます。カバレッジについて、以下、復習を含め、概要を記述します。

　自動車の製造で、一度も使ったことがなく、テストしたこともないスイッチがある自動車をそのままマーケットにリリースすることはあり得ません。ソフトウェア開発で同様の概念を取り入れたのがカバレッジの考え方で、ホワイトボックステストの一種です。

　プログラムのカバレッジには多くの種類があります。例えば、図2のようなプログラムがあるとします。黄色い丸がソースコードを表します。黄色の丸を全て実行するのがC0カバレッジで、図3のように2回実行すれば網羅できます。

図2　ソースコードの概念図

図3　C0カバレッジの例

　図3での2つの実行結果を重ねると図4となります。図4では、ソースコードは全て実行したことになり、「C0カバレッジ」を100％網羅していますが、パス（矢印の線）は全ては実行できていません。パスを全て実行したのが図5で、これが「C1カバレッジ」を100％網羅した状態です。

図4　C0カバレッジでの網羅

図5　C1カバレッジでの網羅

　通常のプログラムのカバレッジでは、C0カバレッジを100％網羅すれば高品質が期待できますが、状態遷移モデルでは、C0カバレッジを100％網羅するだけでは不十分で、C1カバレッジも100％網羅する必要があります。図6は、状態遷移図の線をテストするイメージ図です。このように状態間を結ぶ線（パス）も少なくとも1回はテストする必要があります。

図6　状態遷移図でのパス・カバレッジのイメージ図

　前回の本コラムの付録その2では、タクシーを例に状態遷移モデルの概要や特徴を解説しました。タクシーの状態遷移モデルでは、以下の図7のように、赤い線を全て実行する必要があり、テストでのC1カバレッジの100％網羅は必須です。

図7　タクシーの状態遷移モデルのC1カバレッジ［クリックで拡大］

4.1.3 状態遷移を複数回テストしているか

　状態遷移を繰り返すことで顕在化するバグもあります。今回のプログラムには、弱速→中速→強速→弱速→中速→強速を繰り返し通ると顕在化するバグを埋めました。ただし、繰り返す数を増やしても、摘出できるバグの数は劇的には増えません。2回繰り返すと、この系統のバグの大部分を検出できます。やみくもに繰り返しても、労力と実行時間が増えるだけなので、注意が必要です。