ソフトウェアテスト-方法
ソフトウェアテストに使用できるさまざまな方法があります。この章では、使用可能な方法について簡単に説明します。
ブラックボックステスト
アプリケーションの内部動作に関する知識がなくてもテストする手法は、ブラックボックステストと呼ばれます。テスターはシステムアーキテクチャに気づかず、ソースコードにアクセスできません。通常、ブラックボックステストの実行中、テスターは、入力が処理される方法と場所を知らなくても、入力を提供し、出力を調べることによって、システムのユーザーインターフェイスと対話します。
次の表に、ブラックボックステストの長所と短所を示します。
利点 | 短所 |
---|---|
大きなコードセグメントに最適で効率的です。 | 選択された数のテストシナリオのみが実際に実行されるため、カバレッジが制限されます。 |
コードアクセスは必要ありません。 | テスターがアプリケーションについての知識が限られているため、非効率的なテスト。 |
視覚的に定義された役割を通じて、ユーザーの視点と開発者の視点を明確に分離します。 | テスターは特定のコードセグメントやエラーが発生しやすい領域をターゲットにできないため、ブラインドカバレッジ。 |
中程度のスキルを持つ多数のテスターは、実装、プログラミング言語、またはオペレーティングシステムの知識がなくてもアプリケーションをテストできます。 | テストケースの設計は困難です。 |
ホワイトボックステスト
ホワイトボックステストは、コードの内部ロジックと構造の詳細な調査です。ホワイトボックステストは、glass testing または open-box testing。実行するためにwhite-box アプリケーションでテストする場合、テスターはコードの内部動作を知る必要があります。
テスターは、ソースコードの内部を調べて、コードのどのユニット/チャンクが不適切に動作しているかを確認する必要があります。
次の表に、ホワイトボックステストの長所と短所を示します。
利点 | 短所 |
---|---|
テスターはソースコードの知識を持っているため、アプリケーションの効果的なテストに役立つデータの種類を簡単に見つけることができます。 | ホワイトボックステストを実行するには熟練したテスターが必要であるため、コストが増加します。 |
コードの最適化に役立ちます。 | 多くのパスがテストされていないため、問題を引き起こす可能性のある隠れたエラーを見つけるために隅々まで調べることが不可能な場合があります。 |
隠れた欠陥をもたらす可能性のある余分なコード行を削除できます。 | ホワイトボックステストは、コードアナライザーやデバッグツールなどの特殊なツールを必要とするため、維持するのは困難です。 |
コードに関するテスターの知識により、テストシナリオの作成中に最大のカバレッジが達成されます。 |
グレーボックステスト
グレーボックステストは、アプリケーションの内部動作に関する知識が限られている状態でアプリケーションをテストする手法です。ソフトウェアテストでは、このフレーズをよく知っているほど、アプリケーションのテスト中に大きな重みを持ちます。
システムのドメインをマスターすることで、テスターは常にドメイン知識が限られている人よりも優位に立つことができます。テスターがアプリケーションのユーザーインターフェイスのみをテストするブラックボックステストとは異なります。グレーボックステストでは、テスターは設計ドキュメントとデータベースにアクセスできます。この知識があれば、テスターはテスト計画を立てながら、より良いテストデータとテストシナリオを準備できます。
利点 | 短所 |
---|---|
可能な限り、ブラックボックステストとホワイトボックステストを組み合わせた利点を提供します。 | ソースコードへのアクセスが利用できないため、コードを調べてカバレッジをテストする機能は制限されています。 |
グレーボックステスターはソースコードに依存しません。代わりに、インターフェイスの定義と機能仕様に依存しています。 | ソフトウェア設計者がすでにテストケースを実行している場合、テストは冗長になる可能性があります。 |
利用可能な限られた情報に基づいて、グレーボックステスターは、特に通信プロトコルとデータ型処理に関する優れたテストシナリオを設計できます。 | 考えられるすべての入力ストリームをテストすることは、不当な時間がかかるため、非現実的です。したがって、多くのプログラムパスはテストされません。 |
テストは、設計者ではなくユーザーの観点から行われます。 |
試験方法の比較
次の表に、ブラックボックステスト、グレーボックステスト、およびホワイトボックステストを区別するポイントを示します。
ブラックボックステスト | グレーボックステスト | ホワイトボックステスト |
---|---|---|
アプリケーションの内部動作を知る必要はありません。 | テスターは、アプリケーションの内部動作に関する知識が限られています。 | テスターは、アプリケーションの内部動作について完全な知識を持っています。 |
クローズドボックステスト、データ駆動型テスト、または機能テストとも呼ばれます。 | テスターはアプリケーションの内部に関する知識が限られているため、半透明テストとも呼ばれます。 | クリアボックステスト、構造テスト、またはコードベースのテストとも呼ばれます。 |
エンドユーザーだけでなく、テスターや開発者によっても実行されます。 | エンドユーザーだけでなく、テスターや開発者によっても実行されます。 | 通常、テスターと開発者によって行われます。 |
テストは外部の期待に基づいています-アプリケーションの内部動作は不明です。 | テストは、高レベルのデータベース図とデータフロー図に基づいて行われます。 | 内部の仕組みは完全にわかっており、テスターはそれに応じてテストデータを設計できます。 |
それは網羅的で、最も時間のかからないものです。 | 部分的に時間がかかり、網羅的です。 | 最も徹底的で時間のかかるタイプのテスト。 |
アルゴリズムのテストには適していません。 | アルゴリズムのテストには適していません。 | アルゴリズムテストに適しています。 |
これは試行錯誤の方法でのみ行うことができます。 | わかっている場合は、データドメインと内部境界をテストできます。 | データドメインと内部境界をより適切にテストできます。 |