ブラック ボックス テストは、機能テスト、データ駆動型テスト、または要件仕様に基づく機能テストとも呼ばれます。このタイプのテストは、ソフトウェアの機能要件のテストに重点を置きます。プログラムの内部論理構造や内部特性を全く無視して、テスト対象をブラックボックスとして扱い、プログラムの機能がプログラムの「要件仕様書」に従った機能記述に適合しているかどうかだけをチェックします。テスターはプログラムコードの内部構造を理解する必要がなく、ソフトウェア製品のエンドユーザーがソフトウェアを使用することを完全にシミュレートし、ソフトウェア製品がユーザーのニーズを満たしているかどうかを確認します。ブラックボックス テスト方法では、テスト対象システムの機能要件の実現をユーザーの観点からより適切かつ現実的に検査できます。ブラックボックステストは単体テスト、結合テスト、システムテスト、受け入れテストなどソフトウェアテストのあらゆる段階で重要な役割を果たしており、特にシステムテストと確認テストにおいては他のテスト手法では代替できない役割を果たしています。
「ブラックボックス」テストモデル：ソフトウェアやプログラムを利用する観点から、入力データと出力データの対応関係からテストを行うモデル。
効果
外部機能自体の設計に問題がある場合や、仕様が間違っている場合は、ブラックボックステストでは発見できません。したがって、ブラック ボックス テストはホワイト ボックス テストに代わることはできません。ブラック ボックス テストは、ソフトウェアの機能要件のテストに焦点を当てており、主に次のエラーを検出するプログラム インターフェイスのテストです。
- 機能エラーまたは機能の欠落。
- インターフェースエラーまたはインターフェースエラー。
- パフォーマンスエラー。
- 入力データを正しく受け取り、正しい出力結果を生成できるかどうか (入力、出力)
- データ構造エラーや外部情報アクセスエラーの有無。
- プログラムの初期化および終了にエラーはありませんか。
メインコンテンツ
(1) 受け入れテスト。
ブラックボックステストは、テスト出力結果をソフトウェアのインターフェースから受け入れるものであり、受け入れテストの特徴を持っています。
(2) α/βテスト。
テストはプロジェクトチームのメンバーがテスト対象のソフトウェアに対して実行するテストで、アルファ/ベータテストはプロジェクトチーム以外の人が参加するテストです。アルファ/ベータ テストはブラック ボックス テストにも適しています。つまり、テストでエラーが見つかり、開発者がそれを修正すると、プロジェクト マネージャーもそれに対応して製品計画を調整し、製品の機能は常に修正されます。
(3) メニュー/ヘルプのテスト。
ソフトウェアテストの過程で、開発者はテスターが発見したエラーを修正したり、ソフトウェアの一部の機能を変更したりすると同時に、プロジェクトマネージャーは状況に応じてソフトウェアの特性を調整します。ソフトウェア開発とテストのプロセスで、すべての機能を調整できます。したがって、ソフトウェア製品開発の最終段階では、ほとんどの問題がドキュメントで見つかることがよくあります。
(4) リリーステスト。
正式リリース前に、製品は非常に慎重にテストされます。専任のテスターに加えて、製品の使用を通じてテストするには、何千人、さらには何十万人もの他のユーザーや協力者が必要です。その後、リリーステスト時にエラー情報が技術部門にフィードバックされ、修正が必要なエラーがあればソフトウェアのリリースを延期し、延期期間中にソフトウェア製品の再修正が必要となります。 - 包括的にテストされるため、多くの時間、人的資源、物理的リソースが消費されます。
(5) 回帰テスト。
この段階では、まず、以前に見つかったエラーが修正されたかどうかがチェックされます。回帰テストにより、修正されたバグの再発が防止され、新しいバグが発生することはありません。
(6) RTM テスト。
RTM テストとは、製品リリース段階で実施されるテストを指します。このテスト段階では、すべてのエラーを高レベルの承認を得て修正する必要があります。現時点ではソフトウェアを変更して他のエラーを発生させるのは非常に簡単であるため、修正が許可されるのは修復できないエラーのみです。リリース段階でソフトウェアに重大なエラーが多数存在する場合、予定どおりにリリースすることはできません。
標準
ブラック ボックス テストで設計されたテスト ケースのセットは、次の 2 つの基準を満たす必要があります。
- テスト ケースを設計すると、合理的なテストを実現するために設計する必要があるテスト ケースの総数を減らすことができます。
- テスト ケースは、特定のテストに関連するエラーがあるかどうかを単に指摘するのではなく、特定の種類のエラーがあるかどうかを示すように設計されています。
試験方法
1. 等価クラスの分割 等価クラス
の分割方法は、プログラムの入力領域をいくつかの部分（サブセット）に分割し、各部分から代表的な少数のデータをテストケースとして選択する方法です。各クラスの代表データは、テストにおけるこのクラスの他の値と等価です、つまり、特定のクラスの 1 つの例でエラーが見つかった場合、この等価クラスの他の例でも同じエラーが見つかります。
等価クラスは、入力ドメインのサブセットを参照します。このサブセットでは、個々の入力データはプログラム内のエラーを発見するのに等価であり、ある等価クラスの代表値をテストすることは、このクラスの他の値をテストすることと同等であると想定するのが合理的です。したがって、すべての入力データをいくつかの同値クラスに合理的に分割でき、各同値クラスの 1 つのデータがテストの入力条件として取得されるため、少量の代表的なテスト データを使用してより良いテスト結果を得ることができます。
同値クラス分割には、有効な同値クラスと無効な同値クラスの 2 つの異なるケースがあります。
有効等価クラス: プログラムの仕様にとって合理的で意味のある入力データのセットを指します。有効な等価クラスを使用すると、プログラムが仕様で指定された機能や性能を実装しているかどうかを確認できます。
無効な同値クラス: 有効な同値クラスの定義の正反対。
同値クラス分割法を用いてテスト計画を設計するには、まずプログラム（ソフトウェア）の機能記述を検討し、次に入力データの同値クラスを分割し、分割した同値クラスに応じてテストケースを設計する必要がある。テスト ケースの設計は次の原則を満たしています。
1. 各同値クラスに一意の番号を指定します;
2. すべての有効な同値クラスがカバーされるまでカバーされていない有効な同値クラスをできるだけカバーするように新しいテスト ケースを設計します; 3. 新しいテスト ケースを設計し
ますすべての無効な同値クラスがカバーされるまで、カバーされていない無効な同値クラスを可能な限りカバーします。
例：
都市の電話番号は 2 つの部分で構成されます。これら 2 つの部分の名前と内容は次のとおりです:
1) 市外局番: 0 で始まる 3 桁または 4 桁 (0 を含む)、
2) 電話番号: 0 以外または 1 以外で始まる 7 桁または 8 桁。
デバッグ中のプログラムが上記の要件を満たすすべての電話番号を受け入れ、要件を満たさないすべての番号を拒否できると仮定して、等価分類法を使用してテスト ケースを設計してください。
要件: まず同値クラスを分割し、次にカバレッジ ルールに従ってすべての同値クラスをカバーします。
2. 境界値分析
境界値分析は、同値クラスの境界にあるテスト ケースを選択することによって行われます。境界値分析では、入力条件の境界に注意を払うだけでなく、出力領域の境界も考慮する必要があります。これは、同値クラス分割方法の補足です。
境界値分析テスト ケースの設計原則:
- 1. 入力条件で値の範囲が定められている場合は、その範囲の境界に達する直前の値と、この範囲の境界を越える直前の値をテスト入力データとします。
例: 値の範囲「1 ～ 9」を入力すると、入力テスト ケースは次のようになります: 1、9、0.9、9.1- 2. 入力条件に値の個数が指定されている場合は、最大値、最小値、最小値から 1 を引いた値、および最大値から 1 を加えた値をテスト データとして使用します。
例: 入力ファイルには 1 ～ 64 のレコードを含めることができ、入力テスト ケースは次のようになります: 1、64、0、65 (レコード)- 3. 仕様に記載されている各出力条件に従って、前の原則 1 を使用します。
- 4. プログラムの仕様で指定された入力フィールドまたは出力フィールドが順序集合である場合、その集合の最初の要素と最後の要素をテスト ケースとして選択する必要があります。
- 5. プログラム内で内部データ構造が使用されている場合、内部データ構造の境界上の値をテスト ケースとして選択する必要があります。
- 6. 仕様を分析して、他の考えられる境界条件を見つけます。
3. 因果関係図
同値クラス分割も境界値分析も、入力条件を考慮することに重点を置いていますが、入力条件の接続や組み合わせについては考慮していません。因果関係グラフ法は、入力条件間の相互の組み合わせや相互の制約関係を十分に考慮したものです。
因果関係図の基本的な表記法:
- 同一性: 原因と結果が 1 対 1 で対応していることを示します。原因があれば結果が生じ、原因が生じなければ結果は生じません。
- Not: 原因と結果の間に否定的な関係があることを示します。原因があれば結果は生じず、原因があれば結果が生じます。
- または: いくつかの理由のうちの 1 つが発生した場合に結果が表示され、これらの理由のいずれも表示されなかった場合にのみ結果が表示されないことを意味します。
- そして：原因が複数現れて初めて結果が現れるということです。原因のどれかが発生しなければ、結果も発生しません。
因果関係グラフにおける制約の表記:
- E（排他的）：aとbの2つの理由は同時に成立せず、どちらか一方しか成立しないことを示します。
- I (両端を含む): 3 つの理由 a、b、c のうち少なくとも 1 つが真である必要があることを示します。
- ○（ユニーク）：a、bのいずれかが必ず存在し、どちらか一方のみが成立することを示します。
- R（必須）：aが出現する場合にはbも出現する必要があることを示します。a が発生し、b が発生しないことは不可能です。
- M (マスク): a が 1 の場合、b は 0 でなければならないことを示します。そして、a が 0 の場合、b の値は不確かになります。
因果関係図を含むテスト ケースを生成する基本手順:
- 解析ソフトウェアの仕様の記述では、原因（つまり、入力条件または入力条件の等価クラス）がどれであり、結果（つまり、出力条件）がどれであるかを示し、それぞれの原因に識別子を割り当てます。そして効果。
- ソフトウェア仕様記述のセマンティクスを分析します。原因と結果、原因と原因の間の対応関係を見つけてください。これらの関係に基づいて、因果関係図を描きます。
- 原因と原因の組み合わせ、および原因と結果の間の組み合わせの中には、文法または環境上の制約により不可能なものもあります。これらの特殊なケースを示すために、因果図上に制約または制限が記号でマークされます。
- 因果関係図を意思決定表に変換します。
- テスト ケースを設計するための基礎として、デシジョン テーブルの各列を取り出します。
因果関係図（局所的、組み合わせ関係下）から生成されるテストケースには、すべての入力データの真偽をとるケースが含まれており、作成されるテストケースの数は最小となり、テストケースの数は増加に伴って直線的に増加します。入力データ数の増加 増加します。
4. デシジョンテーブルの構成方法
デシジョンテーブルは、これまでの因果関係図法で使用されてきました。デシジョンテーブルは、複数の論理条件が異なる操作を実行する状況を分析および表現するためのツールです。
- 条件スタブ: 問題のすべての条件をリストします。条件をリストする順序は、一般に重要ではないと考えられています。
- アクション スタブ: 質問で指定された可能なアクションをリストします。これらの操作をリストする順序に制約はありません。
- 条件項目 (条件エントリ): 左側の列に条件の値がリストされます。考えられるすべてのケースにおける True と False の値。
- アクション項目 (アクションエントリ): 条件項目のさまざまな値の下で実行する必要があるアクションをリストします。
ルール: 条件の任意の組み合わせの特定の値と、対応する実行される操作。デシジョンテーブルの条件項目とアクション項目を貫く列がルールです。明らかに、デシジョンテーブルに多数の条件値のセットがリストされるのと同じ数のルール、つまり、条件項目とアクション項目と同じ数の列も存在します。
デシジョンテーブルを作成する手順:
① ルールの数を決定します。条件が n 個ある場合、各条件は 2 つの値 (0, 1) を持つため、2n 種類のルールが存在します。
② 条件パイルとアクションパイルをすべてリストアップします。
③条件項目を入力します。
④ 実施項目を記入します。最初の決定テーブルまで待ちます。
⑤簡素化する。類似したルール (同じアクション) をマージします。(オプション)
例：
ある学校の教員報酬の計算計画は次のとおりである:
(l) 基本教員報酬は 1 クラスあたり 10 元、
(2) クラスの生徒数が 40 名を超えると、教員報酬は増加する: 基本教員報酬 × 0.1;
(3) クラスの学生数が60人を超える場合 1人あたり報酬が増額：基本報酬×0.2; (
4) 教員が准教授の場合は報酬が増額：基本報酬×0.1;
(5) ) 教員の場合、報酬が増額：基本報酬×0.2
(6) 講師の場合、報酬は増額なし、
(7) ティーチングアシスタントの場合、報酬は減額：基本報酬×0.1。
5. ランダム テスト
ランダム テストとは、テスト入力データがすべての可能な入力値からランダムに選択されることを意味し、基本的な「ブラック ボックス」テスト方法です。ランダム選択では、擬似乱数ジェネレーターやハードウェア ランダム シミュレーターなどのランダム シミュレーション手法を使用して入力データを生成します。この方法では大量のテスト データを取得でき、テスターは入力変数の値の範囲を指定し、必要に応じて必要な変換メカニズムを提供するだけで、生成された乱数が期待される確率分布に従うようになります。
6. 間違った方法を推測する
間違った方法を推測することは、経験と直観に基づいて、プログラム内で考えられるすべてのエラーを推測し、的を絞った方法でテスト ケースを設計します。
間違った方法を推測する基本的な考え方は、プログラム内で考えられるすべてのエラーと、エラーが発生しやすい特殊なケースを列挙し、それらに従ってテスト ケースを選択することです。プログラムでエラーが発生しやすい状況としては、①入力データが 0 または出力データが 0 の場合、②入力または出力の数が変更できる場合、入力または出力の数が 1 または 0 などです。さらに、プログラムの仕様を注意深く分析し、欠落または省略された部分を見つけて対応するテスト計画を設計し、プログラマーがこれらの部分を正しく処理しているかどうかを確認する必要があります。
7. シナリオ
方式 ほとんどのソフトウェアはイベントトリガを使って処理を制御しており、イベントをトリガとするシナリオがシナリオを構成し、同じイベントの異なるトリガシーケンスや処理結果がイベントフローを構成します。ソフトウェア設計におけるこの種の考え方は、ソフトウェア テストにも導入できます。これにより、イベントがトリガーされたときの状況が生き生きと描写され、テスト設計者がテスト ケースを設計するのに役立ち、同時にテスト ケースを理解しやすくなり、実行する。
基本フローと代替フロー: 図 1 に示すように、図 1 のユース ケースを通る各パスは基本フローと代替フローで表され、黒い直線は基本フローを表します。これは、ユース ケースを通る最も単純なパスです。 。代替ストリームは、異なる色で表されます。代替ストリームは、基本ストリームから開始し、特定の条件下で実行され、その後、基本ストリームに再結合する場合があります (代替ストリーム 1 および 3 など)。また、別の代替ストリームから発生する場合もあります。フロー (代替フロー 2 など) を選択するか、フロー (代替フロー 2 および 4 など) に再参加せずにユース ケースを終了します。
ブラックボックス テストの利点: 機能テスト、ユーザビリティ テスト、受け入れ可能性テスト、命令に対するプログラム機能のテストに適しており、長く複雑なプログラムの動作ロジックをテストでき、理解しやすいです。
ブラックボックス テストの欠点: 完全かつ完全な入力テストを実行することは不可能であり、一部のソフトウェアのバグや人為的な障害はブラックボックス テストでは検出できません。ブラックボックス テストのテスト データは仕様に基づいているため、このアプローチの主な欠点は、仕様の正確さに依存することです。実際、仕様書が完全に正しいことを保証することはできません。仕様に冗長な機能が指定されたり、一部の機能が省略されたりすると、ブラックボックステストとしてはまったく無力になってしまいます。