1 of 24

テストは人間にやらせろ！�~ テスト配信プラットフォームを使おう ~

Kouta Imanaka

​

2013/12/10�Android Test Casual Talks #1

2 of 24

自己紹介

今中幸太( @pside )

    • Androidアプリ開発者
    • そろそろAngularJSやる
  • http://about.me/keima
  • できること
    • Obj-C
    • Chef
    • PHP
    • ・・・

3 of 24

テストケース書くの大変！

  • 時間ない！
  • 人が足りない！
  • お金がない！

​

  • テスト書く時間 ＜＜＜＜＜ サービスの改善

4 of 24

“リソース（人、時間）が足りません”

“ユニットテストを導入してはいけません。”

​

​

引用：ユニットテスト改善ガイド ｜ Developers.IO�http://dev.classmethod.jp/testing/unittesting/working-effectively-with-unit-testing/

5 of 24

それでも品質を保たなければならぬ

  • 信頼性の高いライブラリを使う
  • ちゃんとした設計を行う
  • 細かい粒度で機能開発する
  • 見つかったバグはすぐに潰す
  • 安定している既存iOSアプリの実装をパクる
  • 安定している既存iOSアプリの実装をパクる
  • 安定している既存iOSアプリの実装をパクる

→ それでもアプリはFATAL Exceptionを吐く！どうすれば！！

6 of 24

人間にテストをさせる

  • テストをパスする ≠ バグがない
    • テストをパスした部分に起因するバグが起きないだけ
    • 広範囲のテストを書くには時間と人手が不足する
  • 開発者の考えが及ばない部分ではバグを取り逃す

人間にテストをさせるという発想

出来るだけ手間をかけずに�効果的・広範囲なテストをするには・・・？

7 of 24

テスト配信プラットフォームのススメ

  • テスト用アプリを配信するプラットフォーム
    • エラートレース(クラッシュレポート)
    • 版(リビジョン)管理
    • アプリのネットワーク配信(Over-The-Air Update)
    • チームに属するユーザーに配信
      • 承認タイプ(承認したユーザーにだけ配信)
      • 公募タイプ(基本だれでもBeta Testingに参加できる)

8 of 24

種類

公式

  • Google Play

​

国内

  • DeployGate

海外

  • TestFlight
  • Vessel.io
  • BetaGlide
  • AppLover
  • The Beta Family

下線部のサービスについて、実際に使ってみた。

9 of 24

Google Play

公式ストアの仕組みを使ってアプリのテスト配信を行う

  • Googleグループ or Google+のサークルに�所属するユーザーにだけ配信
  • 公式のエコシステムに内包されているので�比較的とっつきやすい
  • Playストア経由での配信

10 of 24

Google Play

利点

  • 公式の枠組みで使える
    • 通知
    • 自動更新
    • クラッシュレポート
  • 追加のSDK類が�一切必要ない

欠点

  • versionCodeの重複ダメ
  • debugKeyでのsignダメ
  • Bouncer仕事しろ(反映遅い)
  • APIがない
    • 自動化するとなると�骨折れそう

結論：成熟したアプリで有用。成長段階のアプリだとフットワーク重い。�一般ユーザーを巻き込んだテストをするならベスト。

11 of 24

TestFlight

元祖ベータテスト配信プラットフォーム

  • 現在でもiOS方面で高い人気を誇る
  • 2013年初めにAndroid対応したっぽい
  • 今現在は弊社アプリのデバッグ用途で使用中
  • ネイティブ(?)アプリ経由でのアプリ配信

12 of 24

クラッシュレポートの自動取得

13 of 24

TestFlight

利点

  • 無料でユーザを限定した�テストができる
  • versionCodeの重複OK
  • SDK組み込むと�クラッシュログ取れる
  • APIでアプリ自動公開

欠点

  • アプリがイケてない
  • Push通知じゃない
  • SDK使うと�余計な権限追加が要る
    • INTERNET
    • ACCESS_NETWORK_STATE

結論：プライベートなテスト環境を構築するには良い。�iOSアプリが先行している現場では導入がスムーズに進みます。

14 of 24

Deploygate

mixiが提供している国産テスト配信プラットフォーム

  • 日本語を完全サポート
  • 細部にまで行き届いた作り込みが伺える
    • 配布ページ、QRコードでインストール、Analytics連携etc
    • Bootcamp、開発者からのメールなどのワクワク感多い
  • 無料版は一部の機能に制限あり
  • アプリに組み込むとき識別IDをセットする必要がない
  • ネイティブアプリ経由でのアプリ配信(Push通知アリ)

15 of 24

アップデート通知はプッシュ通知される

16 of 24

DeployGate SDKを組み込むことで�テストユーザの状況やクラッシュレポートを取得できる

17 of 24

リモートLogCatでクラッシュ時の状況を詳細に取得

18 of 24

DeployGate

利点

  • アプリ配信ページ
  • リモートLogCat
  • アプリに追加の権限を�書き足さなくて良い
  • Gradleでビルド毎配信

欠点

  • クローズドなアプリ配信は無料プランでは不可�(リンクを知っている人だけDLできるオプション)

結論：配信者を限定する必要が無ければ一番のオススメ。�開発初期に組み込んでおけば色々捗りそう。リモートLogCatは夢のようだ。

19 of 24

Vessel (ex- Zubhium)

実はそれなりに古参(2012年2月-)のプラットフォーム

  • A/Bテストに特化している
  • 管理画面が非常にリッチ。使っていて楽しい。
    • むしろプロジェクトマネージャ向けに作ってあるのかも
  • メールでのテストアプリ配信
    • リンクを押すとS3にあるapkを入手させる仕組み

20 of 24

A/B テスト と 管理画面 ( https://www.vessel.io )

21 of 24

Vessel

利点

  • A/Bテストが試せる
  • Jenkinsプラグイン有
  • 管理画面で色々見れる

欠点

  • SDK組み込むと�強制終了ダイアログが�表示されなくなる
  • アニメーションがくどい�（人によるかも？）
  • 追加の権限

結論：A/Bテストのプラットフォームとして非常に良いのでは。�メールベースでのアプリ配信というのもシンプルで良い

22 of 24

WebAPIでCI

  1. アプリ開発
  2. git等にコミット
  3. git hookなどを起点にJenkinsで自動テスト開始
  4. Passしたらサーバーにapkファイル投げる
  5. ユーザーがテストを始める
  6. フィードバックを得る

今回紹介したプラットフォームで�WebAPI経由でのアップロードに�対応しているもの

  • Deploygate
  • TestFlight
  • Vessel

23 of 24

まとめ

  • テストの自動化する余力がないのであれば、�手動テストのプロセスを簡素化する方向の提案。
  • テスト配信プラットフォームについて紹介。
    • プラットフォームによって様々な特徴がある
    • アプリの形式・規模に応じて使い分けていきたい
  • 余力が出てJenkinsを導入した時でも�テスト配信をプロセスに組み込むことが出来る。

24 of 24

おわり

SampleApp SourceCode: https://github.com/keima/androidtest-1