key differences between black box testing
ブラックボックステストとホワイトボックステストの徹底的な調査：
ソフトウェアテストにはいくつかの種類のテストが含まれ、ソフトウェアテスターとして、それぞれがどのように実行されるかを知る必要があります。
さまざまなタイプのテストの中で、最も紛らわしいトピックの1つは、ブラックボックステストとホワイトボックステストのトピックです。多くのソフトウェアテスターは、これら2つのタイプのテストの間に類似性があるかどうか疑問に思います。どちらもどのように実行されますか？それらは両方とも一緒に実行されますか？
このドキュメントでは、すべての質問に回答し、ブラックボックステストとホワイトボックステストの基本的な考え方を説明し、それらの違いを簡単に説明します。 。
配列javaから要素を削除します
学習内容：
ブラックボックステストとは何ですか？
ISTQBの定義– ブラックボックステスト： 内部構造を参照せずに被テストアプリケーション（AUT）をテストすることは、ブラックボックステストと呼ばれます。テストは、アプリケーションをブラックボックスとして視覚化することによって行われます。
ブラックボックステスト手法： システムの内部構造を考慮せずに、アプリケーションの機能に基づいてテストケースを導出するためのテスト手法。
同義語： 仕様ベースのテスト
ブラックボックステストは、テスト対象のアプリケーションの実装に使用されるテクノロジの知識がなくても、仕様/ SRSに基づいてAUTの機能をテストするために使用されるテストアプローチです。
ブラックボックステストでは、主要なテストは可能な入力と期待される出力に関するものです。テスターは、有効なテストデータを慎重に選択できる必要があります。簡単に言うと、テスターはAUTのアクションしか見ることができません。テスターは、これらのアクションがどのように実行されるかを知る必要はありません。
例： ブラックボックステストの簡単な例は、テレビ（テレビ）です。ユーザーとしてテレビを見ますが、テレビの作り方や仕組みなどの知識は必要ありません。リモコンの操作方法を知っていれば、電源を入れたり、切ったり、チャンネルを変更したりできます。音量の増減など。
この例では、
ザ・ テレビ あなたの AUT（テスト中のアプリケーション）。
ザ・ リモコン テストに使用するユーザーインターフェイス（UI）です。
あなたはただアプリケーションの使い方を知る必要があります。
推奨読書=> ブラックボックステストについて知っておくべきことすべて
ホワイトボックステストとは何ですか？
ISTQBの定義– ホワイトボックステスト： ソフトウェアコンポーネントの内部構造を参照してアプリケーションをテストすることを、ホワイトボックステストと呼びます。
ホワイトボックステスト手法： コンポーネントまたはシステムの内部構造の分析に基づいてテストケースを導出および/または選択する手順。
同義語： クリアボックステスト、コードベースのテスト、ガラスボックステスト、ロジックカバレッジテスト、ロジック駆動型テスト、構造テスト、構造ベースのテストなど。
ホワイトボックステストは、テスト対象のアプリケーションの実装部分をテストするために使用されるテストアプローチです。このテストを実行するには、テスター/おそらく開発者は、アプリケーションの内部構造とその動作を知っている必要があります。
アトムエディターとビジュアルスタジオコード
例： 自動車整備士は、それを修理するために車のエンジンの内部構造を知っている必要があります。
この例では、
車 それは AUT（テスト中のアプリケーション）。
ザ・ ユーザー それは ブラックボックステスター。
ザ・ メカニック それは ホワイトボックステスター。
これらはホワイトボックステストとブラックボックステストの基本的な定義であり、各テスト方法には従うべき異なる手法があります。
推奨読書=> ホワイトボックステストに関する詳細なチュートリアル
ブラックボックステストとホワイトボックステストの違い
| S.No | ブラックボックステスト | ホワイトボックステスト |
|---|---|---|
| 7 | テストケースには、入力条件、テストステップ、期待される結果、およびテストデータに関する詳細が含まれます。 | テストケースは、ステートメント、コードカバレッジなどの技術的概念の詳細を含む単純なものになります。 |
| 1 | このテストの主な目的は、アプリケーションの機能/動作をテストすることです。 | 主な目的は、アプリケーションのインフラストラクチャをテストすることです。 |
| 二 | これは、AUT（Application Under Test）のコーディング知識がなくてもテスターが実行できます。 | テスターは、内部構造とその仕組みに関する知識を持っている必要があります。 |
| 3 | テストはGUIを使用してのみ実行できます。 | GUIの準備が整う前に、テストを早い段階で行うことができます。 |
| 4 | このテストでは、考えられるすべての入力を網羅できるわけではありません。 | このテストは、各パスをテストできるため、より徹底的です。 |
| 5 | いくつかのテスト手法には、境界値分析、等価分割、エラー推測などが含まれます。 | 一部のテスト手法には、条件付きテスト、データフローテスト、ループテストなどがあります。 |
| 6 | テストケースは、要件仕様に基づいて作成する必要があります。 | テストケースは、詳細設計ドキュメントに基づいて作成する必要があります。 |
| 8 | これは、プロのソフトウェアテスターによって実行されます。 | これはソフトウェア開発者の責任です。 |
| 9 | プログラミングと実装の知識は必要ありません。 | プログラミングと実装の知識が必要です。 |
| 10 | 主に、受け入れテスト、システムテストなどの高レベルのテストで使用されます。 | 主に、単体テストや統合テストなどの低レベルのテストで使用されます。 |
| 十一 | これにより、時間がかからず、網羅的です。 | これは、より時間がかかり、網羅的です。 |
| 12 | テストデータには幅広い可能性があるため、正しいデータを特定するのは困難です。 | 機能の特定の部分のみが一度に焦点を合わせられるため、テストデータを簡単に識別できます。 |
| 13 | テスターの主な焦点は、アプリケーションがどのように機能しているかにあります。 | 主な焦点は、アプリケーションの構築方法です。 |
| 14 | すべてのシナリオのテストデータを作成できるわけではないため、テストカバレッジは少なくなります。 | 部分的にテストするのは簡単なので、ほとんどすべてのパス/アプリケーションフローがカバーされています。 |
| 15 | コード関連のエラーを特定できないか、技術的なエラーを特定できません。 | 隠れたエラーを特定し、コードを最適化するのに役立ちます。 |
| 16 | 基本コードが開発されると、欠陥が特定されます。 | 早期の欠陥検出が可能です。 |
| 17 | このテストの範囲は広いため、ユーザーは不足している機能を特定できるはずです。 | スコープは実装された機能のみに制限されているため、テスターは欠落している機能を識別できません。 |
| 18 | コードアクセスは必要ありません。 | コードアクセスが必要です。 |
| 19 | テスターは技術的な側面についての知識が限られているため、テストカバレッジは少なくなります。 | テスターが技術的概念についてより多くの知識を持っているので、テストカバレッジはより多くなります。 |
| 20 | プロのテスターの焦点は、アプリケーション全体がどのように機能しているかにあります。 | テスター/開発者の焦点は、特定のパスが機能しているかどうかを確認することです。 |
結論
ソフトウェアの配信を成功させるには、ホワイトボックステストとブラックボックステストが必要ですが、どちらの場合も100％テストは不可能です。
テスターの主な責任は、特定のアプリケーションに関連するテストの種類と手法を特定することです。これにより、最大の欠陥が見つかり、アプリケーションの効率が向上します。
テスターは、アプリケーションが期待どおりに機能していることを証明するために、ブラックボックステストまたはホワイトボックステストのいずれかで実行できるテストの量を識別できる必要があります。
このチュートリアルで、ブラックボックスとホワイトボックスのテストに関するすべてのクエリが明確になったことを願っています。