状態遷移のテストケース自動生成の見直し － 少し複雑な状態遷移を例に

前回はNスイッチテストとは違うアプローチでやってみましたが、その後、検討を加えたところ、そのやり方では別の問題が起きることが分かりました。前回の方法では、Nスイッチテストがすべての状態についてN+1回の状態遷移を網羅するのに対して、始状態から終状態までの全ての状態遷移を網羅しようとするものでした。しかし、この方法で始状態から終状態までの全ての状態遷移を網羅しようとすると、状態数がごく少ない場合は問題ありませんが、状態数が多くなるとテストケース数が指数関数的に増加し、現実的なテストではなくなってしまうという本質的な問題があります。テストの効果よりもテストにかかるコストが簡単に上回ってしまうことになります。

プログラムの制御パステストですべてのパスを網羅しようとする場合に比較して、状態遷移の全ての遷移ルートを網羅するには、はるかに多くのテストケースが必要となります。その大きな理由が状態遷移では、前に通った状態に戻る遷移ルートが多くあるということです。これがあるために少し複雑な状態遷移ですべての遷移ルートを網羅しようとするとテストケース数が膨大なものとなります。１つのテストケースでいくつもの状態遷移を行なわせる必要があるため、テストの作業量が多くなりすぎます。

ということで、、始状態から終状態までの全ての状態遷移を網羅しようとする方法はとらないことにしました。PictMasterで状態遷移のテストケースを自動生成させる方法を考えたとき、最初に浮かんだ方法は始状態から終状態までの遷移を複数回通るテストケースを生成する方法でした。今から考えると、この方法では少し複雑な状態遷移でもテスト作業量が膨大なものとなってしまいます。そのため、この方法ではうまくいきません。始状態から終状態までの遷移を１回だけ通るテストケースを生成する方法は前回考えた方法でした。しかし、この方法でもやや複雑な状態遷移ではテスト作業量が多すぎることになります。

テストケースが増えすぎる理由は、前に通った状態に戻る遷移ルートの存在にあります。この遷移ルートを網羅しようとするとテストケースが増加します。ここで考え方を変えて、前に通った状態に戻る遷移ルートは網羅しないようにしてみます。その代り、テストケース上では次にどの状態に遷移するかを明示するようにします。

見直した方法では、テストケースの最上部には始状態から終状態までの状態名が並ぶ形式になります。そしてテストケースの各セルには、その列の状態で有効なイベント名を記入します。その状態でそのイベントが発生した場合、次に遷移する状態は何らかのイベント名が記入されている列（状態）になります。こうした形式で終状態まで状態が遷移することを表現します。この表現形式は、2008年頃に考案した形式と同じです。違う点は始状態から終状態までを１回だけ通る遷移に限定する点です。

前に通った状態に戻る遷移については、イベント名の記述に続けて次の遷移先の状態番号をを「→ｎ」の形式で記述するようにします。

状態遷移のないイベントについては、イベント名の記述に続けて状態が遷移しないことを示す「@」を付加することにします。

この方法を少し複雑な状態遷移に適用してみましょう。取り上げる状態遷移図は過去記事「少し複雑な状態遷移のテストケースを生成する」で使った次の状態遷移図です。

8個の状態があり、すべての状態遷移の回数は23回です。この状態遷移図でも小さな部類に入るでしょう。この状態遷移図からテストケースを生成するPictMasterのモデルを次に示します。制約表の記入にあたっては、CTL+e を押してウインドウを分割すると記入しやすくなります。

この状態遷移では始状態である s0 でのイベントが２つあります。もしこれが１つだけの状態遷移の場合は、制約１にダミーの「-」を制約条件とし、終状態の s0' までダミーの「-」を制約対象としてすべて記入する必要があります。これは、PICTが値が１つしかないパラメータの場合に、その値を制約条件に指定するとエラーにしてしまうため、これを回避するために必要となるダミーのテストケースです。この場合はパラメータ s0 にダミーの値「-」を追加する必要があります。

制約の指定方法はその状態で有効なイベントを制約条件として記入し、そのイベントによる遷移先の状態で有効となるイベントを制約対象としてすべて記入します。その間に無関係な状態がある場合はダミーの値「-」を記入しておきます。続けて制約対象として記入されたイベントは、１つづつ別の制約条件として取り出して記入します。後は同じ手順の繰り返しです。この手順は非常に単純なルールです。複雑な点は何もありません。

例えば、制約１では状態 s0 で有効なイベント e2 が制約条件に指定されています。このイベントによる遷移先が状態 s1です。その制約の状態 s1 のセルには、その状態で有効な３つのイベントが制約対象として記入されています。その状態の行を右に行くと、制約３～５に先ほどの３つのイベントが１つづつ制約条件として指定されています。後はそれぞれのイベントについて、遷移先の状態のセルにその状態で有効なイベント、例えば制約３では状態 s3 で有効な3つのイベントが記入されています。その間の状態 s2 は無関係なのでダミーの「-」を記入しておきます。後は同じように記入を繰り返すだけです。セル内に記入されたイベントが前に通った状態に戻るものだけの場合は、それから先の状態への遷移は網羅しないのでそれ以降から終状態まではダミーの「-」を記入します。終状態の s0' への遷移はダミーのイベント「end」で終わることにします。

組み合わせるパラメータ数には2を指定します。制約指定に「強い制約」を行なっているので今回のモデルでは組み合わせるパラメータ数は2で充分です。それ以上大きくしても生成されるテストケース数は増えません。このモデルの生成結果を次に示します。

テストケースは21件となりました。最上部に始状態から終状態が並ぶ形になります。各状態で有効なイベントがセル内に記入されています。そのイベントが発生すると、テストケースを右に進んで最初のイベントが記入されている状態に遷移することになります。前に状態に戻る遷移は「e2→s1」などのように表現されます。これはイベント e2 が発生すると状態 s1 に遷移する、という意味です。状態遷移のないイベントは今回の例にはありません。別途取り上げることにします。

このテストケースで太字で表現されているイベントは、このテストケースで他と重複していないユニークな遷移イベントです。これによる状態遷移の回数は33回です。単純に状態遷移図から数えた状態遷移の回数は23回ですから、状態遷移の組み合わせがある程度網羅されていることが分かります。

8個の状態があり、すべての状態遷移の回数が23回の場合のテストケースが21件というのは多すぎず少なすぎもしない程度のようです。注意が必要なのが、前の状態に戻る遷移である「e2→s1」などの扱いです。テストケースでは遷移先の状態は明記されていますが、そこから先はどのように遷移させるかまでは明記されていません。これはそこまで網羅させてしまうとテスト作業量が多くなりすぎるためですが、どこに遷移させるかはテスト実施前にあらかじめ決めておいた方がよいかもしれません。セル内に追記しておくことができます。あるいはまたアドリブで怪しそうな遷移ルートを網羅してみてもよいでしょう。

状態遷移のNスイッチテストに対する違和感 Nスイッチテストとは違うアプローチでやってみる

Nスイッチテストについてはこれまで何度も取り上げてきましたが、いつも少なからぬ違和感がありました。それは何かというと、Nスイッチテストに対する基本的な考え方にあります。Nスイッチテストでは、すべての状態についてその状態から任意の回数の遷移を網羅するという手法を採用しています。この方法ですと、ある状態がどの状態を経由してその状態に至ったかが不明であり、そこから2回や3回遷移させたところで大したことは分からないのではないかという漠然とした違和感でした。本当にやりたいのは、始状態から始めて終状態まで遷移させてみることです。こういう考え方はNスイッチテストにはありません。高々２～３回遷移させたところで何かが分かるという可能性はかなり低いのではないでしょうか。始状態から初めて終状態までのすべての遷移ルートを連続して遷移させて初めて何かが分かるのではないかと思います。

ということで今回はNスイッチテストとは違うアプローチでやってみることにしてみました。遷移は始状態からのみ始まります。そこからは遷移可能なすべてのルートを網羅したテストケースが生成されます。この考え方は2009年のJaSSTで発表しましたがその方法とはまったく違います。終状態での停止は現状ではできていませんが可能だと思います。それに一度終状態に戻ってからまた別状態に遷移することだって可能にしたいものです。ほとんどの場合、始状態と終状態は同じ状態です。

Nスイッチテストとの考え方の違いは、最初の状態を始状態だけに限定するということです。始状態から遷移可能なすべての状態への遷移ルートを網羅していきます。これは制御パステストの考え方と似ています。制御パステストの判定文を状態に置き換えれば同じような考え方ができます。Nスイッチテストの考え方は制御パステストに当てはめるとある分岐分から他の分岐分へのルートをすべて網羅するという考え方です。しかしこの考え方ですべての判定文のルートが網羅されたテストができたとは言えないでしょう。それぞれのテストケースに連続性がないからです。

新しい考え方はこのテストケースの連続性を確保することを目的としています。始状態から終状態までの全ての可能な遷移ルートを一度で網羅することを目指しています。ここでは例として過去記事で使用した次の状態遷移図を用いてみます。

この状態遷移図をもとに始状態からの状態遷移ルートを網羅するPictMasterのモデルを次に示します。

第１状態は始状態の s0 のみです。後はこの s0 を出発点として他の全ての状態遷移ルートを網羅するように制約表で指定します。制約の指定方法は基本的にはNスイッチでの方法と似ていますが、制約条件となる状態がNスイッチのようにすべての状態であるとは限らない点です。1つ前の遷移で遷移先となった状態が次の制約条件の状態となります。その他はNスイッチでの方法と同じです。

パラメータの値にダミーの「-」が付加されているのは次の理由からです。この状態遷移でパラメータ s0 が１つの遷移先しかないので値が１つとなっています。１つしかない値を制約条件に指定するとPICTのエラーとなるので、ここでは便宜上ダミーの値を付加しているのです。

この方法で第１状態から第５状態まで、４回の状態遷移を繰り返したテストケースを次に示します。

このテストケースでは状態 s0 から４回の状態遷移で遷移可能な全てのルートが網羅されています。テストケース数はダミーを除いた１２件となりました。この方法を大きな状態遷移に適用したらどうなるか興味深いところですが、かなりのテストケースになることは間違いありません。ですが、状態遷移テストそのものは他のテストとは異なり、１つ１つのテスト時間が短くて済むという特徴があります。また例えば状態が３０ある場合は第３０状態まで網羅しなければならないかというとそんなことはありません。もっと少ない状態（パラメータ）数ですべて網羅できます。

もう少しこの方法を調べてみるだけの価値がありそうです。

※ 6月26日追記　この方法では少し複雑な状態遷移でも生成されるテストケースでの作業量が大きくなりすぎる問題のあることが分かりました。詳細は6月25日の記事を参照してください。

３パラメータ間の組み合わせテストを実施するならテスト工程の終盤に行なうべし

徹底的なテストが必要な場合、３パラメータ間の組み合わせテストを行なうことになるでしょう。問題は３パラメータ間の組み合わせテストをいつ実施するかです。テスト工程の最初から行なう方がよいか、最後に行なう方がよいか、判断に迷うところです。この問題の参考になる過去記事があります。「テストが進むにつれて２つの要因の組合せで発生する障害が多くを占める」がそれです。テストの序盤では１つの要因だけで発生する障害が大部分を占めますが、テストが進むにつれて２つ以上の要因の組み合わせで発生する障害が多くなるという記事です。

それでは「テストが進むにつれて２つ以上の要因の組み合わせで発生する障害が多くなる」のは何が理由でしょうか。それはおそらく次の理由からだと思われます。テストの序盤ではソフトウェアの品質は高くはありません。ということは少しテストを行なうと障害が見つかることを意味します。この障害は複数の要因の組み合わせで発生するような込み入ったものではなく、たかだか１つの要因だけで発生する障害が大部分を占めることになります。テストを進めていってソフトウェアの品質が向上すると、１つの要因だけで発生する障害の多くはすでに発見され、今度は２つ以上の要因の組み合わせで発生する障害が増えてくることになります。

２つ以上の要因の組み合わせで発生する障害を検出するためには、１つの要因だけで発生する障害が取り除かれていなければなりません。このことは３つの要因の組み合わせで発生する障害についてもあてはまります。３つの要因の組み合わせで発生する障害を検出するためには、２つまでの要因の組み合わせで発生する障害が取り除かれている必要があります。

３パラメータ間の組み合わせテストを実施する場合は、２つまでの要因の組み合わせで発生する障害があらかた取り除かれているテスト工程の終盤で実施したほうが最も効率的に行なえることになります。テストの終盤で実施しても、３つの要因の組み合わせで発生する障害そのものの絶対数がかなり少ないですから、テスト終盤で検出される障害数が増えるといった心配は無用です。逆にテスト終盤になって１つの要因で発生する障害が多くを占めているようだとソフトウェアの品質に問題がありそうです。このあたりのことについては定量的な解析が必要だと思われます。

どのようなソフトウェアでも、テストが進むにつれて１つの要因で発生する障害の割合が減少し、２つ以上の要因の組み合わせで発生する障害の割合が増えるというのはまだ仮説の段階です。ですがかなり信頼のおける考え方だと思います。これとは別に、ソフトウェアの種類によって、テスト工程全体での２つ以上の要因の組み合わせで発生する障害の割合にはいくらかの違いがありそうです。この点についても今後の解明が待たれるところです。

３パラメータ間の組み合わせテストを実施するならPictMasterの「希望するカバレッジを指定して生成」機能の利用も検討してほしいところです。80%程度の3因子間網羅率を指定してテストケースを生成することで、扱うモデルにもよりますが3因子間網羅率100%の場合の1/4程度のテストケースに抑えることができます。これはテストのコストとテスト漏れのリスクとの兼ね合いで決めることになりますが、検討してみるだけの価値はあると思います。

直交表とPairwise法の併用 PictMasterを制約のある直交表に適用することの是非

これまでにPictMasterを制約のある直交表に適用して2因子間網羅を100%にする方法を何度か紹介してきましたが、いろいろ試した結果、私の中では結論はでました。直交表とPairwise法の併用するメリットは確かにありますが、それは制約がとても単純な場合に限られるということです。

直交表に複雑な制約を盛り込もうとすると、かかる手間が急激に増大し、その割には3因子間網羅が大きく低下するという結果となるからです。複雑な制約では、制約対象に2つ以上の値を指定する場合があります。この場合、PictMasterで扱おうとするには、原型シートに貼り付ける直交表に制約を盛り込んでおく必要があるのですが、制約対象に2つ以上の値を指定する際に、どの値をどのセルに指定すれば最善の結果（3因子間網羅が最も高い）となるかが分かりません。その結果、3因子間網羅が期待したほど高くなくなります。

また、複雑な制約指定があると直交表にその制約指定を反映させる作業がかなり煩雑になってしまうという問題もあります。この作業で間違いがあると、PICTは直交表をそのまま読み込まなくなるため、生成結果の3因子間網羅が大きく低下してしまうことになります。

制約指定がごく単純なものであればPictMasterを利用するメリットはあります。例えば、制約対象の値が1種類だけの場合です。この場合は制約対象のセルにどの値を記入したらいいか迷う必要はありません。こういう場合はPictMasterを利用して3因子間網羅率を100%にすることが便利に行えます。そうでない場合はPictMasterを利用するメリットはあまりないと言わざるを得ません。

直交表の作成にPictMasterを利用する ３因子間網羅率が非常に高い直交表に制約を適用

直交表に制約を適用する際にPictMasterを利用して２因子間網羅率100%を確保する方法については、過去記事「直交表の作成にPictMasterを利用する　制約による２因子網羅率低下の問題を解決」で紹介しました。その記事では、３因子間網羅率が低い直交表では問題ないが、元々３因子間網羅率が非常に高い直交表では、PictMasterを利用した結果として３因子間網羅率が低下する問題があると述べました。今回は実際に３因子間網羅率が非常に高い直交表に制約を適用し、２因子間網羅率100%を確保するためにPictMasterを利用した場合、どの程度３因子間網羅率が低下するかを調べてみましょう。

使用する直交表はネット上から探してきます。「Orthogonal Array Finder」という希望する直交表を探してくれる便利なサイトから、6^2 3^4 で検索し、最初にリストされる6水準が2因子、3水準が4因子、2水準が9因子の直交表をコピーしてきてExcelで読み込ませます。

なるべく３因子間網羅率が高くなるように、6水準の因子は2つめを削除して1つのみとします。また2水準は最後の因子を削除して8つとします。そしてパラメータ名として1行目に A、B、C、… M を追記します。こうして手を加えた直交表を表１に示します。

次にこの直交表の３因子間網羅率を測定します。PictMasterのワークシートの右隣りにワークシートを設け、そこに表１の直交表を貼り付けます。次にPictMasterのパラメータ欄と値の並び欄にパラメータ名と水準名を次のように記入します。

ここで、パラメータAの水準が1つ多い7水準になっているのは、PictMasterでできるだけ正確な３因子間網羅率を測定するために必要なことです。PICTは原型シートのモデルとモデルファイルのモデルの値の数に違いがあると原型シートの内容をそのまますべて読み取る動作をします。違いがないと原型シートを読み込んでいって２因子間網羅率が100%になった時点でそれ以上読み込もうとしなくなります。こうなると実際の３因子間網羅率より低い値になってしまいます。それを避けるために一番値の数の多い因子の水準を+1しておきます。

PictMasterの環境設定で、組み合わせるパラメータに2、「原型シートを使用」にチェックを入れ、「統計情報を表示」と「カバレッジを表示」にチェックを入れ、「デフォルトのシードで生成」を指定して生成を行ないます。このとき「自動整形を行なう」のチェックを外しておきます。そうすると次の統計情報が表示されます。

　テストケース数：39件
　3-wayカバレッジ：89.0%

テストケース数が36件から39件に3件増加しているのは6水準を7水準にしたためです。実際の水準数より増えているので実際の３因子間網羅率はより高い90%程度だと思われます。

次にPictMasterで制約指定を行ないます。制約指定としてはなるべく直交表に大きな影響がある方がよいので次の制約指定を行なうことにします。

続いてPictMasterの原型シートに貼り付けた直交表に制約表で指定した制約を盛り込みます。Excelのフィルタ機能を使ってパラメータAの値が 0～4の場合に、パラメータB～Dの値をすべて0に書き換えます。こうして制約を盛り込んだ原型シートを表２に示します。

次にPictMasterのパラメータAの値の並びから6を削除し、7水準から6水準に戻しておきます。これは原型シートに大きな変更を加えたために、原型シートのモデルとモデルファイルのモデルの値の数が同じでも、原型シートの内容すべてをPICTが読み込んでも２因子間網羅率が100%にならないためです。こうして再度生成を行なうと制約を盛り込んだ次の統計情報が表示されます。

　テストケース数：41件
　3-wayカバレッジ：86.8%

元の直交表が36件ですから5件増えていることになります。この5件は２因子間網羅率が100%になるために追加されたテストケースです。このテストケースを表３に示します。

制約がないときの３因子間網羅率が89.0%に対して、制約を盛り込んだ時の３因子間網羅率が86.8%ですからそれほど３因子間網羅率は低下していないことになります。今回のケースでは直交表とPictMasterの併用は行なうだけの価値があると言えるでしょう。