組み合わせテストを科学的に効率化する――手法とツール、品質保証のための道具:現場で使うためのオールペア法、直交表の基本(2)(1/3 ページ)
あらゆる条件を網羅したテストを実行することは現実的ではありません。しかし、職人技と勘、あるいは闇雲にテストツールに頼っても、科学的に品質を保証できません。最小のコストで品質を保証するための手法と、その考え方、制約がどのようなものかをじっくり見ていきましょう。
前回はソフトウエアテストの問題点とテストの基本的な考え方やその手法を紹介し、その中で「デシジョンテーブル」を例に挙げました。今回はデシジョンテーブルなどの「組み合わせテスト」を効率的に実施するための手法として、「オールペア法」や「直交表」の考え方を見ていきましょう。考え方や用語がやや難解に見えるかもしれませんが、テストケース自体はツールが生成してくれます。ツールを適切に使うための考え方は次回解説しますので、今回は「習うより慣れろ」の精神で、仕組みと雰囲気を理解することに注力してみましょう。
組み合わせテストとは
最初に組み合わせテストの定義と例を紹介します。組み合わせテストとは、多数の入力条件の値をいろいろと組み合わせて実施するテストです。しかし、全ての入力条件で値の組み合わせを考えると、膨大な数になり、全てをテストするのは現実的ではありません。
そこで実務における組み合わせテストでは、全ての組み合わせではなく、何らかの合理的な制限を設けて、組み合わせの一部のみをテストすることになります。この制限された組み合わせは全て網羅するテストになります。つまりこの制限による網羅が組み合わせテストにおける網羅基準の一つになり、ここが組み合わせテストの肝になります。
ここでは「実験計画法」で用いられる用語を使って説明していきます。今まで入力条件と呼んできたものを因子、その値を水準と呼ぶようにします。これは直交表などのテスト手法が実験計画法から出てきたことに由来する伝統的な言葉使いです。
*実験計画法 実験計画法は、効率のよい実験を行うために考案された統計的手法の一つです。一般的には、数学的な考え方で品質のムラを削減する目的で使われます。もともとの手法としては、ソフトウエアテストに限定せず、品質工学やサービス設計にも使われていますが、本稿で紹介する「実験計画法」は、この手法をソフトウエアテストのテストケース生成に応用したもので、入力の組み合わせや網羅性の度合いを数学的に保証するものといえます。
組み合わせテストの例
例として、前回の記事中においてデシジョンテーブルで記述したアミューズメントパークの入場料金を考えてみましょう。このパークでは子供と高齢者の年齢割引があり、女性に限っての曜日割引、高齢者に限っての県内在住者割引があります。このときの因子とその水準は表1のようになります。そして組み合わせテストでは、「男性、子供、県内」のような水準の組み合わせでテストをすることになります。
因子(入力条件) | 水準(入力条件の値) |
---|---|
性別 | 男性 |
女性 | |
その他 | |
年齢 | 子供 |
一般 | |
高齢者 | |
その他 | |
曜日 | 月曜日 |
月曜以外 | |
その他 | |
在住 | 県内 |
県外 | |
その他 |
このように入力条件が比較的多いものが対象であれば、組み合わせテストを適用しやすくなります。特に条件が多い制御系・組み込み系機器や、画面入力が多いWebシステムなどでは、組み合わせテストが必須になっているといえるでしょう。
オールペア法と直交表による組み合わせテストの準備
組み合わせテストでは、どのような手法やツールを使っても、最初は因子とその水準を見つけるところから始まります。次に、あり得ない組み合わせ=禁則組み合わせを発見して、テストケースの生成から除外します。今回はこれらの発見のコツの概要を紹介し、次回は実践的なコツを例も含めて紹介する予定です。
因子と水準の発見のコツ
実際の因子や水準の発見方法は、アミューズメントパークの例でいうと、まず条件となる名詞句を探し出し、性別や年齢などの因子を発見します。しかし、多くのテスト対象では、水準は比較的明示されていますが因子が暗黙的になっていることが多く、文字通り、因子を発見する必要があります。一方、有効系の水準(正常値)は明示されていますが無効系の水準(無効値、例外となる値)は示されていないことが多いので、これも発見する必要があります。
因子と水準の発見のコツは、因子や水準を(1)実装プログラムを想像して、(2)抜け漏れなく、(3)重なりなくデータを同値分割することです。
また(4)優先度の高い因子や水準を多めに発見することもコツです。他にも、例えば、(5)因子に水準を組み込んで融合したり、あるいは(6)分解したりすることで、因子数や水準数を調整します。コツについては、次回、紹介していきます。
禁則組み合わせの発見のコツ
前述した、「あり得ない組み合わせ=禁則組み合わせ」とは、物理的にまたは機能的に出現しない水準の組み合わせのことで、テストをしなくてもよい(できない)組み合わせです。先のアミューズメントパークの例は単純化しているため、禁則組み合わせは出現しませんでしたが、現実にはそれなりの数の禁則組み合わせが発生することがほとんどです。因子と水準が決まれば、一般的に禁則はテスト対象から自動的に見つかりますが、企画者がそもそも禁則組み合わせを当たり前だと思ってしまうことで、あえて示されていないことも多いので、注意してあらかじめきちんと発見しておく必要があります。
ここではプリンターを制御するシステムを例にして、禁則組み合わせを考えてみましょう。このプリンターではA4、A5、A6、A7サイズの用紙に印刷できます。ただし、両面印刷はA4とA5のみ、四辺フチなし印刷はA4とA7のみに対応しているとします。また、両面印刷と四辺フチなし印刷は同時に指定できます。
このとき、禁則となる組み合わせは表2のように「A5-片面-フチなし」から「A7-両面-フチあり」までの計7個です。
因子 | 水準 | 禁則組み合わせ | ||||||
---|---|---|---|---|---|---|---|---|
No.1 | No.2 | No.3 | No.4 | No.5 | No.6 | No.7 | ||
用紙 | A4 | |||||||
A5 | × | × | ||||||
A6 | × | × | × | |||||
A7 | × | × | ||||||
印刷 | 片面 | × | × | |||||
両面 | × | × | × | × | × | |||
四辺フチ | なし | × | × | × | × | × | ||
あり | × | × |
ここではプリンター向けの制御システムを例にしましたが、こうした組み合わせはWebアプリケーションやモバイルアプリ、あるいはIoT(Internet of Things:モノのインターネット)機器向けソフトウエアなどでも、同様に考えることができるものです。
このプリンターの例では、いくつもの禁則組み合わせがあります。一つ一つは単純なものですが、禁則が多いと抜け漏れや重なりが出やすくなります。
このため、禁則そのものを減らせるように、因子と水準の取り出し方を調整する必要があります。禁則を減らすコツは次回紹介する予定なので、ここでは雰囲気をつかんでいきましょう。
6561件を15件に! 網羅基準として「組み合わせの強さ」を決定する
本連載では何度も言及していますが、全ての組み合わせを考えるとテストケース数が膨大になるので、その全てをテストするのは現実的ではありません。例えば、1因子当たり3個の水準があるとき、因子が8個あれば、全組み合わせは3の8乗個=6561個にもなります。
そこで例えば、2個の因子の組(ペア)に注目して、全ての因子の組み合わせでなく、全てのペアの組み合わせにテストを制限します。ここではこの因子の組み合わせの個数を組み合わせの強さと呼びます。2個の因子を1組とするペアの場合は「強さ2」になります。
先のプリンターの例で言うと、「用紙」と「印刷」、「用紙」と「四辺フチ」、「印刷」と「四辺フチ」の3組のペアにすれば、組み合わせの数を減らすことができます(この例では因子が3個しかありませんので、それほど組み合わせ数は減少しません)。
強さを因子全部ではなく2や3に制限すると、テストケース数は大幅に減らすことができます。例えば、オールペア法と直交表ツールを使って、8因子3水準で強さ2と3の場合のテストケース数は、表3のようになります(後述しますが、オールペア法と直交表では組み合わせの数が若干異なります)。このテストケースの削減が、普通のエンジニアでも自動的に、そして数学的にできるところが、オールペア法や直交表を使うメリットです。
全組み合わせ | オールペア法 | 直交表 | |||
---|---|---|---|---|---|
強さ | 8 | 2 | 3 | 2 | 3 |
8因子3水準 | 6561 | 15 | 56 | 27 | 81 |
ただし、強さをいくつにするか(つまり網羅基準をどうするか)はプロダクトやプロジェクトに応じて決めることです。そして、この強さを合理的にいくつにするかが組み合わせテストの品質を担保する大きなポイントです。表3の例では、全ての組み合わせ=6561通りに対して、オールペア法で強さ2にすると15通りにまでテストケースを削減できますが、「削減してよいかどうか」は別問題です。この選定基準については次回で紹介しますが、基準を決定すれば組み合わせテストの数がおのずと明確に決まる、ということを覚えておいてください。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- いまさら聞けないTDD/BDD超入門(4):開発現場で保守性の高いTDD/BDDを実現するための3つのポイント――テストレベル/網羅性とは
開発現場でTDD/BDDを導入するためのポイントを大きく三つに分けて解説。テストレベルや網羅性、サイクルタイムについても紹介します。 - テストエビデンス取得自動化の秘技(前編):Selenium VBAを使って自動でブラウザーを操作してスクショをExcelに張り付けてみた
システム開発におけるソフトウェアテスト(結合テスト〜システムテスト)において重要視されるエビデンス(作業記録)。前後編の2回にわたって、エビデンスとしてスクリーンショットをキャプチャし、テスト仕様書や納品書に張り付けていく作業を自動化するためのVBA/マクロのテクニックを紹介する。前編はSelenium VBAのインストール方法と使い方、スクリーンショットを自動でExcelに張り付ける方法について。 - テスト自動化のROIを計算してみよう(1):テスト自動化の3つの目的とROIの必要性、定義
テスト自動化の導入理由や効果測定をROIという観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを解説する連載です。