![Build
• おまけ：制御用パイプラインスクリプト概要
【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト
stage(テスト設定エクセルのロード) {
// テスト設定エクセルには1ケース1行で実行用パラメータが記載されている
// オートテスト用リポジトリからファイル一式を更新
// エクセル⇒csvに変換、読み込み
}
stage(テスト名) {
while(!executed) {
// 実行可能なノードの検索
def c = Jenkins.instance.computers.find { it.isOnline() } // 実際はラベル条件などもチェック
def idleExecutors = c.executors.findAll { it.isIdle() }
// パラメータを渡してオートテストジョブを実行
build job: 'AutotestJob', parameters: [string(name: 'AUTO_INPUT_FILE', value: auto_input_file), string(name: 'SAVE_DATA', value: save_data_file),
(中略), [$class: 'LabelParameterValue', name: 'RUN_ON', label: c.getDisplayName()]], propagate: false, wait: false
// 実行できるまでスリープしながらループ
sleep 30
}
}
// 1周終わったら次のジョブを呼び出す
build job: 'Autotest_Master_Pipeline', propagate: false, wait: false](https://image.slidesharecdn.com/cedec2020sakauekokawapdf-200825055741/85/QA-28-320.jpg)
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
- 4. QA 龍が如くスタジオのバグチケット数の推移 17,448 13,367 5,095 22,963 11,857 12,211 17,346 25,155 龍 維新 2014年 龍０ 2015年 龍極 2016年 龍６ 2016年 龍極２ 2017年 北斗が如く 2018年 JUDGE EYES 2018年 龍７ 2020年 ゲーム規模の拡大とともにバグチケット数も増加傾向
- 9. QA • バグやタスクを一括管理するシステム – 龍が如くスタジオではRedmineを使用 • バグチケットのステータスの流れ チケット管理システムについて 確認待ち対応中新規 差し戻し 確認済 修正開始 修正完了 修正確認OK 修正確認NG チケット管理システムの詳細は『「龍が如く」の高速デバッグ術 ～そびえ立つバグの山を踏破するための弾丸ワークフロー～』 http://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf
- 10. QA • ゲームの開発効率を上げるために最重要 – バグの処理作業に時間がかかると最悪発売延期 – 自動化がデバッグ期間の短縮につながる – 単純なバグ取りに人的リソースをかけたくない なぜバグ作業フローの自動化するのか？ 全自動バグ取りシステムを作ろう！
- 11. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
- 12. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
- 16. QA • どこでもリプレイシステム – 自動テスト作成・実行するためのシステム – 手動プレイをリプレイ用スクリプトとして記録・ 再生 – プログラミング知識なしで自動テストが作成可能 – リプレイ用スクリプトはPythonを採用 • 後から条件分岐や繰り返し処理を追加可能 • 将来的な画像認識や機械学習との連携を想定 【テスト作成・実行の自動化】
- 18. QA 外部ツールゲーム内 どこでもリプレイエディタ GUI(C#) WebSocket サーバ どこでもリプレイシステム（記録） ゲーム動作を アクション単位で スクリプト化 ゲームを手動で プレイ
- 25. Build • オートテストクライアントとJenkinsの使い分け – オートテストクライアント • 利用者（テスト協力者）が扱いやすい – 利用PCで実行状態がわかる – 起動前と終了後の処理を正しく行う • 開発の空き時間での運用 – Jenkinsからの実行 • オートテスト管理者が扱いやすい – より複雑なオートテスト制御を行う • 24時間稼働している前提での運用 【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト 24時間稼働している前提での運用 開発の空き時間での運用 サブシナリオのテスト • 1つ30分～2時間程度のサ ブシナリオが50以上 • 全サブシナリオを効率的に 実行したい
- 26. Build • Jenkinsからより複雑なオートテスト制御を行う – 実行内容の制御 • テスト対象の指定 – セーブデータ、リプレイ用スクリプト • タイムアウト設定 – 実行PCの制御 • 1つ1つのサブシナリオテストを順に空きPCに 割り当てて実行していく 【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト
- 27. Build • Jenkins実行でのジョブ実行例 【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト Autotest_Master_Pipeline node: autotest-001 node: autotest-002 node: autotest-003 AutotestJob #111 sub01.py 空きPC(ノード)を検知して次のオートテストジョブを実行 AutotestJob #112 sub02.py AutotestJob #113 sub03.py AutotestJob #114 sub04.py 結果：成功 結果：失敗 結果：失敗(タイムアウト) Autotest_Master_Pipeline は1000周以上、AutotestJobは4万回弱実行
- 28. Build • おまけ：制御用パイプラインスクリプト概要 【テストケース設定の自動化】 Jenkins上でのサブシナリオのテスト stage(テスト設定エクセルのロード) { // テスト設定エクセルには1ケース1行で実行用パラメータが記載されている // オートテスト用リポジトリからファイル一式を更新 // エクセル⇒csvに変換、読み込み } stage(テスト名) { while(!executed) { // 実行可能なノードの検索 def c = Jenkins.instance.computers.find { it.isOnline() } // 実際はラベル条件などもチェック def idleExecutors = c.executors.findAll { it.isIdle() } // パラメータを渡してオートテストジョブを実行 build job: 'AutotestJob', parameters: [string(name: 'AUTO_INPUT_FILE', value: auto_input_file), string(name: 'SAVE_DATA', value: save_data_file), (中略), [$class: 'LabelParameterValue', name: 'RUN_ON', label: c.getDisplayName()]], propagate: false, wait: false // 実行できるまでスリープしながらループ sleep 30 } } // 1周終わったら次のジョブを呼び出す build job: 'Autotest_Master_Pipeline', propagate: false, wait: false
- 30. QA 【エラー検知の自動化】 • エラー検知の種類 – 例外（アプリケーションエラー） – ASSERT • 例外と同じくエラー扱い – WARNING • 開発モードは継続可能 • テストではエラー扱い – テスト結果分析 • どこでもログ分析で進行不能等を見える化 適切なアサーションを大量に入れる どこでもログ分析の詳細は 『無料で始める！ 「龍が如く」を面白くするための 高速デバッグログ分析と自動化』 http://jasst.jp/symposium/jasst18tokyo/pdf/D4.pdf ©SEGA
- 31. QA オートテストのエラー検出数と割合 オートテスト 8,102件 18.6% 龍が如く6 命の詩。 (ランダム＋パス) 龍が如く7 光と闇の行方 (ランダム＋Python) オートテスト 手動テスト JUDGE EYES：死神の遺言 (ランダム＋Lua) オートテスト 16,930件 33.4% ※2020年7月に集計 オートテスト 29,242件 68.5%
- 33. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
- 35. QA 龍が如くスタジオのクラッシュレポート機能 【バグ周辺情報収集の自動化】エラー送信 ゲーム実行中に 例外発生！ ネットワークドライブ • ダンプ • ログ • スタックトレース • スクリーンショット • 直前の動画 • リプレイデータ メール送信 • ダンプ表示batのURL • スタックトレース • リビジョン チケット管理システム (Redmine) ログサーバ 1エラー数百MB～数GB
- 38. QA • 自動で作成したチケットを手動のバグと区別する – Redmineのトラッカー • 手動のバグ→「バグ」 • 自動のバグ→「エラー送信」 – 区別する理由 • Jenkinsによる自動操作のミスを防止 • 実際のプロジェクトへの混乱のない導入 • マスターアップ直前は選別が必要 自動作成チケットのルール
- 41. Build • 再現確認のための実行 – セーブデータ、リプレイ用スクリプト – 実行用Jenkinsジョブを呼びだす – 複数回実行する（タイムアウト付き） • 実行結果をRedmineチケットに反映 – 同じエラーが発生 • 対象チケットの「自動再現」項目を「はい」 ⇒ 開発者：再現用データを使って確認可能（詳細は修正編） – エラーが発生しない ⇒ 開発者：「再現しなかった」という情報と共に調査 【再現確認の自動化】Jenkinsと連携
- 42. Build エラー送信経由でJenkinsをキック リプレイデータ • 直前のオートセーブ • リプレイ用スクリプト(.py) • デバッグ設定情報(.ini) • 再現用bat(replay_jenkins.bat) チケット管理システム (Redmine) Jenkins 再現確認 ジョブ実行 自動再現 「はい」
- 45. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
- 47. QA • 優先度と重要度の違い – 優先度 • 修正を急ぐ必要性 – 高：多くの場所に影響がある – 低：特定の条件がそろわないと起きない/再現率が低い – 重要度 • バグの重大性 – 高：アプリケーションエラーで強制終了 – 低：誤字脱字などの表記ミス » ただし権利表記や製品基準に関わる誤字は重要度高 【優先度・重要度の決定の自動化】
- 48. QA • 重複数が多い＝広範囲で発生して緊急性が高い • 重複判定 – エラーメッセージの1行目の一致 – スタックトレースの最初の1行目の一致 • 重複数の表示例 重複数で優先度を決定 スタックトレース または エラーメッセージ チ ケ ッ ト 番 号
- 49. QA • エラーの種類でシンプルに判定 – 例外 • 重要度：高 – ASSERT • 重要度：高 – WARNING • 重要度：中 重要度の自動設定
- 51. Build • 機械学習を使ったチケット担当者の自動割り当て – 今回はチャレンジのみで実運用には至らず • 取り組みの概要 – 学習データ：過去、進行中プロジェクトのRedmineデータ • 入力：件名、説明（エラーメッセージ、スタックトレース） • ターゲット：担当者 – アルゴリズム • CNN, Character-level CNN – 出力例 • ユーザ毎の担当者確率 【修正担当者決定の自動化】機械学習
- 52. Build • 簡単な考察 – ここでの結論 • 方向性は悪くなかったが、 こういうことができる前提としてエラー登録の仕組みと運用が整っ ている – 機械学習導入の労力 • 機能の実装（今回はやってみた） • 結果の検証、調整（今回は途中まで） • 学習を繰り返しながら運用（今回取り組まず） 【修正担当者決定の自動化】機械学習 ⇒ 今回はASSERTマクロ機能（後述）の拡張という別手段で解決 ルールで解決可能な場合はルールに沿った仕組みの方が費用対効果は高い
- 53. QA 【修正担当者決定の自動化】ASSERTマクロ WARNING ASSERT DEBUGBREAK 例外 例外は13%程度 エラーの全体の87%はアサーション
- 56. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
- 58. QA • どこでもリプレイを開発者環境で実行 – 「自動再現」が「はい」のチケットで利用可能 – ダンプ保存場所に作成済みの再現用batを利用 • replay_autotest.bat – 自席PCのオートテスト環境で再現確認 • replay_local.bat – 自席PCのビルドを使って修正確認 【開発者環境での再現・修正確認の自動化】
- 60. QA 【コンバートの自動化】Jenkins コンバート ビルド チェック exe更新 (Nightly Build) スモーク テスト 静的コード 解析 Redmine ステータス 変更 Jenkinsによる自動化 プログラム データ （モデル/サウンドなど） ゲーム に反映 コンバート自動化の詳細は『「龍が如く」の高速デバッグ術 ～そびえ立つバグの山を踏破するための弾丸ワークフロー～』 http://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf
- 65. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
- 67. QA • 入念なデグレチェック体制 – ビルドチェック – 静的解析（VSコード分析・Coverity） – スモークテスト – オートテスト（ゲーム全域をカバー） 【リグレッションテストの自動化】 修正によるデグレ（エンバグ）を自動検出
- 69. Build • どこでもリプレイによる修正確認（Jenkins） – チケットステータスが「確認待ち」になる – Jenkinsが検知 – 最新ビルドに更新 – 「再現確認の自動化」の仕組みで再度実行 • 不具合再発無し ⇒ 「確認済」 • 不具合が再発 ⇒ 「差し戻し」 【自動テストによる修正確認の自動化】
- 71. Build • 時間経過による自動確認済（Jenkins） – 前提：日々のオートテスト実行とエラー報告の自動化 により、未修正の問題は継続的に報告され続ける • ⇒ エラー報告が止まったものは解決とみなす – 方針：チケットの更新（自動報告の重複関連付け、作 業者による更新も含む）が一定期間以上無い場合、チ ケットは「確認済」とする • （意味的には「確認済」よりは「再発しない」） – 対応：Jenkinsで定期的にチェック、自動処理 【重複判定による修正確認の自動化】
- 72. Build 【重複判定による修正確認の自動化】 エラー送信 #84 ステータス：対応中 Redmine_Check_ErrorIssues2週間以上更新が無い エラー送信 #85 ステータス：対応中 更新を確認 エラー送信 #86 「重複数」を更新(+1) 重複関連付け Jenkins Redmine 自 動 確認済 （再発しない）
- 74. QA • はじめに • バグ探索編 • バグ報告編 • バグ選別編 • バグ修正編 • バグ修正確認編 • まとめ 全自動バグ取りシステムへの道（目次）
- 76. QA 代表的な自動化機能の適用件数 ゲームタイトル どこでもバグ報告 コンバート予約 エラー送信 全自動化 龍が如く 維新！ 9,338 未計測 未計測 - 龍が如く0 誓いの場所 6,316 7,930 621 - 龍が如く 極 1,931 4,013 未計測 - 龍が如く6 命の詩。 18,529 18,101 8,102 - 龍が如く 極2 10,487 9,836 8,645 - 北斗が如く 8,676 8,096 16,532 - JUDGE EYES：死神の遺言 15,253 13,457 16,930 - 龍が如く7 光と闇の行方 20,478 19,131 29,242 250 いずれかの恩恵をうけてバグ作業フローが効率化！
- 77. QA バグ１件当たりの作業時間 龍 維新 龍０ 龍極 龍６ 龍極２ 北斗が如く JUDGE EYES 龍７ 全自動バグ取りシステムが1件当たりの作業時間を削減 各自動化の恩恵を 受けたチケット数を 集計してポイント化
- 78. QA • 全自動化できたバグチケット（純粋な修正除く） – 250件とまだまだ少ない • バグ作業フロー全体の効率化は達成！ – ほぼすべてのバグチケットが自動化のいずれかの 恩恵をうけているため • 今後の課題 – どこでもリプレイの精度向上 • 経過時間の再現 • ランダムのシードの固定化 全自動バグ取りシステムの運用結果
- 80. QA Build • 「龍が如く」の高速デバッグ術 ～そびえ立つバグの山を踏破するための弾丸ワークフロー～ – http://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf • 無料で始める！ 「龍が如く」を面白くするための 高速デバッグログ分析と自動化 – http://www.jasst.jp/symposium/jasst18tokyo/pdf/D4.pdf • 「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成 の取り組みについて – https://www.slideshare.net/SEGADevTech/7-234572005 関連資料
- 81. QA Build • 社内ヘルプデスクをＡＩで！ フューチャーアーキテクト開発者ブログ – https://future-architect.github.io/articles/20171005/ • GDC 2018 - Tools Tutorial Day: Tools to Reduce Open Bug Count at Media Molecule – https://www.gdcvault.com/play/1025439/Tools-Tutorial-Day-Tools-to – https://www.gdcvault.com/play/1025013/Tools-Tutorial-Day-Tools-to 参考文献