Upgrade to Pro — share decks privately, control downloads, hide ads and more …

モバイルアプリテスト入門 / Getting Started with Mobile App Testing

tkmnzm
March 02, 2022

モバイルアプリテスト入門 / Getting Started with Mobile App Testing

学生エンジニア団体VolareさんとDeNAの合同イベント「ソフトウェアテスト手法を学ぼう」の発表資料です。
https://volare.connpass.com/event/236403/

tkmnzm

March 02, 2022
Tweet

More Decks by tkmnzm

Other Decks in Technology

Transcript

  1. モバイルアプリテスト入門
    Nozomi Takuma
    2022-03-02ソフトウェアテストについて学ぼう

    View Slide

  2. 自己紹介
    ● Nozomi Takuma
    ● DeNA SWETグループ
    ○ 兼務: Pococha事業部システム部
    ● Androidとテストが好き

    View Slide

  3. 今日の発表のゴール

    View Slide

  4. 今日の発表のゴール
    ● モバイルアプリのテスト経験が少ない方に、テストを
    設計する上で考えるべきポイントを知ってもらう
    ● モバイルアプリのテストにおける難しさと工夫について
    知ってもらう
    ● モバイルアプリのテストをやるべきタイミングが来たと
    きに参考になれば嬉しい

    View Slide

  5. アジェンダ
    ● モバイルアプリのテストの基本方針
    ○ テストのスコープ
    ○ テスト戦略
    ● モバイルアプリのテストのハードルを下げるため工夫

    View Slide

  6. 説明に使うサンプルアプリ

    View Slide

  7. ライブ配信アプリを例に
    考えてみる
    ● アプリ起動時に表示されるホーム画面
    ● 現在ライブ配信中のユーザーがリストで表
    示されている
    ○ 下にスクロールしてページング
    ○ リスト内のアイテムを押すとそのユー
    ザーの配信に移動できる
    ○ プリセットのフィルターが用意されて
    おり、▼から切り替えができる
    ● 画面下部のタブから主要機能の画面に移動
    ● タブの右上のボタンから自身の配信を開始

    View Slide

  8. アプリの内部構成

    View Slide

  9. 例:ホーム画面を起動する

    View Slide

  10. モバイルアプリのテストの基本方針

    View Slide

  11. モバイルアプリのテストって何をするの?

    端末にアプリを入れて、それぞれの機能が問題ないか
    操作して確認すればいいかな?

    View Slide

  12. スコープの種類
    ● Unit
    ● Integration
    ● End-to-end

    View Slide

  13. スコープの種類
    Unit test Unit test Unit test
    Integration test
    End-to-end test(E2E test)
    ● Unit
    ● Integration
    ● End-to-end
    Unit test

    View Slide

  14. スコープの種類
    Unit test Unit test Unit test
    クラス・メソッド・UIパーツ単位等
    小さいスコープで正しく動作するか
    を検証する
    Unit test

    View Slide

  15. スコープの種類
    Integration test
    複数のユニットを結合した状態で
    正しく動作するかを検証をする

    View Slide

  16. スコープの種類
    End-to-end test(E2E test)
    アプリ全体を統合した状態で検証する
    アプリのフローやAPI含むアプリ外との
    連携が正しく動作するか等、広いスコー
    プで検証する

    View Slide

  17. スコープの種類
    Unit test Unit test Unit test
    Integration test
    End-to-end test(E2E test)
    Unit test
    厳密に線を引く必要はなく、
    スコープに種類があることが
    わかれば👌

    View Slide

  18. テストしてみよう
    ● アプリ起動時に表示されるホーム画面
    ● 現在ライブ配信中のユーザーがリストで表
    示されている
    ○ 下にスクロールしてページング
    ○ リスト内のアイテムを押すとそのユー
    ザーの配信に移動できる
    ○ プリセットのフィルターが用意されて
    おり、▼から切り替えができる
    ● 画面下部のタブから主要機能の画面に移動
    ● タブの右上のボタンから自身の配信を開始

    View Slide

  19. テストしてみよう
    ● アプリ起動時に表示されるホーム画面
    ● 現在ライブ配信中のユーザーがリストで表
    示されている
    ○ 下にスクロールしてページング
    ○ リスト内のアイテムを押すとそのユー
    ザーの配信に移動できる
    ○ プリセットのフィルターが用意されて
    おり、▼から切り替えができる
    ● 画面下部のタブから主要機能の画面に移動
    ● タブの右上のボタンから自身の配信を開始
    初期表示が6件
    スクロールすると追加で表示される

    View Slide

  20. ● ユーザーを8件以上作成する
    ○ 初期表示6ユーザー
    ○ ページングで追加される1ユーザー
    ○ ホーム画面を表示するユーザー
    ● 7ユーザー以上で配信を開始する
    ○ ※全員がフィルターに含まれるように
    する必要あり
    ● 配信を行っていないユーザーでホーム画面
    を起動する
    ● 6ユーザー表示されることを確認して、下に
    スクロール
    検証手順

    View Slide

  21. ● ユーザーを8件以上作成する
    ○ 初期表示6ユーザー
    ○ ページングで追加される1ユーザー
    ○ ホーム画面を表示するユーザー
    ● 7ユーザー以上で配信を開始する
    ○ ※全員がフィルターに含まれるように
    する必要あり
    ● 配信を行っていないユーザーでホーム画面
    を起動する
    ● 6ユーザー表示されることを確認して、下に
    スクロール
    検証手順
    ちょっと大変そう....

    View Slide

  22. モバイルアプリのテスト戦略
    ● テストのスコープによって次のパラメーターが変化する
    ○ 実行時間
    ○ 忠実度(実環境・実アプリにどこまで近いか)
    ○ 信頼性・安定性
    ● 基本的にはトレードオフになっているので、バランスを取りながら
    手段を選択する

    View Slide

  23. Unit testだったら
    どんなテストができそう?
    ● ページングのロジックの確認
    ○ 現在保持しているリストの
    次のページを取得する
    ○ 新たに取得したアイテムを保
    持しているリストに追加する
    ○ ページング終了の判定
    ● ページングを開始してから
    読み込み中→読み込み完了
    までの状態の変化の確認

    View Slide

  24. Unit testだったら
    どんなテストができそう?
    ● ページングのロジックの確認
    ○ 現在保持しているリストの
    次のページを取得する
    ○ 新たに取得したアイテムを保
    持しているリストに追加する
    ○ ページング終了の判定
    ● ページングを開始してから
    読み込み中→読み込み完了
    までの状態の変化の確認
    API通信している箇所をテストダブルに置き換
    えて、テストデータを返すようにする
    実際にユーザーを作成したり、別端末で配信を
    開始しなくてもよくなる

    View Slide

  25. テストダブル
    ● テストしたい対象が依存しているコンポーネントを本物そっくりに振
    る舞う代役(ダブル)と差し替えることで、自分の期待する挙動や値の
    返却をできるようにする
    ● SWET blog:「テスタビリティの高いGoのAPIサーバを開発しよう」と
    いうハンズオンを公開しました
    ○ https://swet.dena.com/entry/2021/12/07/123000

    View Slide

  26. Unit testの場合のトレードオフ
    実行時間
    ● 速い
    ○ UIの操作やAPI通信が含まれないため高速に実行できる
    忠実度
    ● 低い
    ○ 画面やAPIとの連携は含まれない
    信頼性
    ● 高い
    ○ 独立性が高く実行ごとに変化する要素が少ないため壊れに
    くい

    View Slide

  27. Integration testだったら
    どんなテストができそう?
    ● Unit testで確認した範囲に
    プラスしてリストの操作の確認
    ● 7件と言わず大量にデータを用意
    してスクロールしつづけると
    いったことも簡単にできそう
    テストデータを返すように
    API通信部分を置き換える

    View Slide

  28. Integration testの場合のトレードオフ
    実行時間
    ● やや遅い
    ○ アプリと画面の起動、UIの操作が含まれるためやや遅い
    忠実度
    ● そこそこ高い
    ○ UI操作とページング処理が確認できる
    信頼性
    ● 中くらい
    ○ API通信がない分独立性が高いが、端末の状態や同じ画面内
    の別の処理の影響を受ける可能性はある

    View Slide

  29. End-to-end testだったら
    どんなテストができそう?
    ● Integration testで確認した
    範囲にプラスして、APIとの
    疎通確認
    ○ API通信の仕組みの実装
    ○ リクエスト・レスポンス
    の誤り
    ○ API自体が動いているか
    ● ライブ配信しているユーザー
    がホームに表示されているか
    確認

    View Slide

  30. End-to-end testの場合のトレードオフ
    実行時間
    ● 遅い
    ○ アプリと画面の起動 + UIの操作 + API通信
    ○ 検証したい項目に辿りつくまでの準備の時間
    忠実度
    ● 高い
    ○ ユーザーがアプリを触るのとほぼ同じ状態で検証できる
    信頼性
    ● 低い
    ○ 端末の状態と同じ画面内の別の処理以外にも、通信状態や
    APIサーバーの状態の影響をうける

    View Slide

  31. 表にするとこうなった
    実行速度 忠実度 信頼性
    Unit 速い 低い 高い
    Integration やや遅い そこそこ高い 中くらい
    End-to-end 遅い 高い 低い

    View Slide

  32. トレードオフ以外に考慮するべきこと
    ● 確認したいことがテストできているか?
    ● テストの難易度
    ○ テストを実装する難しさ
    ○ 検証したいパスに到達するための難しさ
    ● テスト実行以外の時間

    View Slide

  33. 確認したいことがテストできているか?
    ● 何を検証したいかによって、結合する範囲や手段は変わってくる
    ○ 例えば、実ユーザーが触るときの使用感はEnd-to-endと手動の組み
    合わせでないと確認ができない
    ○ 最小単位でテストすることにこだわりすぎた結果、スタブが正しい
    値を返すことのテストになってしまっている、みたいな場合もある
    ● テストの目的を忘れないことはとても大事で、それにあわせて
    スコープを決定する

    View Slide

  34. テストを実装する難しさ
    ● テスト実装の難易度が選択する手段に影響する場合がある
    ○ テストしたい内容によっては自動テストだと難しく、手動での検証
    を選択したほうがよい場合がある
    ○ Unit testは実装が簡単と考えられるが、テスタビリティが低い設計
    の場合は、大きいスコープのテストよりも難易度が上がる
    ○ テストに必要なデータの準備コストは、スコープの大きさと比例し
    て難しくなるとは限らない

    View Slide

  35. テスタビリティ
    ● テスタビリティが高い設計は、戦略通りのテストスコープの実現やス
    コープの変更に対応できるようになっている
    ● SWET blog:「テスタビリティの高いGoのAPIサーバを開発しよう」と
    いうハンズオンを公開しました(2回目の宣伝)
    ○ https://swet.dena.com/entry/2021/12/07/123000

    View Slide

  36. 検証したいパスに到達するための難しさ
    ● 単体でみると数ケース見ればよくても、結合する範囲が広がると通り
    得るパスの数が膨れ上がっていき、網羅するのが難しくなる
    ● 結合範囲が広がると、特定のケースに到達するにはどうしたらいいか
    を把握することが難しくなる
    ● テストのスコープによっては、検証したいパスに到達するのが難しい
    場合がある
    ○ 例えばAPIから返却されうるエラーパターンの確認

    View Slide

  37. 検証したいパスに到達するための難しさ
    関数A
    関数B
    関数C
    関数D
    処理の分岐
    関数E
    関数F
    関数G
    関数H
    関数H

    View Slide

  38. 検証したいパスに到達するための難しさ
    関数A
    関数B
    関数C
    関数D
    処理の分岐
    関数E
    関数F
    関数G
    関数H
    関数H
    ユニットテストの場合
    関数のパターンをみればいい
    パターンを網羅してテストケースが増えても
    実行時間が短いためスケールしやすい

    View Slide

  39. 検証したいパスに到達するための難しさ
    関数A
    関数B
    関数C
    関数D
    処理の分岐
    関数E
    関数F
    関数G
    関数H
    関数H
    スコープを広げると通りえるパ
    ターンが膨れ上がる
    実行時間も長いため、確認できる
    ケースが限られてくる

    View Slide

  40. 検証したいパスに到達するための難しさ
    関数A
    関数B
    関数C
    関数D
    処理の分岐
    関数E
    関数F
    関数G
    関数H
    関数H
    ここを検証したい

    View Slide

  41. 検証したいパスに到達するための難しさ
    関数A
    関数B
    関数C
    関数D
    処理の分岐
    関数E
    関数F
    関数G
    関数H
    関数H
    ユニットテストの場合
    関数Eに着目すればよい

    View Slide

  42. 検証したいパスに到達するための難しさ
    関数A
    関数B
    関数C
    関数D
    処理の分岐
    関数E
    関数F
    関数G
    関数H
    関数H
    スコープを広げると
    ここの分岐も考慮する必要がある

    View Slide

  43. テスト実行以外の時間
    ● スコープの小さいテストは時間の面で優位
    ○ 完全に実装が終わっていなくても一部を切り出してテストでき、
    動作確認がはじめられるまでの時間が短い
    ○ プロジェクトを分割することでテストしたい対象のみビルドをする
    といったことが可能になり、ビルド時間の短縮も見込める
    ● 時間が短いことは、テスト活動を継続していく上でとても大事
    ○ Developer Experience(開発体験)に直結する

    View Slide

  44. モバイルアプリのテスト戦略
    ● スコープの異なるテストをバランスよく選択する
    ○ スコープが大きいテストだけだと実行速度や信頼性が課題になり、
    スケールしない・メンテナンスが難しいといった問題に直面する
    ○ スコープが小さいテストだけだとUI/操作性/結合時といった問題を
    取りこぼしてしまう
    ● スコープ以外にも、確認したいことがテストできているか・テストの
    難易度・実行までの時間といったポイントを考慮する

    View Slide

  45. モバイルアプリのテストのハードルを
    下げるための様々な工夫

    View Slide

  46. モバイルアプリのテストをやっていて難しいと感じること
    ● UIが絡むことで発生する問題が多い
    ○ 特定のUIパターンの表示・特定のUI操作をトリガーに発生するもの
    ○ テストのスコープを広げないと見つかりづらい
    ● アプリをビルドするのに時間がかかる
    ○ UIの動作確認したいのに、それをするにはアプリをビルドしないと
    いけなくて時間がかかるというジレンマ

    View Slide

  47. ● UIが絡むことで発生する問題が多い
    ○ 特定のUIパターンの表示・特定のUI操作をトリガーに発生するもの
    ○ テストのスコープを広げないと見つかりづらい
    ● アプリをビルドするのに時間がかかる
    ○ UIの動作確認したいのに、それをするにはアプリをビルドしないと
    いけなくて時間がかかるというジレンマ
    モバイルアプリのテストをやっていて難しいと感じること
    このハードルを乗り越えるために様々なチームで様々な工夫が行われている
    どんな工夫している事例があるのかを紹介していきます(Android多め)

    View Slide

  48. ミニアプリ化
    ● アプリを機能ごとに分割して起動できるようにする
    ● アプリ全体をビルドするよりもビルド時間が短縮され、動作確認にか
    かるコストと機能に行き着くまでのコストを下げる
    ● クックパッド開発者ブログ: 大規模なiOSアプリの画面開発を効率化
    するために動作確認用ミニアプリを構築する
    ○ https://techlife.cookpad.com/entry/2020/08/05/090000

    View Slide

  49. Jetpack composeやSwift UIのプレビュー機能
    ● モバイルアプリにおいて新たに登場した宣言的UIフレームワークは、
    既存のViewシステムにはない高度なプレビュー機能が実装されている
    ● UIのバリエーションを目視で確認する時間の削減が見込める
    ● DroidKaigi 2021: Let's Preview! Jetpack Compose
    ○ https://speakerdeck.com/mochico/title-lets-preview-jetpack-compose

    View Slide

  50. UIカタログ
    ● UIコンポーネントを一覧化し、各コンポーネントの表示パターンを
    確認できるようにする
    ● UIのバリエーションを目視で確認する時間の削減が見込める
    ● CyberAgent Developers Blog: Android向けUI Catalog Library –
    Katalogを公開しました
    ○ https://developers.cyberagent.co.jp/blog/archives/33059/

    View Slide

  51. Visual regression test
    ● コードの変更前と変更後のアプリUIをキャプチャした画像を比較して
    差分を検知する
    ● reg-suitといったツールを使うことで、目視では気が付きづらいよう
    な差分も検知できる
    ● プレビュー機能やUIカタログとの親和性が高い
    ● CATS PRODUCTIVITY BLOG: Android のアプリ開発でも Visual
    Regression Testing を始めましょう
    ○ https://cats-234205.web.app/2020/visual-regression-testing-with-android/

    View Slide

  52. UI操作の自動化
    ● The Airbnb Tech Blog: Better Android Testing at Airbnb
    — Part 3: Interaction Testing
    ○ 画面上のパーツを走査的にクリックしていき、その際の内部の振る舞い
    (API通信・画面遷移等)をjsonに記録し、差分を比較する
    ○ UI操作時に意図せぬ変更がされていないかを確認する
    ■ https://medium.com/airbnb-engineering/better-android-testing-at-airb
    nb-1d1e91e489b4

    View Slide

  53. End-to-end test自動化のハードルを下げる
    ● ノーコードでのテスト実装をサポートする機能を提供することで、
    より多くの人がEnd-to-end test実装に関われるようになる
    ○ Magic pod
    ○ Autify for Mobile
    ■ Mot Lab: デリバリーアプリ「GO Dine」でのテスト自動化の取り組み
    ● https://lab.mo-t.com/blog/godine-qa

    View Slide

  54. モバイルアプリのテストの今後
    ● モバイルアプリのテストはまだまだ伸びしろがある
    ○ もっと使いやすくできる
    ○ もっと多くの人に使ってもらえる
    ○ もっと多くのことができるようになる
    ● DeNAのSWETチームでは、そういったことを模索している

    View Slide

  55. まとめ

    View Slide

  56. まとめ
    ● モバイルアプリのテストはトレードオフになっているパラメータのバ
    ランスを取りながら戦略を立てる必要がある
    ● UIが絡む動作確認は難易度が高く、ハードルを下げるために様々な
    工夫がされている
    ● モバイルアプリのテストはまだまだ伸びしろがあるので、発展に貢献
    していきたい

    View Slide

  57. ご清聴ありがとうございました!

    View Slide