Gamedevenvstudy1

ゲーム開発環境勉強会

邦訳：[GDC2011]Automated Testing
Roundtable

• http://wiki.igda.org/GDC_2011_-
_Automated_Testing_Roundtable

2

• Day1

• 1日目のトピックはテストについて具体的に：
何が有効でその理由は？

3

• 出席者はほとんどプログラマー、しかし尐数
のQAと生産の人も居た。

4

1日目のトピック（テスト）：
• シンプルなテスト、スケジューリング、ツール
• 入力の扱い
• レポートと履歴
• テスト環境
• アンチパターン、避けるべき事
• ボット
• 静的コード解析

5

• シンプルなテスト、スケジューリング、ツール

• Simple Tests, Scheduling, and Tools

6

シンプルなテスト、スケジューリング、ツール

• まず、最も効果が高くて実用性のある最もシ
ンプルなテストについての議論から始めようと
思います。

7


• 既存のプロジェクトのテストを始める場合は、
ユニットテストよりも基本的な機能テストを好
む

8


• 明確な「ホットスポット」を見つける。プロジェク
ト特有の複雑な部分やありそうな部分に注目
する

9


• 既存のシステムを活用する：ゲームプレイの
記録と再生ができ、追加のメトリクス情報を生
成する。

10


• TTY（標準出力）出力をパース、もしくは既存
のTTYログシステムにさらに出力を追加して、
すぐに最初のテストをブートストラップ（今ある
ものだけで何とか）します。

11


• 「ゲームがロードされているか？」「それぞれ
のレベルがロードされているか？」というスモ
ークテストから始める。

12


• 視覚的なスクリプトシステムは、小さなテスト
を行うための素晴らしい環境です。

visual scripting system
• http://forum.unity3d.com/threads/54580-Visual-Scripting-System
• http://www.extremetech.com/article2/0,2845,1152028,00.asp

13


14


• テストインフラを整える事と関連して、累積さ
れた技術的な負債があると思います。物事を
シンプルにして、これらの問題は先送りにして
始めましょう。

15


• 単純な通過/失敗レポートは基本テストとして
充分です。（より精錬されたレポーティングに
ついては後日の議論でカバーされています）

16


• 変更をコミットする前にテストを実行する（能
力のある）スタジオもあります。"ローカル版"
テストは、よりフル機能に対応したものと比べ
て幾分取り除かれてるとしても有益です。

17


• テストは、オールオアナッシングではない。す
ぐにやらなくてはならない（コミット前か、コミッ
ト後）ものと、猶予のあるテスト（デイリーでス
ケジュール化されたもののように）両方ある。
ビルドイテレーション時間を大きく遅らせるよ
うなものは後でやるべきだ。

18


• 「失敗を期待する」テストはいくつかのケース
で有用だろう。

19


• テストのための「次のターゲット」をどう選択し
ていくかの計画実行には、尐なくとも部分的
にはプロジェクトリーダーやプロデューサーが
責任を持つ。

20


• バージョン管理システムのセットアップやレイ
アウトは重要だ。それは自動化が容易か難し
くなるかに影響する。

21


22


• どうやってテストを運用していますか？多くの
人はCI（continuous integration）ビルドサーバ
ーか、テストスイート管理システムを使用して
いるでしょう。尐なくとも1日目には次の内容を
話し合います。（CI/継続ビルドについて）

23

• TeamCity
• Pulse Continuous Integration Server
http://zutubi.com/products/pulse/ , http://zutubi.com/sales/
• Hudson [forked to "Jenkins"]
• CruiseControl.NET
• Buildbot
• Bitten (automated metrics collection for Trac)
http://bitten.edgewall.org
• Cucumber (behavior-driven testing)
http://cukes.info/
• BugSplat (drop-in crash tracking)
http://www.bugsplatsoftware.com/

24


• BugSplat (drop-in crash tracking)
http://www.bugsplatsoftware.com/

BugSplatはあなた自身の製品のエンドユーザーがクラッシュを追跡
するためのツールの包括的なセットを提供しています。 BugSplatを
使用すると、簡単には、ユーザーがクラッシュを監視し、ライブラリ
を統合して取得します。クラッシュのイベントでは、ユーザーは、オ
ンラインサービスへのクラッシュ情報をアップロードするオプション
が与えられます。あなたのエンジニアリングチームはBugSplatの
Webサイトにあるすべてのクラッシュ情報を閲覧することができま
す象徴呼び出し、実際の問題を特定するために使用できるスタッ
クを含む貴重な情報へのアクセスを持っています。オンラインクラ
ッシュ報告はあなたの傾向を分析し、最も一般的なユーザーがク
ラッシュを分離するツールの広いセットを提供します。(Featuresを
機械翻訳)

25


• ゲームに「コマンドラインパーサー」を組み込
む事は役に立ちます：例えばCIビルドが
「rungame.exe alltests」のようにビルド後のス
テップを実行する事ができます。

26


27

• 入力の扱い

• Input Driving

28

入力の扱い

• 入力の記録・運用・プレイバックをうまく使お
う：ランダムにボタンを押したりランダムな方
向に向かって動く「モンキー」は尐なくともいく
つかのチームで使われている。

29

入力の扱い

• もしランダムに歩かせるボットが動きがとれな
くなったら、前のゲーム実行のヒートマップデ
ータを使って頻繁に移動している場所にテレ
ポートして戻す、その時「厄介な」場所として
レポートを残すかもしれない、そしてテストを
継続する。

30

入力の扱い

• UIとメニューの横断テストの自動化はチーム
毎かプロダクト毎に異なる

31

入力の扱い

• テスターのプレイの入力ストリームをそのまま
記録するチームもある、そしてそれを自動テ
ストで再生する、成功して完走するか失敗/ク
ラッシュするかをチェックする。
• ゲームやUIの頻繁な変更に伴いこれらの入力ストリームが
「古く」なる場合があります、そして再レコーディングするオー
バーヘッドもあります。（このタイプのテストでは整合性を保
つためのオーバーヘッドが大きすぎるという人も居ます。簡
単に言えば、プロダクトや技術者に依存します。）
• UIが安定に達するのと、入力ストリームの記録をとり再記録
がめったに起きなくなるのを競わせたゲームもあります。

32

入力の扱い

• UI横断テストには違ったレベルのAPI（フレー
ムワークや言語機能として提供される）を使う
チームも居ました

33

入力の扱い

• 尐なくとも1チームは入力ストリームの記録と
スクリプトによるUI横断テストの両方を使って
成功している。QAはテストを作り、記録された
ストリームか直接書かれたスクリプトのどちら
か（あるいは両方）をUIフローのテストに利用
する事ができる。

34

入力の扱い

• fuzz testingを主要ツールとして使っていて個
人的に推薦するという人が居た。入力の記録
やスクリプトよりも。ネットワークパケットやファ
イル（とかその他可能なもの）からファズデー
タをパース・ロードし、ハードウェアの欠陥や
ソフトウェアバグをシミュレートする。
• 彼のチームのエンジンはほとんど全てのものに対してロードができ
なかった場合の代替リソースがある、そしてその方法は対象のコ
ードパスに対する正常・異常を見つけるのが本当に早い。（PCゲー
ムのこと？）いくつものハードウェア障害に対応できる安定したエ
ンジンが何百万ものユーザを持つビッグタイトルを支えます（おそ
らく何千もの不良ユニットを持っている可能性がある）。
http://www.ibm.com/developerworks/jp/java/library/j-fuzztest.html
http://www.sophia-it.com/content/fuzz+testing
35

• レポートと履歴

• Reporting and History

36

レポートと履歴

• 内蔵のツールでの行動履歴を記録します：バ
グやクラッシュレポートと一緒に梱包します。

37


• グラフは、報告された情報を理解するのに大
いに役立ちます。相関グラフにより個々のリ
ビジョンと時間経過によるトレンド/差異にフォ
ーカスしたエントリーを見る事ができます。

38


• Long soak tests：浸せき試験（1日から2週間っ
て言っていた）を行えばリークや他の問題をグ
ラフ化する事ができるよ。

http://www.c-able.ne.jp/~tips-com/00topics/01dictionary/0111sa/
（信頼性テスト）

39


• スモークテストやソークテストのために、メモリ
ー使用、FPS、GPUステート（ポリゴン数など）、
ゲームプレイに関するイベントやバランス調
整に関する統計情報等を記録する。

40


• クラッシュ/ハングレポートにスタックトレース
を添付する：それらレポートかまるまる全部を、
例えばP4 blameで（Perforceの機能？）、自動
的にパースするかアサインするという手もあ
る。スタックとレースに「ハッシュ」を付けるの
もデータを汲むのに役立つ。["Debugging in
the (Very) Large"という論文参照]
"Debugging in the (Very) Large"→
http://research.microsoft.com/apps/pubs/default.aspx?id=81176

41


• Windowsのエラーレポートを試したが情報を
得るまでのターンアラウンドタイムが期待より
長すぎた；カスタムソリューションを推奨した。

42


• 商用製品の「BugSplat」はドロップインのクラッ
シュレポーティングソリューションとして言及さ
れた。
• http://www.bugsplatsoftware.com/

43


• すでに持っているものをさらしてみよう！既存
のシステムにテコ入れして、レポートのために
もっと情報を追加しよう！

44

• テスト環境

• Test Environments

45

テスト環境

• 環境のスナップショットはテストのための一貫
性のあるOSやソフトウェアスタックを構築した
り維持するのに有用です。VMWareを使って
これを実現している人も居ます。

46

テスト環境

• Valgrind, Bounds Checker, Insure++ といった
ツール専用の環境はスケジューリングされた
テストに追加して走らせるのに良い場所です。
Valgrind： http://ja.wikipedia.org/wiki/Valgrind
Bounds Checker：
http://www.microfocus.co.jp/products/devpartner/devpartner_fm/devpartnervisualc/

Insure++： http://www.techmatrix.co.jp/quality/insure/index.html

47

テスト環境

• debugビルドやreleaseビルド、「特別な」ビルド
の違いには慎重になるべきだ：特別なビルド
はバグをより一層生成するし、クレイジーなバ
グは特別な事をしていないビルドでしか浮き
上がってこない。「debugビルドはreleaseにロ
グ機能を付けるだけであるべき」と断言する
人も居た。

48

• アンチパターン、避けるべき事

• Anti-patterns, Things to Avoid

49

アンチパターン、避けるべき事

• ユニットテストのカバレッジを100%にしようと
する人が居るが、大体の人の意見はそれは
努力の無駄遣いだという傾向にある：いくつ
かは機能テストにより充分にテストされている
し。

50


• ユニットテストがフィットしているとしても、「よく
似た」機能テストを作成して走らせた方が
往々にして早い：（他の全てが同じようにユニ
ットテストが好ましいとしても）

51


• チューニングのために進化（改造）されたビル
ドからデータを使用する場合、何かが変わっ
た時に深刻な問題が発生する。
• [このGDC2011のAI Summit内"AI Pr0n: Maximum
Exposure of Your Debug Info!" by Michael Dawe(Big
Huge Games/38 Studios), Rez Graham (Electronic
Arts - Sims Division), and Brian Schwab (Blizzard
Entertainment) でこの事に関するすばらしい発表が
あった]

52


• 可能であれば、ベータ、実験、未熟なツール
とコンポーネントは[ビルドや自動テスト内で
使うのを、おそらく一般使用も]避けるべきだ。

53


• モックはそれらの価値から得られるものよりも
大体の場合維持のトラブルがある。（ここで数
人は成功したと言ったが、それ以外は一貫性
の問題を挙げた）

54


• "Process and people make all the difference."

ことわざ「people make all the difference」に
Processもつけた物と思われる。ひとそれぞれ、
プロセスもそれぞれ

55


• ビルドは実際には彼らの手によって実行され
る事に注意しないといけない！よくある「これ
は今壊れた」という態度に、あなたはそれを
打開しないといけない。
• （よくある「今ビルドしてみたら通らないんです
けど」と言うがそれ以前におかしくなっていた
という場合にがんばれという話）

56

• ボット

• Bots

57

ボット

• [ランダムウォークについては上の Input
Driving で述べられました。]

58

ボット

• 優秀なプレイヤーをシミュレートして、ゲーム
内経済においてバランス崩壊する変更が露
呈するのをテストします。

59

• 静的コード解析

• Static Code Analysis

60

静的コード解析

• 意見が分かれました。検出：ノイズの比率の
問題でほとんどの人はそれ（静的解析）をお
勧めしませんでした。

61


• 「当然」、（Pythonスクリプトなどの）非コンパイ
ル言語に対するランタイムチェック前のある
程度のソートは使っている。

62


• 昔ながらのやりかたでの追跡か既存の静的
解析ツールかカスタムツールどれでも良いの
で違反を検知しましょう。あなたがどんな事を
しているか（コードを書いているか）を知るた
めに、「スマートコメント」を使ってこれらのチェ
ックをバイパスします。

63


• 静的解析は「64bit移植」問題を修正する時に
かなり役立ったという人も居た。

それから始める場合は、静的解析を使うと簡単です。
（64bit移植のこと？）
It's easier to do static code analysis if you start with it.

64


• レガシー（新しいものが出現したが、長年使
われ、いろいろな事情で完全に捨てることが
できない古い技術や仕様など。）なコードをベ
ースに作業する場合、検出とノイズの割合
（閾値）を調整して走らせる事で、差異に対し
てのみレポーティングする事ができる。

65


• コンパイラの警告はできる限り大きくしておく
べきです、そして「警告をエラーとして扱う」、
できる限り。

66

• Day 2

• 2日目のトピックはインフラです：誰がデプロイ
や自動化を保持しますか、そしてどんなツー
ルやプラクティスを使っていますか。

• この日は「一般的な質問を集めて、それらに
ついて答えていく」モデルにしました。

67

2日目のトピック（インフラ）：
• 内製かサードパーティーのソリューションか
• テレメトリー（遠隔測定）
• インテグレーション[どこでどうやって、そしてメ
ンテナンス]
• ブランチとCI（継続的インテグレーション）の戦
略；特にブランチの扱いについて
• 応答（所要）時間
• 提供方法（集めた情報、テスト結果、など）
• 分散ビルド
68

• 内製vsサードパーティー

• In-house vs. 3rd Party

69

内製vsサードパーティー

• 出席者の75%以上は内製のカスタムビルド＆
テストソリューションを使用している。

70


• 統合と自動化のメンテナンス時間がキーで
す：その自動化システム自体がテストされて
いない、という事はよくあります。自動化テス
ターが割り当てられたチームもある。買う余裕
のないところもある。

71


• サードパーティーのツールは以下のものが挙
げられました：
• Hudson (builds)
Hudson→forked to Jenkins http://jenkins-ci.org/
• TeamCity (builds)
• JIRA (issue/project tracking) [someone
mentioned integration with Hudson here]
• FishEye (VCS notification, visualization, and
search)
http://www.atlassian.com/software/fisheye/ 10 users $10

72

• テレメトリー（遠隔測定）

• Telemetry

73

テレメトリー（遠隔測定）

• E-mailは万国共通

74


• アサートや警告ログをレポートする

75


• メモリ状況をグラフ化する

76


• なにかをグラフ化するときは、履歴のデータ
に対応した「現在のスナップショット」を見せる
ようにする。特にメモリ。

77


• サードパーティーのツールは以下のものが挙
げられました：
• Confluence (info share)
http://www.atlassian.com/software/confluence/ $10
• SQL Server Reporting Services (analytics)
http://msdn.microsoft.com/ja-jp/library/ms159106.aspx
• Callgrind [part of Valgrind] (call graph)
http://valgrind.org/docs/manual/cl-manual.html
• Tableau (analytics) [高いと言われるけど、買う余裕があれ
ばそれだけの効果がある]
http://www.tableausoftware.com/ 日本サポート会社あり
http://www.tableausoftware.jp/
78


• ビルド毎にテレメトリーを収穫する、定期的
（12時間毎など）にも実行する、そしてそれぞ
れについて見れるようにする。

79


• Callgrindを使って5分毎のゲームのデータを
集めているチームもあった。

80


• 「全ての可能な武器vsゾンビの組み合わせに
対して」ヒット数、ダメージ、誰が勝つかを試す
とか。

81


• テスト中に獲得した全ての「達成
（achievements）」を記録する。

82


• プレイ時間を記録する（「QA側のチェック」は
この方法でできる、もし傾向があれば）

83


• テレメトリーツールは重要：
• アクションと完了までにかかった時間を記録
• ビルド時の追跡データを残す
• データを集めるために1つの簡単なグローバ
ルデータベース（例：SQL）と（例ASPのような）
webサービスを使う。
• スクリーンショットを撮る
• クラッシュした時やバグレポートが提出された
際にログとスクリーンショットをアップロードす
る；これらはテストケース管理システムに置く
事ができる。
84


• 「収集は簡単、提示が難しい」

85


• レポートは信頼できないネットワーク（UDP、
HTTP）でもレポーティングできる。統計的に必
要なものが得られる。

86

• 統合/メンテナンス

• Integration / Maintenance

87

統合/メンテナンス

• 出席者の約15%はユニットテストを使っている。
同じく15%の出席者は機能テストも行っている。
（それなりにかぶっている）

88


• 自動化の維持を任せる事ができる人々という
新しい特徴の情報を得る事が難しいというチ
ームも居る

89


• （入力ダンプのように）自動でテストケースを
作ると「打ちのめされる」、失敗をたくさん作っ
てしまう傾向がある。

90


• スクリーンショットを撮る。これは人によって素
早く検証できるし、ピクセル毎の比較にも使え
る（よく失敗するし、プロダクトに依存するが）、
もしくはPerceptualDiff。ボットはゲームを旋回
する中でスクリーンショットを撮るべきだ。

• PerceptualDiff http://pdiff.sourceforge.net/

91


• レンダリングのテストには、シンプルなボック
スかスケルトンにレンダーしそれらの画像比
較を行う。推進するほどの価値はないかもし
れないが。

92


• いつテストを追加しますか？
• ビルドが壊れた時、バグの起こった時毎、機
能追加する時。

93

• 応答（所要）時間

• Turnaround Time

94

応答（所要）時間

• いくつかのテストの系統によって期間が分か
れた？

• Wii: 1 hour
• PC: 5-6 minutes

95


• スモークテストは早くできるべき。アイデア：

• start editor
• start each level
• save and then load

96


• シーケンシャルなステップ（初期の失敗がテス
トの完了を阻止しない？）を必要とするテスト
はやりたくないと言う人も居た。
• ターンアラウンドタイムは早く修正も早いので
気にするほど長くはないと言う人も居た。

97


• 多くのチームはインクリメンタルデータビルド
（結果をキャッシュ）とビルドサーバーでのフ
ルコードビルドを行う。1日に1回（かもっと多
く？尐なく？）データとコアのビルドをクリーン
にする。

98


• コードのビルド時間は一般的には早い、ほと
んどの人はフルコードビルドは数分で終わる
と答えた、しかし40分や1時間と答えた人も居
た、分散（ビルド）しているのに。

99


• 空いているコンソール（Xboxなど）を確認して
テストスイートを日和見的に
（opportunistically）走らせる。

100


• 自動テスト専用のハードウェアがあるは一般
的です。

101

• プレゼンテーション（見せ方、表現方法）

• Presentation

102

プレゼンテーション

• 結果を1日に1回か2回は出力する。

103


• 結果は探させるよりユーザに提示しよう。け
れどやりすぎは良くない。

104


• ユーザには自発的に他の人にもっと頻繁にソ
ース（ビルドの成功、現在の状態など）をプッ
シュする事を賛成するのを許可しましょう

105


• テストやビルドの失敗は例外（exception）で
す：これらはすぐに関係者に通知するようにし
ましょう。

106


• データはビジュアルに見えるようにしたほうが
好まれる（vs. テキスト表示）

107


• シンプルなビジュアル化を使おう、例：赤と緑
のドット、概要が簡単につかめるように。

108


• TeamCityの「Trial builds」やPerforceの
「shelving」機能とフルテストを合わせる事はこ
れらを使いこなせる人達に愛されている。

109


• 「ビルドフェイズ毎」のエラーレポート。[それぞ
れのビルドエラーをタイプ毎に分ける事がで
き、コードのエラーかスクリプトのコンパイル
エラーか等切り分けることができる]。結果に
適した相手にメールを送る。

110


• Pythonといったスクリプト言語を書くことを恐
れてはいけない。ビルドログや特定のエラー
に興味を持たせ、「宣伝」するために。

111


• 最後の（最新の）レポートはだれでも読めるよ
うにしておこう。可能なら、基本的な修正方法
の概要と詳細へのリンクを含める。

112

• 通知方法について
• e-mail
• yammer
https://www.yammer.com/
• tumblr
http://www.tumblr.com/
• growl
http://growl.info/ , http://ascii.jp/elem/000/000/562/562062/
• the famous GitHub traffic light =)
http://blog.littlebirdelectronics.com/git-hub-traffic-light-via-urbanhonkingcom

• 本物のサイレン
• 真ん中に置かれたTVとかモニター
113


• To/Ccのリストは最小限に：人数を尐なくすれ
ばするほど = 効果的。通知されたfaiureに一
定期間対処されない場合、それを上司やプロ
デューサー、マネージャーに「宣伝する」。

114


• シンプルだが容赦なく効果的：ビルドが失敗し
たらコミットを拒否する。

115

• 分散ビルド

• Distributed Builds

116

分散ビルド

• 以下のサードパーティーの商品が挙がった
• SN-DBS (Sony platforms)
http://www.snsys.jp/products/SN-DBS.asp

SN-DBS は PlayStation2、PSP (PlayStationPortable) 及
び PlayStation3 の開発者の皆様にこれより無償で、
Product Licensing System 無しにご利用いただけま
す。
• IncrediBuild
http://www.xoreax.co.jp/

117

分散ビルド

• 分散アセットビルドのために IncrediGrid を使
おうとしている人もいた。

118

分散ビルド

• 一般的に、分散ツールよりもマルチコアスケ
ーラブルツールの方が好まれるようだ。[構築
とメンテナンスの容易性、もっとわかり易いの
は、変なやり方をしても壊れにくい点]

119

分散ビルド

• ビルドシステム：より多くのコアでより信頼でき
る1つ以上のドライブを使用するべき。これら
は最近、他のほとんどのものよりも重要であ
るように思われる。

120

分散ビルド

• ユニットテストを分散しよう。（1例として：6分
かかるものが40秒になった）

121

分散ビルド

• VCS（バージョン管理システム）は何を使って
いますか？ほとんどの人はPreforce（60%くら
い）、次にSubversion（10%未満くらい）、いくつ
かのチームはGit。
• （粉川が現地で取った記録では、Perforceが50%以
上、Subversion20%、gitが1人、2人くらいに感じまし
たが。）

122

• Day 3

• 3日目のトピックはデータ収集、マイニング、
可視化について。

• [前日に結構うまくいったので、「一般的な質
問を集めて、それらについて答えていく」モデ
ルを続けます。

123

3日目のトピック（データ収集、マイニング、可視化）：
• 普段どのように自動化していますか？
• ゲームシステムの上位層のテストについて
• 投資収益率
• モバイル機器でのテストについて
• 「充分」vs「やりすぎ」なテスト
• フレームワークの選択
• 可視化ツール
• ユニットテストvs結合テスト、どちらに投資する？
• webでのテスト
124

• どのように自動化していますか？

125

どのように自動化していますか？
/アサーションについて

• アサーションについて

126


• およそ5チームではアサーションが完全に禁
止されています。

127


• データが正しいフォーマットであるかどうかを
検証するためにアサーションを広範囲に使用
している人もいる。

128


• できるなら、アサート時にコールスタックを取
れるように！

129


• 実行フローを継続させる事ができる「スキップ
できるアサート」を使っている人もいる。

• （例：モンキーテストのような）ボットにトリガーされた
全てのアサーションを記録するようにしている。
• ユーザのプレイを通してスキップされたアサーション
はサーバにレポートされる（ユーザ名と一緒に！）。

130


• 「関数単位で全てのパラメータをテストする」
ためにアサーションを使う人もいる。

• 似たような感じで、「全ての事前、事後状態を
テストする」ためにアサーションを使う。

131


• アサーションは「アーティスト（デザイナ）フレン
ドリー」であるべき。人間に読める記述と、修
正のための指示やリンクを含めよう。

132


• アサートにグループによるタグ付けをする（マ
クロを使ったりして）、自動的に修正ができる
人にレポートする。

133


• アサーションの統計をとる -- これによりバグ
の多いシステムを識別する事ができる。

134


• できるだけ、通常のスキップ可能なアサートと
致命的なアサートを切り分ける。

135


• アサートを使用するチームの約10%は、稼働
させる時にに無効にしない

136


• アサートは「アルゴリズムのエラー用」に限定
し、全てのデータエラーのケースは別のコード
で扱う人もいる。

137


138


• 5,6チームだけがコードカバレッジ/ブランチカ
バレッジ解析ツールを使用

139

• ゲームシステムの上位層のテスト

• Testing High-Level Game Systems

140

ゲームシステムの上位層のテスト

• ゲームプレイ中の指示（メッセージストリーム
等）を簡単にもしくは自動的に記録するように
する；QAは記録されたストリームを取り出しス
クリプトから使う事ができる。シーケンスを記
録のスタート/ストップが簡単にできるように作
っておくべきだ。

141


• 入力とゲームプレイメッセージを記録する事
はゲームを一意に決定するのを助ける事が
できる、他の恩恵もある。

142


• 非現実なパラメータがシステムに入ってきた
場合アサートする。チート対策にも使える。

143


• 機能テストが失敗した時、もう一度同じ事が
起こるか試してみるのもあり。（数チームだけ
がこの方法をやっていた）

144


• あなたのAIはきちんと定義されたAPIがあるか
を確認してください、そして開発のスタート時
に「動かせる（drivable）」事を確認してください。
このAPIを装備する事により自動テストが作れ
ます。

145


• サーバをフレームレートを固定せずに実行で
きるようにした方がいい（できればレンダリン
グのOffも）；これによりテストを速くできる。

146


• テスト結果をSQL等に記録する。レポートのプ
ロトコルやデータベースのセットアップに過剰
装飾をしてはいけない；そんなに価値はない。

147


• いくつかのモック[抜粋--モックオブジェクトパタ
ーンにはたくさんの不幸があるが、これにつ
いては1日目に話した]は上位層のテストを行
う助けになる。

148

• 投資収益率

• Return on Investment

149

投資収益率

• 時間を記録する：通常の開発時間、自動化方
法の開発・メンテナンス時間・バグの修正時
間を記録する。一度自動化が導入されれば
減らすことができたバグの数やバグの修正時
間が明らかになるべき。

150

投資収益率

• 一度だけの移植やDLCなどの「一度作って終
わり」のプロジェクトは、スモークテストのよう
なシンプルな上位レベルの機能テストに注目
される。ユニットテストに取り組むのはやめる
べき。

151

投資収益率

• 自動テストのキャッシュから全ての失敗を集
めてレポートするべき。

152

• モバイル機器でのテストについて

• Testing on Mobile Devices

153

モバイル機器でのテスト

• 以下のサードパーティーの製品が挙がりまし
た
• Selenium (web specific)
http://seleniumhq.org/
• Sikuli (GUI testing with screen shots)
http://sikuli.org/
http://www.moongift.jp/r/2010/01/project-sikuli/
• .NET UI Automation framework
http://msdn.microsoft.com/ja-jp/library/ms747327.aspx

154


• 「Seleniumのような」なにかは使って走らせよ
う：尐なくともランダムにタップを行う「タッチモ
ンキー」くらいは。
http://en.wikipedia.org/wiki/Monkey_test

155


• [前のセッションで出たように]入力の記録と、
UIテストのプレイバックのどちらが「邪悪」か
意見が分かれた。「邪悪」：（あまりにも間違っ
た失敗をし･･･おそらくテストのfalse報告が間
違っているの意味･･･、メンテナンスコストが
高い）

156


• アクセスしやすいという特徴はUIの自動横断
テストに恩恵を与える。

157


• パイプラインからUIの「マップ」を引っこ抜く、
ビルドの前に、そしてそれをテストの生成に使
う。

158


• もしUIがXMLのデータドリブンであれば、その
XMLをテストにパースする事ができる。

159


• ほとんどのゲームで、80%の必要とされるテ
ストはゲームコンポーネントについてだ。それ
はUIテストのRoI (return on investment：投資
利益率)よりももっと高くなる。

160

• 「充分」vs「やりすぎ」なテスト

• What is "Enough" Testing Vs. "Too Much"?

161

「充分」vs「やりすぎ」なテスト

• 最初に再利用可能なコンポーネントをテスト
するのが良い。

162


• 他のシステムよりもまずゲームプレイのテスト
をした方が良い。

163


• より「専門的職業としてのQA」を必要とする。
QA→生産とQA→プログラミングの両方があ
る;もっとQA→QAが必要；「ソフトウェアデザイ
ンエンジニア」か「QAエンジニア」のポジション
をより多くの会社に与えて欲しい（すでにいく
つかの会社にはある！）。そして彼らにたくさ
ん給料をあげよう、できればね^^

164


• QAによる turnover --〔一定の期間の〕粗利益、
益金？〔会社などの〕離職者数［率］、補充者
数？-- は取り組まれるべき巨大な問題だ。

165


• 「壁を越えた」コミュニケーションを促進しよう。
（出席者のうちたった50%しかこれに取り組ん
でいなかった。）デイリー「スクラム」かミーティ
ングにQAの人を1人は連れてこよう。

166


• QAやテストエンジニアにさまざまなバックグラ
ウンドを持たせよう。例えば：ハードウェアの
知識は有益で卓越した洞察力に貢献する。

167


• QA turnover（上述）の問題に対して、独立し
たQA部門を成長させるのと期ごとのアルバイ
トを拡大する事で解決している会社もあった

168

• 可視化ツール

• Visualization Tools

169

可視化ツール

• [以下のほとんどは初日に挙げられた；いくつかは厳密には可視化
ツールではないが、この日挙がったリストとして]
• Hudson (builds)
• CruiseControl (builds)
• TeamCity (builds)
• NUnit (unit testing)
• VMWare (virtual machines)
• Sonar (code coverage)
http://www.sonarsource.org/
• Tableau (analytics)
• ･･･その他、内製のツール詰め合わせ
170

• ユニットテストvs結合テスト、どちらに投資する？

• Investment in unit tests vs. integration testing?

171

ユニットテストvs結合テスト、どちらに投資する？

• [このセクションのノートを無くしてしまった・・・
簡潔だったのと終わりが近かったので・・・ご
めんなさい！]

172

• webでのテスト

• Testing on the Web

173

webでのテスト

• ユーザを活用する：webアプリやゲームを使っ
て、レポートを返すようにする

174

webでのテスト

• ボットを使ってブラウザの自動化。

175

webでのテスト

• テストのために、専用のハードウェアと環境毎
（例えばOS毎、ブラウザ毎、など）に分けて用
意する。VMを使ったり。

176

• その他のリファレンス

• Other References

177

• IGDA Tools SIG: http://www.igda.org/toolssig
• tools_discuss mailing list:
http://two.pairlist.net/mailman/listinfo/tools_discuss
• wiki: http://wiki.igda.org/Tools_SIG
• IGDA QA SIG: http://www.igda.org/qa/
• wiki: http://wiki.igda.org/Quality_Assurance_SIG
• IGDA QA SIG: http://www.igda.org/qa/
• wiki: http://wiki.igda.org/Quality_Assurance_SIG
• "Six Million Dollar Tester: Making QA Better/Stronger/Faster
Through Automation"
• The GDC Vault : http://www.gdcvault.com/
178

Gamedevenvstudy1

More Related Content

What's hot (20)

Similar to Gamedevenvstudy1 (20)

Gamedevenvstudy1