Sansan における Android アプリ自動テスト導入事例

1. Robotium を使った Android アプリ自動テスト導入事例 2016/03/23 Android Testing Bootcamp#1 Sansan 株式会社辰濱健一

2. Robotium を使った Android アプリ自動テスト導入事例 2016/03/23 Android Testing Bootcamp#1 Sansan 株式会社辰濱健一

3. Sansan における Android アプリ自動テスト導入事例 2016/03/23 Android Testing Bootcamp#1 Sansan 株式会社辰濱健一

4. Sansan における Android アプリ自動テスト導入事例 2016/03/23 Android Testing Bootcamp#1 Sansan 株式会社辰濱健一 DroidKaigi RejectConf の完コピの予定でしたが、内容変更しました！！

5. Sansan における Android アプリ自動テスト導入事例 2016/03/23 Android Testing Bootcamp#1 Sansan 株式会社辰濱健一実は、既に自分の中では Robotium オワコン…

6. > Agenda 5 • 自己紹介 • なぜ Robotium？ • テスト記述のポリシー • 実行環境 • デモ • 自動テストを導入してみて • Appium で iOS とコードの共通化 • UI テストで他にもできそうなこと • これから

7. 自己紹介 6

8. > 自己紹介 7 • 辰濱健一 @tatsuhama50 • https://www.facebook.com/kenichi.tatsuhama • http://www.slideshare.net/kenichitatsuhama • 徳島県生まれ、徳島県勤務 • Tokushima.app というスマホアプリ勉強会を主催 • 趣味は音楽＆旅行

9. > 自己紹介 8 • 業務経歴 • 1社目＠徳島市 • Java, C++, MFC • UWSC を使った Windows アプリの UI 自動テストの導入 • 性能改善チームにて、自動性能計測ツールを作成 • 2社目＠徳島市 • iOS（Objective-C）, Android（Java）, Windows（C#）のスマホ＆タブレット向けアプリ開発 • 機能担当制、iOS で作った機能は作った人が他 OS に移植 • 3社目＠徳島県神山町 • スマホアプリの自動テスト • リモートワーク開発＆品質担保と自動テストモバイル開発モバイル開発での品質担保と自動テスト

10. > Sansan株式会社 9 モバイルアプリエンジニアは、2つの事業部で8人のメンバー・Sansan … 4名（iOS x2 / Android x2）・Eight … 4名（iOS x2 / Android x2）

11. - もう紙の名刺はいらない！ - 「超音波」等で周囲のEight ユーザーを検索 - 複数のユーザー間でも名刺交換ができる - まずはアプリで＋ボタンを！ 10 > Eightの新機能「オンライン名刺交換」

12. 11 > それでは Eightのアプリを起動して、「＋」→「名刺交換」 →「近くのユーザと名刺交換」画面をタッチで名刺交換してみましょう！ QRコードでもできるよ。

13. > Sansan神山ラボ 12 • 築70年の木造古民家（3棟） • 略歴 • 2010年設置 • 〜2013/11:合宿所 • 2013/11〜:常駐メンバーのいる開発拠点に • 家具家電、畑付き、風呂トイレセパレート • 家賃：数万円 / 月 • インターネット接続：光回線 • 最寄り駅まで徒歩15分 • 改装OK物件

14. > Sansan神山ラボ 13

15. 本題に入る前に… 14

16. > 本題に入る前に… 15 • UI テストは、ユニットテストに比べて、ものすごく時間がかかります。 • コミット毎の UI テスト実施は現実的じゃないです • デイリーやリリースごとがオススメ • 本セッションは、UI テストのノウハウや弊社における導入事例を紹介します • 導入する費用対効果は、プロダクトによってまちまちだと思うので各自で判断下さい

17. なぜ Robotium？ 16

18. > スマホアプリの自動テストライブラリ 17 - Android 専用 - Robotium - monkeyrunner - Espresso - UI Automater など… - iOS 専用 - KIF - Kiwi - など… - ハイブリッド - Appium - Calabash - MonkeyTALK - など…

19. > Robotium にした理由 18 • Android 実装と同じ Java 言語で記述 • アプリケーション内部のオブジェクトを参照できる • UI に見えない内部の値、Activity の getter を呼べる SharedPreference の値 • DB にもアクセスできるので期待値や操作を動的生成できる → サーバ DB 状態の変更にも強い • ただし、リリースビルドでは使えない • 導入当時（2014/05）、最終局面で Espresso とどっちにするか悩んだ。 •

20. > Robotium にした理由 19 • Android 実装と同じ Java 言語で記述 • アプリケーション内部のオブジェクトを参照できる • UI に見えない内部の値、Activity の getter を呼べる SharedPreference の値 • DB にもアクセスできるので期待値や操作を動的生成できる → サーバ DB 状態の変更にも強い • ただし、リリースビルドでは使えない • 導入当時（2014/05）、最終局面で Espresso とどっちにするか悩んだ。 • 今となっては、Espresso にしておけば良かったと思う…。

21. > Robotium にした理由 20 • Android 実装と同じ Java 言語で記述 • アプリケーション内部のオブジェクトを参照できる • UI に見えない内部の値、Activity の getter を呼べる SharedPreference の値 • DB にもアクセスできるので期待値や操作を動的生成できる → サーバ DB 状態の変更にも強い • ただし、リリースビルドでは使えない • 導入当時（2014/05）、最終局面で Espresso とどっちにするか悩んだ。 • 今となっては、Espresso にしておけば良かったと思う…。 • 判断当時メンテが最新の方を採った。Espresso の方が便利！

22. テスト記述のポリシー 21

23. > テスト記述のポリシー 22 • ライブラリとテストコードの結合度を下げる • まずは、浅く・広く記述する • あきらめも大事 • 待ち方のコツ • どの環境でも動くように

24. テスト記述のポリシーライブラリとテストコードの結合度を下げる 23

25. > ライブラリとテストコードの結合度を下げる 24 • 目的 • テストコードの可読性を上げる • ライブラリに依存しないテストコードにする • ライブラリにない機能追加ができる • 実行ログの記録 • エラー時にスクリーンショットを残すようにする • 理由 • ライブラリの API 変更, ライブラリの置き換えでテストコードの修正が伴わない • 失敗時の原因調査がしやすい

26. > Robotium Getting Started は密結合 25 • https://github.com/RobotiumTech/robotium/wiki/Getting-Started • あくまでも API の使い方と思っておきましょう。 • 【対応】テストの基底クラスなどを作って clickOnText(String)を作り、テストコードではそちらを呼び出すテストコードとライブラリが密結合

27. > ライブラリの依存性排除 26 • ライブラリの隠蔽 Robotium 版

28. > ライブラリを置き換えるとしても… 27 • テストコードを修正することなく、対応可能 Robotium 版 Espresso 版 ※Robotium と Espresso は同じ InstrumentationTest なので、共存可能！！

29. テスト記述のポリシーまずは、広く・浅く記述する 28

30. > まずは、広く・浅く記述する 29 • 背景 • スマホアプリの UI や機能は比較的すぐ見直しが入る • 使えないと致命的な機能と、そうでない機能がある • 対策 • まずは、費用対効果の高い、主要機能のワンパスを通す • ログイン → 検索・閲覧・編集 → ログアウトあたり • ログイン時のバリデートチェックよりも、ログインできるかの方が重要 • 慣れてきたら、各画面の詳細テストへ

31. テスト記述のポリシーあきらめも大事 30

32. > あきらめも大事 31 • 別アプリと連携するものなどは手動で確認へ • 例） • カメラのピントが合っていること • 住所文字列をタップすると地図アプリが起動し、その場所にピンが立っていること • URL をタップするとブラウザが起動し、ページが正しく表示されること • 場合によってはアプリ選択画面が出る • 起動後の状態判定は目視の方が容易 • こういう所の自動化を頑張るのは費用対効果的に微妙…

33. > あきらめも大事 32 • 例）URL をタップするとブラウザが開くアプリブラウザ

34. > あきらめも大事（だけど、知見共有） 33 • 例）URL をタップするとブラウザが開く • Robotium や Espresso は UI 操作により別アプリが開くと、その後どうしようもなくなる… • 理由 • アプリケーションの操作であって、端末の操作ではない • 対応策 • UI Automaterと併用する • ※但し、minSdkVersion に注意 • このあたりは、TOYAMA Sumio 氏の発表に委ねます • Espresso の Intent チェックを使う

35. > あきらめも大事：メールチェック編 34 • 別アプリ…とはいえ、送られてきたメールをチェックするなら、MailCatcher & MailCatcher API で実現可能 • MailCatcher • SMTPサーバを経由したメールをブラウザから確認できる。開発中の誤送信防止にも役立つ。 • http://mailcatcher.me/ • MailCatcher API • /messages • /messages/:id.json • /messages/:id.html • /messages/:id.plain など

36. > あきらめも大事：メールチェック編 35 • Retrofit & RxAndroid を使えば容易 • 指定したタイトルのメールが届いているか？ • 特定のメールを開いて本文の URL をタップ（メール本文から URL を抽出して、OkHttpClient などで post する） ※Message モデルのプロパティは一部しか宣言していない

37. テスト記述のポリシー待ち方のコツ 36

38. > 待ち方のコツ 37 • テストコードでは SLEEP 関数は使わない • 自作関数やライブラリのラッパー関数内で使うのはアリ • 端末、実行環境、サーバの状態によって待ち時間は違う！ • どうするか？ → wait* 関数を使う • ライブラリ関数の例 • waitForActivity • waitForFragmentByTag • waitForCondition

39. テスト記述のポリシーどの環境でも動くように 38

40. > どの環境でも動くように 39 • 操作手順や期待値の動的生成 • エミュレータ判定 • 多言語対応

42. > 操作手順や期待値の動的生成 41 • 弊社の開発事情によるところかも知れないですが… 「開発用」「ステージング」「本番」でデータセットが異なります。 • 検索結果などが保証されるためにも • ローカル DB を参照して操作手順や期待値を動的生成する • ログイン後にテストコードでデータを作る操作を行う • このデータに対し、検索・編集・削除などのテストを行う • ノイズにならないためにログアウト前に作ったデータを削除する操作を行う • これにより、環境非依存なテストケースになります

43. > 操作手順や期待値の動的生成 42 実際のテストコード myName : ”山田賢治” users : {Uesr(阿部拓真), User(浅野緋美) , User(葉加瀬万太郎), …} ※ログインユーザを変えると、myName は違う値 ※ログイン企業を変えると、users も違うデータセットが返る

45. > どの環境でも動くように 44 • エミュレータかどうかの判定 • 実機じゃないと確認できない項目（カメラなど）はこのフラグを見てスキップさせる

47. > 多言語対応 46 • https://github.com/RobotiumTech/robotium/wiki/Getting-Started • ↑あくまでも API の使い方と思っておきましょう。 • 【対応】 • Robotium なら、clickOnText(@StringRes int) を作って、 getString(…) • Espresso なら、withText に @StringRes int を渡す日本語の時文言が違えば、このコードはエラーになる ※表示文言が仕様通りであることの判定にはならないので要注意

48. 実行環境

49. > 実行環境 48 • 基本的に実機で実行 • 昔は Jenkins & エミュレータでやっていた • テストが増え、CI 環境を長時間（2h 以上※）占有する＆エミュレータが不安定なためやめた • ※無料版、有料版など全パターン回した場合 • jacoco でカバレッジ計測 • どこのテストが足りてないかわかる • 開発環境 DB で実施 • 固定のデータセット、特定のデータを使いたい場合は Docker にて特定のデータセットを持つ DB を用意

50. > Jacoco のカバレッジレポート 49 • html で出力される（抜粋） • • 2016/02時点で 59% をカバーできている

51. > Jacoco のカバレッジレポート 50 • html で出力される • 通っていないパスがよくわかる

52. > Docker を使った固定データ環境 51 • 開発環境（データや件数が他者によって書き換えられる可能性がある）でもテストが行えるようにしているが、以下のニーズがある • パフォーマンス計測がしたい（ので、件数固定じゃないとダメ） • テスト用に特定のユーザセットが欲しい • 例）アカウント停止ユーザのエラーチェック • アプリからは設定できないデータを持つ名刺が欲しい • 例）名刺交換日未設定 • ローカル DB をアテにしない期待値を書きたい • 例）山田賢治さんは○○枚名刺を持っている • Docker で環境（API&DB）のイメージを持っておき、テストコードから環境準備＆片付けを行う

53. > Docker を使った固定データ環境 52 • 事前準備 • Jenkins に環境起動用のジョブ / 環境破棄用のを作成 • テスト実行時 • setup() で環境起動用の Jenkins ジョブを Jenkins WebAPI を用いて実行 • アプリの API の向き先を差し替える • テスト実行中 • 起動した環境に接続してテストを実施 • テスト終了時 • tearDown() で環境破棄用の Jenkins ジョブを Jenkins WebAPI を用いて実行 • API の向き先を戻す

54. デモ

55. > デモ動画 54 • 2014/11 時点の動画です • http://youtu.be/scY_RPgfxeY • 4分ぐらいありますが、発表時間の都合上ちょっとだけ…

56. 自動テストを導入してみて

57. > 自動テスト導入してみて 56 • デグレードがないことを容易に確認できる • メンテは思ったほど大変じゃない • コツ：1行で書ける画面操作も clickSendButton() などの関数にして共通利用するとよい • テストでしっかりカバーしていれば、大規模なリファクタリングも安心！ • これから、通信ライブラリ・カメラ API・デザインパーツの差し替え・DB の置き換え？などが控えている • モックを使わないので、サーバの動作確認にもなる • 同じ仕様の iOS アプリもテストしたい…

58. > 自動テスト導入してみて 57 • デグレードがないことを容易に確認できる • メンテは思ったほど大変じゃない • コツ：1行で書ける画面操作も clickSendButton() などの関数にして共通利用するとよい • テストでしっかりカバーしていれば、大規模なリファクタリングも安心！ • これから、通信ライブラリ・カメラ API・デザインパーツの差し替え・DB の置き換え？などが控えている • モックを使わないので、サーバの動作確認にもなる • 同じ仕様の iOS アプリもテストしたい…

59. Appium で iOS アプリとテストコードを共有する

60. > Appium 59 • http://appium.io/ • iOS アプリでも Android アプリでもテスト可能 • リリースバイナリでもテスト可能 • 但し、アプリ内部オブジェクトにはアクセスできない… • Java, Ruby, JavaScript などで記述可能

61. > 設定ファイル（1/2） 60

62. > 設定ファイル（2/2） 61

63. > デモシナリオ 62 タップ入力エラー

64. > テストコード 63 iOS アプリの View のアクセシビリティラベルに Android と同様の View ID を付与しているのがミソ

65. > 実行するコマンド 64 - Appium 起動 > appium & - for iOS > OS=iOS rspec spec/signup_spec.rb - for Android > OS=Android rspec spec/signup_spec.rb - スクショ一覧作成（オレオレ Ruby ツール） > cd screenshot > ruby collector.rb 同じ！

66. デモ

67. > スクショ一覧（Android & iOS8） 66

68. > スクショ一覧（Android & iOS9） 67 iOS9だと、スクショで一部 View が欠落する…

69. > Some elements are invisible on screenshot of iOS 9.2 68https://github.com/appium/appium/issues/6229

70. Appium の話は終わり。

71. Appium の話は終わり。 Appium 遅いね。。。

72. UI テストで他にもできそうなこと（ちょっとだけ着手して、本格導入できていない件）

73. > 推移時間（イメージ） 72 • パフォーマンス改善の結果確認、性能デグレの検出ができる（かも？） • 通信状態やサーバ状態に大きく左右される気がする… 0 2 4 6 8 10 12 2015/2/27 2015/2/28 2015/3/1 2015/3/2 2015/3/3 2015/3/4 2015/3/5 2015/3/6 ログイン処理初回同期名刺画像送信詳細データ取得高画質画像データ取得手動同期処理

74. > 通信回数の分析 73 - 呼び出し毎に API名と実行時間を csv ファイルに出力 - Excel のピボットテーブルで集計 - iOS / Android で同じ仕組みを入れれば、同じ操作で API 呼び出しの違いがわかる！そんなに呼び出す必要あるの…？サーバ負荷削減のためのボトルネック分析が容易になる Excelマクロ

75. > 通信回数の分析（推移） 74 - さっきのデータを実行毎に集計する呼び出し回数削減施策導入

76. > スクショ一覧 75 画面名→ 画面名→ 画面名→ Nexus4 Nexus5 デザイン指示画像（期待値） ※元サイズが違うけど、今は同じサイズで表示されている目で比較する！デザイナのチェックや意図しないレイアウト崩れの確認が楽になりました

77. これから

78. > これから 77 • Espresso も併用して、Robotium ではテストしづらかった部分のテスト（Intent のチェックなど）を行う • UI Automater も併用して、 • アクティビティを保持しない設定にする • 最小化＆復帰後の画面状態のテスト • AWS Device Farm を使って、所有していない端末を時間借りしてテストを行う • Device Farm も Appium をサポートしている！ ※但し、まだ Java 記述のみ… • http://www.slideshare.net/kenichitatsuhama/device-farm

79. まとめ

80. > まとめ 79 • 頑張ればいろいろできる • 少人数でやっていれば影響範囲はわかるので、導入は各自判断ください… • 頑張りすぎない、広く浅くから！ • 色んな機種でスクリーンショット集めるのはオススメ • 色んなライブラリを組み合わすことも可能

81. 質疑応答

82. ステッカー欲しい方はお声がけ下さい！！

Sansan における Android アプリ自動テスト導入事例

Esté a ler uma amostra.

Confira estes a seguir

Sansan における Android アプリ自動テスト導入事例

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)

Semelhante a Sansan における Android アプリ自動テスト導入事例 (20)

Mais de 健一辰濱 (20)

Mais recentes (20)