Loading article…
| ブラックボックスシステム | |
|---|---|
 | |
| システム | |
| ブラックボックス、オラクルマシン | |
| 方法とテクニック | |
| ブラックボックステスト、ブラックボックス化 | |
| 関連技術 | |
| フィードフォワード、難読化、パターン認識、ホワイトボックス、ホワイトボックステスト、グレーボックステスト、システム識別 | |
| 基礎 | |
| 先験情報、制御システム、オープンシステム、オペレーションズリサーチ、熱力学システム | |
ホワイトボックステスト（クリアボックステスト、グラスボックステスト、トランスペアレントボックステスト、構造テストとも呼ばれる）は、アプリケーションの機能（ブラックボックステスト）ではなく、内部構造や仕組みをテストするソフトウェアテストの方法です。ホワイトボックステストでは、システムの内部的な視点を使用してテストケースを設計します。テスターは入力を選択してコード内のパスを実行し、予想される出力を決定します。これは、回路内のノードをテストすることに似ています（インサーキットテスト（ICT）など）。ホワイトボックステストは、ソフトウェアテストプロセスのユニットレベル、統合レベル、システムレベルで適用できます。従来のテスターは、ホワイトボックステストはユニットレベルで行われると考えがちでしたが、今日では統合テストやシステムテストでより頻繁に使用されています。ユニット内のパス、統合中のユニット間のパス、システムレベルテスト中のサブシステム間のパスをテストできます。このテスト設計方法では多くのエラーや問題を発見できますが、仕様の未実装部分や要件の欠落を見逃す可能性があります。ホワイトボックステストが設計主導型[1]、つまりソフトウェアの各コンポーネントの動作方法に関する合意された仕様のみによって駆動される場合（DO-178CおよびISO 26262プロセスの場合など）、ホワイトボックステスト手法は、実装されていない要件や不足している要件の評価を実行できます。
ホワイト ボックス テスト設計手法には、次のコード カバレッジ基準が含まれます。
- 制御フローテスト
- データフローテスト
- ブランチテスト
- ステートメントカバレッジ
- 決定範囲
- 修正された条件/決定範囲
- プライムパステスト
- パステスト
概要
ホワイトボックステストは、ソースコードレベルでアプリケーションをテストする方法です。これらのテストケースは、上記の設計手法、つまり制御フローテスト、データフローテスト、分岐テスト、パステスト、ステートメントカバレッジと決定カバレッジ、および変更された条件/決定カバレッジを使用して作成されます。ホワイトボックステストは、すべてのコードを調べてエラーのない環境を作成するためのガイドラインとしてこれらの手法を使用することです。これらのホワイトボックステスト手法は、ホワイトボックステストの構成要素であり、その本質は、後で隠れたエラーを減らすためにソースコードレベルでアプリケーションを慎重にテストすることです。[2]これらのさまざまな手法は、ソースコードの目に見えるすべてのパスを実行してエラーを最小限に抑え、エラーのない環境を作成します。ホワイトボックステストの全体的なポイントは、コードのどの行が実行されているかを把握し、正しい出力が何であるかを識別できることです。[2]
レベル
- ユニットテスト。ホワイトボックステストは、以前にテストされたコードとの統合が行われる前に、コードが意図したとおりに動作することを確認するためにユニットテスト中に行われます。ユニットテスト中のホワイトボックステストは、多くの欠陥を早期に検出する可能性があり、コードがアプリケーションの他の部分と統合された後に発生する欠陥に対処するのに役立ち、開発後のエラーの影響を軽減します。[2]
- 統合テスト。このレベルのホワイトボックステストは、インターフェース同士の相互作用をテストするために書かれています。ユニットレベルのテストでは、各コードがテストされ、隔離された環境で適切に動作していることを確認し、統合では、プログラマーが知っているインターフェースの相互作用についてホワイトボックステストを使用して、オープン環境での動作の正確性を検査します。[2]
- 回帰テスト。回帰テスト中のホワイトボックステストは、ユニットテストと統合テストのレベルで再利用されたホワイトボックステストケースを使用することです。[2]
基本的な手順
ホワイト ボックス テストの基本的な手順では、テスト担当者がテスト対象のソース コードについて深い知識を持っている必要があります。プログラマーは、アプリケーションについて深く理解し、目に見えるすべてのパスをテストで実行できるように、どのようなテスト ケースを作成すればよいかを把握している必要があります。ソース コードが理解されると、それを分析してテスト ケースを作成できます。ホワイト ボックス テストでテスト ケースを作成するために実行される 3 つの基本的な手順は次のとおりです。
- 入力には、さまざまな種類の要件、機能仕様、ドキュメントの詳細な設計、適切なソース コード、セキュリティ仕様が含まれます。[引用が必要]これは、すべての基本情報をレイアウトするためのホワイト ボックス テストの準備段階です。
- 処理には、リスク分析を実行して、テストプロセス全体をガイドし、適切なテスト計画を立て、テストケースを実行して、結果を伝達することが含まれます。[引用が必要]これは、アプリケーションを徹底的にテストし、与えられた結果がそれに応じて記録されるようにするためのテストケースを構築するフェーズです。
- 出力には、上記の準備と結果をすべて網羅した最終レポートの作成が含まれます。[引用が必要]
利点
- ソースコードの知識を持つことの副作用は、徹底的なテストに有益です。[引用が必要]
- 目立たないボトルネックが明らかになると、コードの最適化が容易になります。[引用が必要]
- 開発者が新しい実装を注意深く記述するため、プログラマーは内省できるようになります。[引用が必要]
- ソースからのテストのトレーサビリティを提供し、それによってソースへの将来の変更を新しく追加または変更されたテストに簡単にキャプチャできるようになります。[3]
- 自動化が容易。[4]
- テストをいつ停止するかについて、明確なエンジニアリングベースのルールを提供します。[5] [4]
デメリット
- ホワイト ボックス テストは、特定の実装の詳細をテストするために作成されます。つまり、テストは実装と密接に結合されているため、実装が変更されるとテストは失敗します。実装が変更されたときにテストが再び実装と一致するように、テストを更新するための追加作業を行う必要があります。一方、ブラック ボックス テストでは、テストは実装から独立しているため、実装が変更されても実装の出力または副作用が変わらない場合は、テストは正常に実行されます。
- テスト対象のコードが書き換えられ、同じ機能を別の方法で実装すると、テストに組み込まれた想定が無効になる可能性があります。その結果、テストが不必要に失敗するか、最悪の場合、誤検知が発生してコード内のエラーが隠されるテストが発生する可能性があります。ホワイト ボックス テストは、テスト対象のコードの意図された動作をテストするようには作成されておらず、特定の実装が実行する動作のみを行うように作成されています。
- ホワイト ボックス テストでは、テスターがプログラムの知識を持っているか、テスト チームにコード レベルでプログラムを理解できる優秀なプログラマーが少なくとも 1 人必要となるため、テストが複雑になります。ホワイト ボックス テストでは、実行する必要があるテスト レベルの複雑さのため、高度な知識を持つプログラマーが必要です。
- 場合によっては、アプリケーションの既存の条件をすべてテストすることは現実的ではなく、一部の条件はテストされないことがあります。
- テストは既存のソフトウェアに焦点を合わせているため、不足している機能は検出されない可能性があります。
モダンビュー
より現代的な見方では、ホワイトボックス テストとブラックボックス テストの二分法は曖昧になり、あまり重要ではなくなってきています。「ホワイトボックス」は元々ソース コードの使用を意味し、ブラックボックスは要件の使用を意味していましたが、現在ではテストはさまざまな抽象化レベルの多くのドキュメントから派生しています。実際のポイントは、テストは通常、入力空間、グラフ、論理述語などの抽象構造から設計されており、その抽象構造をどの抽象化レベルから派生させるかが問題であるということです。[4]それは、ソース コード、要件、入力空間の説明、または数十種類の設計モデルのいずれかです。したがって、「ホワイトボックス / ブラックボックス」の区別はそれほど重要ではなく、用語の関連性も低くなっています。[引用が必要]
ハッキング
侵入テストにおいて、ホワイトボックステストとは、ホワイトハットハッカーが攻撃対象のシステムについて十分な知識を持っている方法を指します。[6]ホワイトボックス侵入テストの目的は、ターゲットシステムに関する知識と、おそらく基本的な資格情報を持つ悪意のある内部者をシミュレートすることです。このような侵入テストでは、通常、管理者の資格情報が提供され、どの攻撃が高権限アカウントに影響を与えるかを分析します。[7]ソースコードは、テスト担当者の参照用に提供できます。コード自体がターゲットである場合、これは（単なる）侵入テストではなく、ソースコードセキュリティ監査（またはセキュリティレビュー）です。[8]
参照
参考文献
- ^ Stacy Nelson (2003 年 6 月)、NASA/CR–2003-212806 安全上およびミッションクリティカルな航空宇宙ソフトウェアの認証プロセス(PDF)、エイムズ研究センター、p. 25、
[用語集] ホワイト ボックス テスト:エンジニアがコードの内部動作を検査する設計主導のテスト
- ^ abcde Williams, Laurie . 「ホワイトボックステスト」(PDF) . pp. 60–61, 69. 2016年3月3日時点のオリジナル(PDF)からアーカイブ。2013年2月13日閲覧。[確認が必要]
- ^ バインダー、ボブ (2000)。オブジェクト指向システムのテスト。Addison-Wesley Publishing Company Inc. ISBN 9780201809381。
- ^ abc Ammann, Paul; Offutt, Jeff (2008). ソフトウェアテスト入門. ケンブリッジ大学出版局. ISBN 978-0-521-88038-1。
- ^ マイヤーズ、グレンフォード(1979)。ソフトウェアテストの芸術。ジョン・ワイリー・アンド・サンズ。ISBN 9780471043287。
- ^ 「侵入テストモデル」(PDF)。連邦情報セキュリティ局 (BSI)。
- ^ Baran, Ewelina. 「侵入テストの種類」。Blaze Information Security GmbH 。 2024年9月12日閲覧。
- ^ Sullivan, James. 「コード監査とは何か：その目的とプロセスを理解する」. 17 Web Dev, LLC . 2024年9月12日閲覧。
外部リンク
- BCS SIGIST (英国コンピュータ協会ソフトウェアテスト専門利益団体): http://www.testingstandards.co.uk/Component%20Testing.pdf ソフトウェアコンポーネントテストの標準]、ワーキングドラフト 3.4、2001 年 4 月 27 日。
- http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf には、制御フロー テストとデータ フロー テストに関する詳細情報が記載されています。
- http://research.microsoft.com/en-us/projects/pex/ Pex – .NET の自動ホワイトボックス テスト