アプリの不具合を少なくするために

アプリの不具合を少なくするために

2016/02/16 　 Sansan×SONY アプリ勉強会

Sansan 株式会社　辰濱健一

Copyright © 2014 Sansan, Inc. All rights reserved.

>Agenda

2

• 自己紹介

• Sansan アプリについて

• 不具合を少なくするために

• 導入ツール

• 手動でのテスト

• 自動テスト

• まとめ

Copyright © 2014 Sansan, Inc. All rights reserved. 3

自己紹介


>自己紹介

4

• 辰濱健一• https://www.facebook.com/kenichi.tatsuhama• http://www.slideshare.net/kenichitatsuhama

• 徳島県生まれ、徳島県勤務

• Tokushima.app というスマホアプリ勉強会を主催

• 趣味は音楽＆旅行

https://www.facebook.com/kenichi.tatsuhama



http://www.slideshare.net/kenichitatsuhama





>自己紹介

5

• 業務経歴

• 1 社目＠徳島市

• Java, C++, MFC• UWSC を使った Windows アプリの UI 自動テストの導入

• 性能改善チームにて、自動性能計測ツールを作成

• 2 社目＠徳島市

• iOS （ Objective-C ） , Android （ Java ） , Windows （ C# ）のスマホ＆タブレット向けアプリ開発

• 機能担当制、 iOS で作った機能は作った人が他 OS に移植

• 3 社目＠徳島県神山町

• スマホアプリの自動テスト

• リモートワーク

開発＆品質担保と自動テスト

モバイル開発

モバイル開発での品質担保と自動テスト


>自己紹介

6

• Sansan 神山ラボ（勤務先）


Sansan アプリについて


>Sansan アプリについて

8

• 法人向け名刺管理サービスのクライアントアプリ

• 社員の名刺を検索・閲覧でき、社内の人脈を共有


>Sansan アプリについて

9

• iOS / Android ほぼ同一仕様、ネイティブ実装

• 安価な機能制限版（海外向け）もワンバイナリで実現

• アプリ内でモードによる分岐多々…

• 海外向けには色んな施策を試すべく、スピーディーに対応する必要がある

• 日本語 / 英語に対応

• 名刺データ（個人情報）を扱っているので、アプリの品質が悪いと、サービスだけでなく会社の信用失墜に繋がる


>Sansan Android アプリについて

10

• 辰濱の入社前までは外注していた

• 辰濱の入社後も、早期リリースに迫られ外注さんのコードベースで不具合修正＆機能追加を余儀なくされる

• 直近まで、事業部内で Android エンジニアが１人だったので事業要求に応えるだけで精一杯（現在は２名体制）

• スピード感と品質が求められる


不具合を少なくするために


>不具合を少なくするために

12

• 導入ツール

• 手動でのテスト

• 自動でのテスト



〜導入ツール〜


>導入ツール

14

• Lint• Android Studio Inspect Code• Support Annotations• Crashlytics• Infer （ Facebook ）

• QARK （ LinkedIn ）


>Lint

15

• http://developer.android.com/intl/ja/tools/help/lint.html

• Android SDK tools に含まれている静的コード解析ツール

• ./gradlew lint で実行

• 指摘内容

• UnuserdResources （未使用リソース）

• UselessParent （ View の不要なネスト）

• HardcodedText （国際化非対応）

など…

http://developer.android.com/intl/ja/tools/help/lint.html







>Lint

16

未使用文言

Notification icon の visual style


>Android Studio Inspect Code

17

• Android Studio から実行できる静的コード解析

• Analyze > Inspect Code で実行

• 指摘内容

• Deprecated API use 　（非推奨 API の利用）

• Field can be local 　（変数のスコープの指摘）

• Javadoc issues 　（ Javadoc コメントと実体の乖離）

• Declaration can have final modifier （ final にできる）

• Spelling 　（スペルミス）

• Actual method parameter is the same constant（同じ値しか渡ってこない）

など…


>Android Studio Inspect Code

18

Android Studio 上でレポートを確認できる

自動補正もサポート！


>Support Annotations

19

• http://tools.android.com/tech-docs/support-annotations

• アノテーションを使って、パラメータの nonnull / nullable や値範囲を宣言できる

• Android Studio 上で警告してくれる

http://tools.android.com/tech-docs/support-annotations




>Crashlytics

20

• https://try.crashlytics.com/• クラッシュレポート収集＆分析ツール

• ダッシュボードで、クラッシュの詳細を見ることができる

• 時刻、端末情報、アプリバージョン、発生箇所、頻度…

• ProGuard をかけた apk でも、元のクラス名・関数名・行数で確認できるのは嬉しい

https://try.crashlytics.com/


>Crashlytics

21


>Infer

22

• http://fbinfer.com/• Facebook 製、静的コード解析ツール

• 指摘内容

• CONTEXT_LEAK• NULL_DEREFERENCE• RESOURCE_LEAK

• 結果は CSV, Json で出力される

• Android Studio Inspect Code での内容と重複するところもあるが、 Inspect Code にない指摘もある

http://fbinfer.com/

http://fbinfer.com/


>QARK

23

• https://github.com/linkedin/qark • LinkedIn 製、セキュリティチェックツール

• 指摘内容

• export されたコンポーネント

• WebView の設定

• Intent のセキュリティ

• 弱い暗号方式の利用など…

• 結果は html で出力される

https://github.com/linkedin/qark








〜手動でのテスト〜


>手動でのテストの観点

25

• アクティビティを保持しない

• さまざまな通信環境

• iOS 版や Web 版との比較

• 社内 β 版の配布

• リグレッションテスト



26







>アクティビティを保持しない

27

• 開発者向けオプションで設定

• この時に、

• 正しく画面遷移（行き来）できるか

• 最小化 → 復帰後の状態は適切か

• 各種変数の値

• 表示中のダイアログやメッセージが、復帰後も正しく動作するか？

• これにより以下の確認になる

• on(Save/Restore)InstanceState 対応

• 適切な Fragment の扱い方


>【コラム】適切な Fragment の扱い方

28

• デフォルトコンストラクタを使っているか？

• 外から渡したい値は、 Bundle で渡しているか？


>【コラム】適切な Fragment の扱い方

29

• setListener などしていないか？

• フラグメント再構築時に、 setter は呼ばれない！

• ※onCreate は呼ばれます

• DialogFragment に setListener してると、再構築時に Listener が set されず、意図した Listener の呼び出しが行われない

• 詳しくは「Master of Fragment」を！http://tatsu-zine.com/books/master-of-fragments

http://tatsu-zine.com/books/master-of-fragments





30







>さまざまな通信環境

31

• 安定した通信環境　（当然なので解説省略）

• 機内モードの時

• 通信が遅いとき

• Wi-Fi に繋がっているが、インターネットに繋がっていない場合


>機内モードの時

32

• 端末で予め判定できる（ ConnectivityManager ）

• 事前のエラー表示ができているか？（そもそも画面遷移させないなど）

• 通信処理を行った場合、エラーハンドリングできているか？

• キャッシュで表示できるモノだけでも表示する？

• 送信処理を受け付け、オンラインになったら送信？（ Facebook などはオフライン投稿機能がある）


>通信が遅いとき

33

• 再現方法は色々

• 通信ライブラリと interceptor で可能かも？

• 低速 SIM• Android エミュレータの設定　など…

• UX は適切か？　（ぐるぐる表示、進捗表示）

• 最小化や画面遷移後のコールバック処理は大丈夫か？• Fragment#isAdded() で Activity に attach されているかチェッ

ク

• ViewPager 内の破棄された Fragment へのコールバックは忘れがち

• 可能であれば、前画面用の通信はキャンセル or 優先度を下げたい


> Wi-Fi にはつながってるが、ネットにつながってない

34

• 基本的には、前項の項目と同じ

• ※端末側での判定は難しい

• ただ、サーバからのレスポンスが帰ってこないので、タイムアウトのエラーハンドリングが必要

• タイムアウトまで通信スレッドを占有するので、通信キューが山積みになったり、いくつものスレッドを走らせすぎる懸念



35







>iOS 版や Web 版との比較

36

• 同じ操作をしたり、同じデータを表示させて見比べる

• よくある差違

• 数値や日付の表示形式

• データのソート順

• 長い文字列の対応（末尾…、折り返し、スクロール）


>iOS 版や Web 版との比較

37

桁区切りの有無

数値の違い



38







>社内 β 版の配布

39

• 社内ヘビーユーザにリリース前に配布

• 実データならではの問題が出る可能性がある

• 開発中に使っていない端末でも問題なく動作するか？

• なかなか気づかない操作の癖

• バックキー使い？　ナビゲーションで戻る？

• キーボードの虫眼鏡ボタンで検索？

• 2点タップどっちから離すか

• A+B： A押下 → B押下 → どっちから離す？？

• ↑前々職でどっちから離すかで再現が別れる問題があった



40







>リグレッションテスト

41

• リリース直前に必ず実施

• 主要機能のデグレードがないことを確認

• やる）

• 主要機能のワンパス

• ログイン、名刺登録、編集、削除、ログアウト　など

• 過去の重大な不具合が再現しないこと

• やらない）

• 100 文字制限のところに 101 文字入れたときのエラー

• アプリにサーバリリース前にも行っている



〜自動テスト〜


>Robotium を使った自動テスト

43

• ユニットテストではカバーしきれないUI 操作を伴うテストを記述

• Robotium はアプリケーション内部オブジェクトを参照できるため、柔軟なテストが記述できる

• DB のデータを参照して、 ListView に表示されているか

• SharedPreference の値が意図通りかの確認

• ただし、デバッグ版でしか動作しない（リリースバイナリでのテストは Appium を使う）


>テストコードの例

44

ログイン処理

メールアドレス入力欄を取得

パスワード入力欄を取得

メールアドレスを入力

パスワードを入力

ログインボタンを押す

テストライブラリをラップして可読性確保！


>デモ動画

45

• 2014/11 時点の動画です

• http://youtu.be/scY_RPgfxeY• 4 分ぐらいありますが、発表時間の都合上ちょっとだ

け…

http://youtu.be/scY_RPgfxeY


>自動テストの適用

46

• 前述のリグレッションテストには適用済み

• 主要画面の詳細なテストも記述中

• エラーメッセージ

• サインアップ時に送られるメールをパースして、サインアップ処理を行う（ MailCatcher API を利用）

• Jacoco によるカバレッジ計測

• 2016/02時点で 59% をカバー

• ※テストでコードが実行されているからといって、安心ではない。


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

47

• デグレードがないことを容易に確認できる

• メンテはそこまで大変じゃない

• テストでしっかりカバーしていれば、大規模なリファクタリングも安心！• これから、通信ライブラリ・カメラ API ・デザインパーツの差し替

え・ DB の置き換え？などが控えている

• モックを使わないので、サーバの動作確認にもなる


>自動テストの詳細は

48

• DroidKaigi 2016 で！

https://droidkaigi.github.io/2016/






49

と、思ったのですが、CFP 通らなかったので…



50

• 2/20 DroidKaigi 2016 Reject Conf で！

http://connpass.com/event/24264/






51

• 3/23 Android Testing Bootcamp #1 でも！？


※抽選がまだ





>調査中の Device Farm の内容ですが…

52

• 3/12 JAWS DAYS 2016 でも！

http://jawsdays2016.jaws-ug.jp/speaker/409http://jawsdays2016.jaws-ug.jp/

http://jawsdays2016.jaws-ug.jp/speaker/409

http://jawsdays2016.jaws-ug.jp/


効果


>効果

54

• iOS / Android とも、前任者のコードベースの事情を十分にカバーする品質担保ができている。

• 開発部内でサービスインシデントは数十件 /年あるが、アプリにおいては 0件 /年と部内トップレベル

• 新しい OS や端末が出た場合のテストも容易

• テスト工数の削減

• コードレビュー時にこれらの観点でも見るので、チームメンバーの品質意識・対応の底上げになる


まとめ


>まとめ

56

• 使えるツールは使おう！

• 色んな環境でテストしよう！

• テストの自動化に取り組もう！


質疑応答


>こちらもどうぞ

58

• Android アプリ品質ガイドライン【 Google Developers Japan 】• http://googledevjp.blogspot.jp/2013/01/core.html

• Robotium を使った UI テストとレイアウト確認の効率化• http://www.slideshare.net/kenichitatsuhama/robotium-ui

• Appium を使って iOS / Android の UI テストを共通化

• http://www.slideshare.net/kenichitatsuhama/appium-ios-android-ui

• UWSC を使った自動テスト（ for Windows ）• http://qiita.com/tatsuhama/items/d6595050a13c5ed2de48

• Robotium で書いた Android アプリのテストを AWS Device Farm で実行する• http://qiita.com/tatsuhama/items/27d5e3ef1056e740b085

http://googledevjp.blogspot.jp/2013/01/core.html




http://www.slideshare.net/kenichitatsuhama/robotium-ui






http://www.slideshare.net/kenichitatsuhama/appium-ios-android-ui










http://qiita.com/tatsuhama/items/d6595050a13c5ed2de48





http://qiita.com/tatsuhama/items/27d5e3ef1056e740b085





Software

アプリの不具合を少なくするために