「ブラックボックステスト」には限界がある

コンピューターシステムでは、ブラックボックスが正しく動作するかどうかを確かめるために、「ブラックボックステスト」と呼ばれる方法がとられる。これは、ブラックボックスの中身を理解せずに、ブラックボックスへのインプットと、そこからのアウトプットをもとに、テストをするというものだ。

たとえば、適当な年月日をインプットしたときに、実際にそういう日があるかどうかを判定するシステムを考えてみよう。このシステムは、「2022年6月28日」や「2022年10月31日」といった実際にある日のインプットには“Yes”。「2021年9月31日」や「2023年4月31日」といったありえない日のインプットには“No”をアウトプットする。

ブラックボックステストでは、ありうる年月日と、ありえない年月日を次々にインプットしてみて、アウトプットが正しいかどうかを確認する。

ブラックボックステストは、プログラムの利用者目線からのテストといえる。テストの内容が限られるため、システムにそれほど詳しくない人でも、短時間でテストが実行できるという利点がある。

ただし、ブラックボックステストをどれだけ重ねても、システムが絶対に正しいとは言い切れない。インプットしなかったデータで、なんらかの誤動作を起こす可能性がぬぐい切れないからだ。ブラックボックステストは、計算ロジックを検証しないため、どこまで行っても不十分なのである。

「ホワイトボックステスト」は負担が大きい

これとは対照的に、「ホワイトボックステスト」というものもある。インプットとアウトプットだけではなく、システムの中身を確認するものだ。プログラムそのものを確認したり、プログラムの条件分岐を通過するインプットデータを網羅的に流してアウトプットを検証したりする。

先ほどの年月日判定システムのテストの例でいうと、「うるう年の対応ができているかどうか」といった確認が該当する。まず、うるう年を判定するプログラムが適切に作られているかどうかを確認する。そして、実際にうるう年の判定が正しくできるかどうか、「XX年2月29日」のデータを集中的にインプットして確かめてみる。たとえば、「2020年2月29日」、「2021年2月29日」、「2022年2月29日」を入れてみる。うるう年である「2020年2月29日」には“Yes”。うるう年ではない「2021年2月29日」や「2022年2月29日」には“No”がアウトプットされることを確認する。

更に、100年に一度や、400年に一度のうるう年の例外を含めた、グレゴリウス暦^＊に対応しているかどうかも確認する。たとえば、2100年は100年に一度の例外でうるう年ではない。そこで、「2100年2月29日」をインプットして、アウトプットが“No”となることを確認する。また、2000年は400年に一度の例外でうるう年であった。そこで、「2000年2月29日」をインプットして“Yes”と、正しいアウトプットが出力されるか確かめる。こうした確認も「ホワイトボックステスト」に含まれる。

＊現在、一般に用いられている太陽暦。西暦の年数が、100で割り切れるが400では割り切れない年は、平年。それ以外で西暦年数が4で割り切れる年はうるう年、というルール。

ホワイトボックステストは、プログラムの開発者目線からのテストといえる。システムの内容を熟知して網羅的に行われるテストであるため、基礎となる知識の習得や、テストの手間、一定の時間が必要となる。特に、複雑なシステムをテストする場合には、こうした負担が大きくなる。