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

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

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. ライブ配信アプリを例に 考えてみる • アプリ起動時に表示されるホーム画面 • 現在ライブ配信中のユーザーがリストで表 示されている ◦ 下にスクロールしてページング ◦

    リスト内のアイテムを押すとそのユー ザーの配信に移動できる ◦ プリセットのフィルターが用意されて おり、▼から切り替えができる • 画面下部のタブから主要機能の画面に移動 • タブの右上のボタンから自身の配信を開始
  2. スコープの種類 Unit test Unit test Unit test Integration test End-to-end

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

    test(E2E test) Unit test 厳密に線を引く必要はなく、 スコープに種類があることが わかれば👌
  4. テストしてみよう • アプリ起動時に表示されるホーム画面 • 現在ライブ配信中のユーザーがリストで表 示されている ◦ 下にスクロールしてページング ◦ リスト内のアイテムを押すとそのユー

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

    ザーの配信に移動できる ◦ プリセットのフィルターが用意されて おり、▼から切り替えができる • 画面下部のタブから主要機能の画面に移動 • タブの右上のボタンから自身の配信を開始 初期表示が6件 スクロールすると追加で表示される
  6. • ユーザーを8件以上作成する ◦ 初期表示6ユーザー ◦ ページングで追加される1ユーザー ◦ ホーム画面を表示するユーザー • 7ユーザー以上で配信を開始する

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

    ◦ ※全員がフィルターに含まれるように する必要あり • 配信を行っていないユーザーでホーム画面 を起動する • 6ユーザー表示されることを確認して、下に スクロール 検証手順 ちょっと大変そう....
  8. Unit testだったら どんなテストができそう? • ページングのロジックの確認 ◦ 現在保持しているリストの 次のページを取得する ◦ 新たに取得したアイテムを保

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

    持しているリストに追加する ◦ ページング終了の判定 • ページングを開始してから 読み込み中→読み込み完了 までの状態の変化の確認 API通信している箇所をテストダブルに置き換 えて、テストデータを返すようにする 実際にユーザーを作成したり、別端末で配信を 開始しなくてもよくなる
  10. Unit testの場合のトレードオフ 実行時間 • 速い ◦ UIの操作やAPI通信が含まれないため高速に実行できる 忠実度 • 低い

    ◦ 画面やAPIとの連携は含まれない 信頼性 • 高い ◦ 独立性が高く実行ごとに変化する要素が少ないため壊れに くい
  11. Integration testの場合のトレードオフ 実行時間 • やや遅い ◦ アプリと画面の起動、UIの操作が含まれるためやや遅い 忠実度 • そこそこ高い

    ◦ UI操作とページング処理が確認できる 信頼性 • 中くらい ◦ API通信がない分独立性が高いが、端末の状態や同じ画面内 の別の処理の影響を受ける可能性はある
  12. End-to-end testだったら どんなテストができそう? • Integration testで確認した 範囲にプラスして、APIとの 疎通確認 ◦ API通信の仕組みの実装

    ◦ リクエスト・レスポンス の誤り ◦ API自体が動いているか • ライブ配信しているユーザー がホームに表示されているか 確認
  13. End-to-end testの場合のトレードオフ 実行時間 • 遅い ◦ アプリと画面の起動 + UIの操作 +

    API通信 ◦ 検証したい項目に辿りつくまでの準備の時間 忠実度 • 高い ◦ ユーザーがアプリを触るのとほぼ同じ状態で検証できる 信頼性 • 低い ◦ 端末の状態と同じ画面内の別の処理以外にも、通信状態や APIサーバーの状態の影響をうける
  14. 検証したいパスに到達するための難しさ 関数A 関数B 関数C 関数D 処理の分岐 関数E 関数F 関数G 関数H

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

    関数H スコープを広げると通りえるパ ターンが膨れ上がる 実行時間も長いため、確認できる ケースが限られてくる
  16. • UIが絡むことで発生する問題が多い ◦ 特定のUIパターンの表示・特定のUI操作をトリガーに発生するもの ◦ テストのスコープを広げないと見つかりづらい • アプリをビルドするのに時間がかかる ◦ UIの動作確認したいのに、それをするにはアプリをビルドしないと

    いけなくて時間がかかるというジレンマ モバイルアプリのテストをやっていて難しいと感じること このハードルを乗り越えるために様々なチームで様々な工夫が行われている どんな工夫している事例があるのかを紹介していきます(Android多め)
  17. 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/
  18. 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