UMLモデルからテストケースを作ろう

4. テストケースを作成する

付箋によるタスク管理をソフトウエアで実現した場合、実装したソフトウエアのタスク・オブジェクトは、図2のステートマシン図で表した通りの状態遷移を行わなければなりません。

例えば「ある状態が、あるイベントを通して、次の状態に遷移する」といった、状態遷移を1回だけ行う状態遷移パスは、図3の上部の表を用いて簡単に抽出できます。

ところが、イベントの発生に伴って実行されたアクションに不具合があり、その後の状態遷移に影響を与えてしまう場合があります。その結果、状態遷移を複数回行うと、期待通りの状態遷移パスをたどらなくなってしまいます。

状態遷移を1回だけ行うテストケースでは、このような不具合を発見することができません。かといって、状態遷移の回数を多くしてしまうと、状態遷移のパスが爆発的に増えてしまい、テストを実施することが困難になってしまいます。何回の状態遷移を対象としたテストケースを作成するかは、テスト設計として検討しなければなりません。

今回は、2回の状態遷移を行う状態遷移パスを抽出します。2回の状態遷移を行う状態遷移パスとは、「TODO→（とりかかる）→DOING→（やりおえた）→DONE」のような組み合わせです。しかし、2回の状態遷移を行う全ての状態遷移パスを1つ1つ手動で拾い上げると時間もかかりますし、ミスが発生する可能性もあります。

そこで、今回は数学の行列計算を応用し、（2回の状態遷移を行う）全ての状態遷移パスを抽出する方法を用います。

2回の状態遷移を行う状態遷移パスは、現状態から次状態への遷移を表した表（図3の上部の表）のイベント部分を行列とみなし、2乗することで抽出できます（図4）。

なお、表を見やすくするために、表中では各イベントを以下の通り略字で表しています。本記事では、行列計算の詳細については解説しません。しかし、非常に効率的な手法なので、ご興味がある方はぜひ学習してください。

• Nothing … E1
• とりかかる … E2
• 放棄する … E3
• やりおえた … E4
• やりのこしを見つけた … E5
• 破棄する … E6

図4の下部の表「2回の遷移を行った場合の状態遷移パス」を見てください。この表は、縦軸に現状態、横軸に次々状態（現状態から2回遷移した後の状態）を記述しています。そして、縦軸と横軸が交差するセルには、現状態から次々状態へ遷移するイベントの組み合わせを記述しています。

例えば、2回の状態遷移を行うことで、TODO状態からTODO状態へ遷移する（戻ってくる）状態遷移パスは「TODO→（E2:とりかかる）→DOING→（E3:放棄する）→TODO」であることがわかります。

現状態から次々状態までの状態遷移パスが、複数存在する場合があります。例えば、2回の状態遷移を行うことでDOING状態からDOING状態へ遷移する状態遷移パスは、「DOING→（E3:放棄する）→TODO→（E2:とりかかる）→DOING」という状態遷移パスと、「DOING→（E4:やりおえた）→DONE→（E5:やりのこしを見つけた）→DOING」という状態遷移パスの、2通りあることがわかります。

以上で、2回の状態遷移を行う状態遷移パスを抽出することができました。これらの状態遷移パスは、ソフトウエアの動作を検証するための、簡単なテストシナリオとして利用することができます。

5. まとめ

今回は、コミュニケーションをサポートするために作成したUMLモデルが、さらに他の用途にも利用できることを解説しました。このように、UMLモデルに複数の利用方法があれば、UMLモデルを作成する価値がさらに高まります。