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

アプリの不具合を少なくするために
2016/02/16 Sansan×SONYアプリ勉強会
Sansan株式会社辰濱健一

Copyright © 2014 Sansan, Inc. All rights reserved.
> Agenda
1
• 自己紹介
• Sansanアプリについて
• 不具合を少なくするために
• 導入ツール
• 手動でのテスト
• 自動テスト
• まとめ

Copyright © 2014 Sansan, Inc. All rights reserved. 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社目＠徳島県神山町
• スマホアプリの自動テスト
• リモートワーク
開発＆
品質担保と自動テスト
モバイル開発
モバイル開発での
品質担保と
自動テスト

> 自己紹介
5
• Sansan神山ラボ（勤務先）

Sansan アプリについて

> Sansan アプリについて
7
• 法人向け名刺管理サービスのクライアントアプリ
• 社員の名刺を検索・閲覧でき、社内の人脈を共有

> Sansan アプリについて
8
• iOS / Android ほぼ同一仕様、ネイティブ実装
• 安価な機能制限版（海外向け）もワンバイナリで実現
• アプリ内でモードによる分岐多々…
• 海外向けには色んな施策を試すべく、スピーディーに対
応する必要がある
• 日本語/英語に対応
• 名刺データ（個人情報）を扱っているので、
アプリの品質が悪いと、サービスだけでなく
会社の信用失墜に繋がる

> Sansan Android アプリについて
9
• 辰濱の入社前までは外注していた
• 辰濱の入社後も、早期リリースに迫られ外注さんの
コードベースで不具合修正＆機能追加を余儀なくされ
る
• 直近まで、事業部内で Android エンジニアが１人だっ
たので事業要求に応えるだけで精一杯
（現在は２名体制）
• スピード感と品質が求められる

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

> 不具合を少なくするために
11
• 導入ツール
• 手動でのテスト
• 自動でのテスト

〜導入ツール〜

> 導入ツール
13
• Lint
• Android Studio Inspect Code
• Support Annotations
• Crashlytics
• Infer（Facebook）
• QARK（LinkedIn）

> Lint
14
• http://developer.android.com/intl/ja/tools/help/li
nt.html
• Android SDK tools に含まれている静的コード解析
ツール
• ./gradlew lint で実行
• 指摘内容
• UnuserdResources（未使用リソース）
• UselessParent（View の不要なネスト）
• HardcodedText（国際化非対応）
など…

> Lint
15
未使用文言
Notification icon の visual style

> Android Studio Inspect Code
16
• 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
17
Android Studio 上でレポートを確認できる
自動補正もサポート！

> Support Annotations
18
• http://tools.android.com/tech-docs/support-
annotations
• アノテーションを使って、パラメータの nonnull /
nullable や値範囲を宣言できる
• Android Studio 上で警告してくれる

> Crashlytics
19
• https://try.crashlytics.com/
• クラッシュレポート収集＆分析ツール
• ダッシュボードで、クラッシュの詳細を見ることがで
きる
• 時刻、端末情報、アプリバージョン、発生箇所、頻度…
• ProGuard をかけた apk でも、元のクラス名・関数名・
行数で確認できるのは嬉しい

> Crashlytics
20

> Infer
21
• http://fbinfer.com/
• Facebook 製、静的コード解析ツール
• 指摘内容
• CONTEXT_LEAK
• NULL_DEREFERENCE
• RESOURCE_LEAK
• 結果は CSV, Json で出力される
• Android Studio Inspect Code での内容と重複するとこ
ろもあるが、Inspect Code にない指摘もある

> QARK
22
• https://github.com/linkedin/qark
• LinkedIn 製、セキュリティチェックツール
• 指摘内容
• export されたコンポーネント
• WebView の設定
• Intent のセキュリティ
• 弱い暗号方式の利用
など…
• 結果は html で出力される

〜手動でのテスト〜

> 手動でのテストの観点
24
• アクティビティを保持しない
• さまざまな通信環境
• iOS 版や Web 版との比較
• 社内β版の配布
• リグレッションテスト

25

> アクティビティを保持しない
26
• 開発者向けオプションで設定
• この時に、
• 正しく画面遷移（行き来）できるか
• 最小化 → 復帰後の状態は適切か
• 各種変数の値
• 表示中のダイアログやメッセージが、
復帰後も正しく動作するか？
• これにより以下の確認になる
• on(Save/Restore)InstanceState 対応
• 適切な Fragment の扱い方

> 【コラム】適切な Fragment の扱い方
27
• デフォルトコンストラクタを使っているか？
• 外から渡したい値は、Bundle で渡しているか？

> 【コラム】適切な Fragment の扱い方
28
• setListener などしていないか？
• フラグメント再構築時に、setter は呼ばれない！
• ※onCreate は呼ばれます
• DialogFragment に setListener してると、再構築時に
Listener が set されず、意図した Listener の呼び出し
が行われない
• 詳しくは「Master of Fragment」を！
http://tatsu-zine.com/books/master-of-fragments

29

> さまざまな通信環境
30
• 安定した通信環境（当然なので解説省略）
• 機内モードの時
• 通信が遅いとき
• Wi-Fi に繋がっているが、インターネットに繋がって
いない場合

> 機内モードの時
31
• 端末で予め判定できる
（ConnectivityManager）
• 事前のエラー表示ができているか？
（そもそも画面遷移させないなど）
• 通信処理を行った場合、エラーハンドリングできてい
るか？
• キャッシュで表示できるモノだけでも表示する？
• 送信処理を受け付け、オンラインになったら送信？
（Facebook などはオフライン投稿機能がある）

> 通信が遅いとき
32
• 再現方法は色々
• 通信ライブラリと interceptor で可能かも？
• 低速 SIM
• Android エミュレータの設定など…
• UX は適切か？（ぐるぐる表示、進捗表示）
• 最小化や画面遷移後のコールバック処理は大丈夫か？
• Fragment#isAdded() で Activity に attach されているかチェック
• ViewPager 内の破棄された Fragment へのコールバックは忘れがち
• 可能であれば、前画面用の通信はキャンセル or 優先度を下げたい

> Wi-Fi にはつながってるが、ネットにつながってない
33
• 基本的には、前項の項目と同じ
• ※端末側での判定は難しい
• ただ、サーバからのレスポンスが帰ってこないので、
タイムアウトのエラーハンドリングが必要
• タイムアウトまで通信スレッドを占有するので、通信
キューが山積みになったり、いくつものスレッドを走
らせすぎる懸念

34

> iOS 版や Web 版との比較
35
• 同じ操作をしたり、同じデータを表示させて見比べる
• よくある差違
• 数値や日付の表示形式
• データのソート順
• 長い文字列の対応（末尾…、折り返し、スクロール）

> iOS 版や Web 版との比較
36
桁区切りの有無
数値の違い

37

> 社内β版の配布
38
• 社内ヘビーユーザにリリース前に配布
• 実データならではの問題が出る可能性がある
• 開発中に使っていない端末でも問題なく動作するか？
• なかなか気づかない操作の癖
• バックキー使い？ナビゲーションで戻る？
• キーボードの虫眼鏡ボタンで検索？
• 2点タップどっちから離すか
• A+B：A押下 → B押下 → どっちから離す？？
• ↑前々職でどっちから離すかで再現が別れる問題があった

39

> リグレッションテスト
40
• リリース直前に必ず実施
• 主要機能のデグレードがないことを確認
• やる）
• 主要機能のワンパス
• ログイン、名刺登録、編集、削除、ログアウトなど
• 過去の重大な不具合が再現しないこと
• やらない）
• 100文字制限のところに101文字入れたときのエラー
• アプリにサーバリリース前にも行っている

〜自動テスト〜

> Robotium を使った自動テスト
42
• ユニットテストではカバーしきれない
UI 操作を伴うテストを記述
• Robotium はアプリケーション内部オブジェクトを参
照できるため、柔軟なテストが記述できる
• DB のデータを参照して、ListView に表示されているか
• SharedPreference の値が意図通りかの確認
• ただし、デバッグ版でしか動作しない
（リリースバイナリでのテストは Appium を使う）

> テストコードの例
43
- ログイン処理
- メールアドレス入力欄を取得
- パスワード入力欄を取得
- メールアドレスを入力
- パスワードを入力
- ログインボタンを押す
テストライブラリをラッ
プして可読性確保！

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

> 自動テストの適用
45
• 前述のリグレッションテストには適用済み
• 主要画面の詳細なテストも記述中
• エラーメッセージ
• サインアップ時に送られるメールをパースして、サイン
アップ処理を行う（MailCatcher API を利用）
• Jacoco によるカバレッジ計測
• 2016/02時点で 59% をカバー
• ※テストでコードが実行されているからといって、安心
ではない。

> 自動テスト導入してみて
46
• デグレードがないことを容易に確認できる
• メンテはそこまで大変じゃない
• テストでしっかりカバーしていれば、大規模なリファ
クタリングも安心！
• これから、通信ライブラリ・カメラ API・デザインパーツの差し替
え・DB の置き換え？などが控えている
• モックを使わないので、サーバの動作確認にもなる

> 自動テストの詳細は
47
• DroidKaigi 2016 で！
https://droidkaigi.github.io/2016/

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

49
• 2/20 DroidKaigi 2016 Reject Conf で！
http://connpass.com/event/24264/

50
• 3/23 Android Testing Bootcamp #1 でも！？
http://connpass.com/event/26911/
※抽選がまだ

> 調査中の Device Farm の内容ですが…
51
• 3/12 JAWS DAYS 2016 でも！
http://jawsdays2016.jaws-ug.jp/speaker/409
http://jawsdays2016.jaws-ug.jp/

効果

> 効果
53
• iOS / Android とも、前任者のコードベースの事情を
十分にカバーする品質担保ができている。
• 開発部内でサービスインシデントは数十件/年あるが、アプリ
においては 0件/年と部内トップレベル
• 新しい OS や端末が出た場合のテストも容易
• テスト工数の削減
• コードレビュー時にこれらの観点でも見るので、チー
ムメンバーの品質意識・対応の底上げになる

まとめ

> まとめ
55
• 使えるツールは使おう！
• 色んな環境でテストしよう！
• テストの自動化に取り組もう！

質疑応答

> こちらもどうぞ
57
• 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

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

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

Similaire à アプリの不具合を少なくするために (20)

Plus de 健一辰濱

Plus de 健一辰濱 (20)