2023年3月14日 / 最終更新日時 : 2023年3月14日 user 事例・ソリューション

ブラックボックステストのベストプラクティス

ブラックボックステストでは、ユーザーの視点から機能をチェックして性能を確認することができます。今回、紹介する技法に従って、ブラックボックステストのワークフローを最適化しましょう。

ソフトウェアのテストは、必然的に繰り返しをともない、製品の内部と外部に対する深い理解を必要とします。テスト設計サイクルのいくつかのフェーズでは、ソフトウェアのコードまたは構成に関する知識が必要かもしれません。しかし、それ以外のフェーズでは、入力と出力を見て、期待どおりの結果が得られるかどうかを確認するだけで済みます。それが、ブラックボックステストです。

ブラックボックステストは、製品の機能性、ユーザビリティ、およびセキュリティを、内部のコードを全く知らない状態で評価する方法であり、特にユーザーの視点からソフトウェアの性能に関する情報を得るための効率的な方法です。この記事では、「ブラックボックステストとは何か」という基礎知識に加え、類似のテスト形式と比較し、最も効果的なブラックボックステストの技法をいくつか挙げ、テストの自動化において、どのように役立つかについて説明します。

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

ブラックボックステストは、動作テストとしても知られており、ソフトウェアをテストする人が、実装されているコード、アーキテクチャ、または構成について何も知らない場合に使用される方法です。ソフトウェアが動作するために必要なユースケースや要件は与えられるかもしれませんが、ソフトウェア設計の内部構造について、テスターは何も知らないままです。

ブラックボックステストには以下の 3 種類があります。

機能テスト：与えられた入力の下で特定の機能が動作するかどうかをテストします (例：スモークテスト、サニティテスト、統合テスト）
非機能テスト：それらの入力の下で特定の機能がどのように動作するかをテストします (例：OS の互換性、ユーザビリティ、応答時間)
回帰テスト：製品が最新バージョンでどのように変化するかをテストします。機能的および非機能的な機能に適用できます。

ブラックボックステストは、機能性、ユーザビリティ、信頼性をすべてのサブシステムにわたって検証できるため、ソフトウェアの性能をエンドツーエンドで評価する効果的な方法です。また、テスターは機密性のあるソースコードを見ることができないため、ソフトウェアに関連する企業秘密を保護したい組織にとって特に安全な方法です。

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

ブラックボックステストがソフトウェアの設計を全く知らない状態で実施されるのに対し、ホワイトボックステストはコードの詳細を明確に把握した上で実施されます。データパターンの欠陥、壊れた経路、コードの欠陥を特定して修正するのに役立つホワイトボックステストは、ソフトウェアの内部構造により焦点を当て、ブラックボックステストよりも詳細です。

この透明性は、ホワイトボックステストとブラックボックステストの実施方法の違いにも影響を与えます。このリストはすべてを網羅しているわけではありませんが、特徴的な違いをいくつか紹介します。

ブラックボックステストは、コードの知識を必要としませんが、ホワイトボックステストは必要とします。
ブラックボックステストは、問題が発生するかどうか、いつ発生するか、またはなぜ発生するかを判断するのに役立ちます。ホワイトボックステストは、なぜ問題が発生するかを判断するのに役立ちます。
ブラックボックステストの方が、時間はかかりません。
ブラックボックステストは、アルゴリズムには使用されません。ホワイトボックステストは、使用されます。

開発チームが検討すべきもうひとつの選択肢は、グレーボックステストです。グレーボックステストは、ブラックボックスとホワイトボックスの 2 つのテスト技法を組み合わせたものです。担当者は、ソースコードまたはアーキテクチャの部分的な知識だけでアプリケーションと環境をテストできます。

開発チーム向けのブラックボックステスト技法

開発チームが製品の性能を評価するために使用できるブラックボックステスト技法はいくつかあり、アプリケーション、システム設計、ユースケースなど、多くの要因によって選択する技法が異なります。これらのブラックボックステストは、開発者が直面する最も一般的なソフトウェアエラーを解決するのに役立ち、製品設計のプロセスを加速させることができます。

決定表 (デシジョンテーブル) テスト

ソフトウェアは多くの場合、受け取った入力によって導かれる一連の条件演算子に基づいて出力を決定します。もし可能な入力と出力が分かっていれば、開発者は決定表を作成し、それに基づいてテストを実行することによって、ソフトウェアのコードをモデル化することができます。

たとえば、ある企業の採用プラットフォームでは、求職者が応募する際に特定の資格を持っているかどうかを尋ね、持っている場合は続けて他の質問をし、持っていない場合は応募を拒否するといったことが考えられます。もし開発者がこれらの条件を知っていれば、ソースコードの知識がなくても、すべての潜在的な原因と結果をモデル化した決定表を作成し、それぞれをテストすることができます。

境界値解析

ソフトウェアのエラーの多くは、その境界で発生するため、製品がこれらのエンドポイントで動作することを確認することは、その間のあらゆる場所で機能することを示す良い指標となります。

テスターは、すべての入出力をチェックする時間やリソースを持っていません。境界値は最も問題になる可能性があるため、境界値をテストすることで、ほとんどのバグを明らかにし、全体の機能を把握できます。たとえば、乱数ジェネレーターが 1 から 10,000 までの数字を出力するように設計されている場合、0、1、10,000、10,001 の値をテストすれば、乱数ジェネレーターが目的の範囲内で動作することを確認でき、残りの 9,999 の値についてはすべてをテストしなくてもシステムが健全であることを確認できます。

状態遷移テスト

製品の境界でエラーをチェックするのと同様に、製品によっては状態が変化するところでテストする必要があります。

たとえば、パスワードチェッカーは、 3 回失敗するとユーザーのアカウントをロックし、それによってプラットフォームの状態を変化させるかもしれません。開発者は、この出力とそのトリガーとなる入力を知っていれば、間違ったパスワードを 3 回以上入力してアカウントロックが発生するかどうかを確認することで、状態遷移の発生を試みることができます。ソフトウェアの不具合は状態遷移のポイントで発生することが多いため、このブラックボックステストを使用することで、ソフトウェアの適切な応答を確認できます。

同値分割

ブラックボックステストのもう 1 つの例として、同値分割があります。この方法は、入力を特定のカテゴリにグループ化できるソフトウェアに適しています。グループ化したら、すべての入力をテストするのではなく、各カテゴリから 1 つの代表値をテストします。

たとえば、e コマースプラットフォームでは、顧客が購入を希望する商品の数に基づいて商品の価格を設定する場合があります。ある数量が注文された後に商品の価格が変更された場合、すべての可能な入力をチェックする代わりに、各価格レベルのしきい値でプラットフォームをテストできます。このようにカテゴリ分けすることで、ソフトウェアの精度を犠牲にすることなく、テストプロセスにおける時間を短縮できます。

エラー推測

その名前が示すように、ソフトウェアのエラーの中には、開発者が犯す最も一般的なエラーをテスターが単に推測することで発見できるものがあります。経験豊富なテスターは、間違いが最もよく起こる場所を知っており、直感に基づいてテストすることができます。たとえば、テキストのみのフィールドに数値を入力したり、数値のみのフィールドにテキストを入力したりすることが挙げられます。