ゲーム開発環境勉強会#1の資料です

1. ゲーム開発環境勉強会
邦訳：[GDC2011]Automated Testing
Roundtable

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

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

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

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

6. • シンプルなテスト、スケジューリング、ツール
• Simple Tests, Scheduling, and Tools
6

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

8. シンプルなテスト、スケジューリング、ツール
• 既存のプロジェクトのテストを始める場合は、
ユニットテストよりも基本的な機能テストを好
む
8

9. シンプルなテスト、スケジューリング、ツール
• 明確な「ホットスポット」を見つける。プロジェク
ト特有の複雑な部分やありそうな部分に注目
する
9

10. シンプルなテスト、スケジューリング、ツール
• 既存のシステムを活用する：ゲームプレイの
記録と再生ができ、追加のメトリクス情報を生
成する。
10

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

12. シンプルなテスト、スケジューリング、ツール
• 「ゲームがロードされているか？」「それぞれ
のレベルがロードされているか？」というスモ
ークテストから始める。
12

13. シンプルなテスト、スケジューリング、ツール
• 視覚的なスクリプトシステムは、小さなテスト
を行うための素晴らしい環境です。
visual scripting system
• http://forum.unity3d.com/threads/54580-Visual-Scripting-System
• http://www.extremetech.com/article2/0,2845,1152028,00.asp
13

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

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

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

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

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

19. シンプルなテスト、スケジューリング、ツール
• 「失敗を期待する」テストはいくつかのケース
で有用だろう。
19

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

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

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

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

24. シンプルなテスト、スケジューリング、ツール
• 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

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

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

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

28. • 入力の扱い
• Input Driving
28

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

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

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

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

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

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

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

36. • レポートと履歴
• Reporting and History
36

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

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

39. レポートと履歴
• Long soak tests：浸せき試験（1日から2週間っ
て言っていた）を行えばリークや他の問題をグ
ラフ化する事ができるよ。
http://www.c-able.ne.jp/~tips-com/00topics/01dictionary/0111sa/
（信頼性テスト）
39

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

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

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

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

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

45. • テスト環境
• Test Environments
45

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

47. テスト環境
• 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

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

49. • アンチパターン、避けるべき事
• Anti-patterns, Things to Avoid
49

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

51. アンチパターン、避けるべき事
• ユニットテストがフィットしているとしても、「よく
似た」機能テストを作成して走らせた方が
往々にして早い：（他の全てが同じようにユニ
ットテストが好ましいとしても）
51

52. アンチパターン、避けるべき事
• チューニングのために進化（改造）されたビル
ドからデータを使用する場合、何かが変わっ
た時に深刻な問題が発生する。
• [この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. アンチパターン、避けるべき事
• 可能であれば、ベータ、実験、未熟なツール
とコンポーネントは[ビルドや自動テスト内で
使うのを、おそらく一般使用も]避けるべきだ。
53

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

55. アンチパターン、避けるべき事
• "Process and people make all the difference."
ことわざ「people make all the difference」に
Processもつけた物と思われる。ひとそれぞれ、
プロセスもそれぞれ
55

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

57. • ボット
• Bots
57

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

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

60. • 静的コード解析
• Static Code Analysis
60

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

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

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

64. 静的コード解析
• 静的解析は「64bit移植」問題を修正する時に
かなり役立ったという人も居た。
それから始める場合は、静的解析を使うと簡単です。
（64bit移植のこと？）
It's easier to do static code analysis if you start with it.
64

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

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

67. • Day 2
• 2日目のトピックはインフラです：誰がデプロイ
や自動化を保持しますか、そしてどんなツー
ルやプラクティスを使っていますか。
• この日は「一般的な質問を集めて、それらに
ついて答えていく」モデルにしました。
67

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

69. • 内製vsサードパーティー
• In-house vs. 3rd Party
69

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

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

72. 内製vsサードパーティー
• サードパーティーのツールは以下のものが挙
げられました：
• 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

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

74. テレメトリー（遠隔測定）
• E-mailは万国共通
74

75. テレメトリー（遠隔測定）
• アサートや警告ログをレポートする
75

76. テレメトリー（遠隔測定）
• メモリ状況をグラフ化する
76

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

78. テレメトリー（遠隔測定）
• サードパーティーのツールは以下のものが挙
げられました：
• 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

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

80. テレメトリー（遠隔測定）
• Callgrindを使って5分毎のゲームのデータを
集めているチームもあった。
80

81. テレメトリー（遠隔測定）
• 「全ての可能な武器vsゾンビの組み合わせに
対して」ヒット数、ダメージ、誰が勝つかを試す
とか。
81

82. テレメトリー（遠隔測定）
• テスト中に獲得した全ての「達成
（achievements）」を記録する。
82

83. テレメトリー（遠隔測定）
• プレイ時間を記録する（「QA側のチェック」は
この方法でできる、もし傾向があれば）
83

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

85. テレメトリー（遠隔測定）
• 「収集は簡単、提示が難しい」
85

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

87. • 統合/メンテナンス
• Integration / Maintenance
87

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

89. 統合/メンテナンス
• 自動化の維持を任せる事ができる人々という
新しい特徴の情報を得る事が難しいというチ
ームも居る
89

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

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

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

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

94. • 応答（所要）時間
• Turnaround Time
94

95. 応答（所要）時間
• いくつかのテストの系統によって期間が分か
れた？
• Wii: 1 hour
• PC: 5-6 minutes
95

96. 応答（所要）時間
• スモークテストは早くできるべき。アイデア：
• start editor
• start each level
• save and then load
96

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

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

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

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

101. 応答（所要）時間
• 自動テスト専用のハードウェアがあるは一般
的です。
101

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

103. プレゼンテーション
• 結果を1日に1回か2回は出力する。
103

104. プレゼンテーション
• 結果は探させるよりユーザに提示しよう。け
れどやりすぎは良くない。
104

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

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

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

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

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

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

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

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

113. プレゼンテーション
• 通知方法について
• 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

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

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

116. • 分散ビルド
• Distributed Builds
116

117. 分散ビルド
• 以下のサードパーティーの商品が挙がった
• 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

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

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

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

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

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

123. • Day 3
• 3日目のトピックはデータ収集、マイニング、
可視化について。
• [前日に結構うまくいったので、「一般的な質
問を集めて、それらについて答えていく」モデ
ルを続けます。
123

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

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

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

127. どのように自動化していますか？
/アサーションについて
• およそ5チームではアサーションが完全に禁
止されています。
127

128. どのように自動化していますか？
/アサーションについて
• データが正しいフォーマットであるかどうかを
検証するためにアサーションを広範囲に使用
している人もいる。
128

129. どのように自動化していますか？
/アサーションについて
• できるなら、アサート時にコールスタックを取
れるように！
129

130. どのように自動化していますか？
/アサーションについて
• 実行フローを継続させる事ができる「スキップ
できるアサート」を使っている人もいる。
• （例：モンキーテストのような）ボットにトリガーされた
全てのアサーションを記録するようにしている。
• ユーザのプレイを通してスキップされたアサーション
はサーバにレポートされる（ユーザ名と一緒に！）。
130

131. どのように自動化していますか？
/アサーションについて
• 「関数単位で全てのパラメータをテストする」
ためにアサーションを使う人もいる。
• 似たような感じで、「全ての事前、事後状態を
テストする」ためにアサーションを使う。
131

132. どのように自動化していますか？
/アサーションについて
• アサーションは「アーティスト（デザイナ）フレン
ドリー」であるべき。人間に読める記述と、修
正のための指示やリンクを含めよう。
132

133. どのように自動化していますか？
/アサーションについて
• アサートにグループによるタグ付けをする（マ
クロを使ったりして）、自動的に修正ができる
人にレポートする。
133

134. どのように自動化していますか？
/アサーションについて
• アサーションの統計をとる -- これによりバグ
の多いシステムを識別する事ができる。
134

135. どのように自動化していますか？
/アサーションについて
• できるだけ、通常のスキップ可能なアサートと
致命的なアサートを切り分ける。
135

136. どのように自動化していますか？
/アサーションについて
• アサートを使用するチームの約10%は、稼働
させる時にに無効にしない
136

137. どのように自動化していますか？
/アサーションについて
• アサートは「アルゴリズムのエラー用」に限定
し、全てのデータエラーのケースは別のコード
で扱う人もいる。
137

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

139. どのように自動化していますか？
• 5,6チームだけがコードカバレッジ/ブランチカ
バレッジ解析ツールを使用
139

140. • ゲームシステムの上位層のテスト
• Testing High-Level Game Systems
140

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

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

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

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

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

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

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

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

149. • 投資収益率
• Return on Investment
149

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

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

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

153. • モバイル機器でのテストについて
• Testing on Mobile Devices
153

154. モバイル機器でのテスト
• 以下のサードパーティーの製品が挙がりまし
た
• 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

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

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

157. モバイル機器でのテスト
• アクセスしやすいという特徴はUIの自動横断
テストに恩恵を与える。
157

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

159. モバイル機器でのテスト
• もしUIがXMLのデータドリブンであれば、その
XMLをテストにパースする事ができる。
159

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

161. • 「充分」vs「やりすぎ」なテスト
• What is "Enough" Testing Vs. "Too Much"?
161

162. 「充分」vs「やりすぎ」なテスト
• 最初に再利用可能なコンポーネントをテスト
するのが良い。
162

163. 「充分」vs「やりすぎ」なテスト
• 他のシステムよりもまずゲームプレイのテスト
をした方が良い。
163

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

165. 「充分」vs「やりすぎ」なテスト
• QAによる turnover --〔一定の期間の〕粗利益、
益金？〔会社などの〕離職者数［率］、補充者
数？-- は取り組まれるべき巨大な問題だ。
165

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

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

168. 「充分」vs「やりすぎ」なテスト
• QA turnover（上述）の問題に対して、独立し
たQA部門を成長させるのと期ごとのアルバイ
トを拡大する事で解決している会社もあった
168

169. • 可視化ツール
• Visualization Tools
169

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

171. • ユニットテストvs結合テスト、どちらに投資する？
• Investment in unit tests vs. integration testing?
171

172. ユニットテストvs結合テスト、どちらに投資する？
• [このセクションのノートを無くしてしまった・・・
簡潔だったのと終わりが近かったので・・・ご
めんなさい！]
172

173. • webでのテスト
• Testing on the Web
173

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

175. webでのテスト
• ボットを使ってブラウザの自動化。
175

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

177. • その他のリファレンス
• Other References
177

178. • 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

179. 179