1.
クックパッドアプリの開発を支援する
Appiumの話し
2014/10/18
第2回 日本Seleniumユーザーコミュニティ勉強

2.
私
• 松尾和昭
• テストエンジニア at Cookpad
• Twitter: @Kazu_cocoa
!
• 関連
• JaSST’14 Hokkaido
• 『モバイルアプリ開発体制の継続的改善』

3.
Appium

4.
第1回日本Seleniumユーザーコミュニティ勉強会
http://www.slideshare.net/hugs/selenium-appium

5.
Web Page: http://appium.io/
GitHub: https://github.com/appium/appium

6.
参照: http://www.3pillarglobal.com/insights/appium-a-cross-browser-mobile-automation-tool

7.
UIAutomation
uiautomator
(API 16 (Android 4.1) or higher)

8.
Philosophy

9.
MVCなどで切り分けて
テストしにくい

10.
描画要素をテスト
SDK + 専用ビルド

11.
「SDK+専用ビルド」は
リリースされない

12.
SDK+専用ビルド
+
リリースビルド

13.
リリースビルド + Appium

14.
リリースモジュールを
テストする

15.
自分たちの開発環境に、
Appiumを統合する

16.
Ruby + RSpec + Turnip
ImageMagick or perceptualdiff
Selenium Grid
!
目的に見合ったツール群の組み合わせ

17.
よいとこ
!
よくはない

18.
よいとこ
• リリースビルドをテスト可能
• 多彩なツールの組み合わせ
• Appiumはあくまでもアプリ操作
• 黒魔術を使わないのでOSの変化に追従しやすそう

19.
よくはない
• 実例がない
• 実行に時間がかかる
• 工夫が必要
• 誰もがAppiumを使える環境の構築が手間
• 社内に広げるきっかけの妨げ

20.
Cookpadにおける活用事例

21.
私の今の立ち位置
• テストエンジニア
• Android / iOS アプリ
• 開発行程の改善
• テストに関わる社内への情報伝搬

22.
iOS クックパッドアプリ
• ネイティブアプリ
• UIの修正が頻繁
• 修正規模の大小はあるが
• 約2週間毎のAppStoreへのサブミット
• 実装は数人のチーム

23.
テストレベル
Web API

24.
リリース工程
企画期間開発期間
検証期間
master branch
release branch

25.
Appiumを使うタイミング

26.
企画期間開発期間
master branch
検証期間
release branch

27.
主な確認対象
• 画面遷移
• レイアウト崩れ

28.
テストケース数と時間
• テストケース数
• 100ケース/1capability
• Capability
• 2 ~ 3 種類
• 1種類にかかる時間
• 1時間
今の開発周期ではこの時
間で十分なので、これ以上は
頑張っていない

29.
工夫

30.
変化への追従

31.
• 使い始めた当初は、Appium 1.0.0 よりも前
• 修正が入る可能性が大いにある
• 実行シナリオは変更したくない
• テストケースの変更にのみ依存するようにしたい
• 具体的な実装からは切り離したい

32.
責務の分離
シナリオ
.feature
実装コード
*_steps.rb
ラッパー
.rb
appium_lib
Appium
シナリオ変更の吸収Appium

33.
役割
シナリオ
.feature
実装コード
*_steps.rb
ラッパー
.rb
appium_lib
Appium
シナリオ変更の吸収Appium
シナリオの修正に
のみ追従したいAppium側の修正を、
シナリオから分離したい
Appium側の
修正に依存

34.
$ rspec

35.
login.feature
hs| |_YMcWRdCG=
||Z^bTQS]aRd
||_YMEOFOeKNQUSd]IcWRdDNAJ?I@N
||||pr|%5*$|ImiPj
|||||421!23342|_YIcWRdDN
|||||fxL|70$3%|?toBOH=N
|||||[VbdZ`]P|2$1.2)/3|J=wpIkN
!
||{
||||:|%5*$|||:|421!23342||:|||70$3%|||||:|2$1.2)/3|:
||||:|*0)/.|:|X[]|||||:|gqDNun|:|$0341
|:
||||:|*0)/.|:|vz|||||||:|gqDNun|:|$0341|:
||||:|*0)/.|:|yz|||||||:|gqDNun|:|$0341

36.
|:

37.
login_steps.rb -/%4,|2302
||230|lM|$$/4.3|J|022|IcWRdDN|%/|:$$/4.3|022:
||||,-.32||373'*,%2
||||,-.32 2.%!+82|$$/4.3
||||,-.32
2.%!+82|022
||||#433/.cWRd$,*$+
||.%
!
||230|lM|421|_YIcWRdDN|%/|:421:
||||*'|421||vz
||||||$$/4.3||!!
||||||022||!!
||||,2*'|421||yz
||||||$$/4.3||!!
||||||022||!!
||||,2
||||||$$/4.3||
||||||022||
||||.%
||||2.%|lM|$$/4.3|J|022|IcWRdDN|$$/4.3|022
||.%
!
||230|[VbdZ`]P|'*,.-|J=wpIkN|%/|:'*,.-:
||||25!2$1.!6*3)!
!2'*,.-
||.%
!
||230|fxL|.-|?toBOH=N|%/|:.-:
||||2,0|
||||70$3|6*3|9|'*.%!,-.3$$22*#*,*38!*%|.-|;%*20,8%|3/|#|314
||.%
.%

38.
薄いラッパー層
-/%4,|00*4-2341
|||'*.%|,-.3|6*3)|$$22*#*,*38!*%|2313(8
||%'|30!.-,-.3!.-
||||2,0|
||||'*.%!,-.3$$22*#*,*38!*%|,-.3!.-$,*$+
||.%
!
|||'*.%|,-.3|6*3)|703)|2313(8
||%'|30!703),-.3!703)
||||2,0|
||||'*.%!,-.3703)|,-.3!703)$,*$+
||.%
!
||%'|30!373373!.-
||||2,0|
||||373373!.-$,*$+
||.%
.%

39.
Ruby
コード
JavaScript

40.
どんなテストをAppiumに
任せるか

41.
機械が実行可能なタスクは
機械に任せる

42.
人が忘れがちなシナリオは
機械に任せる

43.
シナリオの統合/作り替え

44.
• アカウントの状態に依存しない処理はアカウントの
各状態ではシナリオを用意しない
• 複数の操作を1つのシナリオで内包できる場合、内
包させ、テストケースを削減
• 他の手段（UIから確認しなくても良い方法に対応し
たなど）が見つかったシナリオは削除、もしくは操
作を限定

45.
機械が実施していない領域を
探索的にテスト

46.
• 機能
• 状態が関係するような複雑性を増した手順
• 非機能
• ユーザビリティ
• ISO 2941
• Context of use
など

47.
これまでの成果
• 検証期間中のタスク内容の変化
• 致命的な不具合の検出（落ちバグ系）
• Crashlytics/お問い合わせによるク
ラッシュ系不具合、不具合報告が減少

48.
これからの課題
• Appiumを使っているところ
• iOS8対応
• Androidのシナリオ充実
• 社内への他アプリへの展開
• モバイルアプリの評価自体
• 評価体制のスケール

49.
まとめ
• Appium
• Android / iOS (FireFox)
• ツールの組み合わせ
• よいとこ / よくないとこ
• Cookpadでの活用事例

50.
Questions ?