eコマースの注文者情報入力画面のテストにデシジョンテーブルを使用する

Webサイトでの通信販売などで商品を注文するとき、ほとんどの場合、何段階かの入力画面を遷移していって、最後に注文確定の画面となるようになっています。これは、入力項目が多いため、いくつかの入力画面に分けたほうが注文者にとって分かりやすいからだと思われます。こうしたeコマースの商品購入での入力画面のテストに最適なテスト技法はなんでしょうか？

１つには状態遷移テストが最適だと思われるかもしれません。確かに入力画面の遷移があるのでその遷移のテストには役立つでしょう。しかし、一般の状態遷移と異なり、状態遷移のイベントは「次に進む」と「前に戻る」の他に、入力内容に不備がある場合にそのことを指摘するエラー画面への遷移が多数存在します。これは「次に進む」のボタンをクリックしたときに、入力内容のチェックが行なわれ、エラー内容に応じて多種類のエラー画面遷移します。

このように入力内容のエラーの種別の違いで、１つのイベントによって、遷移先が多数存在する場合は、状態遷移テストよりも、デシジョンテーブルテスト（DT)が最適だと思われます。デシジョンテーブルであれば、多数の入力項目のエラーの有無に応じたアクション（状態遷移を意味する）を定義することができます。また、入力項目間に依存関係がある場合もDTのルールで定義することができます。そしてユーザが「次へ進む」ボタンをクリックした瞬間に各入力項目の正常性チェックが同時に行なわれる点が、DTの特性とマッチしています。つまり、入力する項目の順番には依存しないということです。

そこで今回は、eコマースの注文者情報入力画面のテストにデシジョンテーブルを使用する場合を取り上げてみます。といっても、すべての入力項目を対象にするとPICTの処理能力を超えてしまうので、ここでは必須入力項目だけをテスト対象とします。

注文者情報入力画面はあるメーカの例を取り上げてみました。この例では、注文者が個人か法人かによって画面内容が変化します。個人の場合は生年月日は必須ですが、法人の場合は必須ではありません。この変化は、注文者２つのボタンのいずれかをクリックしたときに変化します。この二つの場合の注文者情報入力画面を示します。

図１．個人の注文者情報入力画面

図２．法人の注文者情報入力画面
このDTのモデルを以下に示します。このモデルでは、パラメータの値を正常入力、異常入力、入力なし、の３つとしています。実際には入力項目ごとに異常入力の内容は異なりますし、異常とする入力値の形態にはかなり多数の異なる形態が考えられます。しかし、その違いまでモデルに含めるとモデルが多くなりすぎるので、３つに抽象化しています。具体的な異常入力値とそれに対応したエラー表示内容については、別の欄で記述したほうがよいでしょう。制約表で、入力内容が正常でない時点でエラーメッセージ表示に遷移するものとし、組み合わせの爆発を防いでいます。これがないと生成されるルールは3000を越えてしまいます。

 

図３．注文者情報入力画面のDTモデル
以上のモデルを作成した後、MTGの環境設定で、組み合わせるパラメータ数に、パラメータの個数である８を指定し、生成を行ないます。この際、１回だけの生成でかまいません。何回生成しても生成される件数は同じです。
生成結果を以下に示します。

表１．DTの組み合わせ結果

生成されたDTは２８件となりました。このテストケースでは、異常入力の内容については規定していないので、別途、異常入力のセルを具体的な異常入力値に置き換える必要があります。その結果としてテストケース数が大幅に増えるかもしれませんが、作業自体はテストケースのセルに具体値を追加していくことなので、それほど難しいことではないでしょう。

異常入力値によってアクション（期待する結果）が異なる場合があるので、結果内容欄も個別の内容を追加する必要があるかもしれません。

PICTでDTのテストケースを作成しようとする場合は、パラメータの個数は１０個以内に抑えたほうが処理時間の関係でよいと思います。

組み合わせテストはテスト全体の20％にすぎない。

テスト対象の性質によってふさわしいテスト技法がことなります。MTGは主に組み合わせテスト用のツールですが、わたしたちの現場では、組み合わせテストはテスト対象全体の20％程度にすぎません。例えば、状態の遷移が対象のテストでは、状態遷移表が適用するテスト技法になります。またWebアプリケーションの画面入力のテストでは、デシジョンテーブルが最適なテスト技法となります。

では組み合わせテストはどのような対象に使用するのかと言えば、組み合わせるパラメータによって異なるプログラムのブロックが動作する場合です。なかばグレーボックスの知識もないと効率的な組み合わせテストがおこなえません。具体的には、各機能の正常ルートに対して組み合わせテストを適用しています。機能の組み合わせで、あらかじめ組み合わせても意味がないパラメータが分かっていれば、テストの効率を上げることができます。

組み合わせテストは非常に有効なテスト技法の1つですが、テストケース数が多くなりがちという欠点があります。最低でも最も多くの値を持つ2つのパラメータが持つ値の数を掛けた数のテストケースが必要となります。仮に値が10個あるパラメータを2つ含むモデルでは、最低でも100個のテストケースとなります。それゆえ、組み合わせテストはむやみに使用する訳にはいきません。テスト工数が不足するからです。そのため、私たちのチームでは主に正常ルートを対象として組み合わせテストを適用しています。

そしてもう1つ、組み合わせテスト自体がテスト工数のかかるテストだという理由もあります。多数のパラメータの組み合わせを変えながらテストするには組み合わせの変更にあわせて設定も変えなければなりません。時間がかかるものです。

ということで組み合わせテストはそれほど多くはありません。最も多いのは、組み合わせを行なわず、各パラメータを単に列挙する、要因列挙テストです。このテストを行なうことで、全てのパラメータで機能が正常に動作することが確認できます。さらに列挙することも不要と考えられるケースでは、一部のパラメータに限ってテストする要因限定テストも行なっています。いすれのテストでも基本的に同値分割・境界値分析を使用します。

任意のパラメータのみ組み合わせる数を３にする（サブモデルの使い方）

MTGでは、サブモデル指定で最大２つのサブモデルを指定できます。サブモデルは指定した任意の複数のパラメータについて各パラメータ間の組み合わせ数に２以外の値を指定できる機能です。サブモデル機能を適切に使用することで特に組み合わせ上、重要と考えられるいくつかのパラメータについて選択的に３パラメータ間の組み合わせとすることで全パラメータを３パラメータの組合せとするよりも少ないテストケース数でメリハリのついたテストケースを生成することができます。

現在のMTGでは、サブモデルは２つまでしか指定できませんが、実験的にこの制限を取り払ったMTGを作成し、４個以上のパラメータについて組み合わせ数を３にすることができるか試してみました。

例として、パラメータがAからFまでの６個あり、それぞれ異なる値を持つモデルを対象としてみます。（図１）

図１．モデルとサブモデルの例

サブモデル指定で、パラメータA,B,C,Dについて組み合わせ数を３と指定しています。同じ行に記入するときはセミコロン（;）が区切り記号となり、１行にいくつでもサブモデルを記入することができます。
図１で示すように、複数のパラメータは１つづつカスケード状に互いに同じ値を１つ含むように記述することが重要です。なぜこうするかというと、単純にパラメータを列挙して組み合わせ数に３を設定して生成すると、それらのパラメータは、それ以外のパラメータと４パラメータの組み合わせが生成されてしまい、テストケース数が多くなりすぎるためです。

このモデルの生成結果を表１に示します。

表１．モデルの生成結果

この例ではテストケース数は３６となりました。パラメータの組み合わせ数を３とした場合は５３でした（表２）。この例では重要なパラメータだけサブモデルで選択的に組み合わせ数を３とすることで、全てのパラメータの組み合わせ数を３とした場合よりもかなりテストケース数を減らすことができました。

表２．全てのパラメータの組み合わせ数を３とした場合

では、サブモデルを使って生成したテストケースは本当に指定したパラメータの組み合わせ数が３となっているでしょうか。それを確認するには、生成結果のパラメータにExcelのフィルタをかけ、サブモデルで指定したパラメータのうち、任意の２つのパラメータについて特定の値だけを表示します。その状態で、サブモデルで指定した以外の残りのパラメータについて、すべての値が出現しているかを確認します。

以下の例では、パラメータAとパラメータDのみをフィルタにかけて値1のみ表示した結果です（表３）。この結果を見ると、サブモデルで指定したパラメータA,B,C,Dのうち、フィルタで特定の値を指定したパラメータAとDを除く、残りのパラメータB,Cについては、全ての値が出現していることが分かります。

表３．パラメータAとDにフィルタをかけた生成結果

このようにサブモデルを有効に使用するためには、サブモデルで指定したパラメータの値が少ないことが条件です。ON/OFFなどの２値を取るような値の少ないパラメータに適用すると、全てのパラメータについて組み合わせるパラメータ数を３とするよりも、テストケース数を大幅に少なくすることができます。

なお、今回の例のように各パラメータをカスケード状に独立したパラメータとして２パラメータ間のサブモデルに指定すると、なぜ任意のパラメータの組み合わせ数を３とすることができるのか。またその場合、サブモデルで指定しなかったパラメータとは組み合わせ数が２となるのか、その理由は今のところよく分りません。

サブモデルをセミコロン（;）で区切り、いくつでもサブモデルを記入できるようにしたバージョンは次のバージョンでリリースする予定です。

2009年05月28日の記事内容の訂正とおわび

2009年05月28日の記事「制約指定で意図しない制約が生まれる!? 」の末尾の部分で、「直交表で制約をサポートした場合も同じ結果になると思います。」とありますが、この記述は読者の方に誤解を抱かせる記述ですので、この部分を削除しました。

直交表ベースのHAYST法では、この記述は当てはまりません。矛盾したパラメータEの値にはNULLが割り当てられ、パラメータＡとパラメータＢの値が１と２、２と２の組み合わせがNULLとの組み合わせとして網羅される結果となります。

この点はPICTにはないHAYST法の長所です。なお、少なからぬ方々に誤解の念を抱かせる結果になったことに対して、HAYST法の開発者の方々、とりわけ秋山さんにお詫び申し上げます。

制約にコメント欄がほしい！

制約が多くなってくると各制約の間の関係を把握することが難しくなってきます。制約式で表現するより、制約表がはるかに分かりやすいのですが、それでも複雑な制約が多くなってくると関係把握が難しくなる場合があります。

わたしのチームの一員から、各制約にコメント欄がほしい、という要望が出されました。Excelには簡単なコメント機能がありますが、それではなく、各コメントが一覧できるコメント行を設けてほしいというものでした。行や列の幅を変えるのは簡単に自由にカスタマイズ可能ですが、新しい行を追加するとなると、プログラムに手を入れなければならず、できれば避けたいところです。

もともとExcelには「セルを結合」の機能がありますので、コメント行は「制約表」のタイトルの行として、制約のセルの上にコメント欄を設けることにしました。

少し行の高さが高くなって不恰好ですが、普段は通常の高さ（12ポイント）にしておけばよいでしょう。コメント欄のセルの文字は、MS Pゴシックにすると狭いセル内に多くの文字がかけます。Excelはカスタマイズがいろいろできるので、この例のように必要に応じてカスタマイズしてみてはいかがでしょうか。