ブラックボックステスト

ブラックボックステスト

プログラムの組み方の論理的な方法が「アルゴリズム」と呼ばれるものです。 プログラムの処理方法や流れの論理的・理論的な考え方です。

プログラムの検証（テスト）のやり方にも、似たような理論があって、よくテストに使われるのが「ホワイトボックステスト」と「ブラックボックステスト」があります。

今日は、Firebaseとは直接関係がありませんが、ブラックボックステストについて解説します。

ブラックボックスとは？

最初にブラックボックスとは何かから説明します。

ブラックボックスは、読んで字のごとく「黒い箱」です。イメージできるかどうかわかりませんが、黒い箱は中身の見えない箱という意味で使われます。つまり、プログラムの中身を見ないでテストをするやり方をブラックボックステストと言います。

従って、プログラムの中身を知らなくても、プログラムが何をするかがわかればテストできる方法です。

基本は入力と出力

ブラックボックステストの基本は「入力」と「出力」です。 プログラムに入力として与えるデータと、それを処理して得られる結果を検証する方法です。

検証を行う際は、入力するデータに対応する出力（処理結果）を予め準備して行います。

そのうえで、プログラムに入力データを与えて、実際の処理結果が期待通りになるかというテストです。従って、この入力と出力のペアの数がテスト項目になります。

このテストの基本は、可能性のある全ての入力の組み合わせをテストします。そうすると、基本的に「想定外」はないことになります。

ところが、この全ての組み合わせをテストするのが現実には難しいのが実情です。

例えば前回のメルマガの送付先の登録です。

入力項目は３種類だけです。

＊　E-Mail

＊　苗字

＊　名前

ですが、可能性のある全ての組み合わせとなると無限とは言いませんがかなりの数の組み合わせになってしまい、テストするのは通常は不可能です。

そこで、もう少し現実的な入力の組み合わせを考える必要があります。

Javascriptの大きな問題！

WebサービスやWebアプリの場合、Javascriptでプログラムを書くことが多くなります。このJavascriptの場合、厄介なのが「変数の型が決まっていない」という問題があります。これは、テストを考える立場で見ると、例えば、苗字などの場合でも、いろいろなケースをテストしないといけなくなるからです。

苗字の場合基本は「文字列(string)」ですが、可能性としては、数字もあり得ますし、初期化されずに「null」や「undefined」になる場合もあります。これだけで、テストの項目は一気に増えてしまいます。

これが、Typescriptで書くと、きちんと型宣言すれば、変数の型を特定する事ができて、他の型のデータを渡そうとすると、コンパイル時にエラーになるのでテスト項目から外すことができます。

プログラムを書くのに多少手間が多くなるのは事実ですが、その分、コードの品質はコンパイルがパスした時点でJavascriptよりは高いと考えることができます。テストの項目も少なくて済むので、特に規模の大きな開発には断然有利になります。

そうすると、テストのデータは数パターンでもかなりよい検証になります。

＊　中身が空の文字列「""」

＊　通常の文字列「"ABC"」

＊　２バイトコードの文字列「"日本語"」

＊　後は、文字列の組み合わせ、通常の文字、数字、記号など

＊　常識的には異常に長い文字列は「E-Mail」、「苗字」、「名前」ではないと仮定できる

＊　Emailの場合は「＠」が入っている場合とない場合など

という風に考えると、テストの組み合わせは現実的なものに収めることができます。

ブラックボックステストの限界

ここまで見てきたところでは、「十分な入力の組み合わせ」をテストすれば、そのモジュールのテストカバレッジはよさそうに見えます。

ところが、このブラックボックステストには限界があります。これをよく理解していないとテストに大きな抜けや勘違いを引き起こす原因になります。

実は、ブラックボックステストが有効となるにはある条件が必要になります。

それは、「同じ入力を入れたとき、必ず同じ結果（出力）が得られる」これが成り立たない場合はブラックボックステストの結果は信頼性がなくなります。

ここで疑問に思われる方もいるかと思いますのでもう少し詳しく説明します。

「同じ入力で同じ結果が出ない場合は、検証結果がエラーになるのでは？」と思いませんか？ 実際、結果が頻繁に変わるような場合は、そこで問題がわかるので問題は余りない場合が多くなります。例えば、プログラムの処理に「時間」などを使って「乱数」を作っている場合はほぼ、毎回違う結果が出るのが普通なのでテストをすればすぐにわかります。

同じ入力で結果が変わる場合というのは、そのプログラムの「中の状態が常に同じ状態でない」場合に起きます。時間がその良い例です。

厄介なのは、「殆どの場合同じ結果が出る」ケースです。

これは、テストをすると一見問題なく動いているように見えます。 ところが、「たまに違う結果が出る」場合に思った動作と違う動作をする事があります。

この場合は、ブラックボックステストがパスしてもそのモジュールの動作が正常とは言い切れません。これがブラックボックステストの限界であり制約になります。

例えばどんな場合があるかというと、「バックエンドからデータをもらう場合」などです。 バックエンドからデータをもらう場合は別のプログラムからネットワークを介してデータを受け取ることになります。ネットワークやバックエンドのサーバーが正常に機能している場合は、基本的に常に同じ結果がかえって来るので結果も同じになります。しかし、ネットワークやバックエンドのサーバーに障害がある場合はデータが受け取れないという事態が発生します。その場合は当然結果が変わります。こうした事態を想定して設計している場合は対処が可能です。しかし、想定していない場合は、どのような動作になるかわからない場合もあります。

もう一つは、例えばバックエンドのデータベースのデータを使う場合です。当然ですが、バックエンドのデータベースは「他のプログラム」もアクセスできるので、例えば、２つ以上のプログラムが動いていて同じデータを使う場合、一つのプログラムが別のプログラムの知らないところでデータを書き換えてしまうこともあります。その場合、書き換えられたことを知らないプログラムがそのデータを使う場合、想定外のデータになっている場合もあり得ます。 実際は、こうした事態が起こること自体が「バグ」ですが、テストでは起きないケースの場合が多く発見が難しい不具合の一つです。

こうしたケースに対応するには、そうした違う状態も考慮したテスト計画を立てることが必要になってきます。

まとめ

ブラックボックステストは上手く使うと、有効なテスト手法です。 しかし、検証対象のプログラムの状態が常に同じでない場合は、検証対象のプログラムの状態も考慮したテスト計画を作らないと正しい検証を行うことができません。

WebサービスやWebアプリでは、複数のフロントエンド（Webブラウザ）がバックエンドやデータベースにアクセスするので一般的なデスクトップのプログラムの検証より複雑になる場合が多くなります。それに加えて、ネットワークやサーバーの状態など、フロントエンドのプログラムから見ると状態が変わる要素が多いため、完全な検証は難しい場合が多くなります。

そうした、状況も考慮したテスト計画を作成して実行する事が大切です。