効率のよい組み合わせテストを行なうには
このことは「少ないテストケース」と矛盾すると思われるかもしれません。この意味は、従来の経験と勘に頼る方法では網羅性の低いテストになってしまうが、組み合わせテスト技法を使用することで、全数組み合わせテストと比較してそれほど障害検出効果を落とすことなく、テストケース数を大幅に少なくできるという意味です。全数組み合わせと比較して「少ないテストケース」で済むということであり、組み合わせテスト技法を使わなかった場合と比較して、少ないテストケースで済むという訳ではありません。
組み合わせテスト技法を使えば、イコール「効率のよいテスト」ができるということにはなりません。網羅性の高いテストが行なえるようになることは確かですが、往々にしてテストケース数が多くなる場合があり得ます。そのままではテストの効率が落ちてしまいます。組み合わせテストを実施する上では、効率のよいテストが行なえるように次に示すいくつかの対策をとった方がよいでしょう。
1．組み合わせテスト技法がふさわしくないテスト対象を明確にする
テスト対象の性質に応じて組み合わせテストとは相性の悪いものがあります。状態の遷移が関係する、複雑な論理構造を持つテスト対象などがそれです。状態の遷移が関係する対象を組み合わせテストの対象としようとして、いたずらに制約指定が増えてしまい収拾がつかなくなってしまう場合などがそうです。組み合わせテストの対象外とするテスト対象を明確にする必要があります。
2．リスクに応じて組み合わせか列挙かを分ける
すべてを要因組み合わせとしようとするとテストケース数が膨大なものとなってしまいます。テスト対象のリスク分析を行ない、リスクが小さいテスト対象については要因組み合わせではなく、要因を単に列挙するだけの要因列挙テストとしましょう。要因列挙テストでは、パラメータのすべての値が少なくとも1回はテストされます。仕様変更のない機能については組み合わせを行なわず、列挙するだけで済ますといったことです。PictMasterのサブモデルの機能を使用することで、同じテストにおいて一部のパラメータは要因組み合わせで、残りのパラメータは要因列挙で、といった使い分けもできます。
3．取り上げる代表的なパラメータと値を明記する
よく取り上げることになるパラメータと値の一覧表を作成しておきましょう。テスト設計をする人によって取り上げるパラメータに違いがでることはよくありません。誰がテスト仕様書を作成しても同じレベルのテスト仕様書が作成できるようにする上で、こうした一覧表は役に立ちます。
4．エイリアス化が可能な代表的なパラメータと値を明記する
エイリアス化はテストケース数の増加を合理的に抑える上でとても役に立つものです。エイリアス化が可能な代表的なパラメータと値の一覧表を作成しておきましょう。テスト対象によってはエイリアス化は危険な場合があり得ます。特に新規機能などリスクの大きいテスト対象がそれです。こうした点に注意した上で使用することで効果的にテストを実施することができます。
5．代表的な制約の関係を明記する
レビューを実施してもテスト実施中に組み合わせできないテストケースに遭遇することがあります。制約の関係は機能仕様を良く理解していないと把握が難しいものです。代表的な制約の関係を明記した一覧表を作成しておきましょう。こうしておけば制約指定が間違ったテストケースが紛れ込むことをかなり防ぐことができます。
6．複雑なデータ設定が必要な機能についてデータ設定項目を明記する
機能を動作させるために複雑なデータ設定が必要な場合があります。テスト担当者のすべてがそうした機能に精通しているという訳ではないかもしれません。そうした場合に、必要なデータ設定項目の説明が明記された一覧表があれば、時間をかけずにテストを実施することができるようになります。
組み合わせテスト技法は数あるテスト技法のひとつに過ぎません。組み合わせテスト技法でテストの網羅性を高めることはできますが、そのままではテストの効率が向上する訳ではありません。これまで10人でやっていたテストが、組み合わせテスト技法を採用したことで8人で済むようになるというようなことはなかなか難しいと思います。
組み合わせテスト技法では、1つのテストケースに数多くのパラメータが組み合わされるようになるために、テストケース1件当たりのテスト実施時間が増加する傾向があります。ここで挙げた6つの対策を講じることで、組み合わせテスト技法採用によるテスト実施効率の低下を防ぐ効果が期待できます。
テスト中に実施できない組み合わせのテストケースが見つかった場合の対処法
このテストケースで灰色の部分はすでにテストを実施した部分です。No.17まできたところで、パラメータAの値が3の場合、パラメータBの値が3とは組み合わせできないことが分かったとします。この場合、制約表に正しい制約を追加することにします。
PictMasterに原型シートを追加し、テストケースのうちNo.1６までの正しいテストケースを原型シートに貼り付けます。
PictMasterの環境設定で、原型シートを使用するを指定し、テストケースを再度生成し直します。生成されたテストケースを以下に示します。
このテストケースで、No.17までの灰色の部分は原型シートで流用されたテストケースです。このうち、茶色で塗りつぶしたテストケースが、制約指定の追加で新しく生まれたテストケースです。この例のように、新しいテストケースが原型シートで流用したテストケースに混入する場合があります。テストケースが多い場合は、混入したテストケースがないか探すのが大変です。
新しいテストケースが原型シートで流用したテストケースに混入するのは、自動整形を指定しているためです。自動整形をしない設定で再度生成したテストケースを以下に示します。
このテストケースでは新しいテストケースが原型シートで流用したテストケースに混入していません。
自動整形を使用しないでテストケースを再生成したため、原型シートで流用した実施済みのテストケースの部分に新しいテストケースが混入することがありません。これから実施する必要のある未実施のテストケースは自動整形が行なわれていませんが、特に問題となることはないでしょう。
探索的テスト（テストとデバッグの違い）
テストはバグを見つける作業ですが、デバッグはテストで見つかったバグの原因を特定し、修正し、確認する作業です。
テストはテスト漏れを防ぐために網羅的に行なう必要があり、ほとんどの場合、テストドキュメントを使用するスクリプトテストを行なうことになります。一方、デバッグはバグがどういう条件で発生するかが分かっています。デバッグで行う作業は、バグ発生条件の絞り込みによる障害発生原因の特定と障害部分の修正と修正後の動作確認です。
デバッグで行うバグ発生条件の絞り込みによる障害発生原因の特定には、探索的テストが使われます。ある条件でテストを実施し、その結果をによって次のテスト条件を決めていきます。これの繰り返しで障害発生原因の特定が行なわれることになります。
ソフトウェアテストにおける探索的テストはテスト技法の１つではありますが、他のテスト技法と比べてよく使われているとは言い難いと思います。探索的テストでは基本的にテストドキュメントを用意しません。大まかな実施方針を明記したドキュメントを作成することはありますが、基本的にはテスト担当者のアドリブによるテストです。
テスト担当者が狙いを定めた個所についてテストを実施し、その結果によって次にどのようなテストを実施するかを決めていく。これが探索的テストの手順です。しかしながら、テストの実施結果に応じて次のテスト内容を決めると言っても、まずほとんどの場合、テスト実施結果は正常であるでしょう。これがたびたび異常であるならばテスト対象の品質が相当程度に低いと言わざるを得ません。これはテスト実施以前の問題です。
一般的なテストがテストドキュメントを作成し、できるだけ網羅度の高いテストを行なおうとしているのに対して、探索的テストにおける網羅度はかなり低いものにならざるを得ません。何しろテストドキュメントがないのですから、テストはテスト担当者の勘に依存したものにならざるを得ないからです。
探索的テストが威力を発揮するのはデバッグにおいてです。すでにバグが発生することが分かっている場合に、障害発生原因の特定を行なう際に威力を発揮します。テストの実施結果に応じて次のテスト内容を決めるという探索的テストの手法が、障害発生原因の特定に非常に役に立つことになります。
テストにおいても、見つかったバグがどのような条件で発生するのかを絞り込む作業を行なう場合があります。これは広い意味でのデバッグ作業と言えます。
テスト担当者がデバッグ作業まで行なう必要があるのかという疑問を持たれる人がいるかもしれません。しかしながら、テストで見つかったバグについては、すでにデバッグを行なう環境が整っており、バグ発生条件の絞り込み作業はそれほど時間がかかる訳ではないという事情があります。
したがって、テスト担当者が少しの時間を割いて探索的テストにより、バグ発生条件の絞り込みを行なうことは、ソフト開発者との円満な関係を維持する上で有益であり、ひいてはテスト担当者自身の利益にもつながるものだと言うことができます。
パラメータの重みづけ - 拡張サブモデル
PictMasterはパラメータの重みづけの機能を備えています。希望する複数のパラメータについて、通常のパラメータ組み合わせ数とは異なるパラメータ組み合わせ数を指定できる機能です。この機能は拡張サブモデルの機能を使用して実現しています。PICTが備えているサブモデルの機能を使用すると生成されるテストケース数が膨大となってしまいますが、PictMasterの拡張サブモデルの機能では、PICTのサブモデルに比べて生成されるテストケース数が大幅に少なくて済みます。
例えば、次に示すモデルのようにパラメータごとの値の数が 6,6,4,4,4,4,2,2,2,2,2,2,2,2 である場合、拡張サブモデルで値の数が4つのパラメータ C,D,E,F のみパラメータ組み合わせ数を通常の2ではなく、例えば3とすることができます。
この条件で生成されたテストケース数は79件です。一方、PICTのサブモデルの機能を使用した場合は438件となってしまいます。PictMasterの拡張サブモデルの機能では、最初にパラメータ組み合わせ数を1とし、拡張サブモデルで指定した希望するパラメータのみPICTのサブモデルの機能でパラメータ組み合わせ数を3として一度テストケースを生成し、生成されたテストケースを原型シートに貼り付けて、パラメータ組み合わせ数を通常の2として再度テストケースの生成を行なっています。最初に環境設定のパラメータ組み合わせ数に1を指定して生成することでテストケース数が膨大とならないようにしているのです。
生成されたテストケースにフィルタをかけた結果を次に示します。
パラメータ CとDは値が1のみです。このとき、拡張サブモデルで指定した残りのパラメータ EとFは、そのすべての値が現れています。このことから、拡張サブモデルで指定したパラメータ C,D,E,F は3パラメータ間の組み合わせが網羅されていることが分かります。これ以外の組み合わせでも3パラメータ間の組み合わせが網羅されていることは確認済みです。
拡張サブモデルを使用した場合のテストケース数は79件でした。これに対して環境設定の組み合わせるパラメータ数に3を指定した場合のテストケース数は193件でした。このケースでは拡張サブモデルの機能を使用することで、テストケース数を半分以下に抑えることができたことになります。
拡張サブモデルによるパラメータの重みづけは、値の数が多すぎず、少な過ぎないパラメータに適用した場合、テストケース低減の効果が最も大きくなります。これに対して値の数が多いパラメータに適用した場合は効果がないことがあります。また値の数が少ないパラメータでは、もともと3パラメータ間の組み合わせ網羅率が100%に近い場合が多いので、パラメータの重みづけを行なうメリットがあまりありません。
パラメータの重みづけを行なう場合は、対象パラメータの値の数に注目したほうがよいでしょう。
機能が動作しない条件の組み合わせテスト
組み合わせテストにおいては機能が動作する条件でのテスト以外に、機能が動作しない条件での組み合わせテストも実施する必要があります。
機能が動作しない条件での組み合わせテストでは、機能が動作しない条件（無効値）が１つのテストケースに１つだけ存在するようにしなければなりません。１つのテストケースに２つ以上の無効値が含まれていると、最初に評価された無効値だけのテストとなり、２つ目以降の無効値のテストが行われなくなるからです。
PICTには無効値を指定する修飾記号（~）を無効値の前に付加することで無効値が１つのテストケースに１つだけ含まれるようにすることができます。
例えば次のモデルにあるように、a4, b4, c4 の３つが無効値とした場合、
生成されるテストケースは次の通りとなります。
このテストケースのうち、無効値を１つも含まないテストケース（塗りつぶしを行なっていない）は、通常の機能が動作する組み合わせテストで実施するため、機能が動作しない条件の組み合わせテストでは不要です。そこで無効値を含むテストケースだけを残してあとは削除します。
この例ではテストケースが２９件から１３件となりました。この例で示したように、PICTの無効値指定を使用することで、機能が動作しない条件での組み合わせテストのテストケースを簡単に作成することができます。