できるところから始めよう～ゲーム開発支援ツールのテスト自 … · –C/C++ –プラットフォーム •Windows（約45万行） •組み込み（約10万行）

できるところから始めよう～ゲーム開発支援ツールの

テスト自動化事例

自己紹介

• 白柳隆澄（しらやなぎたかずみ）

– 株式会社インテリジェントシステムズ

– 総合開発部総合開発課システムプログラマー

ゲームプログラマーとして3年間働いたのち、2010年に株式会社インテリジェントシステムズに入社。システムプログラマーとして、ゲーム開発支援ツールの開発に従事。組み込みソフトウェア、Windows ソフトウェアの開発のほか、Jenkins の管理者としてテスト自動化やビルド環境構築にも従事。

2

ゲーム開発支援ツールって何？

インテリジェントシステムズの代表作

– ファイアーエムブレムシリーズ

– ペーパーマリオシリーズ

– メイドインワリオシリーズ

– 引ク押スシリーズ

– ゲーム開発支援ツール

• ゲームソフトを制作するための機材・ソフトウェア

3


インテリジェントシステムズは

ゲーム開発会社であり

ツールベンダーでもある

とても珍しい会社

• ゲーム開発とツール開発で相互に情報共有

• より良いものを作るための良い関係

4


• ハードウェア（機材）市販のゲーム機ではできないデバッグや映像出力などを可能にした開発専用のハードウェア

• ソフトウェアハードウェアを操作するためのソフトウェア

– デバッガー

– キャプチャー

– ビデオ出力

– テスティング支援

5


どんなものかわかっていただけましたか？

6

どういうことを話すの？

• テストとそれにまつわる自動化の話

• ゲーム開発支援ツールの開発ではこうしている！

• お話する内容が正解ではありません

• テスト自動化に関しての情報共有意見交換ができたらいいなと考えています

7

このセッションは参考になるの？

ところで、ゲーム開発とツール開発って

全然違うんじゃないの？

8

テスト自動化の観点での共通点

• ゲーム開発もツール開発も同じソフトウェア開発

• テスト自動化に対する考え方などは一緒と言って良い

• プログラミング言語も（ほぼ）一緒

• 専用ハードウェア上で動作する点も同じ

9

アジェンダ

1. ゲーム開発支援ツールって何？

2. テスト自動化事例

1. 単体テスト

2. システムテスト

3. テスト戦略

3. できるところから始めよう

4. まとめ

10

開発規模

• 開発メンバー

– 少人数で開発

• 開発ソフトウェア

– デバッガー

– キャプチャー

– ビデオ出力

– テスティング支援

– Visual Studio 連携

11

開発規模

• プログラム開発

– C/C++

– プラットフォーム

• Windows（約45万行）

• 組み込み（約10万行）

• ゲーム機（約10万行）

• ゲーム開発支援ツールはシリーズもの

– ゲーム機の進化とともにツールも進化

– ノウハウやソースコードを引き継いで開発

12

開発規模

• 継続的にアップデート

– １～２ヶ月に１回のペースでリリース

– 常に新規機能を開発

• デバッグ

– すべて自分たちでデバッグ

– 変更点のみに集中してデバッグテストがあるからできること

13

ソフトウェア開発にテスト自動化は欠かせない

14

アジェンダ



1. 単体テスト


3. テスト戦略


4. まとめ

15

テスト自動化事例

• 単体テスト

• システムテスト

• テスト戦略

16

アジェンダ



1. 単体テスト


3. テスト戦略


4. まとめ

17

単体テスト

18

Windows プログラムの単体テスト

単体テストを導入して最初に書いたのが Windows プログラムのテスト

19

テスティングフレームワーク

Google Test を採用

• 言語は C++

• 有名どころ

– Google Test

– Boost.Test

– CppUnit

– Catch

なぜか？

• Jenkins で集計可能な XML を出力できる

• 記述量が少なくてすむ

• 日本語ドキュメントが充実

• CEDEC 2010に参加したときに良いと聞いた

20

テストコード例

TEST(CEDEC, Test) { for( int i=0; i < 100; ++i ) { SCOPED_TRACE(Message() << "loop " << i); ASSERT_EQ(nullptr, p); EXPECT_EQ("IS", p->name); EXPECT_LT(0, p->size); for( int j=0; j < p->size; ++j ) { EXPECT_NE(0, p->data[j]) << “ [" << j << "]"; } } }

• テストが失敗してもなるべく続行する

– ASSERT は続行不可能な場合にだけ使う

– それ以外は EXPECT

• 失敗したときの情報をなるべく出力する

– SCOPED_TRACE

– EXPECT_EQ(x,y) << "情報"

21

自動化

Jenkins !!

• Google Test が出力するテスト結果XMLを集計

• 失敗通知等は Jenkins から

22

構成

特に難しいことはしてません

23

詳しい話は別の機会があれば…

Jenkins 関連の話は尽きないので別の機会があれば…

24

Groovy ちょー便利

• Groovy Postbuild Plugin ビルド後の処理で Groovy Script を実行できる

– テスト結果の説明に自動で書き込み

– パラメータの見える化

– 致命的な失敗が発生した場合にオフラインにする

25

組み込みプログラムの単体テスト

組み込みソフトウェアの場合

26

Windows 上で実行可能にする

• プラットフォームやハードウェアに依存しないアルゴリズムなどは簡単に対応可能

• 入力と出力を整理してまとめることでテスタビリティが向上

27

Windows 上で実行可能にする

• プラットフォームやハードウェアに依存する場合でもモックを作ることでテスト可能

28

Windows 上で実行できない場合

• ハードウェア上でしかできない or したいテストがある

– プラットフォーム、ハードウェアに依存する

– モック作成が困難、もしくは手間がかかる

• ハードウェア側にテストプログラムを置く方法

– ツールの場合、容量不足のため不可

29

通信プログラムを介してテスト

• PC とハードウェア間で情報をやりとりできるプログラムを作成

• PC 側にテストを書く

30

通信プログラムを介してテスト

• 入力をハードウェア側に与える

• ハードウェア側が指示に従い動作をする

• 動作した結果をハードウェア側に尋ねる

• 返ってきた結果を出力とし比較テストする

31

ゲーム開発の場合

組み込みの場合と一緒

• Windows 上で実行できるようにする

• ハードウェア上でしかできないテスト

– PC側と情報をやりとりする

• PC側と通信する環境は用意されているので、それを利用

– ハードウェア側にテストプログラムを置く

• テスティングフレームワークが提供されている

• テストの自動実行と結果のフィードバックがあれば独自フレームワークでも可能

32

アジェンダ



1. 単体テスト


3. テスト戦略


4. まとめ

33

システムテスト自動化の道のり

デバッガーソフトウェアのシステムテスト

34

システムテストの導入

デバッグの単純作業の繰り返しをテスト化するところから始まった

35

システムテスト（初期）

• 手動で行っていた作業のテストコード化

– テストコードはアプリケーションの中に埋め込み

– メニューバーから手動で実行

– 半自動

36

システムテスト（初期）

結果

• 毎回やっていた多くのデバッグ手順が自動化

• デバッグ工数のコストダウンができた

問題

• テスト漏れ

• テスト時間増加

• テスト中に PC を占有

– 誰もテストをしなくなり…

– 最終的にメンテナンスされなくなり…

37

システムテストの自動化

Jenkins の導入をきっかけに自動化対応

• 自動化のポイントは以下の３つ

– テスト実行の自動化

– 比較の自動化

– フィードバックの自動化

38

• 既存のシステムテストを再利用

• テスト実行の自動化

– 管理クラスに登録されたテストを順番に実行

– コマンドライン引数からのテスト実行に対応

– Jenkins のジョブに登録

テスト実行の自動化

39

テストの事前・事後処理の自動化

• スクリプト化

– コマンド機能をスクリプトから実行

– テストに必要なテストプログラム（ゲーム）のダウンロード実行や、ブレークポイント設置など

40

比較の自動化

• スクリプトで比較処理

– 特定のバージョンを正しい挙動のバージョンと決めその出力を比較データとした

• 比較する出力（一例）

– ログ出力などのテキスト情報

– コールスタック、ウォッチ等

• ツリー構造など、見た目に関わる部分もテキスト化

41

比較の自動化

• ログの一例

42

Watch

├─a 0x0000000A 0x0FFFFFEC int

├─i --- ‘i’ は、最適化により評価できません。

├─test 0x00000014 0x0FFFFFE4 CTest

│ ├─m_nData 0x0000000A 0x0FFFFFE4 int

│ └─m_nData2 0x00000014 0x0FFFFFE8 int

└─pTest 0x0FFFFFE4 0x0FFFFFE0 CTest*

├─m_nData 0x0000000A 0x0FFFFFE4 int

└─m_nData2 0x00000014 0x0FFFFFE8 int

比較データ作成の自動化

• テストモードと比較データ作成モードをスクリプトに用意

• モード変更のみで比較データを自動作成

43

テストセットの管理

比較データ、テストスクリプト、テストデータなど、

テスト実行に必要なファイルの管理

• 比較データ、テストスクリプトはバージョン管理

– 最新仕様にあわせて、比較データ・スクリプトは更新される

– 古いバージョンでもテストができるように、ソースコードと一緒にバージョン管理

• テストデータはネットワークドライブ上に配置

44

フィードバックの自動化

Jenkins !!

• Google Test と同じ形式で XML 出力する機能を実装

• 単体テストのときと同様に XML を集計

• 失敗時の通知等は Jenkins から

45

自動化できました

46

まだまだある問題

• 失敗したテストが修正されない

• テスト数増加によるコストアップ

47

失敗したテストが修正されない

• 修正されないテスト

– 放置されたテスト

– たまにしか失敗しないテスト

– Jenkins で実行したときだけ失敗するテスト

テストの失敗が続くと重大なテストの失敗が埋もれてしまう

フィードバック情報の改善、テスト間依存の排除など対処したが、どうしても修正されないテストは残ってしまった

48

テスト数増加によるコストアップ

• テスト数の増加

– メンテナンスコストが増加

– テスト時間が増加

– すべてのテストが終わるのに、12時間以上かかったことも…

テスト時間が増えると変更に対してのテストフィードバックが遅くなる

ビルドごとにやるテスト、１日１回、週１回のテストと分けているが新しいテストが追加されていくので、増加の一途をたどるばかり…

49

テストのフィルタリング

テスト属性でフィルタリング

• 自動テスト対象かどうか、テスト頻度など

• ハードウェア前提条件

• 検証テスト属性を追加

50

さらなる自動化

テストの自動振り分けに対応

51

テストの自動振り分け

テスト属性に対応した Jenkins ジョブ

52

「メインテストジョブ」

TEST •ビルドごとにテスト •重要なテスト

「デイリーテストジョブ」

TEST-DAILY •１日１回のテスト •安定した、変更の少ない所のテスト

「テスト検証ジョブ」

TEST-INSPECTION •テストの検証用ジョブ •不安定、失敗が連続したテスト

「ウィークリーテストジョブ」

TEST-WEEKLY •週１回のテスト •安定した、変更の少ない所のテスト


■ テスト本来の属性と付加ファイルの属性をマージ

■ 長期間失敗がなく成功しているテスト → DAILY や WEEKLY へ

■ 不安定なテスト、失敗が連続したテスト → INSPECTION へ

53


自動振り分けに対応したことで

• ジョブが成功状態を保ちやすくなった

• 失敗したテストにすぐに気付ける

• テストの回転率が向上

• 検証属性のテストは再評価

– テスト側の不備、前提条件不足タイミング依存や実行順序依存などが炙り出される

– メンテナンス性の悪いテストや効果の薄いテストを捨てやすくなった

54

システムテスト自動化事例

ここまでが現時点でツールチームが行っているシステムテストの全てです

しかし、これで完成ではなく改善を積み重ねていくのが大事

55

ゲーム開発の場合

自動化におけるポイントは同じ

• 初めは手動実行でも OK

• 自動化の各ポイントを押さえる

– テスト実行の自動化

– 比較の自動化

– フィードバックの自動化

56

GUI テスト

GUI のテストについて少しだけ紹介します

57

GUI テスト

• システムテストを利用

– システムテストの仕組み上で GUIテスト

– GUI 操作と同等のコマンドやイベントが発生したふりをして関数呼び出し

• GUI 操作スクリプトを使用（一部だけ）

– AutoIt を使用していた

– Friendly を最近使い始めた

– Sikuli が気になっている

58

アジェンダ



1. 単体テスト


3. テスト戦略


4. まとめ

59

テスト戦略

ツールチームでは明確なテスト戦略はありませんテストをしていく上で気をつけている部分など、どのようにテストと向き合っているかを紹介します

• テストの目的

• テストの記述

• 網羅・取捨選択

• チームでの取り組み

60

テストの目的

• 不具合を検出するためのテスト

• 動作保障のためのテスト

– 既に出来上がっているものに対してテストを書くことが多いため、仕様を保障するのが目的

– テストで保障をすることで、リリース前のデバッグでは変更点のみに集中できる

61

テストの記述

• Red/Green/Refactor のサイクル

• 厳格なテスト駆動開発ではない

– テストファーストや、カバレッジ100% はしてない

62

テストの記述

• バグが出たとき

– バグを直す前に、まずは再現テスト

– バグを直したら、テストで確認

– 高速化、メンテナンス性の向上などリファクタリング

– Red/Green/Refactor のサイクルで修正しやすい

63

網羅・取捨選択

• すべてのコードを網羅するのは（時間的に）不可

• 挙動の違いが出やすい部分を選択する

– 上限・下限値、境界値

– 代表値（同値分割）

• エラーケースは忘れがちなので注意

• なるべく低レベル層でテストしておく

– 下のレイヤーから保障することで、上のレイヤーも保障しやすい

64

網羅・取捨選択

状況から考える

• 正確性が必要な部分はきっちりテスト

– 認証試験、お金が絡む部分など、失敗できないところ

• 不安をテストにする

– この修正を入れたいけど、大丈夫かな…

– とりあえずできたけど…

– テストを書くことで不安を解消

65

チームでの取り組み

• マネージャー/リーダー

– テストや自動化の課題を投げる

– チームの課題として扱う

• テスト自動化担当者

– チームメンバーが課題を解決するための土台作り

– テスト環境や自動化フロー、 Jenkins のユーティリティ、etc...

– オレオレ環境にしない、情報共有

66

アジェンダ



1. 単体テスト


3. テスト戦略


4. まとめ

67

テスト自動化の話をしてきたが…

最後に失敗談

私が担当しているソフトウェアには、システムテストがなかった

• 私は優秀なテストエンジニアではない

• テストよりも機能実装していた方が楽しい

• 引き継いだ膨大なソースコード

• 時間は待ってくれない

68

一言でいうと

テストを書くのが面倒臭かった

69

致命的なバグが出てしまった

ただ、それで上手くいくわけがなく… 致命的なバグが発生しました

対処

• 原因調査

• コード修正

• 動作確認

70

バグを直したし今後は安心？

本当はテストで保護したいけど…

• 一度直したから大丈夫

• 今後同じ所でバグは出ない

71

同じ致命的なバグが再発

そんなわけがない！

致命的なバグだったため、修正を優先して対応

対処

• 原因調査

• コード修正

• 動作確認

72

なんでテスト書かなかったの？

• 最初にバグが出た時にテストを書いておけば…

– テストを書く環境がなかった

– 致命的なバグのため修正スピードが重要だった

• なぜ、テスト環境を用意していなかったのか…

– テスト環境を構築する時間がなかった

– 既存のテスト環境（システムテスト）と比べ、より高機能なテスト環境を想定していた

73

テスト環境の構築をした

• 同じミスを何回も繰り返してはいけない

• テスト環境を構築

– 最低限のことができればよい

– Google Test を採用

• 最低限のテストを記述

– バグは修正済みだが、テストを記述

– 他のテストは一切なし

74

別の致命的なバグが出た

• 原因調査

• 再現テスト記述（テストで再現することを確認）

• コード修正

• 動作確認

テスト環境があるためテストがすぐ書ける！

すぐにテストが書ける環境があるかないかで全然違う

75

テスト書いてバグ修正した方が

気持ちいい！！

76

アジェンダ



1. 単体テスト


3. テスト戦略


4. まとめ

77

まとめ

• 組み込みやゲーム開発でもテストできます

• できるところから始めよう

– まずは始めること、小さな一歩が大きな歩みとなる

– 「テストが書ける」環境を作りましょう

• 改善を繰り返そう

– テスト自動化に対する問題はプロジェクトごとにそれぞれ出てきます

– １つ１つ改善を積み重ねていくことが大事です

78

79

Windows® の正式名称は、Microsoft® Windows® Operating Systemです。

Microsoft、Windows および Visual Studio は、米国 Microsoft Corporation の、米国およびその他の国における登録商標または商標です。

Jenkins Logo： https://wiki.jenkins-ci.org/display/JENKINS/Logo

INTELLIGENT SYSTEMSロゴは株式会社インテリジェントシステムズの登録商標です。

その他記載されている会社名、製品名、ロゴは各社の登録商標または商標です。

Documents

できるところから始めよう～ ゲーム開発支援ツールの テスト自 … · –C/C++ –プラットフォーム •Windows（約45万行） •組み込み （約10万行）

できるところから始めよう～ゲーム開発支援ツールのテスト自 … · –C/C++ –プラットフォーム •Windows（約45万行） •組み込み（約10万行）