2024.02.27
ブラックボックステストとは、ソフトウェアテストの手法の一つです。
ソフトウェアの内部構造は意識せずに、入力値と出力結果に着目してテストの振る舞いを確認します。そのため、「振る舞い技法」「振る舞いベースの技法」と呼ばれることもあります。
本記事では、ブラックボックステストの特徴や、ホワイトボックステストとの違いなどについてご紹介します。
また、ブラックボックステストでは、確認すべき条件や入出力値を洗い出したり、膨大な数に及ぶテスト項目を効率的に絞り込んだりするためにさまざまなテスト技法が利用されます。そこで、ブラックボックステストでよく使用される４つの技法と、ブラックボックステストでは検知できない不具合についても解説します。
- もくじ
1．ブラックボックステストとは
ブラックボックステストとは、テスト対象の内部構造を把握せずに入力値と出力結果を確認するテストです。この章では、ブラックボックステストの特徴と、ブラックボックステストとホワイトボックステストの違いについて解説していきます。
1-1 ブラックボックステストの特徴
ブラックボックステストは、ソースコードではなくシステムの外部仕様に基づいてテストを行います。つまり、意図した処理がシステム外部から見て適切に機能することはもちろん、画面配置やシステムの操作性などのUI/UXの観点に基づいたソフトウェアの品質も重要な観点となります。
実際のソフトウェアやそれを搭載したシステムで検証を行うことで、ユーザーと同じようにシステムを利用する立場に立った検証ができる点が、ブラックボックステストの大きな特徴です。
また、システムを包括的に扱うため、機能を連携させた際に時に初めて起こる不具合なども見つけやすく、設計者の想定漏れを補う性質を持っています。設計通りにシステムが動くことよりも、製品全体の要求や仕様を満たすかどうか確認することができます。
1-2 ホワイトボックステストとの違い
テスト対象の内部構造を見ずに正常な動作を確認する「ブラックボックステスト」に対し、モジュール単位での機能を確認する「ホワイトボックステスト」があります。ブラックボックステストとの決定的な違いは、「内部構造が分かった上で正しく機能するかどうかを確かめる」という点です。
ソフトウェアテストでは、必ずホワイトボックステストとブラックボックステストの両方を行います。ホワイトボックステストとブラックボックステストには一長一短があるため、それぞれの性質を理解した上で適切に使い分けることをおすすめします。
2．ブラックボックステストで使われる4つの技法
ブラックボックステストでよく使用される技法は主に4つです。それぞれどういったテスト技法なのか解説していきます。
2-1 同値分割法・境界値分析
同値分割法(同値クラス分割)とは、出力結果が同じ結果となる入力値の集合を区分して行うテストです。テストする「値」を絞り込むことができるため、テスト工数を削減できます。
境界値分析(限界値分析)は、仕様条件の境界となる値とその隣の値に対してテストする技法です。境界値にはバグが潜在していることが多いため、効率的にバグの検出をすることができます。
2-2 状態遷移テスト
状態遷移テストとは、設計仕様どおりにイベントによってソフトウェアの状態が変化することを確かめるテストのことです。
状態遷移テストでは、システムの全体像を状態とイベントに分けて、その因果関係を図表でまとめた「状態遷移図」「状態遷移表」を活用します。ユーザーの実際のシステム利用状況を整理できるため、ソフトウェアの設計段階で作成することもあります。
2-3 デジションテーブルテスト
デシジョンテーブルとは、さまざまな条件（入力）で、どのようにソフトウェアが動作（出力）するのかを、表形式で整理したものです。
条件を漏れなく重複なく洗い出した上で論理的に起こり得る組み合わせを採用できる方法で、網羅性が高く効率的な手法と言えます。
2-4 組合せテスト
組合せテストでは、直交表やAll Pairs法などの手法を使用します。
この2つの手法では、テスト結果を左右するパラメータとしての「因子」と、その因子ごとに起こり得る値である「水準」を組み合わせた表を用います。例えば、「性別」という因子に対して、「男性」「女性」の2つの水準があります。このような因子と水準を複数設けて表にする、というイメージです。
直交表を用いたテストでは、複数の因子の中から任意に2つの因子を選び、そのすべての水準を組み合わせてテストします。一方All Pairs法を用いたテストでは、任意の2つの因子に対して、そのすべての水準を1回以上組み合わせるようにしてテストします。
3．ブラックボックステストでは検出できないバグ・不具合
ブラックボックステストで焦点となるのは「ソフトウェアの外部仕様」です。
そのため、以下のような不具合は見つけられません。
3-1 仕様に表れない内部的・潜在的不具合
ブラックボックステストの場合は、入力値に対する出力値を確認します。
そのため、例えば内部での値の処理が不十分にもかかわらず画面制御やエラー処理によって適切な値に変換されていたら、それに気づくことはできません。このような場合、画面仕様の変更などがあった際に後から不具合として検知されることがあります。
また、ソースコードの冗長さもブラックボックステストでは確認できません。
3-2 入力値の選択方法によって見逃してしまった内部構造上重要な不具合
ブラックボックステストでは、内部構造を知らないままテスト条件を削減します。そのため、ソースコードの書き方によっては重要な入力値のテストが見逃されたり、たまたま条件が重なって仕様通りの結果が出てしまったりする可能性もあります。
入力値の選択には、前のセクションで述べた技法や経験が必須だと言えます。
まとめ
今回は、ブラックボックステストの基本からよく使用される技法までご紹介しました。
ブラックボックステストは、実際のソフトウェアやそれが搭載されたシステムで検証をするため、ユーザー視点に立ったテストができます。
しかし、内部構造についての詳細な確認はできないため、ブラックボックステストでは潜在的なバグや不具合を検知しきれない可能性があります。ブラックボックステストと対称的なホワイトボックステストを組み合わせてテストを行い、ソフトウェアのバグや不具合を検出していくことが重要です。
