グレーボックステスト

ブラックボックステスターは、テスト対象のアプリケーションの内部構造を認識していないが、ホワイトボックステスターはアプリケーションの内部構造を見ることができる。グレーボックステスターは、内部構造を部分的に知っている。これには、内部データ構造の文書や使用されるアルゴリズムの情報が含まれる[3]。

グレーボックステスターは、テストケースを定義するために、アプリケーションのハイレベルな説明文書と、詳細文書の両方を必要とする[4]。

グレーボックステストは、ブラックボックステストのストレートな手法を採用し、ホワイトボックステストのコードターゲットシステムと組み合わせるため有益である。

グレーボックステストは、アサーションメソッドを使用してプログラムをテストする前にすべての条件を提示するため、要件テストケースの生成に基づいている。要件仕様言語は、要件を理解し、その正確性を簡単に検証できるようにするために使用される[5]。

オブジェクト指向ソフトウェアは、主にオブジェクトで構成されている。ここで、オブジェクトとは、実行可能コードやデータを持つ単一の分割できないユニットのことである。グレーボックステストを行うアプリケーションに必要なするために必要ないくつかの仮定を以下に示す。

• メソッドのアクティブ化[6]
• テスト対象クラス（CUT）の状態レポート。
• レポートテストは、テスト対象クラスに固有。 [5]

• アーキテクチャモデル
• 統一モデリング言語-UML設計モデル
• 有限ステートマシン-ステートモデル[7] [8]

Cem Kanerは、「グレーボックステストは入力と出力をテストするが、テストの設計は、通常はテスターからは見えないコードやプログラム操作の情報に基づいて作成される」と定義している[9]。 グレーボックステストの手法は次の通りである。

• マトリックステスト：プロジェクトのステータスレポート。
• 回帰テスト：新しい変更が加えられた場合にテストケースを再実行する。
• パターンテスト：その設計またはアーキテクチャとパターンに適したアプリケーションを検証する。
• 直交表テスト：すべての可能な組み合わせのサブセットとして使用する[10]。

• グレーボックステストは、Webアプリケーションに最適である。 Webアプリケーションは分散ネットワークや分散システムで構成されているが、ソースコードやバイナリはないため、ホワイトボックステストは実施できない。ブラックボックステストも、顧客と開発者の間の契約のために使用されない。重要な情報がWebサービス記述言語（WSDL）で利用できるため、グレーボックステストを使用する方が効率的である[13]。
• グレーボックステストは、機能またはビジネスドメインのテストに適しています。機能テストは基本的に、外部システムとのユーザーインタラクションのテストで行われる。グレーボックステストは、その特性から機能テストに最適である。また、ソフトウェアがソフトウェアに定義された要件を満たしていることを確認するのにも役立つ[14] [15] [16] [17]。

Webサービスの分散性により、グレーボックステストでサービス指向アーキテクチャ（SOA）内の欠陥を検出できます。ご存知のように、ホワイトボックステストは内部構造を直接処理するため、Webサービスには適していません。ホワイトボックステストは、最先端の方法に使用できます。たとえば、大きな配列の自動テストを生成して例外処理状態を支援するメッセージミューテーション、ソースコードやバイナリなしのフロー。このような戦略は、グレーボックステストをホワイトボックステストの結果に近づけるのに役立ちます。

• グレーボックスモデル
• ホワイトボックステスト
• ブラックボックステスト