第96回： 状態遷移テスト（後編）
≡ はじめに
「ASTERセミナー標準テキスト」の109ページについてです。
前回は、状態遷移テストの基礎について書きました。今回は実践編として、「ステート・マシン図」からテストを作る方法についてです。
状態遷移テストのテストすべきパスを手作業で作る場合は、『ソフトウェアテスト技法練習帳』に書いてある方法が簡単で良いと思います。（テスト対象が組み込み系ソフトウェアの場合は、状態遷移表を書いて、遷移しないイベントをテストすることも忘れずにしてください）
その方法は、状態遷移図にある全ての状態を書き出して、そこから2回遷移をたどってテストすべきパスを見つける方法（1スイッチテスト）です。（1回の遷移は状態遷移表で確認済みであることが前提です）
（状態Ａ）┬（状態Ｂ）─（状態Ｄ）
└（状態Ｃ）─（状態Ｅ）
（状態Ｂ）─（状態Ｄ）─（状態Ｆ）
という具合です。状態遷移図をたどりながら、遷移（線）にマーカーを引いて行けば、パスの抜け漏れを簡単に見つけることが出来ます。
具体的にやってみます。キャッチイメージから状態遷移図のところを切り取ります。
■ 状態遷移図にある全ての状態を書き出しす
（計測準備中）
（計測中）
（一時停止中）
※ 括弧で括ったのは見やすくするためで、他に意図はありません。
■ そこから2回遷移をたどってテストすべきパスを見つける
まずは1回の遷移
（計測準備中）→（計測中）
（計測中）→（一時停止中）
（一時停止中）┬（計測準備中）
└（計測中）
もう1回遷移
（計測準備中）→（計測中）→（一時停止中） ①
（計測中）→（一時停止中）┬（計測準備中） ②
└（計測中） ③
（一時停止中）┬（計測準備中）→（計測中） ④
└（計測中）→（一時停止中） ⑤
こうして見つかった①から⑤の5つのパス（状態遷移のフロー）をテストしたら１スイッチテストをしたことになります。もっとも、テストの実行を楽にするため、パスをつないでも構いません。パスをつなげば、
①＋④（＋②）
（計測準備中）→（計測中）→（一時停止中）→（計測準備中）→（計測中）
①＋⑤（＋③）
（計測準備中）→（計測中）→（一時停止中）→（計測中）→（一時停止中）
の2つのパスをテストすれば良いので楽になります。
（開始のノードはできるだけ、状態遷移図の始まりの状態にすると良いです）
ところで、2010年に書いた『ソフトウェアテスト技法ドリル』では、関係行列を掛け算する方法を書いたため、状態遷移図からＮスイッチテストのパスを作る時には『必ず行列計算をするんだ』と思い込んでしまった人もいらっしゃるようで、ごめんなさい。
間違いではないのですが、あの方法は、手計算というよりツールを自作する人向けの説明で、普通の人にはかえって分かりにくかったですね。（あれを書いたときには『バイザー本』に難しく書いてある方法なので、それを分かりやすく書けばいいと単純に考えていたのでした）
グラフ（ここでは、状態遷移図）を数学的に扱うことで別のメリットもあるのですが、そこまでは書いていませんので、中途半端なものになってしまいました。
状態遷移図からテストすべきパスを見つける方法については、湯本さんのnoteにも分かりやすく書いてありますので、そちらも併せてお読みください。
手抜きじゃないです。私が書くよりも練習帳や湯本さんのnoteの方が丁寧でわかりやすいに決まっているので、私が書いても仕方ないのです。
（行列計算の話は、『ドリル本』と同じになってしまいますし）
≡ 状態の見つけ方
状態遷移図から状態遷移表やNスイッチカバレッジテストを作るのは、手作業でしないほうが良いです。
仕組みを理解することを目的として、一度は紙に手で書いてみるというのはアリです。しかし、それを毎回行うのは、プログラマーがコンパイラーを使わずに、毎回、ソースコードからマシン語を書くようなものです。できないことはありませんが、ミスが入り込むリスクがあります。
コストの面から考えてもツール（例えば、以下で紹介している、astah*やEA（Enterprise Architect）など）を使うべきです。
状態遷移図から状態遷移表やNスイッチテストのパスを作るような単調で、かつ、ミスが発生しやすい作業はコンピュータが最も得意とすることです。人間（テスト設計者）は『良い状態遷移図』を描くことに頭と時間を使うべきです。
例えば、astah*やEnterprise Architectといったツールには、そのような機能が実装されています（もしくは、無償のプラグインが使えます）。どちらも良いツールなので使ってみて好きな方を選べばよいと思います。
ところで、Enterprise Architectは、CFDを描けますのでCFD法を使う人は、Enterprise Architectが良いかもしれません。一方、astah*はD-Case（GSN）が描けますし、マインドマップも得意です。図の描きやすさもastah*かなぁ？ 描きやすさは、慣れの問題が大きいと思いますが。
そこで、このnoteでは、そもそも状態遷移図はどう描いたら良いか、「テスト用の状態遷移図」について書きたいと思います。
デシジョンテーブルの回で開発者が作るデシジョンテーブルとテストエンジニアが作るデシジョンテーブルは違うという話を書きました。（補集合の話）
実は状態遷移図も同じです。開発者が描く状態遷移図の状態は一般化している方が望ましく、テストエンジニアが描く状態遷移図の状態は具体的なものが望ましいです。
例えば、100円玉しか受け付けない自動販売機（商品の価格は一律140円とします）があったときに、投入金額（という状態変数）について、開発者は、「購入不可」と「購入可」の2つの状態を描くことが多いと思います。仮に自動販売機の商品の価格が140円だったら、投入金額が0円と100円なら「購入不可」の状態で、200円以上なら「購入可」の状態というわけです。プログラムを組むうえで、一般化した状態区分で全く問題が無い、というより、その方がプログラムを作りやすいですし、商品の価格の仕様変更にも柔軟に対応できるからです。仕様書には、そのような状態遷移図が描かれます。
ところが、テストエンジニアが描く状態遷移図の状態は、具体的な「0円」、「100円」、「200円」、「300円」の方が望ましいです。具体化したほうが、投入金額が「200円」のときと「300円」のときで、商品購入後に遷移する状態は変わるのかな？ といった疑問が浮かぶからです。
300円のときには、160円のお釣りと商品を出して「0円」の状態に遷移するタイプと、60円のお釣りと商品を出して「100円」の状態に遷移するタイプが考えられますので、「200円」と「300円」を一般化した「購入可」の状態にするより丁寧なテストとなります。
ところで、セミナーでこの話をすると開発者から「それはわかりましたが、いくらまで状態を作ったら良いのでしょうか？ 300円、400円、500円、、、？？？」という質問を受けることがあります。
答えは、「テストしたいことに合わせて同値分割法で考える」です。
例えば、「釣銭を出す」というテストアイテムに対してなら、0円から300円までで（以降は同値があるので不要）と考えます。もし、「投入限度額まで投入金額を表示しそれ以降はコインを受け付けない」というテストアイテムに対してなら投入限度額＋1枚までの状態を描きます。
さて、それでは、どうやってそのような状態を見つけるかですが、前回説明した「状態は、“状態変数の値の組合せ”」を思い出してください。
どのような変数が存在するのか。それは、設計書を見れば分かります。
設計書が無ければソースコードを見ればわかります。
コードレビューのときのようにプログラマーでなければ分からないような複雑なロジックを追う必要は無く、ソースコード上の変数が設計書の何を意味しているのかだけ確認すれば良いので、簡単です。
次に（作業としては同時に行いますが）、変数のうち、関数の引数以外の変数に着目します。というのは、引数は関数を動かすときの入力にあたるからです。引数ではなく、関数の途中で利用される変数に着目します。
例えば、購入した品物の合計金額を求めるときに、一品ごとの金額は入力ですが、消費税率のような変数は状態を保持している変数（以降はこの意味で、状態変数と呼びます）となります。
状態変数が見つかったら、次はその変数に格納する値をチェックします。例えば、車のワイパーの状態を格納する変数を見つけたら、その状態変数には、ワイパーの動作モード0（停止）, 1（間欠）, 2（通常）, 3（高速）を格納しているのか、それに加えて間欠動作のときの速さを5段階で格納する状態変数があるのか、、、そういったことを調べてその値を状態にして状態遷移図を作ります。
ワイパーとオートライトの関係をテストしたいなら、「ワイパーの状態の数×オートライトの状態の数」分だけ状態を作ります。このときに、意味が無い状態があるなら削除しますが、初回のテスト時はそれも含めてテスト内容を考える方が良いので、削除しない方が良いです。
≡ 状態遷移テストの網羅基準
1-スイッチテストをお勧めします。なぜなら、ある状態遷移でデータを破壊したとしても、データが壊れた状態で遷移するテストをしないと不具合現象として現れないからです。
2-スイッチテストについては、そこまで昔の遷移を覚えている箇所は少ないので、通常のソフトウェアでは不要と思います。
2-スイッチテストが必要となるのは、例えば、録画再生装置で、
（通常再生）ー 早送り →（早送り再生）ー 一時停止 →（一時停止状態）
のときに、［再生］ボタンを押した時の状態が、（通常再生状態）なのか（早送り再生状態）なのかが、気になるような場合です。
仕様書に書いてあるはずなので、その部分だけ2-スイッチテストをしてください。
≡ 終わりに
今回は、今回は状態遷移テストの実践編についてでした。
このノートに書いたことは、有限状態機械（英: finite state machine, FSM）の範囲の話ですが、もっと複雑な状態遷移テストについては、まなべさんの『UMLステートマシン図を用いた状態遷移テストの注意点』などが参考になると思います。
私は、モード（mode）の切り替えと、状態（state）の遷移は分けてテストしていますので、今回書いた内容で、テストしていますがテスト対象によってはモードを分けない方が良いかもしれません。
モードは、エアコンでいえば、「暖房」、「冷房」、「除湿」といった大きな状態遷移のまとまりで、それぞれの中で「温度」、「風量」、「風の向き」等々の条件（condition）の組合せによって状態が決まり、状態遷移を起こすというアプローチです。
もちろん、どんな動作モードでも「お掃除機能」が時刻をトリガーとして動き出すといった共通的に使われる機能もあるのでその部分のテスト設計は別途必要なのですが、モード間を頻繁に遷移させるテストの必要性は少ないと思っています。
（アーキテクチャによりますが）
次回は「ユースケーステスト」の基礎編となります。ユースケースとユースケース図について書く予定です。
