トレンド情報 / 記事を探すCOLUMN

おさらいしよう!「ブラックボックステスト」の基本

更新日|2018.07.04

Qbook編集部

おさらいしよう!「ブラックボックステスト」の基本

プログラムの内部構造には着目せず、入力値と出力結果を確認するテストが「ブラックボックステスト」です。ブラックボックステストでは、確認すべき条件や入出力値を洗い出したり、膨大な数に及ぶテスト項目を効率的に絞り込んだりするためにさまざまなテスト技法が利用されます。

今回は、ブラックボックステストの基本とテスト設計時に利用される技法をご紹介します。

ブラックボックステストとは

8607-00009-02

本稿では、「実体のある機械やシステム装置において、その機械の原理や機構いわゆる中身を把握していなくても、その機械装置の働きを理解でき、利用できること」を「ブラックボックス」と定義します。

単純にいうと、中身は見えないけど、何かを入れたら何かが出てくる、何かを働きかけたら何か結果が出てくる、といったもののことです。

つまり、テスト対象の内部構造を把握せずに入力値出力結果を確認するテストを「ブラックボックステスト」と言います。

テスト工程についての詳細はこちらをご参照ください。

例えば、顧客名簿システムの検索機能にブラックボックステストを行う場合、顧客名や顧客IDを入力し、名称・IDに紐づく顧客名が出力されるかを確認します。このとき、テスト対象の内部で何がどのように処理しているのかは考慮に入れません。

なお、ブラックボックステストは単体テスト、結合テスト、システムテストのすべてのテスト工程でも実施が可能ですが、主にシステムテストで使用されることが多いです。

よって、ブラックボックステストは、ソフトウェアを利用する顧客の使用状況を想定して、データの入出力を確認するテストとも言えるでしょう。

ブラックボックステストの特徴

8607-00009-03

ブラックボックステストは、ソースコードではなくシステムの外部仕様に基づいてテストを行います。つまり、意図した処理がシステム外部から見て適切に機能することはもちろん、画面配置やシステムの操作性などのUI/UXの観点に基づいたソフトウェアの品質も重要な観点となります。

実際のソフトウェアやそれを搭載したシステムで検証を行うことで、ユーザーと同じようにシステムを利用する立場に立った検証ができる点が、ブラックボックステストの大きな特徴です。

また、システムを包括的に扱うため、機能を連携させた際に時に初めて起こる不具合なども見つけやすく、設計者の想定漏れを補う性質を持っています。設計通りにシステムが動くことよりも、製品全体の要求や仕様を満たすかどうか確認することができます。

ブラックボックステストで使用される技法について

ブラックボックステストでよく使用される技法4つを以下でご紹介します。

【網羅型】

テスト対象とするシステムの動作や条件を洗い出し、整理する際に用いる技法です。

状態遷移図・状態遷移表

システムの全体像を状態とイベントに分けて、その因果関係を図表でまとめたものです。ユーザーの実際のシステム利用状況を整理できるため、ソフトウェアの設計段階で作成することもあります。

デジションテーブル

ステータスやユーザーの動作、入力値などの条件を組み合わせた結果、システム上どのような結果が得られるかを表にまとめたものです。条件を漏れなく重複なく洗い出した上で論理的に起こり得る組み合わせを採用できる方法で、網羅性が高く効率的な手法と言えます。

【削減・標的型】

洗い出したテスト対象の条件・期待値の組み合わせのうち、実際にテストを行う対象を網羅性の高いテストケースを効率良く選び出すための技法です。

同値クラス分割・境界値分割

同値クラス分割とは、システムの動作や入力値などのうち、同じとみなせるもの同士でグループ化する技法です。境界値分割は、同値クラス分割で作成したグループ間の境界にあたる値をテストデータとして採用する技法です。両方の手法を合わせて利用するとより効果的と言えます。

直交表やAll Pairs法などの組み合わせ技法

この2つの技法では、テスト結果を左右するパラメータとしての「因子」と、その因子ごとに起こり得る値である「水準」を組み合わせた表を用います。例えば、「性別」という因子に対して、「男性」「女性」の2つの水準があります。このような因子と水準を複数設けて表にする、というイメージです。

直交表を用いたテストでは、複数の因子の中から任意に2つの因子を選び、そのすべての水準を組み合わせてテストします。一方All Pairs法を用いたテストでは、任意の2つの因子に対して、そのすべての水準を1回以上組み合わせるようにしてテストします。

ブラックボックステストでは検出できないバグ・不具合とは?

ブラックボックステストで焦点となるのは「ソフトウェアの外部仕様」です。

そのため、以下のような不具合は見つけられません。

仕様に表れない内部的・潜在的不具合

ブラックボックステストの場合は、入力値に対する出力値を確認します。

そのため、例えば内部での値の処理が不十分にもかかわらず画面制御やエラー処理によって適切な値に変換されていたら、それに気づくことはできません。このような場合、画面仕様の変更などがあった際に後から不具合として検知されることがあります。また、ソースコードの冗長さもブラックボックステストでは確認できません。

入力値の選択方法によって見逃してしまった内部構造上重要な不具合

ブラックボックステストでは特に内部構造を知らないままテスト条件を削減するため、ソースコードの書き方によっては重要な入力値のテストが見逃されたり、たまたま条件が重なって仕様通りの結果が出てしまったりする可能性もあります。入力値の選択には、前のセクションで述べた技法や経験が必須だと言えます。

「ホワイトボックステスト」との違いは?

テスト対象の内部構造を見ずに正常な動作を確認する「ブラックボックステスト」に対し、モジュール単位での機能を確認する「ホワイトボックステスト」があります。ブラックボックステストとの決定的な違いは、「内部構造が分かった上で正しく機能するかどうかを確かめる」という点です。

ソフトウェアテストでは、必ずホワイトボックステストとブラックボックステストの両方を行います。ホワイトボックステストとブラックボックステストには一長一短があるため、それぞれの性質を理解した上で適切に使い分けることをおすすめします。

参考:おさらいしよう!「ホワイトボックステスト」の基本)

おわりに

今回は、ブラックボックステストの基本からよく使用される技法までご紹介しました。

ブラックボックステストは、実際のソフトウェアやそれが搭載されたシステムで検証をするため、ユーザー視点に立ったテストができます。

しかし、内部構造についての詳細な確認はできないため、ブラックボックステストでは潜在的なバグや不具合を検知しきれない可能性があります。ブラックボックステストと対称的なホワイトボックステストを組み合わせてテストを行い、ソフトウェアのバグや不具合を検出していくことが重要です。

資料ダウンロード

ライター:Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。