今さら聞けないシステムテスト【第3回】：KeyConductors
テストケースの設計方法を知らない方に向けて「ブラックボックステスト」「ホワイトボックステスト」に関する設計技法について説明したい。
テストケースを設計するための具体的な方法論
第1回ではシステムテストの基本的な考え方について、第2回ではシステムテストのプロセスについてお伝えしました。しかし、テストプロセスの中で、テストケースを設計するための具体的な方法論についてご存じないという方もいらっしゃるのではないでしょうか。
そこで、本稿では、具体的な「テストの設計技法」についてお伝えいたします。
【具体的なテストの設計・技法】
1.ブラックボックステスト設計技法
2.ホワイトボックステスト設計技法
3.経験ベースのテスト設計技法
1. ブラックボックステスト設計技法
ブラックボックステスト設計技法は、テスト対象物を「中身の見えない箱」として定義し、ソフトウェアの仕様書や設計書の分析に基づき、テストを設計する手法です。
このブラックボックステストの代表的な設計技法である「同値分割法」と「境界値分析」についてご紹介します。
■同値分割法
同値分割法とは、システムの入出力テストを行う際、同じ処理をするグループ（同値クラス）に入力値を分割し、その中の代表的な値をパラメータとして採用する方法です。
例えば、以下のようなパスワードの入力フォームのテストを実施する場合、入力文字数が、パスワードポリシーで規定されている4文字以上12文字以下のケースだけではなく、1文字や15文字など、考えられる全ての文字数のテストを行う必要があります。
しかし、実際には入力値となりうる全てのパラメータをチェックすることは、時間的な都合を考えると現実的ではありません。そこで、同値分割法を採用することで、想定される入力値が数多く存在するようなケースであっても、期待される結果をグループ分けし、それぞれのグループで代表的なテスト条件のみを実施することで、効率的にテストを進めることができます。
■境界値分析
境界値分析とは、境界値の前後の値に関して入力パラメータを設定し、テストを設計する手法です。
例えば、上記のようなパスワードの入力フォームの場合「4文字以上12文字以下で入力してください」といったような入力条件が設定されていることが多々あります。この場合、境界値となっている4文字や12文字の周辺となる値では、適切なハンドリングができない欠陥が潜在している危険性があることから、境界値でテストをすることは有効なテストといえます。
上記の設計技法を使用した場合のテストケースが以下となります。
2. ホワイトボックステスト設計技法
ホワイトボックステスト設計技法は、テスト対象物を「中身の見える箱」として定義し、データベースやソースコードの分析に基づき、アプリケーションの実装に即した挙動をテストできるように、テスト条件やテストケース、テストデータを導き出し、テストを設計する手法です。
このホワイトボックステストの代表的な設計技法である「ステートメントテスト」及び「ブランチテスト」についてご紹介します。
■ステートメントテスト
ソフトウェアを構成する個々のプログラムコードのなかには、特定の条件を満たすか、特定のイベントが発生しないと呼び出されない関数やメソッドが存在します。しかしながら、アプリケーション内で定義されている全ての関数やメソッドを全て呼び出して挙動を確認しなければ、十分な品質を担保することはできません。
ステートメントテストとは、アプリケーション内のソースコードを分析し、対象のコード内にて定義されている全ての関数やメソッドを実行させるようにテストケース群を作成し、網羅的に挙動を確認する手法です。
この時、テストケース群が対象のコード内で実行可能なステートメントの何パーセントを網羅したかを示す指標をステートメントカバレッジと呼びます。
■ブランチテスト
プログラムコードの中には、IF文やSWITCH文などによって条件分岐処理が定義されていることがあります。しかし、各プログラムコード内で定義されている全ての関数やメソッドを呼び出して挙動を確認しなければ、十分な品質を担保することはできません。
ブランチテストとは、各プログラムコード内のソースコードを分析し、対象の各プログラムコード内にて定義されている条件分岐処理（複合条件は除く）を全てチェックできるようにテストケース群を作成し、網羅的に挙動を確認する手法です。
この時、テストケース群がアプリケーション内で定義されている分岐処理の何パーセントを網羅したかを示す指標をブランチカバレッジと呼びます。
上記の設計技法を使用した場合のテストケースが以下となります。
ブランチテストでは、各ソースコード内で定義されている条件分岐処理を原則として全てチェックするため、結果的に実行可能な関数もしくはメソッドを全て呼び出すことになります。このため、ブランチカバレッジを網羅しているということは、ステートメントカバレッジも同じように満たしていることになります。
3. 経験ベースのテスト設計技法
経験ベースのテスト設計技法は、アプリケーションの構造や仕様を分析するのではなく、テスト担当者のスキルや直感、経験則などに沿ってテスト設計を行う方法です。
この経験ベースのテストの代表的な設計技法である「エラー推測」及び「探索的テスト」についてご紹介します。
■エラー推測
エラー推測とは、テスト対象物と同種または類似したソフトウェアやテクノロジーに関するシステム検証を対応してきたテスト担当者が、これまでの経験をベースにテスト対象物を分析し、欠陥が発生しそうなポイントをリストアップしてテストケースを実装する手法です。
■探索的テスト
探索的テストとは、テスト設計をする際に、冒頭で網羅的なテストケースを策定するのではなく、最初にごく少数のテストポイントを策定し、そこでのテスト結果を見ながら、順次テストケースを策定してテストを進めていく手法です。
こちらの技法は、先述したホワイトボックテスト設計技法やブラックボックステスト設計技法を補完する目的で利用されるケースが多いです。
4. まとめ
テストの設計技法に関するさまざまな方法論をご紹介いたしましたが、実際に皆さまがテストを設計する際、どの技法を用いるのが良いのか分からないという方もいらっしゃると思います。そこで、それぞれのテスト設計技法の長所と短所を以下にまとめました。
実際のソフトウェア開発の現場では、特定のテスト設計技法だけを実施するということはほとんどありません。テスト対象物の製品特性やそれぞれのテスト設計技法の特長をうまく組み合わせ、最適なコストと時間で効率的なテストができるよう努めていくことが重要です。
本連載の最終回となる次回は、第三者検証の重要性とテストアウトソーシングの潮流についてご説明いたします。
Copyright © ITmedia, Inc. All Rights Reserved.