どのテスト工程にも言えることですが、テストはソフトウェアが期待通りに動作することを確認するために行います。
言い換えると、ソフトウェアが設計・仕様どおりに動作することを確認します。
テスト対象に与えた入力に対し、期待した出力が得られることを確認するテストを、ブラックボックステストといいます。
ブラックボックステストでは、テスト対象内の処理には一切着目しません。
ブラックボックステスト
| テスト項目作成の インプット情報 | ・ユニットテストの場合は詳細設計 |
|---|---|
| 長所 | ・テスト項目を設計書から作成するので、設計どおりに実装されているかを検証可能 |
| 短所 | ・内部のソースコードを見ていないため、ゼロ割になる箇所はないかなど実装観点での欠陥検出が困難 ・内部のソースコードを見ていないため、全ルートを網羅するデータを与えることは困難 ・設計書からテスト項目を作成するため、テストの品質は詳細設計の品質に影響されてしまう |
関数単位のユニットテストにおけるブラックボックステストの場合は、以下のように定義できます。
ユニットテストにおけるブラックボックステスト
詳細設計に定められた入力が関数に与えられた場合、詳細設計に定められているとおりに出力することを確認します。
ここでいう『詳細設計』は、必ずしも文書形式のものである必要はありません。
プログラマが関数を作成する際にインプットとして使用した情報が『詳細設計』となります。
Keyword
| ブラックボックステスト | システムの内部構造とは無関係に、外部から見える機能を検証するテスト方法 |
|---|
補足
ISTQBでは、テスト技法を「経験ベース※」「仕様ベース」「構造ベース」の3つに分類しています。
「仕様ベース」および「経験ベース」のテスト技法はブラックボックステスト技法にあたります。
※テストを行う担当者が持つスキルや開発経験、ユーザの利用実態に関する情報、勘などをもとに行うテスト技法。
経験豊富なベテランが、一通りのテストが終わった後の最終確認的なテストとして実施すれば、一定の効果が期待できる。