ソフトウェアテストを実施するのは、ソフトウェア内部の構造を把握する開発者だけではありません。外部のテスター等もソフトウェアテストに加わり、主にこれらテスターによって行われるのが「ブラックボックステスト」です。この記事では、ブラックボックステストの概要や、ブラックボックステストの主なテスト技法について解説しています。

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

一般に内部の構造がどうなっているか分からないもののことを「ブラックボックス」と呼びます。つまり、ブラックボックステストとは内部構造を考慮せず、ソフトウェアが仕様通り設計されているかのみ検証するテストのことです。ブラックボックステストはシステムの内部がどのような構造になっているか理解していなくても行えるため、一般的には開発者以外の第三者が行います。

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

ソフトウェアテストには、コンポーネントごとの単体テストからシステム全体を対象とするシステムテストまで複数のテストレベルがあります。ブラックボックステストは仕様通りの設計かチェックする際に幅広く行われることから、対象となるのはテストレベルのほとんどです。また機能に対するテスト(「機能テスト」)だけでなく、機能以外のユーザビリティなどのテスト(「非機能テスト」)でも実施されます。

ホワイトボックステストとの違い

ブラックボックステスト ホワイトボックステスト

ブラックボックステストとよく比較されるのが、ホワイトボックステストです。ホワイトボックステストは、ソフトウェアの内部構造を理解した上で、設計通りに動作するかチェックするテストを指します。

ホワイトボックステストでは、ソフトウェアの各機能をモジュール単位で解析します。ブラックボックステストと異なり内部構造を熟知している必要があるため、ホワイトボックステストを行うのは主に開発者です。

またホワイトボックステストとブラックボックステストでは、テストする際のポイントにも違いがあります。ホワイトボックステストでは、プログラムの構造に問題ないかをチェックします。一方、ブラックボックステストではインターフェイスの使い勝手のようなユーザビリティのチェックも可能です。

このように、それぞれできることに違いがあることから、両方行う必要があります。いずれか片方だけでは不十分です。

ホワイトボックステストとは?ブラックボックステストとの違いやテスト技法について解説

ブラックボックステストのテスト技法

テスト技法とは、簡単に言うとテスト設計を効率化するための方法のことです。ブラックボックステストには、以下にあげるようなテスト技法の種類があります。

同値分割法

同値分割法とは、正常に処理ができる「有効同値」とエラーとなる「無効同値」を使い、想定通りの動作をするかチェックする技法です。具体的にどんなテストか、格闘ゲームを例に考えてみましょう。

たとえばヒットポイントが100から30以下に減ったら、体力ゲージの色が赤くなる仕様に設計したとします。この仕様が正しく動作するかチェックするのに、同値分割法が使えるのです。この仕様において、体力ゲージが赤くなるヒットポイント20が「有効同値」、赤にならない40が「無効同値」となります。

そうして実際に、これらのヒットポイントに落としてみて体力ゲージの色が仕様通りか試すわけです、このようなテスト技法と同値分割法といいます。

境界値分析(限界値分析)

境界値分析(限界値分析)とは、同値クラスの境界(境界値)に注目したテスト技法です。たとえば先ほどの格闘ゲームの例では、体力ゲージがぎりぎり赤くなる(ならない)ヒットポイント29と30が境界値となります。

境界値分析(限界値分析)では、このぎりぎりの値でテストをして正しく体力ゲージが赤くなる(ならない)かテストするわけです。ソフトウェアでは、実装上この境界値において不具合が発生することが多くなっています。そのため境界値によるテストが行われるのです。

状態遷移テスト

状態遷移テストとは、イベントの発生によってソフトウェアが設計した通りに動作するかをチェックするためのテストです。こちらもゲームを例に、実際にどんなテストなのかみていきましょう。

RPGゲームの戦闘シーンを想定してみましょう。「睡眠攻撃」や「石化攻撃」といった状態異常攻撃を受けたときに、「プレイヤーがその状態に変化するか、またそこから回復できるか」といったことを確認する際に、状態遷移図や状態遷移表に動作をまとめ、仕様を整理していきます。

デシジョンテーブル

ソフトウェアは、いろいろな条件が複雑に絡んで動作が決定することがあります。デシジョンテーブルとは、これらの条件や動作の組み合わせをまとめた表のことです。

これも例を出して考えてみましょう。たとえば健康ランドの割引の例を考えてみます。割引の条件は、以下の通りです。

・毎週水曜日は10%割引
・クーポンを持参すると20%割引
・70歳以上の方は20%割引
・複数の割引を同時に利用することも可能

この例では、複数の条件が組み合わさることによって割引率が変わります。デシジョンテーブルでは、これら条件と起こりえる動作(割引率)をまとめるわけです。このように仕様を整理した上で、表にまとめた通りに動作するかを確認します。

ユースケーステスト

ユースケースとは、ソフトウェアを利用するユーザー(もしくは別システム)の目線に立って、ソフトウェアの動作をまとめたものです。ユースケースをまとめた図のことを「ユースケース図」と呼びます。

たとえばRPGゲームでキャラクターが敵モンスターに出会ったときを想定してみましょう。このときプレイヤーの選択肢として「攻撃する・呪文を使う・道具を使う・逃げる・身を守る」などがあります。ユースケーステストでは、これらユーザーの選択可能な動作をまとめ、ソフトウェアが想定した通り動作するか確認します。

ブラックボックステストのデメリット

ブラックボックステストは、内部構造をみません。そのため表面的には正常な動作をしているようにみえても、潜在的なバグを発見できないことがあります。そのため内部構造をチェックするホワイトボックステストと組み合わせて、バクの検出に努めることが必要です。

またブラックテストにおいて全てのパターンをテストしようとすると、膨大なコストがかかってしまいます。効率も考え、ポイントを絞りテストを設計することが重要です。またテスト観点※によって、バグを検出できるか否かが大きく変わる点も注意しましょう。そのため慎重にテスト観点をまとめる、ホワイトボックステストを併用するといった対応が必要です。


テスト対象の機能ごとにチェックするべきポイントをまとめたもの

まとめ

ブラックボックステストでは、ソフトウェアの内部構造がどうなっているか考慮する必要はありません。単純に仕様通りに動作するかのみを検証します。内部構造について把握している必要がないため、開発者以外が行うことも可能です。ブラックボックステストには、同値分割法・境界値(限界値)分析・状態遷移テスト・デシジョンテーブル・ユースケーステストといった手法があり、必要に応じて使い分けます。

一方でブラックボックステストには、潜在的なバグを見逃す可能性がある等のデメリットがある点は注意してくてはなりません。プログラムの内部構造を詳細に検証できるホワイトボックステストと組み合わせて実施される必要があります。