ブラックボックステストとは？特徴や技法、ホワイトボックステストとの違いを解説

ソフトウェアの機能や不具合を確認するためのテストの中でも、内部構造を意識せずに行うテストのことを、「ブラックボックステスト」といいます。ソフトウェアテストではよく採用される方法ですが、どのようなことがわかるのでしょうか。

本記事では、ブラックボックステストの特徴や技法、ホワイトボックステストとの違いを解説します。

株式会社SHIFTは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

ソフトウェアテストのよくある質問はこちらをご覧ください。
＞＞ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ

ブラックボックステストとは、仕様書などからテストすべき項目を洗い出し、システムの内部構造を考慮せずに実施するテスト技法です。

ソフトウェアテストを行う際、テスト対象やテスト観点、テスト条件などのテストケースを事前に作成します。ブラックボックステストでは、テストケースを作成する際にシステムの内部構造であるソースコードがどのように構築されているのかは考慮せず、テストケースの作成を行い、テストを実行します。そのため、開発に関係した人物ではない第三者がテストを行うことも可能です。

ブラックボックステストと類似した言葉に、「ホワイトボックステスト」があります。両者ともにソフトウェアテストの技法のひとつですが、違いは着目点です。

ブラックボックステストが、内部構造を考慮せずに行うテストであるのに対し、ホワイトボックステストは、システムの内部構造が正しいかを確認するテスト技法です。そのため内部構造を理解することができないと実施が困難になるため、多くの場合、開発者自身が行います。また実施の際、ソースコード内の条件が分岐する箇所においては不具合が発生しやすいので、注意する必要があります。

言い換えれば、ブラックボックステストは実際のユーザー視点からの確認に近く、ホワイトボックステストは、プログラム構造に問題がないかの開発者側の視点で行われるテストなのです。両者はそれぞれできることや着眼点が異なるため、両方実施することが求められます。

あわせて読みたい
＞＞ホワイトボックステストとは？ブラックボックステストとの違いやその手順、よく使われる手法を解説のページへ

ブラックボックステストの特徴は、主に2つあります。

・対応できるテストレベル（コンポーネントテスト、結合テスト、システムテスト、受け入れテスト）が広い
・費用対効果が高い

次項でそれぞれをご紹介します。

※コンポーネントテスト、結合テスト、システムテスト、受入テストのに関してはこちらもご覧ください。
＞＞コンポーネント（単体、ユニット）テストとは？手法などを例で紹介のページへ
＞＞結合テストとは？目的や観点・種類・単体テストとの違いを解説のページへ
＞＞システムテスト（総合テスト）とは？その目的・観点・種類、実務で使える手順について解説のページへ
＞＞受け入れテスト（UAT）とは？実施の目的を観点別に紹介のページへ

テストレベルの段階が進めば進むほどテストすべき機能の組み合わせがより複雑になるため、すべてのシステムの内部構造を把握した状態でのテストは難しくなります。

ブラックボックステストは内部構造を理解していない場合でも、仕様書があればテストを実施することが可能で、テストレベルのどこでも利用ができます。

テスト仕様書に関してはこちらもご覧ください。
＞＞テスト仕様書の書き方～テストケース作成のポイント～のページへ

ブラックボックステストは、費用対効果が高いという特徴もあります。プロジェクトの予算や仕様などの状況に合わせたテスト全体の最適化を行い、高品質で効率的なテストを実施することで、コストを抑えつつ、ソフトウェアの品質を高めることもできます。

＞＞「品質」は誰が決めるもの？～改めて「品質」を考えてみる～のページへ

ソフトウェアの開発者は、開発に関する技術や知識を用いて業務を行いますが、ブラックボックステストの実施には専門的な開発の技術や知識はそれほど多く必要ありません。そのため、開発者以外が担当することができ、外部に委託することも可能です。結果、開発者と比較して人件費を低く抑えることができるでしょう。 

特に、仕様書などを参考にして行うテストの場合、仕様書が読めればある程度までテストの設計や実施が可能です。加えて、開発した人ではない第三者がテストすることによって、思い込みなどにとらわれず、客観的なテストを行うことにもつながります。

しかし、スキルや経験のばらつきなどが要因で、不具合の検出結果が属人的になる、漏れが生じてしまうなどの可能性もあるでしょう。もし、手戻りが発生するなど非効率的なテストになってしまうと、必要以上の経費がかさんでしまう事態も考えられます。

そのような事態を防ぐために、プロジェクトの予算や仕様などの状況に合わせたテスト全体の最適化を行い、高品質で効率的なテストを行うソフトウェアテストの代行をする会社に委託するのがよいでしょう。それにより結果的にコストを抑えることができ、かつソフトウェアの品質を高めることもできます。

さらにソフトウェアテストを代行する会社には、ECサイトや業務システムをはじめとするさまざまなサービス形態に対して、不具合が起きやすい箇所に対する知見があります。数多くのテスト実施によって得た知識やノウハウが発揮されるため、テストの精度が高く、このような点も依頼を行うメリットのひとつとなります。

ソフトウェアテストを代行する会社をお探しでしたら、まずはSHIFTにお問い合わせください。
＞＞お問い合わせページへ

料金についてはこちらから
＞＞料金についてページへ

SHIFTのサービスについてや導入事例に関してはこちら
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ

ブラックボックステストにおいて、よく使用されるテスト技法があります。代表的なものは以下です。

・同値分割法
・境界値分析
・デシジョンテーブルテスト
・状態遷移テスト
・組み合わせテスト

それぞれどのようなテストなのか、詳細を確認していきましょう。

同値分割法とは、ブラックボックステストの技法のひとつで、同値領域から代表値を実行するテストケ－スを設計するものです。
有効または無効のような同様の結果をもたらす値を、それぞれ「同値クラス」として分類し、最低1回各同値クラスのグループから実行するように設計するのが原則となります。代表値の結果が、同値クラスのほかの値にも同様の結果をもたらすと考えます。

これによりテストケースを限りなく少なくし、効率よく不具合を発見するための技法です。

境界値分析とは、同値クラスの両端にあたる境界値を基にしてテストを行う技法です。境界値分析もブラックボックステストの技法のひとつで、仕様に定められている条件の境界値を基にして行うテスト技法です。境界値とは、ある範囲の最小値または最大値などの同値分割した領域の端にあたる値を指します。

具体的には「未満」や「以下」などが該当します。こういった境界部分は、ソフトウェア開発において間違いを引き起こしやすく、不具合につながりやすいため、境界値分析で検証する必要があるのです。

＞＞境界値分析とは？流れやおさえておきたいポイントをわかりやすく解説のページへ

デシジョンテーブルテストとは、対象が取り得るステータスや動作・入力値といった条件を組み合わせ、どのような結果となるのかを表で整理したデシジョンテーブルを使用して行うテスト技法です。使用上の条件を漏れや重複なく洗い出し、論理的に発生しうる組み合わせでテストを行うため、網羅性が高いという特徴があります。

複雑な条件や組み合わせを要するシステムの場合は、テストケースが増え、デシジョンテーブルの作成に時間がかかることがあります。反面、条件や結果の複雑な組み合わせを整理することで、網羅性の高いテストを実施することができます。

＞＞デシジョンテーブル（決定表）とは？メリットや書き方をわかりやすく解説のページへ

状態遷移テストとは、仕様に基づき、システムの挙動を確認するテストです。システムの状態が条件によって変化した様子を図式化した状態遷移図と状態と状態が遷移する条件を表でまとめた状態遷移表を活用して行います。

＞＞状態遷移図とは？書き方や状態遷移表との違いをわかりやすく解説のページへ

組合せテストとは、ある入力条件（因子）と値（水準）を組み合わせてチェックするテスト技法です。

ただ、もしそのシステムにおけるすべての入力条件と値を組み合わせてテストを実施しようとすると膨大な数になることもあり、実施すること自体が難しい場合もあります。そのため、オールペア法（n因子間網羅）や直交法などの技法を活用し、テストケースを削減して実施することが一般的です。

＞＞テスト設計基礎(機能テスト編)テスト設計手法の適切な使い方～2因子間網羅～のページへ

ブラックボックステストだけでは、不具合の発見が難しいケースも存在します。具体的には以下のようなケースです。

・仕様自体が矛盾している、もしくは間違っているケース
・仕様変更の際に記載されなかった条件
・非機能的な要件（同時アクセスが起きたときに発生する要件、サーバーやデータベースの状態によって発生する要件などがあります）

ブラックボックステストだけでは、仕様が矛盾していたり間違っていたりしてもわからない場合があります。ブラックボックステストは、仕様書に記載されている入出力が正しいかどうかを確認するテストです。そのため、仕様書そのものに問題があっても発見しにくく、矛盾や間違いに気が付かない可能性があります。

ブラックボックステストでは見えないこういった部分を明確にするには、仕様書のレビューやインスペクションを行うといいでしょう。レビューやインスペクションで仕様書間のトレーサビリティを確認することで、仕様の矛盾や間違いを検出できます。

仕様変更があった場合、本来は仕様書がメンテナンスされていくべきなのですが、諸事情で仕様書への変更の記載が漏れてしまうケースがあります。仕様変更が起こった際に記載されなかった条件は、仕様書通りかどうかを確認するブラックボックステストでは見抜けない可能性があります。ブラックボックステストではその条件を見ることはないため、新たに変更や追加があったものでも正常に動作してしまえば見過ごされてしまうケースもあるのです。

こちらは、ホワイトボックステストを用いたテストが必要になるでしょう。ソースコードの差分を確認することで、仕様書に書かれていない変更があってもすぐに発見することができます。基本的には、ブラックボックステストとホワイトボックステストは組み合わせて行うのがベストです。

非機能的な要件とは、同時アクセスやサーバーの可用性など、機能に対する要件とは異なる要件のことです。ブラックボックステストはあくまでも該当するソフトウェアが正しく動作するかを確認するテストであり、環境面などの非機能的な要件は考慮しません。そのため、実践環境で非機能的な要件が発生したと仮定しての動作確認ができないのです。

対策としては、以下のテストを同時に行うことが求められます。

・負荷テスト
・キャパシティテスト
・ロングランテスト　など

このようなテストを実施することで、ブラックボックステストだけではわからない非機能的な要件の確認もできます。手間はかかりますが、品質の高いソフトウェアを完成させるためには必須の工程といえるでしょう。

ブラックボックステストは、よりユーザーの目線に近い形で行われるテスト技法です。品質の高いソフトウェアを提供するために欠かせないテストである一方、ブラックボックステストだけでソフトウェアの品質を保てるわけではありません。ホワイトボックステストやそのほかのテストと組み合わせて行うことで、より高い品質を維持したソフトウェアを提供できるのです。

SHIFTでは、ソフトウェアテストのみのご依頼も可能です。ブラックボックステストを第三者に依頼するメリットも記事中でお伝えしましたが、開発者とは異なる人物がテストを実施することで、先入観にとらわれない結果を得られるでしょう。今まで積み重ねたテスト実績と蓄積した事例をもとに、質の高いソフトウェアテストが可能です。

ソフトウェアテストでお困りの方、ソフトウェアの品質を向上させたい方は、ぜひSHIFTまでご相談ください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

質の高いソフトウェアテストを効率よく行うためには、多くの知識や経験が必要です。社内に経験豊富なIT人材が不足していると、質の高いテストを実施するのがむずかしく、かといって一からIT人材を集めるためには膨大な時間とコストがかかってしまいます。

そのような悩みは、SHIFTのソフトウェアテスト・第三者検証のサービスを利用いただくことで解決できます。

＼おすすめの資料／　※すべて無料でダウンロードいただけます。
・3分で知るSHIFTのテストサービス
・テスト効率が大幅アップ、人手不足解消の切り札に ＜理由＆メリット＞
・ソフトウェアテストを外注すべき5つの理由とは！？
・サービス導入事例集

これまで導入いただいた企業様は3,000社以上。その豊富な専門知識と経験を活かして、高品質のソフトウェアテストを効率よく行い、開発のサポートをいたします。

ぜひSHIFTのソフトウェアテスト・第三者検証をご利用ください。

ご相談はこちらから。
＞＞お問い合わせ
＞＞料金について

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座