テスト設計技法

ブラックボックステスト設計技法

ブラックボックステスト設計技法は、テスト対象物を「中身の見えない箱」として定義し、ソフトウェアの仕様書や設計書の分析に基づき、テストを設計する手法です。
次に、ブラックボックステストの代表的な設計技法である「同値分割法」と「境界値分析」についてご紹介します。

同値分割法

同値分割法とは、システムの入出力テストを行う際、同じ処理をするグループ(同値クラス)に入力値を分割し、その中の代表的な値をパラメータとして採用する方法です。

例えば、以下（図1）のようなパスワードの入力フォームのテストを実施する場合、入力文字数が、パスワードポリシーで規定されている4文字以上12文字以下のケースだけではなく、1文字や15文字等、考えられるすべての文字数のテストを行う必要があります。

しかし、実際には、入力値となりうる全てのパラメータをチェックすることは、時間的な都合を考えると現実的ではありません。そこで、同値分割法を採用することで、想定される入力値が数多く存在するようなケースであっても、期待される結果をグループ分けし、それぞれのグループで代表的なテスト条件のみを実施することで、効率的にテストを進めることができます。

下記のようなパスワード入力フォームの場合

なお、本ケースでは、解説をわかりやすくするため、あくまでも文字数のみにフォーカスしてテストケースを設計しております。(以下、同条件)

境界値分析

境界値分析とは、境界値の前後の値に関して入力パラメータを設定し、テストを設計する手法です。
例えば、図1のようなパスワードの入力フォームの場合、「4文字以上12文字以下で入力してください」といったような入力条件が設定されていることが多々あります。この場合、境界値となっている4文字や12文字の周辺となる値では、適切なハンドリングができない欠陥が潜在している危険性があることから、境界値でテストをすることは有効なテストといえます。

境界値テスト事例

ブラックボックステストケース

ホワイトボックステスト設計技法

ホワイトボックステスト設計技法は、テスト対象物を「中身の見える箱」として定義し、データベースやソースコードの分析に基づき、アプリケーションの実装に即した挙動をテストできるように、テスト条件やテストケース、テストデータを導き出し、テストを設計する手法です。
次に、ホワイトボックステストの代表的な設計技法である「ステートメントテスト」及び「ブランチテスト」についてご紹介します。

ステートメントテスト

ソフトウェアを構成する個々のプログラムコードの中には、特定の条件を満たすか、特定のイベントが発生しないと呼び出されない関数やメソッドが存在します。しかしながら、アプリケーション内で定義されている全ての関数やメソッドを全て呼び出して挙動を確認しなければ、十分な品質を担保することはできません。
ステートメントテストとは、アプリケーション内のソースコードを分析し、対象のコード内にて定義されている全ての関数やメソッドを実行させるようにテストケース群を作成し、網羅的に挙動を確認する手法です。
この時、テストケース群が対象のコード内で実行可能なステートメントの何パーセントを網羅したかを示す指標をステートメントカバレッジと呼びます。

ステートメントテスト事例：パスワード入力フォームの場合

ブランチテスト

プログラムコードの中には、IF文やSWITCH文などによって条件分岐処理が定義されていることがあります。しかし、各プログラムコード内で定義されている全ての関数やメソッドを呼び出して挙動を確認しなければ、十分な品質を担保することはできません。
ブランチテストとは、各プログラムコード内のソースコードを分析し、対象の各プログラムコード内にて定義されている条件分岐処理(複合条件は除く)を全てチェックできるようにテストケース群を作成し、網羅的に挙動を確認できるようにする手法です。
この時、テストケース群がアプリケーション内で定義されている分岐処理の何パーセントを網羅したかを示す指標をブランチカバレッジと呼びます。

ブランチテスト事例：パスワード入力フォームの場合

ブランチテストでは、各ソースコード内で定義されている条件分岐処理を原則として全てチェックするため、結果的に実行な可能な関数もしくはメソッドを全て呼び出すことになります。このため、ブランチカバレッジを網羅しているということは、ステートメントカバレッジも同じように満たしていることになります。

経験ベースのテスト設計技法

経験ベースのテスト設計技法は、アプリケーションの構造や仕様を分析するのではなく、テスト担当者のスキルや直感、経験則などを使ってテスト設計を行う方法です。
次に、経験ベースのテストの代表的な設計技法である「エラー推測」及び「探索的テスト」についてご紹介します。

エラー推測

エラー推測とは、テスト対象物と同種または類似したソフトウェアやテクノロジーに関するシステム検証を対応してきたテスト担当者が、これまでの経験をベースにテスト対象物を分析し、欠陥が発生しそうなポイントをリストアップしてテストケースを実装する手法です。

探索的テスト

探索的テストとは、テスト設計をする際に、冒頭で網羅的なテストケースを策定するのではなく、最初にごく少数のテストポイントを策定しておき、そこでのテスト結果を見ながら、順次テストケースを策定してテストを進めていく手法です。
こちらの技法は、先述したホワイトボックテスト設計技法やブラックボックステスト設計技法を補完する目的で利用される場合が多いです。

まとめ

このように、テストの設計技法に関する様々な方法論をご紹介いたしましたが、実際に皆様がテストを設計する際には、どの技法を用いるのが良いのかわからないという方もいらっしゃると思います。 そこで、それぞれのテスト設計技法の長所と短所をまとめてみました。

実際のソフトウェア開発の現場では、特定のテスト設計技法だけを実施するということはほとんどありません。テスト対象物の製品特性やそれぞれのテスト設計技法の特長をうまく組み合わせ、最適なコストと時間で効率的なテストができるよう努めていくことが重要です。