Robotium を使った UI テスト

Robotium を使った UI テスト
2016/02/20 DroidKaigi 2016 Reject Conf
Sansan 株式会社辰濱健一

Copyright © 2014 Sansan, Inc. All rights reserved.
> Agenda
1
• 自己紹介
• なぜ Robotium？
• テスト記述のポリシー
• 実行環境
• デモ
• 自動テストを導入してみて
• UI テストで他にもできること
• これから

自己紹介
2

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

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

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

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

> Sansan神山ラボ
7

> 昨日もパンフレット入れさせて頂きました！
8

> 余談
9

> 余談
10
ちゃんと徳島に
帰ることができるのか！？

> 余談
11
ちゃんと徳島に
帰ることができるのか！？
徳島空港から家まで車なので呑めない…
飛ばないとわかっていれば呑める。。。

なぜ Robotium？
18

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

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

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

テスト記述のポリシー
22

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

ライブラリとテストコードの結合度を下げる
24

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

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

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

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

まずは、広く・浅く記述する
29

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

あきらめも大事
31

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

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

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

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

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

待ち方のコツ
37

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

どの環境でも動くように
39

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

41
• 多言語対応

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

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

44
• 多言語対応

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

46
• 多言語対応

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

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

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

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

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

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

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

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

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

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

> 推移時間（イメージ）
59
• パフォーマンス改善の結果確認、性能デグレの検出が
できる（かも？）
• 通信状態やサーバ状態に大きく左右される気がする…
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
ログイン処理
初回同期
名刺画像送信
詳細データ取得
高画質画像データ取得
手動同期処理

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

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

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

> これから
64
• Espresso も併用して、Robotium ではテストしづら
かった部分のテスト（Intent のチェックなど）を行う
• UI Automater も併用して、
• アクティビティを保持しない設定にする
• 最小化＆復帰後の画面状態のテスト
• AWS Device Farm を使って、所有していない端末
でのテストも行う

> DroidKaigi 2016 落ちたけど…
65
• JAWS DAYS 2016 出ます！
http://jawsdays2016.jaws-ug.jp/speaker/409
http://jawsdays2016.jaws-ug.jp/

> Device Farm を使ったスマホアプリの自動テスト
66
http://jawsdays2016.jaws-ug.jp/speaker/409

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

Robotium を使った UI テスト

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

Similar to Robotium を使った UI テスト

Similar to Robotium を使った UI テスト (20)

More from 健一辰濱

More from 健一辰濱 (20)