ホワイトボックステスト
From Wikipedia, the free encyclopedia
ホワイトボックステスト (英: white-box testing)は、アプリケーションの機能（ブラックボックス）ではなく、アプリケーションの内部構造をテストするソフトウェアテストの手法である。構造テストとも呼ばれる。開発したソフトウェアを中身が見える箱として扱い、内部論理を網羅的にテストする。プログラムが辿る経路をどれだけ実行したかを基準とする。
ホワイトボックステストでは、システムの内部的な視点とプログラミングスキルを使用して、テストケースを設計する。テスターは、入力を選択してコード内のパスを実行し、期待される出力を決定します。これは、インサーキットテスト（ICT）など、回路内のノードのテストに類似しています。ホワイトボックステストは、ソフトウェアテストプロセスのユニット、統合、およびシステムレベルで適用できます。従来のテスターは、ホワイトボックステストをユニットレベルで行われると考える傾向がありましたが、今日では統合およびシステムテストに使用されることが多くなっています。ユニット内のパス、統合中のユニット間のパス、およびシステムレベルのテスト中のサブシステム間のパスをテストできます。このテスト設計方法では、多くのエラーや問題を発見できるが、仕様の実装されていない部分や不足している要件を見逃す可能性がある。ホワイトボックステストが設計主導型である場合[1] 、つまり、ソフトウェアの各コンポーネントの動作が合意された仕様のみに基づく場合（ DO-178CおよびISO 26262プロセスのように）、ホワイトボックステスト手法で、未実装の要件と欠落している要件の評価を行うことができる。
ホワイトボックステストの設計手法には、次のコードカバレッジ基準が含まれる。
- 制御フローテスト
- データフローテスト
- ブランチテスト
- ステートメントカバレッジ
- 決定範囲
- 変更された条件/決定範囲
- プライムパステスト
- パステスト
ホワイトボックステストは、ソースコードのレベルでアプリケーションをテストする方法です。これらのテストケースは、上記の設計手法（制御フローテスト、データフローテスト、ブランチテスト、パステスト、ステートメントカバレッジ、決定カバレッジ、および変更された条件/決定カバレッジ）を使用して導出されます。ホワイトボックステストは、すべてのコードを調べてエラーのない環境を作成するためのガイドラインとしてこれらの手法を使用することです。これらのホワイトボックステスト手法は、ホワイトボックステストの構成要素であり、その本質は、後で隠れたエラーを減らすために、ソースコードレベルでアプリケーションを注意深くテストすることです。 [2]これらのさまざまな手法は、ソースコードの目に見えるすべてのパスを実行して、エラーを最小限に抑え、エラーのない環境を作成します。ホワイトボックステストの要点は、コードのどの行が実行されているかを知り、正しい出力がどうあるべきかを識別できることです。
レベル
- 単体テスト。ホワイトボックステストは、以前にテストされたコードとの統合が行われる前に、コードが意図したとおりに機能していることを確認するために、単体テスト中に実行されます。単体テスト中のホワイトボックステストは、多くの欠陥を早期に発見する可能性があり、コードがアプリケーションの他の部分と統合された後に発生する欠陥に対処するのに役立ち、したがって開発の後半でエラーの影響を軽減します。 [2]
- 統合テスト。このレベルのホワイトボックステストは、インターフェイスの相互作用をテストするために作成されています。ユニットレベルのテストでは、各コードがテストされ、分離された環境で適切に機能していることを確認しました。統合では、プログラマーが知っているインターフェイスの相互作用のホワイトボックステストを使用して、オープン環境での動作の正確さを調べます。
- 回帰テスト。回帰テスト中のホワイトボックステストは、ユニットおよび統合テストレベルでリサイクルされたホワイトボックステストケースを使用することです。
基本的な手順
ホワイトボックステストの基本的な手順では、テスターがテスト対象のソースコードに関する深い知識を持っている必要があります。プログラマーは、アプリケーションを深く理解して、作成するテストケースの種類を把握し、目に見えるすべてのパスがテストのために実行されるようにする必要があります。ソースコードが理解されると、作成するテストケースについてソースコードを分析できます。以下は、テストケースを作成するためにホワイトボックステストが実行する3つの基本的な手順です。
長所
短所
ホワイトボックステストには大きな利点がありますが、完全ではなく、いくつかの欠点があります。
- ホワイトボックステストは、テスターがプログラムの知識を持っている必要があるため、またはテストチームがコードレベルでプログラムを理解できる非常に優れたプログラマーを少なくとも1人持つ必要があるため、テストを複雑にします。ホワイトボックステストでは、実行する必要のあるテストレベルが複雑であるため、高度な知識を持つプログラマーが必要です。[要出典]
- 場合によっては、アプリケーションの既存のすべての条件をテストできることが現実的ではなく、一部の条件はテストされません。[要出典]
- テストは、存在するソフトウェアに焦点を合わせており、不足している機能が発見されない場合があります。
- 結果として得られるテストは、テスト対象の特定の実装と緊密に結合されているため、脆弱になる可能性があります。テスト対象のコードは、テストに組み込まれた仮定を無効にする別の方法で同じ機能を実装するように書き直すことができます。これにより、テストが不必要に失敗したり、最悪の場合、テストで誤検知が発生したり、コードでエラーがマスクされたりする可能性があります。
現代の見解
より現代的な見方は、ホワイトボックステストとブラックボックステストの二分法が曖昧になり、関連性が低くなっているというものです。 「ホワイトボックス」は元々ソースコードを使用することを意味し、ブラックボックスは要件を使用することを意味していましたが、テストは現在、さまざまな抽象化レベルの多くのドキュメントから派生しています。本当のポイントは、テストは通常、入力スペース、グラフ、論理述語などの抽象構造から設計されているということです。問題は、その抽象構造をどのレベルの抽象化から導き出すかです。 [4]これは、ソースコード、要件、入力スペースの説明、または数十種類の設計モデルの1つです。したがって、「ホワイトボックス/ブラックボックス」の区別はそれほど重要ではなく、用語の関連性も低くなります。[要出典]
ハッキング
ペネトレーションテストでは、ホワイトボックステストとは、ホワイトハットハッカーが攻撃対象のシステムを完全に把握している方法を指す。ホワイトボックス侵入テストの目標は、ターゲットシステムの知識と、場合によっては基本的な資格情報を持っている悪意のあるインサイダーをシミュレートすることです。
