この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
お米の国新潟県長岡市からこんにちは。事業開発部の高野です。
前回のエントリ「複数条件の組み合わせによるテストケース数爆発と戦うPairwise(ペアワイズ)法とそれを支えるツール「PICT」 ｜ DevelopersIO」は、ありがたいことにかなり多くの方にご覧いただけたようです。
このエントリについて、はてなブックマーク、SNSなどで意見を見てみると、下記のようなものが多くありました。
- ペアワイズ法ではなぜテストケースを削っても大丈夫なのか
- 全網羅テストをしないと不安だ
本エントリでは、この質問に答えるとともに、その背景となる「組み合わせテスト技法」について、調べた内容を紹介します。
TL;DR;
- ペアワイズ法の有効性は「ほとんどの不具合が2つの要因の相互作用によるものだった」と言う経験則から導かれている
- したがって、ペアワイズ法で生成したテストケースでは十分ではない
- スキルと経験によりテストケースを調整する必要がある
目次
ペアワイズ法の有効性
まず、ペアワイズ法がなぜテストケース数を削減するのに有効な手段なのかについて説明します。と言っても、Pairwise Testingに全て書かれているので、それを引用しましょう。
Pairwise (a.k.a. all-pairs) testing is an effective test case generation technique that is based on the observation that most faults are caused by interactions of at most two factors.
(太字部分は引用者による装飾)
大雑把に訳すと、次のようになります。
ペアワイズ法は、ほとんどの不具合は多くとも2つの因子の相互作用によって引き起こされていると言う観測結果に基づいた、効果的なテストケースを生成するテクニックだ。
(引用者註：因子とは振る舞いに影響を与える一つの条件のこと)
ここで注目すべきポイントはほとんどの不具合と2つの因子の相互作用です。つまり、ペアワイズ法を使うことで大体の不具合の原因となる条件の組み合わせが列挙できると言うことです。したがって、ペアワイズ法で生成したテストケースだけでは、7〜9割程度の不具合を見つけることができると思えば良いでしょう（このことは、下記の資料の10ページに具体的な数字とともに記載されています）。
- NASAにおけるデータベースの欠陥329個を分析したところ、
全体の93％がシングルモードまたはダブルモードの設定の組合せで欠陥が発生- Webブラウザではトリプルモードで95％の欠陥を検出（ダブルモードでは76%）
- シングルモード：その機能（因子）自体で欠陥が発生
- ダブルモード：2つの機能（因子）で欠陥が発生
- トリプルモード：3つの機能（因子）で欠陥が発生
裏を返せば「ペアワイズ法で生成されたテストケースでは、1〜2割の不具合を取りこぼす」可能性があるわけです。よって、ペアワイズ法「だけ」では、必要十分なテストケースを用意することはできないのです。
組み合わせのテストケース作成手順
それでは、足りないテストケースをどうやって用意したら良いでしょうか？それには、手作業によるテストケースの検証が(現在のところ)欠かせません。
私はペアワイズ法を使ったテストケースを、次の手順で作成しています。
- テストに必要な条件(因子)と取りうる値(水準)を見出す
- 因子と水準を使ってペアワイズ法でテストケースを生成する
- テストケースの過不足を仕様を元にスキルと経験であぶり出し調整する
1. テストに必要な条件(因子)と取りうる値(水準)を見出す
前回のエントリでは、次のようなテスト条件と取りうる値を使いました。
- 割引種別
- %引き
- 円引き
- クーポン適用対象商品
- 指定あり
- 指定なし
- クーポン適用対象カテゴリ
- 指定あり
- 指定なし
- ショッピングカートの注文明細の商品
- クーポン適用対象
- クーポン適用対象外
- ショッピングカートの注文明細のカテゴリ
- クーポン適用対象
- クーポン適用対象外
- 指定なし
ペアワイズ法をはじめとした「組合せテスト技法」の用語では、この条件を因子、取りうる値を水準と呼ぶそうです。例えば、因子「割引種別」は水準%引き、円引きを持っています。
テストケースを検討する際、最初に行うのはテスト対象の処理などについて、このような因子と水準を見出すことです。特定の関数をテストするのであれば、引数の一つ一つが因子、その値の範囲が水準です。
水準を考える際、上記の「割引種別」のような因子であれば、取りうる値が決まっているので簡単ですが、数値の因子だと少し厄介です。全ての数値をテストすることなど到底不可能ですので、テストに必要な最小限の水準を見出さねばなりません。
こんな時に役に立つのが同値分割や境界値分析といったテスト技法です。詳しくは下記のようなテスト技法に関するWeb記事、書籍を参照ください。
- 第4回 ブラックボックステスト：ソフトウェアテスト基本テクニック｜gihyo.jp … 技術評論社
- はじめて学ぶソフトウェアのテスト技法 | リー・コープランド, 宗 雅彦 |本 | 通販 | Amazon
2. 因子と水準を使ってペアワイズ法でテストケースを生成する
因子と水準が明らかになったら、次にペアワイズ法を用いてテストケースを生成します。この手順については、先日のエントリでやり方を説明したので詳細は省きます。
3. テストケースの過不足を仕様を元にスキルと経験であぶり出し調整する
2.の手順により生成されたテストケースはまだ不完全です。おそらく「テスト不能な組み合わせ」、「足りない組み合わせ」があるはずです。ここから先は、そういった過不足を見つけ出し、1つ1つ潰していきます。
この作業には仕様の理解が欠かせません。先日のエントリでは
「クーポン適用対象商品」が
指定なしなら、カートの「商品」が任意であるべき
ということを、仕様から読み取って調整していました。その内容次第では、PICTなどのツールでも対応可能ですし、スプレッドシートなどで手作業でやってもいいでしょう。
また、作成したテストケースについては、第三者の視点で確認(レビュー)してもらうことも重要です。複数人の目で見ることで、見落としの確率を下げることができます(0にはできませんが)。
なお、テストケースを調整している作業では、追加、削除したテストケースに「なぜ追加、削除したのか」コメントを残しておくと、後日参加したメンバーに意図を伝えることができるのでおすすめです。
こうやって作成したテストケースであれば、もう「全網羅でないと不安」というようなことはほぼ無くなるでしょう。それでもまだ不安があるなら、不安に感じる条件についてテストケースを増やしましょう。
まとめ
一口にテストといっても、非常に奥深い分野で一つの方法が万能であるということはありません(俗に「銀の弾丸はない」っていうやつです)。
しかし我々はテストをしないわけにはいきません。機能や運用、アーキテクチャと同じくらい、テスト設計についても学び、効率的なテストをやっていきましょうね！
2
