テスト自動化研究会主催「テスト自動化カンファレンス2014」発表資料 質疑応答やTweetいただいた内容について補足を加えたエントリを書きました http://nowsprinting.hatenablog.com/entry/2014/12/15/080000

1. ビルドプロセスとCI
2014.12.14 #STAC2014 at Yahoo! JAPAN
@nowsprinting / Koji Hasegawa

2. 自己紹介
• @nowsprinting
• フリーランス（iOS/Androidアプリ受託開発）
• テスト自動化研究会、Androidテスト部、VR部
• アプリ『山吹色の茸疾走』『フットサル ルールと雑学』
『電エースQuiz - 河崎実監督と特撮映画の世界』
• 著書『システムテスト自動化 標準ガイド』（共訳・共著）
『iOSアプリ テスト自動化入門』
『Androidアプリ テスト技法』（共著）

3. 著書
第14章『CI』担当

4. • Android Bazaar and Conference 2014 Winter
http://abc.android-group.jp/2014w/
12/21（日） 10:00～18:00
東海大学高輪キャンパス（東京都・品川）
• 【VR部屋】タオバイザー(Cardboard)ハンズオン
https://atnd.org/events/60117

5. アジェンダ
• ビルドプロセス、CIの概要（本日お話する範囲）
• テストウェアアーキテクチャ（STA第5章）
• 前処理と後処理の自動化（STA第6章）
• ビルドパイプラインの事例

6. ビルドプロセス、CI

7. “ビルド”の定義
• 狭義のビルド
• 製品のコンパイル、リンケージ、パッケージング
• 広義のビルド
• 自動化されたテストの実行
• 各種テスト環境へのデプロイ（配備）
• 商用環境へのデプロイ、リリース

8. CI
• 継続的インテグレーション
• 自動化されたビルドプロセス（Integration）を
繰り返し・継続的に（Continuous）実行する
• CIツール/サービス
• Jenkins, CloudBees, Travis CI, Circle CIなど

9. CIツール/サービスを
使えばCIと言える?

10. “ハンマーを持つ人には
すべてが釘に見える”
“If all you have is a hammer, everything looks like a nail.”
- Abraham Harold Maslow
http://www.wwezone.org/wwe/triple-h/page/8/

11. 数年前…

13. ©BeeworksGames

14. 同じ過ちを繰り返さないために
『システムテスト自動化
標準ガイド』
から知見を得ましょう！

15. テストウェア
アーキテクチャ

16. テストウェア
• 自動・手動の区別なく、テストに関わる作成物
• テスト資料
• ドキュメント、データ、スクリプト、入力、
期待結果
• テスト結果
• 実際の出力、ログ、ステータス、比較レポート

17. テストウェアアーキテクチャ
• テストウェアを
• どこに格納し、利用するか
• どのようにグループ化し、参照するか
• どのように変更し、保守するか
5.1「テストウェアアーキテクチャとは何か」より

18. なにが問題になるか
• 規模（ファイルの数が多い）
• 再利用性（建て増し旅館）
• 複数のバージョン（製品のバージョンとの同期）
• プラットフォームと環境からの独立（動作環境ごと
にテストウェアのコピーを作るのか）
5.2「カギとなる4つの課題」より

19. ツールで解決できるもの
• 規模（ファイルの数が多い）
• 再利用性（建て増し旅館）
• 複数のバージョン（製品のバージョンとの同期）
• プラットフォームと環境からの独立（動作環境ごと
にテストウェアのコピーを作るのか）
5.2「カギとなる4つの課題」より

20. 規模（1/2）
• 「テスト結果」のうち、実際の出力、ログなどにつ
いてはCIツールに任せる

21. 規模（2/2）
• CIツールのレポート機能で、失敗したテストだけを
視認し、調査できる

22. 複数のバージョン（1/3）
• 緊急修正を行なった際の回帰テストで、どのバージョ
ンのテストセットを実行すべきか
• インクリメンタルな開発・テストでは、どのテスト
セットを実行すべきか

23. 複数のバージョン（2/3）
• 「テスト資料」は、バージョン管理システムで管理
• 例えば、テストコード、テストデータ（SQL）、
テーブル定義、比較用の出力データ（期待結果）、
サーバ構成定義、VMイメージ

24. 複数のバージョン（3/3）
• Git-flowなど、ブランチやタグの運用ルールを導入
する
• テスト実行環境の再現性を得るために
➡ サーバ構成管理ツール、仮想マシンの活用

25. ほかの課題に対して
• 5.3「取り組み方」に、以下のようなヒントがあり
ます
• テストセット、データセットといった論理構造
• 物理的構造、命名規約

26. 前処理と後処理の
自動化

27. 前処理と後処理
• テスト実行の前処理、後処理
• 前処理・・・生成、チェック、再配置、変換
• 後処理・・・削除、チェック、再配置、変換
6.2「前処理と後処理」より

28. 前処理
• 生成・・・・DBへのデータ投入など
• チェック・・テスト実行環境のチェック
（自動実行できない前提条件・環境のチェック）
• 再配置・・・ファイルの移動など
• 変換・・・・zipの展開など
6.2「前処理と後処理」より

29. 後処理
• 削除・・・・不要な生成物の削除
• チェック・・テスト出力の事後チェックなど
（スクリプト内でチェックできない場合）
• 再配置・・・ファイルの移動など
• 変換・・・・zipへの圧縮など
6.2「前処理と後処理」より

30. 後処理の補足
• 「削除」「再配置」は、極力「前処理」で行なうほ
うが、安定します
• テストが異常終了したとき
• バージョンを切り替えたとき
• ログなど、CIツールに任せればよいものは任せる

31. 前処理/後処理の自動化
• なぜ自動化が必要なのか
• テスト実行環境の再現性
• 繰り返しテスト実行に耐えるように
• 実装は、スクリプト（6.4.2）、コマンドファイル
（6.4.3）、もしくは専用のビルドツール

32. ビルドツール
• Make、Rake、Ant、Gradle など
• ライブラリ依存関係の解決
• タスク単位（狭義のビルド、テスト実行など）での
スクリプト記述
• タスクの前提条件を考慮した実行

33. （改めて）CI

34. CIの定義とメリット
• ビルドプロセスを、少なくとも1日1回、理想的に
はバージョン管理システムへのチェックインごとに
自動実行する
• バグの作り込みを、早期に検出できる
• メトリクスの採取、通知（チャットやメール）など
との連動

35. Jenkins
• http://jenkins-ci.org
• 自前の筐体にインストールして起動するタイプ
• 操作、管理はWebブラウザから可能
• 豊富なプラグインで拡張できる

36. CloudBees
• https://www.cloudbees.com
• Jenkinsのホスティングを提供するサービス
• プラグイン等、Jenkinsの利点はそのまま

37. Travis CI
• https://travis-ci.org
• GitHub上のリポジトリを対象としたCIを提供
• WorkerにMac OS Xがあり、iOSでも利用可能
• 実行環境自体がImmutableで、ビルドの定義は
YAML形式のファイルで指定できる

38. Travis CIの例
• Androidアプリの例
『システムテスト自動化 標準ガイド』14.1に掲載
されています
• iOSアプリの例
『iOSアプリ テスト自動化入門』7.3に掲載されて
います（サンプルコードはGitHubにあります）

39. ビルドパイプライン

40. ビルドパイプライン
• テストレベル（結合度）ごとに順番に実行する
• フィードバックを素早くする効果
• STA 9.2「どのテストをいつ実行するか」
• 各種テスト環境へのデプロイ（配備）
• 自動テストをパスしたら、次の工程に進む
• 手動トリガーで次工程をキック

41. ビルドパイプラインの実現
• Jenkinsのプラグインを利用する
Build Pipeline Plugin、Delivery Pipeline Plugin
• ビルドスクリプトで組む
• Walterなどのツールを利用する

42. Build Pipeline Plugin

43. Delivery Pipeline Plugin

44. Walter
• https://github.com/walter-cd/walter
• Go製のパイプライン実行ツール。YAML形式で
パイプラインを記述し、実行できる

45. ビルドパイプラインの
事例

46. 前提
• BtoBtoCのスマートフォンアプリ
• 弊社はシステムテストまで。顧客で受け入れテスト
• ビルドターゲットが複数（OEMなど）
• ビルドコンフィグも複数（サーバ接続先に応じて）
• Git-flowを利用

47. 前提 - Git-flow
• masterはリリースされているアプリの状態
• 開発中のコードはdevelop
• リリース候補はdevelopからrelease/1.1など
• 緊急修正はmasterからhotfix/1.0.1など
• アプリ等に向く（Web向き：GitHub Flowなど）

48. パイプラインの事例
1. ユニットテスト、統合テスト（UI操作が中心）、
メトリクス採取
2. システムテスト
3. UAT・リリース向けに全ターゲットのビルド
4. DeployGateにアップロード

49. パイプラインの事例
1. ユニットテスト、統合テスト（UI操作が中心）、
メトリクス採取
2. システムテスト
3. UAT・リリース向けに全ターゲットのビルド
4. DeployGateにアップロード
• UI操作のテストは、ユニットテストフレームワーク
上で動作するもの（iOS: KIF, Android: Robotium）
＋モックサーバで構築
• develop, release, hotfixブランチで実行

50. パイプラインの事例
1. ユニットテスト、統合テスト（UI操作が中心）、
メトリクス採取
2. システムテスト
3. UAT・リリース向けに全ターゲットのビルド
4. DeployGateにアップロード
• 1の後、2を実行（ひとつのジョブ）
• 当初、Frankでごくシンプルな機能テストのみ実装
→OSバージョン問題で動かない
• OSのバリエーションをマトリクスで実行（予定）

51. パイプラインの事例
• release, hotfixのとき実行
• Pythonのスクリプトで複数ターゲットxコンフィグ
のビルド
• BundleVersionなども自動設定
1. ユニットテスト、統合テスト（UI操作が中心）、
メトリクス採取
2. システムテスト
3. UAT・リリース向けに全ターゲットのビルド
4. DeployGateにアップロード

52. パイプラインの事例
1. ユニットテスト、統合テスト（UI操作が中心）、
メト• リ3のク後ス、採4取
を実行（ひとつのジョブ）
• アップロードAPIをスクリプトから実行
2. シス• テ以ム前テはTestFlightスト
を利用
• https://deploygate.com
3. UAT・リリース向けに全ターゲットのビルド
4. DeployGateにアップロード

53. パイプラインの事例
1. ユニットテスト、統合テスト（UI操作が中心）、
メトリクス採取
2. システムテスト
3. UAT・リリース向けに全ターゲットのビルド
4. DeployGateにアップロード

54. パイプラインの事例
1. ユニットテスト、統合テスト（UI操作が中心）、
メトリクス採取
パイプライン
2. システムテスト
3. UAT・リリースじ向けゃに全なターい
ゲットのビルド
4. DeployGateにアップロード

55. 構築のポイント
• 分割する意味のあるジョブだけ分割する
（手動トリガーでキックしたい等）
• ブランチを利用する
• パイプラインにこだわらない

56. 参考文献

57. まとめ

58. “ハンマーを持つ人には
すべてが釘に見える”
“If all you have is a hammer, everything looks like a nail.”
- Abraham Harold Maslow
http://www.wwezone.org/wwe/triple-h/page/8/

59. まとめ
• 基本は『システムテスト自動化 標準ガイド』
• テストウェアアーキテクチャ（第5章）
• 前処理と後処理の自動化（第6章）
• ツールに振り回されず、開発が捗るCI環境を！