組み合わせテストを開発現場で使いこなすには？――考え方のヒントと5つのコツ：現場で使うためのオールペア法、直交表の基本（3）（3/3 ページ）

オールペア法や直交表は組み合わせテストの品質を一定に保ち、テストケースを合理的に削減できる利点を持ちます。しかし、ツールでやみくもにテストケースを削減してはいけません。そこには勘も経験則もコツも必要です。筆者がコツを伝授します。

[五味弘，OKI（沖電気工業）]

コツその4：「機能要求」の中に隠れている因子・水準を見つけるコツ

　組み合わせテストの基本に戻って、因子や水準の発見方法について考えてみます。前回も少し触れたように、ユーザーや企画者からヒアリングを行い、そこから得られた機能要求から名詞句を探すことで、組み合わせテストの因子候補や水準候補を見つけます。

　「因子と水準」は「抽象と具象」の関係がありますので、どちらかを見つければ、片一方はこの関係から見つけることもできます。

　例えば、「20歳代」という名詞（＝水準）を見つければ、これを抽象化して、「年齢」という因子を見つけることができます。逆に「20歳代」を具象化して「23歳」を見つければ、「20歳代」という因子と「23歳」という水準を見つけることができます。

　また、機能要求の中で水準は比較的明示されていますが、それを抽象化したものである因子については明確化されていないことが少なくありません。例えば、「子供料金と高齢者料金は一般の料金と比較して安く設定する」という要求からは、「子供」「高齢者」「一般」といった名詞から水準となる候補が見つかりますが、その因子である「年齢」という名詞は書かれていませんから、発見する必要があります。

　加えて、「有効系の水準」（正常値）は明示されていますが、「無効系の水準」（無効値、例外となる値）は示されていないことが多く、これも発見する必要があります。例外的な操作は、ユーザーや企画者から見ると当たり前のように排除されるものと思われていることから、機能要求の中には示されていないことが多い点に注意してください。

入力画面のサンプルから因子と水準を見つけてみると？

　これらの注意を踏まえて、簡単な例で考えてみましょう。ここでは、Webアプリケーションの入力画面から、因子と水準を発見する方法を見ていきます。

　通常、テストでは画面単位で疎通確認のテストをすることが多く、このときは画面入力がテストの入力になります。つまり、画面にある「ラジオボタン」や「チェックボックス」「テキストフィールド」、その他のボタンなどがテストの因子になります。押されたボタンやチェックしたボックス、入力した値を同値分割したものが水準です。

　以下ではWebフォームでの因子と水準の見つけ方の例を示します。ここでは、図1のような画面があるとします。

図1　入場料計算の入力画面

　この入力画面の場合は、「性別」のラジオボタンが因子になり、その水準は「男性」「女性」「押されていない」になります。「年齢」は入場料金に関係する年代で分割したものが有効系の水準になります。それに加えて「未入力」「数値以外」などの無効系水準があります。

　複数選択できるチェックボックスの場合は、設定数によっては全組み合わせをテストするのが難しくなります。このときもオールペア法や直交表を用いて、ボタンの状態数を減少させることができます。

　ここでは非常にシンプルなサンプルを示しましたが、実際に皆さんが開発するシステムの画面入力はもっと複雑でしょう。Webフォームの場合はバックエンドのデータベースに格納されているデータも因子になります。また1個のトランザクションで複数の画面で入力がありますので、因子はもっと多岐にわたります。

　このときの因子や水準の発見のコツは （1）入力のグループ化があります。独立性の高い入力グループでテストを分割することにより、組み合わせの数を「掛け算」でなく「足し算」にします。ただし、因子グループの分割の項目で説明した通り、独立性の保証は実装も含めて考慮する必要があります。

　二つ目のコツは（2）入力のパターン化です。例えば、統計的に見て入力パターンを発見します。そして、組み合わせテストの一部を「パターン化した入力セット」だけで行うことにより、全体のテストケース数を少なくできます。

　これも問題となるのは、「パターン化した入力セット以外」でバグが発現するケースを見逃すことにつながり、一般的にパターン化は困難になります。統計的操作だけでなく、探索的手法で入力パターンを見つけることもコツになります。

コツその5：因子と水準の粒度設定のコツ：想像してごらん、このプログラムの実装を

　想像力が試されるコツもあります。まずは簡単な例から考えてみましょう。

　「三角形の三辺の長さ」を引数として与えて、それがどのような三角形であるかを判定するプログラムを考えてみます。このプログラムの因子や水準の粒度を検討してみましょう。

　この三角形判定プログラムの実装が「三辺の長さを配列に格納して繰り返し文の中で長さチェックをする実装」であると想像したときの因子と水準を表9に示します。

表9　繰り返し文の実装での、三角形の判定問題における因子と水準の一部　
この場合の考え方：三辺の長さのチェックは「繰り返し文」で実装されていると想像して、二辺の3つの組を、一回のテストで行う。ポールフェンスバグ（繰り返し終了の基準をポールとフェンスで間違うようなバグ）などをチェックするテストは別途行うことにする

　では、どちらかというと普通の実装と考えられる「辺の長さの引数を別々の3個の変数に格納して、二辺の三つの組み合わせで別々に長さのチェックをしている実装」と想像してみると、因子と水準はどうなるでしょうか？

　このときの辺の長さの判定プログラムに対するテストでは、第一辺と第二辺、第二辺と第三辺、第三辺と第一辺の三つの組で同値分割して、因子や水準を発見します。また辺の長さがゼロである無効系水準による同値分割も、おのおのの辺に対して1個ずつ、三辺で合計3個の水準にします。この因子と水準を表10に示します。

表10　別々のチェック実装での、三角形の判定問題の因子と水準の一部
この場合の考え方：引数が3個と少ないので、二辺の長さの等値比較は、3個のペアで別々に実装されていると想像。引数が3個と少ないので、ゼロチェックは別々に実装されていると想像

　このように実装を想像して、同値分割をどれくらい妥当にできるかがエンジニアの腕の見せ所です。

無効系水準は要注意

　前述したように、バグは「無効系水準」（無効値、例外となる入力データの値）の中に多く現れます。このため、テストでは無効系水準を考慮することが重要です。逆に、「組み合わせテストは無効系水準を発見するところから始まる」と言ってもいいでしょう。

　無効系水準を発見するコツは、有効系水準の発見のコツに加え、ソースコードの実装を想像し、エラーチェックがどのようになっているかを予測して、無効系水準をどれくらい同値分割できるかです。エラーチェックは有効系とは違う実装をされていることが多く、有効系のときより因子や水準の粒度を細かくすることも、コツになります。

　つまり、ブラックボックステストだからと言って、ソースコードを全く気にしなくていいということではありません。逆にソースコードが見えないからこそ、「ソースコードを想像」して、テストをする必要があります。つまり、ブラックボックステストはソースコードを単にブラックボックスとしてテストをする、というものではなく、ソースコードがブラックボックスになっている状態でもソースコードが見えているかのようにテストをしなくてはいけないという非常に困難な発見的テストなのです。このように、組み合わせテストのときは、ソースコードを想像して、その因子や水準を発見する必要があり、特に無効系水準の発見は想像力が試されます。

　この想像をさらに進行させると、例えば「プログラマーがＡ君なら、ソースコードの実装はこのようにしているだろうから、因子と水準を意地悪に設定して、バグを見つけ出してやろう」というところまで行き着くでしょう。この例は極端に聞こえるかも知れませんが、実際の開発現場でのコツはこのようなものが多いのです。

　ここまでで紹介してきたコツ以外のものとしては、過去に多くバグが出ている箇所を重点的にテストするために、その部分で因子や水準を多めに発見しておくという経験的なコツや、プロダクト／プロジェクトの重要性による重み付けをする（因子や水準の量を調整する）などの政治的・経済的なコツもあります。

その他のコツ

　大規模なシステムを対象に因子や水準を発見するときのコツもあります。

　段階的に詳細化（具象化）していく、というコツです。いきなり詳細化して因子や水準を発見するのではなく、抽象度の高い因子から段階的に詳細化していきます。

　Webシステムのような画面インターフェースを中心としたシステムでは、因子や水準の発見を（1）機能仕様書中心に見つけていくことと、（2）画面の構成や遷移が書かれている仕様書を中心に見つけていくことの両者からバランスよく発見していくようにしましょう。

　また、「ツールによって生成されたテストケースを並べ替えておく」という、作業効率全体を改善するコツもあります。

　ツールによって生成されたテストケースは、テストの入力だけを扱いますから、出力（結果、期待値）の記述は手動です。そのとき、因子ごとに水準で並べ替えておくと、出力の値を記述するときに便利になります。Excelシートなどの「ソート（並べ替え）」機能で簡単にできますが、マクロを作っておくのもよいでしょう。テストケース数削減などとは関係がありませんが、最終的に出力の値を記述する際に作業がしやすくなります。

　ここまでで、オールペア法や直交表を利用した組み合わせテストを実施する際の、現場目線での調整のヒントを紹介してきました。本稿冒頭にも書きましたが、原則は「実装に素直に」です。今回示したコツは、どうしても必要な場合に、どこをどう調整するのが適切かを判断する材料として考えておきましょう。いろいろなコツを紹介してきましたが、使い過ぎには注意してください。

　次回は、オールペア法・直交表でよく出現する「強さ」の設定方法（＝テストの網羅性の設定指針）について、考え方を見ていきます。

著者プロフィール

五味弘（ごみひろし）

OKI（沖電気工業） シニアスペシャリスト、エバンジェリスト。博士（工学）。

ソフトウエアの開発支援・教育に従事。電子情報振興協会（JEITA）専門委員会の委員長や情報処理振興機構（IPA/SEC）などの委員多数。三重大学などの非常勤講師も務める。エンタープライズ系と組み込み系におけるソフトウエア開発の知見融合が関心事。

共著書に『定量的品質予測のススメ』（オーム社、2008年）、『プログラミング言語論』（コロナ社、2008年）などがある。

連載バックナンバー