ホワイトボックス‐テスト【white box test】
ホワイトボックステスト
ホワイトボックステストとは、システムのテスト手法のうち、特にどのような論理構造で作成されているかに着目したテストのことである。
ホワイトボックステストでは、プログラムの外部仕様には着目せず、論理を実現するために使われている命令や、分岐が正しく動作するか、といった部分についてチェックが行われる。判定の度合いは網羅率（Coverage）によって示され、網羅率が100%となることを目指して進められる。チェックの観点に従い、命令網羅（C0）、分岐網羅（C1）、条件網羅（C2）などの種類に分けられる。
命令網羅（CO）は、全ての命令が正しく一度は実行されたかどうかをテストする観点である。分岐網羅は、全ての分岐が正しく一度は実行されたかどうか、条件網羅は、複数条件の真偽の組み合わせについて全ての分岐が正しく一度は実行されたかをテストする。
ホワイトボックステストは、プログラム側の観点からテストが行われるため、仕様を誤解して作っても正しい結果が得られる。また、ホワイトボックステストに対して、内部構造は関知せず外部仕様だけに着目し、仕様通り動作することを確認するテスト手法が、ブラックボックステストと呼ばれる。
ホワイトボックステスト
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/09/04 04:11 UTC 版)
 | この記事は英語から大ざっぱに翻訳されたものであり、場合によっては不慣れな翻訳者や機械翻訳によって翻訳されたものかもしれません。 |
ホワイトボックステスト (英: white-box testing)は、アプリケーションの機能（ブラックボックス）ではなく、アプリケーションの内部構造をテストするソフトウェアテストの手法である。構造テストとも呼ばれる。開発したソフトウェアを中身が見える箱として扱い、内部論理を網羅的にテストする。プログラムが辿る経路をどれだけ実行したかを基準とする。
ホワイトボックステストでは、システムの内部的な視点とプログラミングスキルを使用して、テストケースを設計する。テスターは、入力を選択してコード内のパスを実行し、期待される出力を決定します。これは、インサーキットテスト（ICT）など、回路内のノードのテストに類似しています。ホワイトボックステストは、ソフトウェアテストプロセスのユニット、統合、およびシステムレベルで適用できます。従来のテスターは、ホワイトボックステストをユニットレベルで行われると考える傾向がありましたが、今日では統合およびシステムテストに使用されることが多くなっています。ユニット内のパス、統合中のユニット間のパス、およびシステムレベルのテスト中のサブシステム間のパスをテストできます。このテスト設計方法では、多くのエラーや問題を発見できるが、仕様の実装されていない部分や不足している要件を見逃す可能性がある。ホワイトボックステストが設計主導型である場合[1] 、つまり、ソフトウェアの各コンポーネントの動作が合意された仕様のみに基づく場合（ DO-178CおよびISO 26262プロセスのように）、ホワイトボックステスト手法で、未実装の要件と欠落している要件の評価を行うことができる。
ホワイトボックステストの設計手法には、次のコードカバレッジ基準が含まれる。
- 制御フローテスト
- データフローテスト
- ブランチテスト
- ステートメントカバレッジ
- 決定範囲
- 変更された条件/決定範囲
- プライムパステスト
- パステスト
概要
ホワイトボックステストは、ソースコードのレベルでアプリケーションをテストする方法です。これらのテストケースは、上記の設計手法（制御フローテスト、データフローテスト、ブランチテスト、パステスト、ステートメントカバレッジ、決定カバレッジ、および変更された条件/決定カバレッジ）を使用して導出されます。ホワイトボックステストは、すべてのコードを調べてエラーのない環境を作成するためのガイドラインとしてこれらの手法を使用することです。これらのホワイトボックステスト手法は、ホワイトボックステストの構成要素であり、その本質は、後で隠れたエラーを減らすために、ソースコードレベルでアプリケーションを注意深くテストすることです。 [2]これらのさまざまな手法は、ソースコードの目に見えるすべてのパスを実行して、エラーを最小限に抑え、エラーのない環境を作成します。ホワイトボックステストの要点は、コードのどの行が実行されているかを知り、正しい出力がどうあるべきかを識別できることです。
レベル
- 単体テスト。ホワイトボックステストは、以前にテストされたコードとの統合が行われる前に、コードが意図したとおりに機能していることを確認するために、単体テスト中に実行されます。単体テスト中のホワイトボックステストは、多くの欠陥を早期に発見する可能性があり、コードがアプリケーションの他の部分と統合された後に発生する欠陥に対処するのに役立ち、したがって開発の後半でエラーの影響を軽減します。 [2]
- 統合テスト。このレベルのホワイトボックステストは、インターフェイスの相互作用をテストするために作成されています。ユニットレベルのテストでは、各コードがテストされ、分離された環境で適切に機能していることを確認しました。統合では、プログラマーが知っているインターフェイスの相互作用のホワイトボックステストを使用して、オープン環境での動作の正確さを調べます。
- 回帰テスト。回帰テスト中のホワイトボックステストは、ユニットおよび統合テストレベルでリサイクルされたホワイトボックステストケースを使用することです。
基本的な手順
ホワイトボックステストの基本的な手順では、テスターがテスト対象のソースコードに関する深い知識を持っている必要があります。プログラマーは、アプリケーションを深く理解して、作成するテストケースの種類を把握し、目に見えるすべてのパスがテストのために実行されるようにする必要があります。ソースコードが理解されると、作成するテストケースについてソースコードを分析できます。以下は、テストケースを作成するためにホワイトボックステストが実行する3つの基本的な手順です。
- 入力には、さまざまなタイプの要件、機能仕様、ドキュメントの詳細設計、適切なソースコード、およびセキュリティ仕様が含まれます。[要出典]これは、すべての基本情報をレイアウトするためのホワイトボックステストの準備段階です。
- 処理には、リスク分析を実行して、テストプロセス全体、適切なテスト計画を導き、テストケースを実行し、結果を伝達することが含まれます。[要出典]これは、テストケースを構築して、アプリケーションを徹底的にテストし、与えられた結果がそれに応じて記録されるようにするフェーズです。
- 出力には、上記の準備と結果のすべてを含む最終レポートの準備が含まれます。[要出典]
長所
- ソースコードの知識を持つことの副作用は、徹底的なテストに役立ちます。[要出典]
- 目立たないボトルネックが露呈するため、コードの最適化が容易になります。[要出典]
- 開発者は新しい実装を注意深く説明するため、プログラマーに内省を与えます。[要出典]
- ソースからのテストのトレーサビリティを提供します。これにより、ソースへの将来の変更を、新しく追加または変更されたテストで簡単にキャプチャできます。 [3]
- 自動化が簡単。 [4]
- テストをいつ停止するかについて、明確なエンジニアリングベースのルールを提供します。 [5]
短所
ホワイトボックステストには大きな利点がありますが、完全ではなく、いくつかの欠点があります。
- ホワイトボックステストは、テスターがプログラムの知識を持っている必要があるため、またはテストチームがコードレベルでプログラムを理解できる非常に優れたプログラマーを少なくとも1人持つ必要があるため、テストを複雑にします。ホワイトボックステストでは、実行する必要のあるテストレベルが複雑であるため、高度な知識を持つプログラマーが必要です。[要出典]
- 場合によっては、アプリケーションの既存のすべての条件をテストできることが現実的ではなく、一部の条件はテストされません。[要出典]
- テストは、存在するソフトウェアに焦点を合わせており、不足している機能が発見されない場合があります。
- 結果として得られるテストは、テスト対象の特定の実装と緊密に結合されているため、脆弱になる可能性があります。テスト対象のコードは、テストに組み込まれた仮定を無効にする別の方法で同じ機能を実装するように書き直すことができます。これにより、テストが不必要に失敗したり、最悪の場合、テストで誤検知が発生したり、コードでエラーがマスクされたりする可能性があります。
現代の見解
より現代的な見方は、ホワイトボックステストとブラックボックステストの二分法が曖昧になり、関連性が低くなっているというものです。 「ホワイトボックス」は元々ソースコードを使用することを意味し、ブラックボックスは要件を使用することを意味していましたが、テストは現在、さまざまな抽象化レベルの多くのドキュメントから派生しています。本当のポイントは、テストは通常、入力スペース、グラフ、論理述語などの抽象構造から設計されているということです。問題は、その抽象構造をどのレベルの抽象化から導き出すかです。 [4]これは、ソースコード、要件、入力スペースの説明、または数十種類の設計モデルの1つです。したがって、「ホワイトボックス/ブラックボックス」の区別はそれほど重要ではなく、用語の関連性も低くなります。[要出典]
ハッキング
ペネトレーションテストでは、ホワイトボックステストとは、ホワイトハットハッカーが攻撃対象のシステムを完全に把握している方法を指す。ホワイトボックス侵入テストの目標は、ターゲットシステムの知識と、場合によっては基本的な資格情報を持っている悪意のあるインサイダーをシミュレートすることです。
関連項目
- ブラックボックステスト
- グレーボックステスト
- ホワイトボックス暗号化
出典
- ^ Stacy Nelson (June 2003), NASA/CR–2003-212806 Certification Processes for Safety-Critical and Mission-Critical Aerospace Software, Ames Research Center, p. 25, "[Glossary] White Box Testing: Design-driven testing where engineers examine internal workings of code"
- ^ a b Williams, Laurie. White-Box Testing. pp. 60–61, 69 2013年2月13日閲覧。.[要検証]
- ^ Binder, Bob (2000). Testing Object-oriented Systems. Addison-Wesley Publishing Company Inc.
- ^ a b Ammann, Paul; Offutt, Jeff (2008). Introduction to Software Testing. Cambridge University Press. ISBN 9780521880381
- ^ Myers, Glenford (1979). The Art of Software Testing. John Wiley and Sons
外部リンク
- BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): Component Testing Standard Standard for Software Component Testing, Working Draft 3.4, 27. April 2001.
- http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf has more information on control flow testing and data flow testing.
- Pex and Moles - Isolation and White Box Unit Testing for .NET - Microsoft Research
ホワイトボックステスト (white box test)
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/03/23 10:14 UTC 版)
「ソフトウェアテスト」の記事における「ホワイトボックステスト (white box test)」の解説
詳細は「ホワイトボックステスト」を参照 ホワイトボックステスト (white box test) は、プログラムの構造に着目したソフトウェアテストのことである。着目する構造には命令や分岐などがあり、注目した構造に対してどれだけの割合の部分を実行できたかを網羅率で表す。 int abs(int x) { if (x < 0) { x = -x; } return x;}
※この「ホワイトボックステスト (white box test)」の解説は、「ソフトウェアテスト」の解説の一部です。
「ホワイトボックステスト (white box test)」を含む「ソフトウェアテスト」の記事については、「ソフトウェアテスト」の概要を参照ください。
- ホワイトボックステストのページへのリンク
