テストでよく聞くブラックボックスとホワイトボックスの話【ゲーム開発】

「ブラックボックス」や「ホワイトボックス」という言葉を聞いたことがありますか？

主にプログラムのテストをする時に使われる言葉で、ブラックボックステストは中身が見えないまま行うテスト、ホワイトボックステストは中身が見えている状態で行うテストです。

これらのテストはゲームを作る時にもやっておきたいものなので、このページではブラックボックステストやホワイトボックステストについて紹介します。

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

ソフトウェア開発においては、お客さんの求めている要件を設計の形にしてからコードを書いていきます。こうした時に設計通り動いているかをテストすることは重要で、ブラックボックステストやホワイトボックステストはそのテストのやり方なんです。

元々の言葉を辿ると、箱の中に電子回路を組み立てたものについて、箱を開けた状態(ホワイトボックス)で回路の細かな部分をテストしたり、箱を閉じた状態(ブラックボックス)で実際に使う時のことを想定してテストしていたものがプログラミングの分野にも持ち込まれたのでした。

作ったゲームのテストを行う時にもこれらの観点があった方がよくて、プログラミング部分の細かい分岐やメソッドの動作などをテストしていくホワイトボックステストと、ユーザーが遊ぶ時の操作を行って確認するブラックボックステストを実施するとグッドです。

ホワイトボックステスト

ホワイトボックステストはシステムの中身を理解した上で、プログラムが設計通りに動作しているかをテストする方法です。条件分岐やメソッドの動作など、モジュールの動作を細かく確認していくテストです。どちらかというと開発者寄りのテストで、if文の分岐があったらtrueの分岐もfalseの分岐も両方チェックしますし、分岐がないなら全ての命令を通っていることを確かめます。

例えば条件に合えば処理を進めるけど、条件に合わなかったらエラーメッセージを出す、という条件だったら、trueになる値、falseになる値を両方試してみてちゃんと想定通りになっていることを確認します。

分岐のない部分の順次処理であれば、ひとつひとつの命令が実行されていることを確認します。変数に値を代入したり、その計算過程が合っているかどうかも細かくみていきます。ここではデバッガーなどを使って変数の中身を追っていったりすることも。ブレークポイントを指定して変数の中身を確認する方法については以下の記事でも触れています。

エクスプラボ

 

1 User

2 Pockets

UnityとVSCodeでブレークポイントを設定して変数をチェックする

https://ekulabo.com/unity-break-point

IDEやコードエディタに搭載されているデバッガーの機能を使ってステップ実行していくことでゲームのシステムの中身が把握しやすくなります。この記事ではブレークポイントを設定してその時点での変数の中身を確認する方法を紹介しています。

テストの単位としてはモジュール(機能)ごとになることが多いので、割と早い段階からこういった部分を確認していくことが多いと思います。逆に作ってすぐくらいの早いタイミングでやっちゃわないと、分岐の数がとんでもないことになるので確認が大変になったりします。

この部分はユーザーから見えない部分なので、ユーザーがゲームプレイに集中できるようにしっかりと確認しておくことが望ましいです。

ブラックボックステスト

ブラックボックステストはプログラムの内部についてはあまり関心を持たず、実際にユーザーが操作する手段を使ってテストしていきます。

ゲームの場合はコントローラーを使って操作したり、画面に表示されたUIをタップして操作して動作を確認していきます。また、ユーザーが値を入力する場合は境界値分析や同値分割といった手法でテストする値をサンプリングして確認を行います。入力されうる値全て確認する、なんて感じだと1, 2, 3, 4, …といったようにテストがとんでもない量になってしまうので、if文の条件で指定した値近辺を確認することが多いんです。

例えばint型の比較で「1以上だったらtrue」という条件式があったら、1でtrue、0でfalseとなることを確認します。こうした境界部分で「1以上のつもりが、1より大きい、になっていた！」なんてバグが出ることが多いので、境界に注目してテストを行う境界値分析がとても有効です。

同値分割は判定結果が同じになる値をグループ分けしよう！　という考え方で、上で挙げた「1以上だったらtrue」の条件式の場合はtrueになるサンプルとして1以上の値のうちどれかひとつを選び、falseになるサンプルとして1未満の値のうちどれかひとつを選びます。trueになるなら9999でも32768でもOKです。テストする値が絞れるということは、それだけテストのコストが減ることでもあるので、適切に値を選ぶことで負担も減ります。

ブラックボックステストはユーザーが目にする部分の確認になるので、ここでエラーやバグがあるとユーザーの満足度が下がってしまうこともあります。

テストする範囲に関してはホワイトボックステストよりは限られるので、時間的なコストだとちょっと低くなります。

どちらをやるべき？

ホワイトボックステストやブラックボックステストはどちらかだけやるというよりは、両方うまくやっておきましょう、という感じです。

ホワイトボックステストは時間がかかる反面、プログラム内部の潜在的なバグなどを拾いやすく、全体の品質を上げられます。

ブラックボックステストは上でも触れたようにユーザーが操作する方法を使ってテストをするので時間は短くて済むかもしれません。ただ、表面上はうまく動いているように見えても内部で正しい状態になっているかは分からないので、潜在的なバグを抱えるリスクはあります。

例えば道具の9番目でセレクトボタンを押してBボタンを2回押す、みたいなバグ技はホワイトボックステストでメモリの中身を見ながらじゃないと拾うのは難しいと思います。

ゲームを作る時にもIT系の技を使って開発者の視点で行うホワイトボックステスト、ユーザーの視点で行うブラックボックステストの両方をやってみましょう。

まとめ

ブラックボックステストやホワイトボックステストについて紹介しました。境界値分析や同値分割など、テストで使われる用語まで触れてしまいましたが、この辺りの考え方も頭に入れておくとテストで自信を持って確認を行うことができます。

目的は意図した通りにゲームが作れているか、ユーザーの操作に対して意図した通りに動いているかを確認することです。ユーザーが楽しくゲームを遊んでくれるのを支えるためにもテスト手法も身に付けていけるとグッド。