グレーボックステスト

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

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

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

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

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

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

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

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

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

• グレーボックステストはホワイトボックステストとブラックボックステストを組み合わせたものであるため、両方のテストの複合的な利点がある。
• 非侵入型：機能仕様、アーキテクチャビューに基づいているが、ソースコードやバイナリに基づいていないため、侵襲性も高くなっている。
• インテリジェントテストオーサリング：グレーボックステスターは、データ型処理、通信プロトコル、例外処理などのインテリジェントテストシナリオを処理する。
• 偏見のないテスト：上記のすべての利点と機能にもかかわらず、グレーボックステストはテスターと開発者の間のテストの境界を維持する^[11]。

• 部分的なコードカバレッジ：グレーボックステストでは、アプリケーションの内部または構造への情報に制限があるので、ソースコードまたはバイナリが欠落しており、コードパストラバーサルへのアクセスが制限されている。
• 欠陥識別：分散アプリケーションでは、欠陥の識別を関連付けることは困難です。それでも、グレーボックステストは、これらのシステムが例外をスローするのがどれほど適切であり、Webサービス環境を備えた分散システムでこれらの例外がどれほど細かく処理されるかを見つけるのに役立つ^{[11] [12]}。

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