2010年は2010
年は 200セッション
200セッション 4500⼈の4500⼈のゲーム開発者・研究者が参加！

JaSST’11 Tokyo

コラボ企画～ゲーム開発でのソフトウェアテストの実例～
CESA Developers Conference

ゲーム開発の世界から

ゲーム業界全体の技術⼒向上を⽬的とした
⽇ 本 最 ⼤ の ゲ ー ム 開 発 者 向 け
国 際 的 技 術 カ ン フ ァ レ ン ス～金をドブに捨てないようにするテスト～

変⾰激しい今⽇のゲーム業界において
産 学 官 ・ 業 界 の 垣 根 を 越 え
最 新 技 術 や ビ ジ ネ ス 情 報 を 共 有

2011年 1⽉ 26⽇

CEDEC プログラムWG リーダー

庄司 卓

業界をリードする⼀流開発者による講演や最新のテクノロジー、ビジネス情報が発信され現場の第⼀線で活躍するゲーム開発者・技術者・
研 究 者 が ⼀ 堂 に 会 し ま す ! !

株式会社セガ伊藤 周、粉川 貴⾄

CEDEC 2010 セッション抜粋• ゲームシナリオの現場から。開発過程におけるゲームシナリオのチェックポイント。
沼本 裕之（コーエーテクモゲームス）• 企画開発段階のチューニングからデバッグ、
ローカライズ、ユーザーサポートまで〜ユーザー視点でのワンストップサービス
橘 鉄平（ポールトゥウィン株式会社）、橋本 徹（株式会社猿楽
庁）、⼩⻄ 直⼈（ピットクルー株式会社）• SCEから⾒るゲームタイトルにおける品質管理
古川 隆信（SCE）• ユニットテスト導⼊の技術的課題とその解決例
主催：⼀般社団法⼈コンピュータエンターテインメント協会

益 弘和（Ubisoft Osaka 株式会社）© 2011 CESA

ゲーム開発の世界から～金をドブに捨てないようにするテスト～

前編：ゲーム開発におけるユニットテストの実例
実例
株式会社セガモバイルニューメディア研究開発一部 シニアプログラマー
伊藤周
E-mail:Ito_Makoto@sega.co.jp

2月上旬：講師募集開始!
© 2011 CESA

自己紹介
• 伊藤 周（いとう まこと）
• 1973年神奈川県生まれ• 1998年株式会社セガ入社• 主にゲームセンター向けゲームの開発に携わる• 1998年 スターウォーズトリロジー
ズ
ジ• 2000年 EA NASCAR ARCADE• 2002年 頭文字D
• 2006年 アーケードカードゲーム• 2010年 モバイルニューメディア事業部に転属• 現在 ブラウザゲームを開発中

突然ですが

ゲームプロ
グ
グラマ診断
診断
テスト

1

プログラマ診断テスト

バグを企画（非PG）から指摘されて…

「あなたはゲー
ムプログラマに向いてい向る？いない？」
診断• あなたはどう返しますか？

バグを企画から指摘されて…

当セッションを通して言いたいこと• あなたはどう返しますか？
1. 仕様のせい→ ○2. 専門用語で煙に巻く → ○3. 「あ、了解です」
あ、了解 す」→ ◎4. 納期のせいにする → ○5. 一応謝る→ ◎6. 心の底から反省→ ×

1. 「仕様が複雑」と仕様のせいにする
2. 「使っているAPIが…」と専門用語を駆使して煙に巻く3 「あ、了解です」とシレっとスル
3.
「あ 了解です」とシレっとスルーする
する
4. 「スケジュールがギリギリでチェックの時間が…」と納期のせいにする
5. 「ああ、すまんすまん」と一応謝るが、毛ほどにも悪いと思わない
6. 「すみません！」と心の底から反省し、二度としないと誓いを立てる• ゲーム開発はシステム開発／組み込み開発と違っているのか？
→ところどころ違う• ではゲーム開発の方法論はシステム開発に応用できないのか？
→修正すれば適応可能

相違点を意識しつつ他の開発現場にも転用してはどうでしょうか？

バグの定義（このセッション内における）• 「仕様どおりにソフトウェアが動かないこと」
仕様にないこと
はバグではないのか？

アジェンダ• ゲーム開発の特徴• ゲーム開発におけるテスト• ご提案• 仕様を解釈したプログラマの意図した通りにソフトウェアが動かないこと

2

ゲーム開発の特徴１

ゲーム開発の特徴２• C/C++が中心（Javaはほとんどなし）• 最近はソーシャルゲームの高まりでActionScriptも• ゲームのコアにスクリプトを導入する例もある（Lua、Python等）• 分担作業• ディレクター• 全体統括• 企画• 仕様書作成、難易度調整• デザイナー• 2D、3D、画面レイアウト• プログラマー• 上記以外のキーボードを打つ仕事

ゲーム開発の特徴３

ゲーム開発の特徴４• ビジネススキーム• 映像中心ハードメーカー開発依頼• ロジックよりも見た目を重視• とりあえず動いて見えればいいという弊害
も• 仕様も抽象的になりやすい
仕様も抽象的 なす• 仕様変更が多い• 「仕様」が売上げに直結する• 明確な仕様書がない（できない）

受注・納品
ディベロッパー

パブリッシャー

小売り

アジェンダ

アジェンダ

• ゲーム開発の特徴• ゲーム開発の特徴• ゲーム開発におけるテスト• ゲーム開発におけるテスト• ご提案• 現状のテスト
ユ ットテスト• ユニットテスト• 現実的なテスト

• ご提案

3

現状のゲーム開発におけるテストは…

人力テストとは• プレイテスト• 人の手で仕様と見比べて間違っていない
かチェックする• 面白さの検証• 誰が？

• 人力テスト• 手の空いているチームメンバー
手の空 て るチン
• QAチーム• 外注会社• 人手によるテスト

人力テストの利点

人力テストの欠点• 仕様が複雑になると、テストする項目が指数関数的に増える• 導入が簡単• 見積もりやすい• 人月コスト• 人間ならではの複雑なテストができる• QAチームにノウハウが溜まりやすい＝バグを見つけやすい

例：カードゲーム（5枚１デッキ、数十種類のカード）→デッキの組み合わせで…

武器右
n種類

武器左
n種類

メカ
m種類

キャラ
l種類

特殊効果
o種類

n ×n ×m ×l ×o種類の組み合わせ！

人力テストの欠点

人力テストはダメ？

• 回帰テスト（以前起こったバグのテスト）が事実上困難• n個のバグに対する回帰テストはn-1の階乗
回しなくてはいけない

これはこれで必要不可欠• 人間ならではの複雑なテストが出来る
ただ…

7
6

これに頼ってだけでは破綻してしまう

5
回帰テスト回数4• コストも• 個人のリソースも

3
2
1
0

1個目 2個目 3個目 4個目 5個目 6個目 7個目 8個目
バグ発見回数4こういった現状を打破するため

アジェンダ• ユニットテスト• ゲーム開発の特徴→効果があるが、問題点も• ゲーム開発におけるテスト• CI• 現状のテスト
ユ ットテスト• ユニットテスト• 現実的なテスト→効果大（詳細は後半で）• 静的解析ツール

• ご提案

→効果大

ユニットテストとはユニットテストとは（コーディング例）• 例：状態遷移クラス• １機能（≒１クラス）
に対し、１つのテストプログラムを作る

class State {void setState( STATE inState );void update();STATE getState() const;}};• 「ひとつのユニット（＝クラス）を多方向から調査」するイメー
ジ• 通常テストフレーム
ワークを使うテスト• 別名単体テスト

SLEEP

クラス
WALK
テスト

WAKE UPINIT• CppUnit (C++)• Google Test(C++)

ユニットテストとは（コーディング例）• 例：状態遷移クラス↓テスト実装ユニットテストとは（コーディング例）• 例：状態遷移クラス

class State {void setState( STATE inState );void update();STATE getState() const;};

void StateTest::testSetState(){
State state;// 事前条件CPPUNIT_ASSERT_EQUAL( INIT, state.getState() );// 「SLEEP」をセットするとSLEEP状態になる
state.setState( SLEEP );// 事後条件CPPUNIT_ASSERT_EQUAL( SLEEP, state.getState() );}↓テスト実装INIT

SLEEP

class State {void setState( STATE inState );void update();STATE getState() const;};

void StateTest::testUpdate(){
State state;// 事前条件
state.setState( SLEEP );CPPUNIT_ASSERT_EQUAL( SLEEP, state.getState() );// １０回updateするとWAKEUP状態になる
for( int i=0 ; i<10 ; i++ ) { state.update(); }// 事後条件CPPUNIT_ASSERT_EQUAL( WAKEUP, state.getState() );
}

SLEEP

WAKE UP5

ユニットテストの効力

ユニットテストの導入障壁• 何度でも同じテストを行える• 面倒くさそう→エンバグ（修正時にバグを混入させてしまう）防げる• 時間がかかりそう• ユニットテストの誤解• リファクタリングが容易
リフ クタリングが容易→可読性の確保、再利用可
LEADER• テストを先に作って、それに合うように実装することも可能

このテストに合うように実装して

1 「テストにバグがあ1.
「テストにバグがあったらどうするん
たらどうするんだ？」
2. 「コードが増える」＝「バグが増える」
3. 「映像中心のゲーム開発には不向き」

PROGRAMMER
了解、ボス

誤解１：「テストにバグがあったらどうするんだ！」
I.

テスト（バグなし）＋プログラム（バグなし）
→OK

II.

テスト（バグなし）＋プログラム（バグあり）
→NG!

III.

テスト（バグあり）＋プログラム（バグなし）→NG!

→あれ？良く見たら…

→OK

IV. テスト（バグあり）＋プログラム（バグあり）→OK

誤解２：「コードが増える」＝「バグが増える」• テストプログラムは
ゲームプログラムを一方的に使うだけ• ゲームプログラムを荒らすことはない• テストにバグがあってフリーズすることがあってもゲームに影響はないTESTPROGRAMGAMEPROGRAM←間違い！ だが…

テストを作らなくてもスルーしていたバグ

誤解３：「映像中心のゲーム開発には不向き？」• テスト次第• 自動プレイテスト• リプレイテスト• スナップショットテスト→後ほど説明コーヒーブレイク• 過去、うまいことを言った人（PG)が…
• 面白ければ…
• ディレクターのおかげ• 絵が綺麗ならば• デザイナーのおかげ• ゲームが売れたら• プロデューサーのおかげ• バグが出たら• プログラマのせい

6

アジェンダアジェンダ• ゲーム開発の特徴• ゲーム開発の特徴• ゲーム開発におけるテスト• ゲーム開発におけるテスト• 現状のテスト
ユ ットテスト• ユニットテスト• 現実的なテスト• 現状のテスト
ユ ットテスト• ユニットテスト• 現実的なテスト• ソフトウェアテスト
• 自動テスト

• ご提案

• ご提案

現実的なテスト：局所的テスト

現実的なテスト：局所的テスト• 不具合が実際に起こったところを重点的にテスト• 間違ったところだけやればいいので気が楽• 開発後期でも導入可• ただユニットテストへの導入障壁が…
ただユ ットテスト の導入障壁が…

TE
EST• 不具合状況の再現• 類似した不具合が起こりそうな状況もテスト• 非常に有効TEST

現実的なテスト：組み合わせテスト

現実的なテスト：組み合わせテスト• 複雑な組み合わせを全て網羅• 複雑な組み合わせを全て網羅

例：全ての武器の組み合わせで整合性をテスト

例：武器の組み合わせの整合性をテスト

武器左

武器右

キャラ

武器左

武器右

キャラ

void MechaTest::testWeapon(){
WeaponChecker cheker( "check.xls" ); // 企画が作ったチェック用Excelを読込
for( int i=0 ; i<MAX_WEAPON ; i++ ) {// 右手の武器のループ
for( int j=0
j 0 ; j<MAX
j<MAX_WEAPONWEAPON ; j++j) {// 左手の武器のル
左手の武器のループプ
Mecha mecha;// 事前条件CPPUNIT_ASSERT_EQUAL( false, mecha.canUseWeaponL() );CPPUNIT_ASSERT_EQUAL( false, mecha.canUseWeaponR() );// メカに左右の武器をセット
mecha.setWeapon( i, j );checker.set( mecha, i, j );// 事後条件CPPUNIT_ASSERT_EQUAL( checker.canUseWeaponL(), mecha.canUseWeaponL() );CPPUNIT_ASSERT_EQUAL( checker.canUseWeaponR(), mecha.canUseWeaponR() );
}
}
}

7

現実的なテスト：組み合わせテスト• 非常に有効• 何個もバグを検出• 回帰テストも楽々• これもユニットテストの導入障壁が…
• やってみせれば、効果は一目瞭然

現実的なテスト：分割統治• ゲーム部とシステム部の切り分け• ゲーム部＝流動的な箇所• 例：ゲームルール、演出、ストーリー、→テストを作らない• 例：算術ライブラリ、物理
計算、画像データ管理、
描画周り→テストを作る

現実的なテスト：分割統治• 難あり• ゲーム部分とシステム部分の切り分けは容易
ではない• システム部が完全に分離できていれば可• 他部門で作られたライブラリ

TEST×

GAME

• システム部＝固定的な箇
所
TEST○

SYSTEM

現実的なテスト：単純な結合テスト• プレイヤークラスはたいてい複数のクラスを利用されている• とりあえずインスタンス生成
するだけでもテストにはなる• 例：３Dモデルをリソース管理クラスで読み込み、キャラクタークラスに結びつける

現実的なテスト：結合テストの注意点• それぞれのクラスの独立性の確保→むしろ望むところ

現実的なテスト：ゲームアプリ以外とのやり取りの再現• 解決策：モック(Mockpp)の利用
例：ランキング管理クラス
問い合わせ• DBやファイルアクセス等のゲームアプリ
DBやファイルアクセス等のゲ ムアプリ
以外とのやり取りの再現

実際の
結合

ラ キ グ
ランキング
管理クラス

モックとの
結合

ランキング
管理クラス

DB

実際の順位

問い合わせ
ダミーの順位DBのモック8現実的なテスト：単純な結合テスト

アジェンダ

• 難あり

• ゲーム開発の特徴• 単純な結合でもゲーム部分は仕様がよく変わるのでテストが古くなる• 細かい仕様変更のたびにテストを書き直す羽目に• モックを作るのが大変• モック作るくらいなら実装する• ゲーム開発におけるテスト• 現状のテスト
ユ ットテスト• ユニットテスト• 現実的なテスト• ソフトウェアテスト
• 自動テスト• ご提案

現実的なテスト：スナップショットテスト• 画像の比較

現実的なテスト：スナップショットテスト• やや難あり• 画像の仕様は刻々と変化する• エフェクトエンジン等に利用は可能• プラットフォームで違いをなくしたいので違

Original

比較

OK
or
NG

Changed

現実的なテスト：リプレイテスト• 適当なゲームプレイを人の手で行い、リプレイデータを保存• リプレイデータは時間＆キー押下情報のみ• 保存したリプレイデータを使って再生させる

現実的なテスト：リプレイテスト• 開発時期でリプレイする
内容を変える（ムダを排除）• 開発初期：起動＆終了確認• 開発中期：適当なアクションが可能かどうか（剣を振る、ジャンプする）• 開発後期：最初から最後まで通したプレイ

9

現実的なテスト：リプレイテスト• 非常に有効• 証拠が残る• プログラミング中でも• 回帰テストも• なるべく簡易にリプレイできる環境が大切• できればワンクリックでリプレイ可能に現実的なテスト： AIテスト• やや難あり• ちょっとした仕様変更でAIが無意味に• 開発後期に導入しても遅くない

現実的なテスト： AIテスト• プレイヤーの代わりとなるAIを作る• AIに一定時間プレイさせる• もっと簡単にモン
キーテスト（完全にランダムにコントロー
ル）でも可

PlayerInterface
InterfaceController
InterfaceAI
InterfaceMonkey

現実的なテスト：デザインテスト• 終了したらデータの整合性テスト• モデルデータを表示させる• テクスチャの貼り忘
れ等の検出

＋
MODEL

TEXTURE？

現実的なテスト：デザインテスト• 有効だが敷居が高い• 仕組みづくりが大変• 大規模開発現場には導入事例アリ• システム開発には転用しにくいかも

自動テストの効力• CIと組み合わせれば、ほとんど人の手を使わず整合性をテストできる• AIテストはやればやるほど効力が増す• 夜中に全員のPCで稼動するとか
夜中に全員の で稼動するとか• 土日はフルタイムをAIテストに費やすとか10ゲーム開発におけるテストのまとめ

アジェンダ• 現状のゲーム開発においては人力テストが中心• ゲーム開発の特徴• ユニットテストは限定的に利用するのが現実的• ゲーム開発におけるテスト• ご提案• 有効なテスト• 局所的テスト• 組み合わせテスト• リプレイテスト

提案１：リプレイテストの導入

提案２：スナップショットテストの導入• アプリ起動から全ての入力情報を保存• ゲーム画面よりも静的画面なのが◎• その入力情報で再現が可能• いい画像比較ツールがない…

• 通信データも入力情報とみなせばネット
ワ クも再現可能ワークも再現可能• ただし非同期は再現ができない• 自作するしかないかも• 局所的に色を調べるだけでもいい• ハイライトになっているかいないか等

提案３：CEDECで講演しませんか？
• こんなことが知りたい！
• テスト手法• ソーシャルアプリ
• ネットワークゲーム• 開発手法• TDDとか• メリット• ビジネスを広げるチャンス

ご静聴ありがとうございました• コンサルティング• ソーシャルアプリ

11

コラボ企画～ゲーム開発でのソフトウェアテストの実例～

CEDEC2010での講演

ゲーム開発の世界から～金をドブに捨てないようにするテスト～

後編：CIでゲーム開発に
後編：CI
でゲーム開発にテストや自動化を推進してみた株式会社 セガ
AM開発技術部
粉川貴至(Takashi KOKAWA)
http://cedec.cesa.or.jp/2010/program/PG/C10_P0070.html

こんな人向け• テスト専門の担当者が居ない• テストはあるが自動化されていない• 開発工程とテスト工程の間に高い壁がある• CI（継続的インテグレーション）に興味がある• 同じ作業を2度行うのが嫌い～目次～• ゲームの開発環境– 現状と問題点– CI
CI（継続的インテグレーション）（継続的インテグレーション）• CI
CI導入の実例
導入の実例
– CI
CIツ
CIツール「ツツール「Hudson
ル「Hudson」の紹介
ル「H
H d
」の紹介
の紹介
– デモ、導入事例• 自動化ツール「自動化ツール「AutoIt
AutoIt」の紹介」の紹介– カスタム・他のツールとの連携• タダから始めよう！
• まとめ

～目次～
• ゲームの開発環境– 現状と問題点– CI
CI（継続的インテグレーション）（継続的インテグレーション）• CI
CI導入の実例
導入の実例
– CI
CIツ
CIツール「ツツール「Hudson
ル「Hudson」の紹介
ル「H
H d
」の紹介
の紹介
– デモ、導入事例• 自動化ツール「自動化ツール「AutoIt
AutoIt」の紹介」の紹介– カスタム・他のツールとの連携• タダから始めよう！
• まとめ

ゲーム開発現場の今• テスト＝プレイテスト（システムテスト）が主– 企画、デザイナー、プログラマー、デバッガー全員で「おもしろさのテスト」と同時に、「動作確認のためのテスト（デバッグ）」も行う– 描画（画面出力）を確認する必要がある• デザイナー側（モデリング、設定）の問題なのか、• プログラマー側の問題なのか
プログラマ 側の問題なのか– ソフトウェアテストという工程は無いのが一般的• 業界のトレンド「開発費をかけてすごいものを作る」→「いかに効率的・効果的に開発するか」12問題点は・・・

今回のアプローチ• 大規模化• ビルドの自動化– プレイテストによるバグチェックには限界– 開発人員の増加により連携が大変– ソフトウェア品質のコントロールが困難– 決められた環境・手順– 誰でも実行・メンテナンスできる– ヒューマンエラーの排除• テストの導入• ソフトウェアテスト環境の不足– 各自の取り組み– テスト作成・実行の手間– ビルド→テストを一連の流れとして自動化– まずは単純な実行テスト– ユニットテストや自動UIテスト等、いろいろな仕組
みと簡単に連携したい

CI（継続的インテグレーション）CI（継続的インテグレーション）• Integration → 統合、統一

CIを導入してみる• 狭い意味では– 頻繁に（常に）ビルドが通る環境• ソースコードのコミットからの自動ビルド• スクリプトやバッチ等、作業の自動化
スクリプトやバッチ等 作業の自動化– 常に最新の安定した成果物が維持される• 広い意味では– 開発サイクル、ワークフローの統合– ソフトウェア品質管理のバックボーン

チラッ

CIの位置づけ
CIの位置づけ

CIサイクルCI
サイクル• アジャイル開発– XP（エクストリーム・プログラミング）• CI（継続的インテグレーション）• 適応的開発（変更に強い・速い）
適応的開発（変更に強い 速い）– アジャイル開発に必要な事（コミュニケーション・シンプルさ・フィードバッ
ク・勇気）• XPの実践の1つ（頻繁にビルドと結合を繰り返す）

コード修正

フィードバック

ビルド

リリース
可能な成果物テスト

13あれもこれもやらないと・・・

CI前
CI
前

CI後
CI
後

開発に集中！

コード修正

コード修正

コミット

フィ ドバック
フィードバック

ビルド

フィードバックビルド

安定！！

混乱・・・！

不安定な成果物テスト

自分でその環境を作るの？

まかせた

安定した成果物テスト

専用のツールがあります！

～目次～• ゲームの開発環境

CIツールを導入して開発現場に秩序と速度を！

– 現状と問題点– CI
CI（継続的インテグレーション）（継続的インテグレーション）• CI
CI導入の実例
導入の実例
– CI
CIツ
CIツール「ツツール「Hudson
ル「Hudson」の紹介
ル「H
H d
」の紹介
の紹介
– デモ、導入事例• 自動化ツール「自動化ツール「AutoIt
AutoIt」の紹介」の紹介– カスタム・他のツールとの連携• タダから始めよう！
• まとめ

14

～目次～
• ゲームの開発環境– 現状と問題点– CI
CI（継続的インテグレーション）（継続的インテグレーション）

CIツール「CI
ツール「Hudson
Hudson」」• CI
CI導入の実例
導入の実例
– CI
CIツ
CIツール「ツツール「Hudson
ル「Hudson」の紹介
ル「H
H d
」の紹介
の紹介
– デモ、導入事例

Hudsonです。

• 自動化ツール「自動化ツール「AutoIt
AutoIt」の紹介」の紹介– カスタム・他のツールとの連携• タダから始めよう！
• まとめ

CIツール「CI
ツール「Hudson
Hudson」」

CIツール「CI
ツール「Hudson
Hudson」」• Java製のオープンソースソフトウェア• インストール・セットアップが簡単！
• Webサーバ機能もセット！
• 日本語標準対応！
• 拡張性が高い！
• 豊富なプラグイン！
カンタン！

CIツール「CI
ツール「Hudson
Hudson」」• 自動ビルド

しかもタダ！

CIツール「CI
ツール「Hudson
Hudson」」• 設定・操作はほぼ全てWebから可能！

– ビルドプロセス（自動化手順）を「ジョブ」として登録– 「ジョブ」を自動・任意に実行
実行ボタン• ソースコード管理システム（SCM）と連動– 最新のソースコードを取得してビルド
最新のソ スドを取得してビルド– 標準でCVSとSubversionに対応– プラグインで様々なSCMに対応• Git、Perforce、StarTeam…

実行中のジョブ
ジョブ一覧
実行結果
青：成功、赤：失敗

チェックアウト⇒ビルド

15その他、自動化可能な作業• 自動テスト

チェックアウト⇒ビルド（結合）⇒テスト– ビルド同様「ジョブ」として登録→実行– 一般的な単体テストツールで出力されるXML（xUnit形式）を読み込み、グラフで表示• スクリプト、コマンド実行
スクリプト コマンド実行

成果物の管理• ビルド結果の保存– いつ実行されたか– 実行手順のログ（コンソール出力）• 成果物の保存– いつビルドされた成果か（MD5チェックサム）
いつビルドされた成果か（MD5チ クサム）
– 依存関係の管理• ライブラリとアプリの関係…

– Windowsならバッチ、Unix系ならシェルで表現可
能な処理を「ジョブ」として登録→実行– プラグインで様々な処理を登録可能• Python、PowerShell…

チェックアウト⇒ビルド（結合）⇒成果物の生成⇒テスト– アプリケーションの実行も ←後で情報共有• ビルド結果の通知– メール通知– プラグインでIRC、Jabber、Twitterなどもまさにインテグレーション！

• バグ管理システム（BTS）との連動– バグがどの成果物で起こったのか
バグがどの成果物で起こ たのか– 知られているBTSにはほぼプラグインで対応• Redmine、Trac、Mantis、Bugzilla…
チェックアウト⇒ビルド（結合）⇒成果物の生成⇒テスト⇒結果の通知・関連付け～目次～• ゲームの開発環境

STEP1 動かしてみよう！
•

Hudsonは導入が簡単！

– 現状と問題点– CI
CI（継続的インテグレーション）（継続的インテグレーション）• CI
CI導入の実例
導入の実例
– CI
CIツ
CIツール「ツツール「Hudson
ル「Hudson」の紹介
ル「H
H d
」の紹介
の紹介
– デモ、導入事例• 自動化ツール「自動化ツール「AutoIt
AutoIt」の紹介」の紹介– カスタム・他のツールとの連携• タダから始めよう！
• まとめ

16

デモ
•

インストール
1. hudson.war をダウンロード
2. java –jar hudson.war (Java実行環境が必要)
3. http://localhost:8080/•

簡単でしたね！

ジョブの作成– ジョブの実行– 結果の成否STEP2 ゲーム開発でのビルド自動化••

SCMの設定C++ソースコードのビルド– 実はVC++のビルドはプラグイン・・・（ビルドコマンドを直接叩いてもOK）

•

デモ
•
•
•
•

Subversionリポジトリの設定
VC++ビルド（MSBuild）
結果表示
成果物の保存ビ ド実行 結果通知
ビルド実行・結果通知・コンソール出力・
出力
履歴

STEP3 CIツールを使いこなすCIツールを使いこなす•••

チームでの導入事例
アプリケーションの実行テスト
さらに品質向上に向けてこれが CI ！
これが・・・CI･･･！

17アーケードゲームライブラリ開発での事例• 社内向けの汎用ゲームライブラリ• ターゲット– Windows OSベースのボード向け– Linux OSベースのボード向け• 機能– OS抽象化、スレッド管理、ファイル管理、算術、描画、フォント、アニメーション、入力、アーケード機能– DCCツールのエクスポータ、コンバータ、ビューア– 内製ツールのランタイム、ビューア• 開発人員（約6名）

ある程度の環境はあるが混乱• 手元の環境でビルド– コミット・更新忘れ– ターゲット・構成のビルドチェック抜け• テスト代わりに手元でサンプルを実行– 実行忘れ• リリース管理が無いので、バグが起こった時の追跡が困難• 抽象的なバグ報告が来る– 1人の担当1モジュール以上

まずは自動ビルドで安定を• ビルドマシンを用意– ターゲット毎に分けるのがベスト– 仮想マシンはゲーム開発環境では▲• リポジトリへのコミット→自動ビルド– 既にあるビルドバッチを実行させる
既にあるビルドバ チを実行させる– MSBuildプラグインでVC++プロジェクトを指定

第 段階完了！
第一段階完了！

• 失敗したらメールで通知– コミッター名@hoge.co.jp– カスタマイズで必要な人にも通知～目次～• ゲームの開発環境– 現状と問題点– CI
CI（継続的インテグレーション）（継続的インテグレーション）• CI
CI導入の実例
導入の実例
– CI
CIツ
CIツール「ツツール「Hudson
ル「Hudson」の紹介
ル「H
H d
」の紹介
の紹介
– デモ、導入事例• 自動化ツール「自動化ツール「AutoIt
AutoIt」の紹介」の紹介

アプリケーションの実行テスト• サンプルが「正常に」動くか確認したい– 起動時、一定時間動かす、終了時にエラーが出ないか– 終了後メモリがリークしていないか• 実行画面を確認したい– 表示がおかしくないか– エラー時の画像が見たい– カスタム・他のツールとの連携• タダから始めよう！
• まとめ

画面操作の自動化ツール「AutoIt」を導入！

18

AutoIt• フリーツール• WindowsのGUI操作を自動化できる、BASICライクなスクリプト言語• キー入力・マウス操作の自動化• WindowsAPIをダイレクトに呼ぶ
ダ– ウインドウハンドルを直接操作– 操作の誤爆を防ぐ• 単独で動作するexeに変換可能• IE、Word、Excelの操作も可能

AutoItを使ったアプリテスト自動化
AutoItを使ったアプリテスト自動化• AutoItからアプリを起動• ウインドウのスクリーンキャプチャ• 入力テスト• ウインドウの終了• コンソール出力のチェック
コンソ ル出力のチェック– プロセスの標準（エラー）出力を取得可能– ライブラリで用意しているメモリリークメッセー
ジ（デバッグ用メッセージ）をキャッチ• アクティブなウインドウのチェック– アプリのウインドウが最前面にきているかデモ••

AutoItのデモ
HudsonからAutoIt経由でアプリのテストをするデモ

これはベンリ！

その他、AutoIt
その他、
AutoItで試した事
で試した事• 実機でのテストは？
– Windows上でデバッグできる範囲であれば有効？

• ゲーム画面を判断しながらの処理には工夫が必要– 一応、AutoItを使ってできます– ライブラリサンプルのテストなのでそこまで突っ込まず

Hudsonの話に
戻ります！

19

～目次～
• ゲームの開発環境– 現状と問題点– CI
CI（継続的インテグレーション）（継続的インテグレーション）• CI
CI導入の実例
導入の実例

CIツールをさらに使いこなす
CI
ツールをさらに使いこなす• Hudsonの機能やプラグインを使って品質向上のためのソフトウェア
開発環境を統合！

– CI
CIツ
CIツール「ツツール「Hudson
ル「Hudson」の紹介
ル「H
H d
」の紹介
の紹介
– デモ、導入事例• 自動化ツール「自動化ツール「AutoIt
AutoIt」の紹介」の紹介– カスタム・他のツールとの連携• タダから始めよう！
• まとめ

Hudsonのカスタム
Hudsonのカスタム• 分散ビルド– 総ビルド時間の短縮– クリーンなビルド環境• ターゲット毎に環境を構築• テストを利用者環境で実行– 構成毎（Debug,Release）に分けてもいいかも？

Hudsonのカスタム
Hudsonのカスタム• リリース管理– UnixサーバにHudsonの分散クライアントを置いてコマンドを実行• 「最新の安定したビルドの成果物」を公開• WebAPI経由で更新情報の管理（実験中）• 分散環境の構築も簡単！

Hudsonのカスタム
Hudsonのカスタム•

デザイン素材など（バージョン管理外のデータ）の管理– ファイル共有+チェックサム
1. ファイル共有⇒ワークスペースにコピー
2. コンバートやデータのチェック
3 追跡したいデ3.
追跡したいデータを成果物に指定
タを成果物に指定– 問題点• ファイルが多い（大きい）とチェックサム
を計算する時間がかかる• 成果物/ワークスペースそれぞれ、ビル
ド毎にデータを保存しておけるが、ディ
スク容量を圧迫

他のツールとの連携（プラグイン）• ユニットテスト– CppUnit– Googletest• 失敗を確認するテスト（DeathTest）がイイ！

– MSTest（有償）• VS2008（Professional Edition以上）からは単体テスト機能が標準装備• データドリブンテスト（cvs、XML）がイイ！

20

他のツールとの連携（プラグイン）• 警告– Warningsプラグイン

他のツールとの連携（プラグイン）• タスク検知– TaskScannerプラグイン

2011/01/26

他のツールとの連携（プラグイン）• 静的解析
– cppcheck、Coverity（有償）

他のツールとの連携（プラグイン）• コードメトリクス– ソースコードの統計情報を計測– CCCC
モジュール数
ジ
ル数
コード行数
複雑度

コメント行数他のツールとの連携（プラグイン）• コーディングスタイルチェック– cpplint（google-styleguide）– 「Google C++ スタイルガイド」に則っているかをチェックできるスクリプト– Pythonスクリプトを、Hudsonから実行• プラグインはまだ無いらしい・・・– IDEと統合するのもあり

他のツールとの連携（プラグイン）• ドキュメント生成– Doxygen• プロジェクト管理ツール– BTS（ Trac、Redmine ）– オススメ構成！
• Redmine：Hudson プラグイン+
TortoiseSVN Plugin• その他– プラグイン情報は公式WikiかHudsonの設定画面からチェック！（英語）21Hudsonを使って・・・
Hudsonを使って・・・• プラグインの導入– 使えるツール、注目されている技術はプラグインが作成される→良さそうなものはどんどん試用・統合！

• CIツ
CIツールをバックボーンとする事で世界中でルをバックボ ンとする事で世界中で利用されている要素技術が分かります！
• 成長していく品質管理環境！
– 最初はデイリービルドからスタート！

CIツールを導入した成果
CI
ツールを導入した成果• ビルドエラーはリリース前に解決！
• サンプルの自動テストで早期バグ発見！
• エラーは起こった時に分かるので手戻り無し！
• 週1回の安定したライブラリリリース！
• 1年間の継続運用！

今すぐCIツールを入れましょう！

～目次～• ゲームの開発環境– 現状と問題点– CI
CI（継続的インテグレーション）（継続的インテグレーション）• CI
CI導入の実例
導入の実例
– CI
CIツ
CIツール「ツツール「Hudson
ル「Hudson」の紹介
ル「H
H d
」の紹介
の紹介
– デモ、導入事例

タダ ら始 ようタダから始めよう！
（ライセンス周りについて）• 自動化ツール「自動化ツール「AutoIt
AutoIt」の紹介」の紹介– カスタム・他のツールとの連携• タダから始めよう！
• まとめ

ライセンスについて• HudsonはMITライセンス– タダ！
– ただし無保証– 有償サポートあり• AutoItはライセンス制約無しのフリーツール

その他のCI
その他の
CIツール
ツール
• Buildbot（GPLライセンス）• CruiseControl（BSDライセンス）• Apache Continuum（Apacheライセンス）• TeamCity（有償）– 20configrations、3agents、20users → 制限あり
でタダ！
• Visual Studio Team Foundation Server （有償）

22

～目次～

まとめ

• ゲームの開発環境– 現状と問題点– CI
CI（継続的インテグレーション）（継続的インテグレーション）• CI
CI導入の実例
導入の実例
– CI
CIツ
CIツール「ツツール「Hudson
ル「Hudson」の紹介
ル「H
H d
」の紹介
の紹介
– デモ、導入事例• CIで、より良い開発環境づくりを！
• ツールはツールです！
– 使い方次第– 使う人次第– まずはチームに溶けこむように• 自動化ツール「自動化ツール「AutoIt
AutoIt」の紹介」の紹介– カスタム・他のツールとの連携• タダから始めよう！
• まとめ• いきなりがんばりすぎない←

ありがとうございました！

質問・ご意見は
Kokawa_Takashi@sega.co.jp
Twitter id: Kokawa_Takashi

23