アドベントカレンダー１１日目
こんにちは。リリカルです。
先ほど、全力で書いた本記事がまっさらな状態に消えていることが判明しました。なんということでしょう…
「もっと勉強しろよ」という神様のお達しですね、わかります。
さてテスト設計について、いよいよ本記事でまとめです。
前回は、テスト設計のタスクとして他にもテストすべきところがないか考える（発想を広げる）というについて触れました。
もう一つ、テストしすぎているところがないか考える（収束させる）というところについて考えていきます。
全数テストは不可能
テスト技術者のFoundation Levelシラバスで紹介されているテストの７原則の一つに「全数テストは不可能」というものがあります。
全数テストが不可能である理由は様々ありますが、わかりやすいのは「因子同士の組み合わせを考慮する場合」「入力値のパターン数が非常に多い場合」などです。
組み合わせを考慮する場合
例えば、WebアプリケーションなどではOSとブラウザの組み合わせをテストすることがあると思います。特定のOSとブラウザの組み合わせでのみ再現される不具合があったりするからです。しかし、ここにブラウザのバージョン、Javaのバージョンなどの因子が組み合わされた場合はどうなるでしょうか？
２つの因子の組み合わせによる動作を保証するのはそこまで大変ではないことが多いです。例えば5種類のOSに対して5種類のブラウザの組み合わせの動作を保証するのであれば、5 * 5 で25パターンをテストすれば網羅できます。これが3つ、4つになると、この25パターンにさらにパターン数を乗算していくわけですから、完全に組み合わせの動作を保証するのはかかるコストから考えても非現実的になっていきます。
そこで、そもそも全数テストをしようという発想をやめます。これは、３因子以上の組み合わせに起因する不具合が比較的少なく、２因子間の組み合わせを保証することである程度の品質を確保できるという考えによります。
All Pair法とか直交表などの組み合わせテスト技法を用いることで、例えば「２因子間の組み合わせの動作は網羅しよう」といったテスト目的に沿ってテストケース数を絞り込むわけです。
入力値のパターンが非常に多い場合
これも同様に、全数テストは非現実的です。例えば1億までの数値を入力できるアプリケーションにおいて、0〜1億の値をすべて入れてテストするでしょうか？普通はしないと思います。なのでこの場合も、「全数をテストせずに、できるだけ広い範囲をテストでカバーする」「バグが出やすそうなところを狙ってテストする」といった目的を設定してテストを絞り込みます。「この値を入れて問題ないなら、（ロジック的に）この値を入れても問題ないはずだ」というふうに考えて、全数をテストせずに有効と思われる値のみをテストしていくことができます。（同値分割）また、「境界になっている値を入力してみよう」としてバグの出やすそうなところを狙ってテストすることができます。（境界値分析）
同値分割と境界値分析はよく知られたテスト技法ですが、他にも色々な技法があります。テストの目的や対象によって、使用する技法は選択する必要があります。
テスト設計３行まとめ
それではまとめです。テスト設計は、３行でまとめると以下のようになります。
テスト分析のアウトプットをもとに他にテストすべきところがないか洗い出しを行い、実施するテストを絞り込むこと。また、これを高位レベルテストケースとしてまとめること。
ここでいう高位レベルテストケースは、具体的な（実行レベルの）入力値や予測結果を使わないテストケースであり、テスト実装の元ネタとなります。
おわりに
長くなりましたが、これでテスト分析・設計の３行まとめシリーズは終了です。
色々書き足りない部分はありますが、次回はWACATE2016夏の必須予習項目であるテスト技術者 Foundation Levelシラバスについてまとめていきます。
次回もお楽しみに。
