自動的にテストケースを作る方法 組み合わせ編

自動的にテストケースを作る方法はないの？と言う話が、今年のCEDECのラウンドテーブルで出ていたのですが、なんとなく相手のニーズに合わない気がしたので、発言しなかった内容をまとめてます。

テストを操作とパラメータに分ける

自動化されたテストを作成する際には「どれくらいテストを再利用出来るのか？」が重要になります。皆さんがxUnit系のテスティングフレームワークを使い出した時には下記のようにテストを書くと思います。

TEST(TestCaseHoge, TestFoo) {
  ASSERT_TRUE( FuncFoo(0) );
  ASSERT_TRUE( FuncFoo(1) );
  ASSERT_FALSE( FuncFoo(-1) );
}

FuncFooに対して三つのパラメータをテストしています。この場合はひとつの関数に３つのパラメータなのでスッキリしていますが、開発が進むと、だんだん次のようになって行きます。

TEST(TestCaseHoge, TestFoo) {
  bool f;
  int b;
  float z;
  f = FuncFoo(0);
  ASSERT_TRUE( f );
  b = FuncBar(0);
  ASSERT_EQ( 0,b );
  z = FuncBaz( f,b )
  ASSERT_EQ( 0.0f,z ); 

  f = FuncFoo(-1);
  ASSERT_FALSE( f );
  b = FuncBar(1);
  ASSERT_EQ( 1,b );
  z = FuncBaz( f,b )
  ASSERT_EQ( 1.0f,z );
  .
  .
  .
}

もうゴチャゴチャして危険な感じがしてきました。もう、こうなくるとテストを書きたくなくなります。

しかし、よく見ると二番目の複雑なテストも三つの関数の呼び出しに対して、すべて同じように二つのパラメータを与えているだけです。これは次のようにまとめられます。

AllFunc(int arg1,int are2,bool test1,int test2,float test3)
{
  bool f;
  int b;
  float z;
  f = FuncFoo(arg1);
  ASSERT_EQ( test1,f );
  b = FuncBar(arg2);
  ASSERT_EQ( test2,b );
  z = FuncBaz( f,b )
  ASSERT_EQ( test3,z );
} 

TEST(TestCaseHoge, TestFoo) {
  AllFunc( 0,0,true,0,0.0f);
  AllFunc(-1,1,true,1,1.0f);
  .
  .
  .
}

あとは各テストに必要なパラメータを、テーブルで持ったり、スプレッドシートから読み込んでもいいでしょう。ここで重要なのは「テストに使用する操作」と「テストに使用するパラメータ」を分けて管理する事です。これによりテストがより再利用しやすくなります。

テストに使用するパラメータを自動生成する

テストは再利用しやすくなりましたが、やはりテストに使用するパラメータは、自分で用意しなければなりません。何も無い所からはパラメータを作成できないので、完全に自動生成は出来ないのですが、テストに使用するパラメータの数とその種類を設定するだけで、自動的にテストに使用するパラメータのバリエーションを作成してくれるツールがあります。

その「組み合わせテストケース作成ツール」と呼ばれるツールの中で、有名なソフトとして「PICT」があります。これ自体はコマンドラインツールでテキストファイルを入力してテキストファイルを出力するツールですが、「PICT」を使いやすくしたフロントエンドアプリケーションとして「PictMaster」も有名です。

このツールを使うと、次のようなパラメータの組み合わせを設定するだけで、実際にテストに使用するパラメータの組み合わせを作成してくれます。

テストしたいパラメータの組み合わせ

「パラメータ1」　(パターン1) 0, (パターン2)-1
「パラメータ2」　(パターン1) 0, (パターン2)1

テストに使用するパラメータの組み合わせ

「パラメータ1」0,「パラメータ2」0
「パラメータ1」0,「パラメータ2」1
「パラメータ1」-1,「パラメータ2」0
「パラメータ1」-1,「パラメータ2」1

これで、パラメータ自体も自動的に生成できるようになりました。

「PICT」はもともとはパラメータの組み合わせが爆発した時に、効率よくテストを間引くためのツールになります。何個のパラメータの組み合わせまでを網羅するのか、パラメータの種類同士でテストする必要のない組み合わせはどれなのか、を設定する事によって、効率よく組み合わせを間引くことができます。

テストケースの完全自動生成に向けて

ここまで来れば、自動的にテストケースを生成する目処が着いたのではないでしょうか？

環境を限れば、もっと便利にもっと自動的にテストケースを作成するツールは存在します。しかしゲーム制作に使用する環境では使えないツールがほとんどだと思います。

ただ環境が揃うのを待つよりは、全自動ではなくても、出来るところからテストケースの自動生成にチャレンジするのは良いのではないでしょか。

ゲームロジックがマルチコア対応し難い理由

マルチコア対応が必要な理由

 現在デジタルゲームの主流になっているハードウェアプラットフォームではマルチコアCPUが搭載される事が標準となっています。先日発表されたPS4では8コアがひとつのCPUに搭載されており、プログラムがマルチコアに対応する事により、8倍の性能を出す事ができます。しかし逆に言うとマルチコア対応していないプログラムは1/8の性能しか出せていないとも言えます。

QAで発見されたバグは修正コストが高い

テストプレイで発見されたバグは、開発者に発見されたバグより修正コストが多くかかります。

テストプレイでバグが発見された場合、一般的に下記の手順で修正が行われます。

1. テストプレイでバグが発見される
2. バグ票に再現手順が記入され開発者に届けられる
3. バグ票を元に開発者がバグを再現する
4. 開発者がバグの修正を行う
5. バグを修正した事がバグ票に記入され発見者に届けられる
6. 発見者はバグが修正された事を確認する

順調に行った場合は、これだけの手順で済みますが、時々下記のような状況が発生します。

• バグ票の再現手順では再現しない。
• バグ票には修正された事として帰ってきたが、実際には修正されていない。

実際に開発者がソースコードやデータを確認するのではなく、テストプレイを実行する人が目で見たものを、ドキュメントに書いて報告するのには多くのコストがかかります。
また、報告されたバグ票を読んで、再現して、修正して、報告するのにもコストがかかります。
それに比べ、開発者が自分で見つけたり、同僚が問題のソースコードやデータを発見した場合は、自分で修正を行って報告を行えば良いだけです。
余計なコミュニケーションのロスは発生しません。

もしテストプレイにアプリケーションを渡す前に、ひとつでも多くのバグを修正できたら、テストプレイの作業を効率化する事が出来たなら、別の事に多くの時間を使う事が出来るかも知れません。

キャラクタープログラムのテスト

ゲームプログラムでのソフトウェアテストは難しいものとして認識されています。

画面上に表示された2Dキャラクターが、ゲームパッドのスティックを左右に入れる事により移動して、ボタンを押す事によりジャンプをする。
今回はキャラクタープログラムのテストを考えてみます。

バグが発生する仕組み

プログラマは毎回慎重にプログラムを作成していますが、如何しても一定数のバグが発生してしまいます。
そこで今回はバグが発生する仕組みについて考えて見ます。

規模の拡大に強い開発体制とは

今年のCEDECでは開発プロセスやプロジェクトマネージメントに関するセッションが多くありました。本当に多かった為に自分は全てのセッションを見れていません。

近年プロジェクトマネージメントが注目されて来た事もあり、安定したスケジュールでリリースを行うノウハウは共有されてきましたが、どうしても特定人物に負担が集まる傾向が何処でもあり、その解決の糸口になるセッションを探していた所、注目のセッションがありました。

「CEDEC2012」スケールアウトできる開発体制構築の取り組み
http://jcgs.co.jp/presentation/CEDEC2012-C12_P0206_public.pdf


とても、ためになる話が多かったのですが、規模の拡大を行う為に標準化で対応しようとしていた事が少し気にかかりました。

パフォーマンスエンジニアリング

コンピュータソフトウェアを作る上で、パフォーマンスが重要な分野はまだまだあります。
しかしパフォーマンス向上には、少なからずコストがかかります。
コストがかかると言う事は、かかるコストに対する効果を示せなければ、実際に実行に移す事が難くなります。
経験と感ではなく、統計と理論によりパフォーマンス向上させる事を、パフォーマンスエンジニアリングと呼びます。