Nスイッチテストを実際の状態遷移テストに適用する際の難しさについて
これまで何回か状態遷移テストについて取り上げてきました。
最初は組み合わせテストツールと制約表を用いることでNスイッチテストのテストケースを生成できることを示しました。この場合、非常に複雑な制約を扱うことになるので制約の扱いが短時間で済む生成エンジンを用いたらいいのではないかと考えました。ですがこの方法は比較的小さな状態遷移には適用可能ですが、状態数が多くなるとNスイッチのNを大きくした場合、生成するテストケースが極端に多くなり、実用的な時間では生成を完了することができないと分かりました。
次にテストケース数が多くなり過ぎるNスイッチテストではなく、前の状態に戻るルートを省略した方法で組み合わせテストツールを用いてテストケースを生成する方法を考えてみました。この方法では状態数が多くなってもテストケース数が多くなり過ぎるということにはなりませんが、前の状態に戻るルートのテストを即興で行なわなければならず、テスト漏れの可能性を無視できません。
次に考えたのがNスイッチのNを大きく（8程度）とり、多数のテストケースを生成してから重要と思われる状態のルートに重みづけを行ない、重みづけの合計が大きい状態遷移を抽出してテストを行なうという方法でした。通常NスイッチのNには1や2が用いられるようですが、それだけの状態遷移を網羅しても発見できるバグは、ごく一般的なすべての状態を１度は網羅するテストと余り変わらないことが予想されます。それ以外のバグには多くの状態を経由して始めて見つかるケースが多いと思われます。ただこの方法では例えば状態が30あって、N=8とした場合、生成されるテストケース数は数万から数十万程度になります。その中から重みづけで重要そうなテストケースを例えば数百件抽出したとしましょう。これは全テストケースの100分の1から1000分の1にしかなりません。これだけのテストケースでは大幅に足りないように思われます。
Nの値を6程度にすれば、生成されるテストケースは数千件程度になりそうです。この程度であれば重みづけで数百件抽出しても10分の1程度の絞り込みですから重みづけとしての意味はありそうです。Nが8の場合と比べて網羅する状態数がやや少なくなりますが実用的という意味ではこの方法が有利です。生成されるテストケースが数千件程度であれば、組み合わせテストツールと制約表を用いた方法でも生成可能かもしれません。
最初は組み合わせテストツールと制約表を用いることでNスイッチテストのテストケースを生成できることを示しました。この場合、非常に複雑な制約を扱うことになるので制約の扱いが短時間で済む生成エンジンを用いたらいいのではないかと考えました。ですがこの方法は比較的小さな状態遷移には適用可能ですが、状態数が多くなるとNスイッチのNを大きくした場合、生成するテストケースが極端に多くなり、実用的な時間では生成を完了することができないと分かりました。
次にテストケース数が多くなり過ぎるNスイッチテストではなく、前の状態に戻るルートを省略した方法で組み合わせテストツールを用いてテストケースを生成する方法を考えてみました。この方法では状態数が多くなってもテストケース数が多くなり過ぎるということにはなりませんが、前の状態に戻るルートのテストを即興で行なわなければならず、テスト漏れの可能性を無視できません。
次に考えたのがNスイッチのNを大きく（8程度）とり、多数のテストケースを生成してから重要と思われる状態のルートに重みづけを行ない、重みづけの合計が大きい状態遷移を抽出してテストを行なうという方法でした。通常NスイッチのNには1や2が用いられるようですが、それだけの状態遷移を網羅しても発見できるバグは、ごく一般的なすべての状態を１度は網羅するテストと余り変わらないことが予想されます。それ以外のバグには多くの状態を経由して始めて見つかるケースが多いと思われます。ただこの方法では例えば状態が30あって、N=8とした場合、生成されるテストケース数は数万から数十万程度になります。その中から重みづけで重要そうなテストケースを例えば数百件抽出したとしましょう。これは全テストケースの100分の1から1000分の1にしかなりません。これだけのテストケースでは大幅に足りないように思われます。
Nの値を6程度にすれば、生成されるテストケースは数千件程度になりそうです。この程度であれば重みづけで数百件抽出しても10分の1程度の絞り込みですから重みづけとしての意味はありそうです。Nが8の場合と比べて網羅する状態数がやや少なくなりますが実用的という意味ではこの方法が有利です。生成されるテストケースが数千件程度であれば、組み合わせテストツールと制約表を用いた方法でも生成可能かもしれません。
状態遷移テストで見つけにくいバグにはどういうものがあるか
状態遷移テストでは最低限すべての状態を一度は通るテストを実施することになります。このテストですべてのバグが見つかればいいのですが実際にはそうはいきません。単純に全状態を網羅しただけでは見つけられないバグにはどういうものがあるでしょうか。今回はこれを考えてみます。
まず挙げられるのが状態を遷移しないループするイベントが関係するバグです。ループするイベントというのは何らかの状態変数の更新を伴っています。状態変数は一つとは限りません。またループするイベントも一つとは限りません。同じ状態で様々なイベントが発生した場合におかしな動作になる場合があります。このような処理は、どうしても状態を分けることができず、複数の状態変数を設けて複雑な処理を行なわなければならないため、複数のイベントの組み合わせでバグが起きやすいものです。このようなバグを見つけるには、バグがありそうな状態というのは大体分かりますから、その状態に集中して探索的テストやエラー推測テストでアドリブで徹底的にテストすることです。
次に特定のいくつかのルートを遷移すると起きるバグがあります。これも状態変数が関係しています。遷移の途中で状態変数の処理に誤りがあり、いくつかの遷移を経て再度その状態変数にアクセスするとおかしくなるというものです。こうしたバグは特定の遷移ルートを通った場合に初めて発生するため発見が難しいものです。バグを見つけても再現できないということにもなりかねません。
またタイマの停止漏れのバグも発見が難しいもののひとつです。ある状態から遷移する際にタイマの停止漏れがあると、遷移した先のどれかの状態で無効なタイムアウトイベントが発生します。ほとんどの状態ではそうしたイベントは無視されるのですが、たまたまそのタイムアウトイベントが有効な状態だと、そのイベントが受け付けられていきなりおかしな動きをすることになります。
高次元のNスイッチテストで見つけることのできる可能性のあるバグは、特定のいくつかのルートを遷移すると起きるバグです。いくつかの状態を挟んで同じ状態変数にアクセスするようなケースがこれに該当します。
まず挙げられるのが状態を遷移しないループするイベントが関係するバグです。ループするイベントというのは何らかの状態変数の更新を伴っています。状態変数は一つとは限りません。またループするイベントも一つとは限りません。同じ状態で様々なイベントが発生した場合におかしな動作になる場合があります。このような処理は、どうしても状態を分けることができず、複数の状態変数を設けて複雑な処理を行なわなければならないため、複数のイベントの組み合わせでバグが起きやすいものです。このようなバグを見つけるには、バグがありそうな状態というのは大体分かりますから、その状態に集中して探索的テストやエラー推測テストでアドリブで徹底的にテストすることです。
次に特定のいくつかのルートを遷移すると起きるバグがあります。これも状態変数が関係しています。遷移の途中で状態変数の処理に誤りがあり、いくつかの遷移を経て再度その状態変数にアクセスするとおかしくなるというものです。こうしたバグは特定の遷移ルートを通った場合に初めて発生するため発見が難しいものです。バグを見つけても再現できないということにもなりかねません。
またタイマの停止漏れのバグも発見が難しいもののひとつです。ある状態から遷移する際にタイマの停止漏れがあると、遷移した先のどれかの状態で無効なタイムアウトイベントが発生します。ほとんどの状態ではそうしたイベントは無視されるのですが、たまたまそのタイムアウトイベントが有効な状態だと、そのイベントが受け付けられていきなりおかしな動きをすることになります。
高次元のNスイッチテストで見つけることのできる可能性のあるバグは、特定のいくつかのルートを遷移すると起きるバグです。いくつかの状態を挟んで同じ状態変数にアクセスするようなケースがこれに該当します。
効果的な状態遷移テストを行なうには 高次元のNスイッチテストと重要な遷移ルートの絞り込み
これまで何度か状態遷移テストを取り上げてきましたが、どうもうまい方法が見つかりません。組み合わせテストツールを使う方法では、状態の戻りを網羅しない方法を試しましたが、それでは網羅性がかなり落ちてしまいます。かといって状態の戻りも網羅しようとすると遷移ルートが多くなりすぎ、組み合わせテストツールではテストケース生成までに時間がかかってしまいます。複雑な制約を短時間で処理できる組み合わせ生成エンジンである CIT-BACHを用いても焼け石に水のように思われます。
一般的に言って、Ｎスイッチテストでは2スイッチテストまでの網羅が多いように感じますが、それだけの浅い網羅で見つかるバグは多くないと思われます。バグを見つけるには8スイッチテスト、つまり10の状態間の遷移は網羅したいと思います。もちろんそれだけの遷移ルートの数は状態が30前後だと数万から数十万と膨大になりますから、そのなかから特に重要な遷移ルートに絞り込んでテストを行なうことが現実的です。絞り込みの基準には、重要な状態を経由するルート、重要な状態変数の参照・更新を行なうルートなどがあるでしょう。0スイッチテストで全体を浅く網羅し、その上で高次のNスイッチテストを特に重要と考えられるルートに限定して実施するとよいと思います。
100万前後の遷移ルートを網羅できるNスイッチテストのツールには次のサイトで紹介されている nswitch があります。
Ruby/Programming/nswitch
http://wikiwiki.jp/hastalavista/?Ruby%2FProgramming%2Fnswitch
このツールを用いれば100万前後の遷移ルートをある程度の時間内に網羅できる可能性があります。このツールはコマンドプロンプトで動作し、Rubyの配列形式でのインターフェースを採用していますから、Excel上からGUIで使えるようにする必要があります。
まとめると、次の手順になります。
1. テスト対象の状態遷移全体に0スイッチテストを実施し、バグ出しを行なう。
2. 高次元（例えば8など）のNスイッチテストのテストケース（数万から数十万）を作成し、その中から特に重要と考えられる数百～千件程度のテストケースに絞り込む。
3. 絞り込んだ重要な遷移ルートについてテストを実施する。
NスイッチのNを固定にしなければならないということもないような気がします。5スイッチテストと10スイッチテストの混在なども考えられます。テストケースの絞り込みの基準をどう決めるかがもっとも難しい点のようです。
一般的に言って、Ｎスイッチテストでは2スイッチテストまでの網羅が多いように感じますが、それだけの浅い網羅で見つかるバグは多くないと思われます。バグを見つけるには8スイッチテスト、つまり10の状態間の遷移は網羅したいと思います。もちろんそれだけの遷移ルートの数は状態が30前後だと数万から数十万と膨大になりますから、そのなかから特に重要な遷移ルートに絞り込んでテストを行なうことが現実的です。絞り込みの基準には、重要な状態を経由するルート、重要な状態変数の参照・更新を行なうルートなどがあるでしょう。0スイッチテストで全体を浅く網羅し、その上で高次のNスイッチテストを特に重要と考えられるルートに限定して実施するとよいと思います。
100万前後の遷移ルートを網羅できるNスイッチテストのツールには次のサイトで紹介されている nswitch があります。
Ruby/Programming/nswitch
http://wikiwiki.jp/hastalavista/?Ruby%2FProgramming%2Fnswitch
このツールを用いれば100万前後の遷移ルートをある程度の時間内に網羅できる可能性があります。このツールはコマンドプロンプトで動作し、Rubyの配列形式でのインターフェースを採用していますから、Excel上からGUIで使えるようにする必要があります。
まとめると、次の手順になります。
1. テスト対象の状態遷移全体に0スイッチテストを実施し、バグ出しを行なう。
2. 高次元（例えば8など）のNスイッチテストのテストケース（数万から数十万）を作成し、その中から特に重要と考えられる数百～千件程度のテストケースに絞り込む。
3. 絞り込んだ重要な遷移ルートについてテストを実施する。
NスイッチのNを固定にしなければならないということもないような気がします。5スイッチテストと10スイッチテストの混在なども考えられます。テストケースの絞り込みの基準をどう決めるかがもっとも難しい点のようです。
状態遷移を伴わない有効なイベント デジタル音楽プレーヤーの例
今回取り上げる例は有効なイベントで状態遷移を伴わないケースです。イベントで処理を行ないますが同じ状態のままで状態遷移を起こさない場合を取り上げてみます。取り上げる例はデジタル音楽プレーヤーです。プレーヤーには「次の曲」、「前の曲」というボタンがありますが、曲の選択が移動しますが状態は遷移しません。このプレーヤーには次のボタンが付いているものとします。
今回新しい点は状態を遷移しないイベントの扱いです。「次の曲」と「前の曲」のイベントは状態は同じで遷移しません。そのことを状態名の後に記号「@」を付加して表現するようにします。例えば制約５では「次の曲」と「前の曲」のイベント名の後に「@」が付加されています。このイベントによる状態遷移はないので、次以降の状態の列にはすべてダミーの「-」を記入するようにします。
このモデルで生成されたテストケースを次に示します。
今回新しい点は状態を遷移しないイベントの扱いです。「次の曲」と「前の曲」のイベントは状態は同じで遷移しません。そのことを状態名の後に記号「@」を付加して表現するようにします。例えば制約５では「次の曲」と「前の曲」のイベント名の後に「@」が付加されています。このイベントによる状態遷移はないので、次以降の状態の列にはすべてダミーの「-」を記入するようにします。
このモデルで生成されたテストケースを次に示します。
PictMaster 5.7.4J をリリースしました
PictMaster 5.7.4J をリリースしました。
今回のリリースでは、PictMasterの著作権表示を変更しています。
それ以外の変更はありません。すでに 5.7.3J を使用している方は改めてダウンロードする必要はありません。
PictMaster 5.7.4J は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
今回のリリースでは、PictMasterの著作権表示を変更しています。
それ以外の変更はありません。すでに 5.7.3J を使用している方は改めてダウンロードする必要はありません。
PictMaster 5.7.4J は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/