ホワイトボックステスト、ブラックボックステストの違いとは?

ホワイトボックステストとブラックボックステストの記事のアイキャッチ画像

ホワイトボックステスト、ブラックボックステストとは何かご存知でしょうか。

初めて聞いて、全くわからないという方も多いのではないでしょうか。

本記事では、ホワイトボックステスト、ブラックボックステストの違いなども含めて詳しく解説しております。

IT企業として20年以上の実績のある当社の蓄積データを活用しながらまとめております。

お読みいただき、知識として蓄えていただけますと幸いです。

 

オフショアのお問い合わせはこちら

1.ホワイトボックステストとブラックボックステストの違いとは

まず、ホワイトボックステストとブラックボックステストの違いについて解説します。

 

1-1 内部と外部のどちらをみるか

ホワイトボックステストとブラックボックステストの違いのイメージ図

 

違いとしては内部と外部のどちらをみるかです。

まず、外部とは使用者が見て触る場所であり、内部はシステムを動かすために実装されたコードなどを指しています。

ホワイトボックステストでは内部のコードが正常に動いているのかを確認します。

一方ブラックボックステストは外部の画面を確認します。

その際に内部のコードなどは「見えないもの」として扱うため、ブラックボックスと呼び名がついています。

内部を見るのがホワイトボックステスト、外部をみるのがブラックボックステストと異なる性質を持っています。

 

ホワイトボックステスト

ブラックボックステスト

内部のコードが正常かテストする

内部を考慮せず外部となる画面などをテストする

作り手側のテスト

ユーザー側のテスト

主に単体テストのフェーズ

主に結合テストのフェーズ


2.ホワイトボックステストとは

ホワイトボックステストとブラックボックステストの流れのイメージ図

ホワイトボックステストはテスト手法の1つであり、複数のテスト技法の総称です。

主に単体テストのフェーズで実施されます。

2-1 システム内部のソースコードなど正常に動作しているか確認するテスト手法

ホワイトボックステストはシステムの内部構造を確認することに重点を置いたテスト手法です。

内部構造とは実装されたソースコードなどを指しており、それらが正常に流れているかを確認します。

いわゆるバグを見つけることが目的です。

エンジニアが実装した内部のテストであるため、「作り手側のテスト」とも呼ばれることがあります。

2-2 ホワイトボックステストで使われる技法

内部のテストを行うホワイトボックステストですが、実際に行う際には次の2つの技法を使用するケースが多いです。

  • 制御フローテスト
  • データフローテスト

1つずつ確認していきましょう。

2-2-1 制御フローテスト

制御フローテストは1つの処理に対してプログラムがどのように動くのかをテストする技法です。

各処理をケース別にフローチャートで示し、意図したとおりに動くか確認をしていきます。

可能であればシステムで想定される全てのケースをフローチャートで示し確認することが理想ではあるものの、それだと膨大な数になってしまうため、次の基準を基にテストケースを作成して実行しましょう。

 

命令網羅(ステートメントカバレッジ)

すべての命令(処理)を1回以上通す。

分岐網羅(ブランチカバレッジ)

すべての条件分岐を1回以上実行する。

条件網羅(デシジョンカバレッジ)

条件分岐のすべての組み合わせを1回以上実行する。

2-2-2 データフローテスト

ある処理を実行したときに意図した結果が返ってきているか確認するテスト技法です。

例えば、勤怠システムでは、有給申請などを行う際に日付を入力させますが、

入力した日付に応じて曜日が正しく表示されることが確認できれば合格となります。

2-3 注意点

ホワイトボックステストを実行していく上で注意すべき点としては、

次の2つがあります。

  • 作成されたプログラムをテストするため、漏れているコードなどを検出するのは難しい
  • システムが使いやすいか判断するためのテストではなく、内部のテストである

あくまで、作成された内側部分のテストを実施するための手法であるため、2-2-2で解説したような曜日が入力されるかなどの単純なミスは検知できますが、

UIと連動した複合的なミスは検知が難しいということを覚えておきましょう。

 

オフショアのお問い合わせはこちら

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

ホワイトボックステストとブラックボックステストの流れのイメージ図

 

ブラックボックステストとはテスト手法の1つであり、複数のテスト技法の総称です。

主に結合テストのフェーズで活用されます。

3-1 システム内部を考慮せずに、外部からみた動作を確認するテスト手法

画面表示やレイアウトの誤りなど正しく出力されているか確認するテストです。

内部を考慮しないというのは、どのような内部の動きになっていようとも、出力された結果などにミスが無い場合は合格となるためです。

また、使用する上での不便な点やデザインなど、UI/UXの面からも確認を行うため、「ユーザー側のテスト」とよばれることもあります。

3-2 ブラックボックステストで使われる技法

外側のテストを行うブラックボックステストですが、実際に行う際には次の2つの技法が使用されるケースが多いです。

  • 同値分割法
  • 境界値分析

1つずつ確認していきましょう。

3-2-1 同値分割法

 テストを効率的に行うため技法で、入力データや条件などを同じく扱われるものを「同値クラス」として同じグループとみなします。そのグループ内からランダムで抽出したデータをテストし合否の判断をするテスト技法です。

 グループ分けがされない場合のテストケースは膨大になってしまい、多くの時間を費やしてしまいます。

 それらを軽減することがこの技法では可能です。

 例えば、年齢に応じて購入できるものが変わるシステムを例として考えてみましょう。

 このシステムでは019歳向けと20歳~向けの商品が2種類あり、事前の登録で年齢を取得した際に表示内容を変える仕様となっています。

 この場合、0,1,2………と何通りものテストケースを作成しテストをする必要が発生します。

 しかし、同値分割法を活用することで019歳を1つのグループとして考え、そこからランダムに抽出された年齢1つをテストし、それが合格であれば全て合格とすることができ、効率的にテストを進めることができます。

3-2-2 境界値分析

正常値と異常となる境界(上限と下限)をテストする技法です。

まだ理解しにくいと思いますので、前項でも触れた年齢に応じて購入できるものが変わるシステムを例として考えてみましょう。

少し条件を整え、019歳と20歳~100歳まで設定しましょう。

この場合上限となるのは100歳で下限が0歳となり、共にテストの実施対象となります。

その他は上限を上回る101歳も異常値としてテスト対象になります。下限を下回る-1も同様です。

テストはそれぞれの入力で正しく画面表示がされるかなどテストしていきます。

また、どちらか一方では正しく評価することが難しいため、前項の同値分割法と基本的にセットで使われる技法です。

3-3 注意点

ホワイトボックステストとは反対に外部をテストする手法であるため、

内部については不具合を検出することが難しいことがあげられます。

そのため、ホワイトボックステストとセットで活用されるケースが多く、それぞれが補完している関係です。


4.グレーボックステストとは

内部構造を一部理解しており、それを基に外部からテストを実施する手法です。

ホワイトボックステストのように内部を理解し、ブラックボックステストのように外部のテスト行う、中間的な位置であるためグレーボックステストといいます。

ピンポイントのテストができるなど、ホワイトボックステストとブラックボックステストを補完できるのがグレーボックステストです。

 

オフショアのお問い合わせはこちら

ホワイトボックスとブラックボックステストのまとめ

ホワイトボックステストとブラックボックステストは、内部と外部という決定的な違いがあります。

まずはこのポイントを理解しましょう。

その上で総称となっているこの2つのテスト技法を理解していきましょう。

また、グレーボックステストは補完的な位置づけであり、ホワイトボックステストとブラックボックステストの良いとこ取りをしています。

まずはホワイトボックステストとブラックボックステストを実施した後に、ピンポイントにテストを実施する機会にはグレーボックステストを実施してみましょう。

分かりにくい部分ではありますが、本記事をお読みいただいた皆様の知識の一旦となれば幸いです。

お客様の課題をワンストップで解決!
お客様の声をカタチに変えて満足頂ける
ソリューションを提供いたします。

お客様が抱える課題を、システム開発で解決しています。ご要件のヒアリングからシステム設計、開発、保守をワンストップで提供します。

ベトナムのエンジニアマーケットから人員調達ができるため、お客様が必要とする人員数を当社のみで提供できる強みがあります。

author-avatar
プログラマー、システムエンジニアを経て2001年にサイバーエイド株式会社を設立。
2008年に株式会社インタラクティブ・コミュニケーション・デザインにジョイン後は、2014年にベトナム・ホーチミンでオフショア開発拠点を立ち上げ、2017年に現地法人ICD Vietnam Limited Liability Companyを創業し現在に至る。
創業以降は東京のみならず、各国内地方拠点(札幌、名古屋、大阪)においても積極的にオフショア開発を推進し、国内のITエンジニア不足の解消を目指す。
ICDベトナムがエンジニア不足を解決します!
ICDベトナムがエンジニア不足を解決します!