グレーとは何ですか Box テスト中? テクニック、例

⚡ スマートサマリー

グレー Box テストでは、アプリケーションの内部構造を部分的に把握した上で検証を行い、ブラックボックステストのユーザー視点と、障害が発生したという事実だけでなく、なぜ発生したのかを説明できる十分なアーキテクチャ上の洞察力を組み合わせます。

  • 🔍 知識レベル: 内部構造は部分的に既知である。これは、ホワイトボックステストでは内部構造が完全に既知であるのに対し、ブラックボックステストでは内部構造が未知であるのと対照的である。
  • 🧪 4つのテクニック: マトリックステスト、回帰テスト、直交配列テスト、パターンテストが、コアとなるツールキットを構成します。
  • 🪜 10のステップ: 入力、出力、主要な経路を特定し、システムをサブ機能に分割してそれぞれを検証する。
  • 🔗 最適なもの: 統合テスト、侵入テスト、データベースを基盤としたワークフロー、Webサービス、API接続tracTS。
  • <XNUMXxEXNUMX><XNUMXxEXNUMX><XNUMXxXNUMXA><XNUMXxXNUMX><XNUMXxXNUMXA>️️ トレード・オフ: 部分的な可視性は労力を軽減する一方で、個々のコードパスの深さを制限する。 tracエド。
  • ???? 前提条件: 正確な設計文書は重要である。なぜなら、古くなったスキーマや仕様書は、テスト設計を静かに無効にしてしまうからだ。

グレー
 Box 部分的な内部知識とユーザー向けテスト設計を組み合わせたテスト

グレーとは何ですか Box テスト中?

グレー Box テスト (Gray とも綴られる) Box グレーテストは、アプリケーションの内部構造に関する部分的な知識に基づいてソフトウェア製品またはアプリケーションをテストするソフトウェアテスト手法です。 Box テストとは、不適切なコード構造やアプリケーションの不適切な使用によって引き起こされる欠陥を探し出し、特定することです。

このプロセスでは、Web システムに関連するコンテキスト固有のエラーが一般的に特定されます。この技術は、 テストカバレッジ 複雑なシステムのいずれかの層に焦点を当てるのではなく、すべての層に焦点を当てることによって。

グレー Box テストは、ソフトウェアテスト方法を組み合わせたものです。 ホワイト Box テスト (NAIST) と ブラック Box テストこの3つの違いは、テスターが内部構造をどの程度把握できるかという点に尽きる。

  • ホワイトで Box 内部構造(コード)のテストは既知である。
  • 黒で Box 内部構造(コード)のテストは不明です。
  • グレーで Box 内部構造(コード)のテストは、部分的には既知である。

下の図は、これら3つの方法を同じ可視性の尺度上に配置したものです。

グレー
 Box ホワイト間のテスト結果 Box と黒 Box 内部コードの可視性に関するテスト

In ソフトウェア工学、 グレー Box テストは、アプリケーションのプレゼンテーション層と背後のコードの両方をテストする機能を提供します。これは主に次のような場合に役立ちます。 統合テスト (NAIST) と 侵入テスト.

灰色の例 Box テスト: リンクや孤立リンクなどのウェブサイトの機能をテストしている際に、テスターがこれらのリンクに問題を発見した場合、HTMLコードに即座に変更を加え、リアルタイムで確認することができます。

グレーを選ぶ理由 Box テスト

グレー Box テストは以下の理由で実施されます。

  • これは、ブラックボックステストとホワイトボックステストの両方の利点を兼ね備えています。
  • 開発者とテスター双方の意見を取り入れることで、製品全体の品質を向上させる。
  • これにより、機能型と非機能型のテストという長時間のプロセスに伴うオーバーヘッドが削減されます。
  • これにより、開発者は不具合を修正するための十分な自由時間を確保できる。
  • テストは、設計者の視点ではなく、ユーザーの視点から行われる。
  • テスターは不具合が発生したレイヤーを確認できるため、不具合を単に報告するだけでなく、その原因を説明することができる。

グレー Box テスト対ブラック Box 対ホワイト Box テスト

これら3つの方法は、競合する選択肢というよりは、アクセスレベルの3つの段階であり、それぞれ異なる種類の疑問に答えるものです。それらを並べて比較することで、選択がより明確になります。

Basis社 ブラック Box テスト グレー Box テスト ホワイト Box テスト
内部構造に関する知識 なし 一部 フル
によって演奏された テスターとエンドユーザー テスター、およびテスターと連携する開発者 開発者とテストエンジニア
テスト設計の基礎 要件と仕様 Archi構造、アルゴリズム、データ構造、インターフェース ソースコードと制御フロー
標準レベル システムおよび受け入れテスト 統合テスト、侵入テスト、およびウェブサービステスト ユニットおよびコンポーネントのテスト
カバー率は以下のように測定されます 要件カバレッジ インターフェース、データ、パスのカバー範囲 ステートメント、ブランチ、パスのカバー範囲
主な制限 失敗の原因は隠されたままになる 深さは、許可されたアクセスによって制限されます。 費用がかさむ上に、必要な要件を見落とす可能性がある

ほとんどのチームは3つすべてを使用しています ソフトウェアテストのライフサイクルそして、グレーボックス層は、ユーザーインターフェースとデータストアの間にある欠陥が通常検出される場所です。

グレー Box テスト戦略

グレイを実行する Box テストにおいては、テスターがソースコードにアクセスできる必要はありません。テストは、アルゴリズム、アーキテクチャ、内部状態、またはプログラムの動作に関するその他の高レベルな記述に関する知識に基づいて設計されます。

グレイを実行する Box テスト:

  • これは、ブラックボックステストという単純な手法を適用するものです。
  • これは要件主導型のテストケース生成に基づいているため、アサーションメソッドによってプログラムがテストされる前に、すべての条件が事前に設定されます。

グレースケールに使用されるテクニック Box テスト内容は以下のとおりです。

  • マトリックスのテスト: この手法では、プログラム内に存在するすべての変数と、それぞれの変数が持つリスクを定義することで、未使用の変数やリスクの高い変数を可視化します。
  • 回帰テスト: 以前のバージョンでの変更が、新しいバージョンでプログラムの他の側面に悪影響を与えていないかを確認します。これは、すべての再テスト、リスクの高い使用ケースの再テスト、ファイアウォール内での再テストなどの戦略を用いて行われます。
  • 直交配列テスト またはOAT: 最小限のテストケースで最大限のコードカバレッジを実現します。
  • パターンテスト: 過去のシステム欠陥の履歴データに基づいて実行されます。ブラックボックステストとは異なり、グレーテストは、 Box テストはコードを詳細に調べ、障害が発生した原因を特定します。

グレー Box この手法は通常自動化されたものを使用する ソフトウェアテストツール テストを実施するため、テスターが手動でコードを生成する必要がないように、スタブとモジュールドライバが作成されます。

グレーを実行する手順 Box テスト内容は以下のとおりです。

  • ステップ1:入力を特定する。
  • ステップ2:出力を特定する。
  • ステップ3:主要な経路を特定する。
  • ステップ4:サブ機能を特定する。
  • ステップ5:サブ関数の入力値を開発する。
  • ステップ6:サブ関数の出力を作成します。
  • ステップ7:サブ関数のテストケースを実行します。
  • ステップ8:サブ関数の正しい結果を確認します。
  • ステップ9:他のサブ関数についても、ステップ4~8を繰り返します。
  • ステップ10:他のサブ関数についてもステップ7と8を繰り返します。

Greyのテストケース Box テストは、GUI、セキュリティ、データベース、ブラウザ、オペレーティングシステムに関する問題などを対象とする場合があります。生成された各ケースには、通常の手順が必要です。 テストケース 属性。なぜなら、自身の記述から再現できない事例は、回帰分析においてほとんど役に立たないからである。

灰色の Box テストが使用される

この技術は、欠陥を診断するためには2つの層を同時に観察する必要があるあらゆる場面で有効です。最もよく適用されるシナリオは以下のとおりです。

  • データベースを活用したワークフロー: ユーザーインターフェースを介してアクションが実行され、その結果得られた行が直接クエリされ、値、型、および関係が意図どおりに保存されていることを確認します。
  • ウェブサービスとAPI: リクエストが送信され、レスポンスのステータス、ヘッダー、ペイロードが公開されている構成と照合されます。tract は、日常的な形です APIテスト.
  • 統合ポイント: 2つのモジュールの境界を越えるメッセージは、両方のモジュールがソースファイルではなく実行中のシステムとして扱われる際に検査されます。
  • セキュリティ評価: ペネトレーションテスターが通常のユーザーアカウントとアーキテクチャの概要を与えられ、内部関係者の立場を再現する。これは標準的なグレーボックス型攻撃モデルである。
  • ウェブアプリケーションとGUI: リンク切れ、孤立ページ、セッション処理、クライアント側検証はすべて、マークアップとリクエストフローを部分的に把握した上でチェックされます。

これらすべてにおいて、問題がパイプラインの下流に進む前に発見され説明されるため、システム欠陥の全体的なコストが削減されます。 システムテスト または生産。

グレー Box テストツール

グレーを実行するツールはありません Box 単独でのテスト。このカテゴリに必要なのは、インターフェースドライバ、下位レイヤーの検査ツール、そしてその2つを連携させるスクリプト機能の組み合わせです。

  • APIおよびWebサービスクライアント など Postman (NAIST) と SoapUIリクエストの発行、ステータスコードおよびレスポンスボディの検証に使用されます。
  • データベースクライアントとSQLクエリツールインターフェース操作後の永続化された状態を確認するために使用されます。
  • ブラウザ開発者ツールとHTTPプロキシ など Burp Suiteセキュリティ重視のセッション中にリクエストを検査および変更するために使用されます。
  • UI自動化フレームワーク など Seleniumプレゼンテーション層を駆動するために使用されます 自動化テスト 上。
  • ログおよび監視ツール観測された障害と、その時点でアプリケーションが内部的に記録した内容を関連付けるために使用されます。

選択肢よりも配線の方が重要です。インターフェースドライバと検査ステップが同じスクリプトの流れで実行されない限り、結果として1つのグレーボックステストではなく、2つの別々の手動チェックが発生します。

グレー Box テストの課題

部分的な可視性は、純粋な方法のどちらにも存在しない問題を引き起こします。チームが最も頻繁に遭遇する問題は次のとおりです。

  • テスト対象のコンポーネントに何らかの不具合が発生した場合、進行中の操作が中断され、残りのシーケンスが実行されないままになることがあります。
  • テストは完全に実行されても、結果の内容が間違っている可能性があるため、検証ステップでは完了ではなく値をチェックする必要があります。
  • テスターはホワイトボックステストで到達するすべての分岐を見ることができないため、コードパス全体を網羅することは不可能です。
  • テストが依拠する設計ドキュメントが古くなっている可能性があり、古いスキーマやインターフェース仕様によってテスト設計が静かに無効になってしまうことがある。
  • テスターに​​は、専門分野の理解と技術的な知識の両方が求められるため、採用する人材のスキルプロファイルは比較的限定的である。
  • 分散され、高度に吸収tracTEDアーキテクチャでは、観測された障害を特定の内部コンポーネントに帰属させることが困難です。

これらの制約は、グレイを治療することを主張する Box テストは他のレイヤーの代替ではなく、複数のレイヤーのうちの1つとして行うものであり、これはより広範なセットで述べられている点である。 ソフトウェアテスト手法 (NAIST) と ソフトウェアテストの種類自然に隣に並びます 機能テスト 仕様主導型のアプローチとしては、 モデルベーステスト.

よくあるご質問

どちらも同じ技術を指します。Greyはイギリス英語の綴りで、grayはアメリカ英語の綴りです。工具の説明書や資格認定試験のシラバスでは、この2つの綴りは区別なく使われています。技術的な意味合いに違いはありません。

すべての行を読まなくても内部構造を推論するのに十分な情報:アーキテクチャ図、データモデル、インターフェース構成tracテストデータベースへの読み取り専用アカウントとtsファイルを用意します。リポジトリへのフルアクセス権限があれば、ホワイトボックステストを実施できます。

通常は開発経験のあるテストエンジニア、またはセッションごとに開発者とペアを組んだテスターが担当します。セキュリティ関連の業務は、標準ユーザーアカウントとアーキテクチャ概要を与えられた侵入テスト担当者によって実施されます。

ステートメントではなく、インターフェースとデータに基づいて評価します。具体的には、実行されたすべてのエンドポイントとステータスコード、アクセスされたすべてのテーブルと状態遷移、実行されたすべての統合パスを対象とします。ステートメントと分岐の割合は、ホワイトボックス測定に含まれます。

スタブは、テスト対象モジュールが呼び出すコンポーネントの代わりとなるものであり、ドライバは、そのコンポーネントを呼び出す側の代わりとなるものです。これらを組み合わせることで、システム全体が構築される前に、サブ関数を単独で実行することが可能になります。

独立したユーザー視点からの判断が必要な場合、部分的な知識ではテスターが想定される経路に偏ってしまうため、受け入れテストやユーザビリティテストはブラックボックスのままとなり、安全性が重要なコードについては完全なホワイトボックス分析が必要となります。

機械学習は、パターンテストのステップのために欠陥履歴を分析し、予測されるリスクに基づいてインターフェースをランク付けして限られたアクセス権限を有効活用し、ログをクラスタリングして観測された障害と、それを引き起こした内部コンポーネントを関連付けます。

はい、繰り返し発生する部分、つまりリクエストビルダー、レスポンスアサーション、検証クエリ、インターフェース定義から作成されたスタブとドライバについてはそうです。どの内部状態が動作の正しさを証明するかは、エンジニアの設計判断に委ねられます。