astahによる状態遷移テストの事例

astahによる状態遷移テストの事例が紹介されていたのでメモ。

【参考】
状態遷移テストと1スイッチカバレッジ｜Tsuyoshi Yumoto｜note

UMLステートマシンと状態遷移図 - astah-info

teyamaguさんはTwitterを使っています 「湯本さんによる，状態遷移テストの話 昨日の社内勉強会で，同じAstahを使っても，湯本さんが書いた状態遷移図と他の人が書いた図の見た目が異なっていて，湯本さんが書いた図がきれいなのは驚いた． 湯本さんとか社外で講師できる人に気軽に色々聞けるのは贅沢だわ． https://t.co/HA9cHxuFWb」 / Twitter

astahソフトウェアの品質向上支援プラグイン

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

上記の記事を読んで、自分の気付きがいくつかあった。

テスト技法には、デシジョンテーブルやオールペア法のような組合せテストが多い気がする。
それらは「テストパラメータの事前入力のバリエーション」に注力する。
一方、状態遷移テストでは、「テストケース構造の事前状態（事前条件）に着目」する。
つまり、単なる事前入力値の組合せだけでなく、事前入力の状態までの履歴も考慮する点が異なる。
この指摘は、改めて気付かされた。

状態遷移テストには、テストカバレッジの考え方にN-switch coverageがある。
詳細は下記を参照。

状態遷移表を使用したテスト手法【後編】 (1/3) - MONOist（モノイスト）

スイッチカバレッジのまとめ: ソフトウェアテストの勉強室

状態遷移テスト - Qiita

おそらく、単体テストレベルでは0-switch coverage、結合テストでは1-switch coverage、総合テストでは、N-switch coverageのようなイメージもあるだろう。
つまり、条件分岐処理に関するC0・C1・C2網羅のような考え方と同じく、状態遷移テストでもN-switch coverageを考えることでテスト網羅性を高めるわけだ。

では、どうやって、0-switch coverageやもN-switch coverageのテストケースを作るか？
おそらくテストケース生成ツールなしでは、状態遷移テストの網羅性を高めることは難しいだろう。

幸いなことに、astahでは品質管理プラグインがあるおかげで、状態遷移図を描けば、状態遷移表を生成し、それに基づくテストケースをExcel出力することができる。
開発者もテスト担当者も、精度の高い状態遷移図を描くことに注力するだけでいいのはすごく良いメリットだ。

改めて思うのは、テスト技法はモデリング技法に密接に関係している。
その意味は、単にモデルの正当性にテストが必要、というだけではない。
開発したソフトウェアをテストするには、何らかの観点が必要であり、それはモデルが提供すべきもの。
モデルがテスト技法を支援しているわけだ。

そういう考え方も色々考えてみる。