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

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

Transcript

1. モバイルアプリテスト入門 Nozomi Takuma 2022-03-02ソフトウェアテストについて学ぼう
2. 自己紹介 • Nozomi Takuma • DeNA SWETグループ ◦ 兼務: Pococha事業部システム部 • Androidとテストが好き
3. 今日の発表のゴール
4. 今日の発表のゴール • モバイルアプリのテスト経験が少ない方に、テストを 設計する上で考えるべきポイントを知ってもらう • モバイルアプリのテストにおける難しさと工夫について 知ってもらう • モバイルアプリのテストをやるべきタイミングが来たと きに参考になれば嬉しい
5. アジェンダ • モバイルアプリのテストの基本方針 ◦ テストのスコープ ◦ テスト戦略 • モバイルアプリのテストのハードルを下げるため工夫
6. 説明に使うサンプルアプリ
7. ライブ配信アプリを例に 考えてみる • アプリ起動時に表示されるホーム画面 • 現在ライブ配信中のユーザーがリストで表 示されている ◦ 下にスクロールしてページング ◦ リスト内のアイテムを押すとそのユー ザーの配信に移動できる ◦ プリセットのフィルターが用意されて おり、▼から切り替えができる • 画面下部のタブから主要機能の画面に移動 • タブの右上のボタンから自身の配信を開始
8. アプリの内部構成
9. 例:ホーム画面を起動する
10. モバイルアプリのテストの基本方針
11. モバイルアプリのテストって何をするの？ 端末にアプリを入れて、それぞれの機能が問題ないか 操作して確認すればいいかな？
12. スコープの種類 • Unit • Integration • End-to-end
13. スコープの種類 Unit test Unit test Unit test Integration test End-to-end test(E2E test) • Unit • Integration • End-to-end Unit test
14. スコープの種類 Unit test Unit test Unit test クラス・メソッド・UIパーツ単位等 小さいスコープで正しく動作するか を検証する Unit test
15. スコープの種類 Integration test 複数のユニットを結合した状態で 正しく動作するかを検証をする
16. スコープの種類 End-to-end test(E2E test) アプリ全体を統合した状態で検証する アプリのフローやAPI含むアプリ外との 連携が正しく動作するか等、広いスコー プで検証する
17. スコープの種類 Unit test Unit test Unit test Integration test End-to-end test(E2E test) Unit test 厳密に線を引く必要はなく、 スコープに種類があることが わかれば👌
18. テストしてみよう • アプリ起動時に表示されるホーム画面 • 現在ライブ配信中のユーザーがリストで表 示されている ◦ 下にスクロールしてページング ◦ リスト内のアイテムを押すとそのユー ザーの配信に移動できる ◦ プリセットのフィルターが用意されて おり、▼から切り替えができる • 画面下部のタブから主要機能の画面に移動 • タブの右上のボタンから自身の配信を開始
19. テストしてみよう • アプリ起動時に表示されるホーム画面 • 現在ライブ配信中のユーザーがリストで表 示されている ◦ 下にスクロールしてページング ◦ リスト内のアイテムを押すとそのユー ザーの配信に移動できる ◦ プリセットのフィルターが用意されて おり、▼から切り替えができる • 画面下部のタブから主要機能の画面に移動 • タブの右上のボタンから自身の配信を開始 初期表示が6件 スクロールすると追加で表示される
20. • ユーザーを8件以上作成する ◦ 初期表示6ユーザー ◦ ページングで追加される1ユーザー ◦ ホーム画面を表示するユーザー • 7ユーザー以上で配信を開始する ◦ ※全員がフィルターに含まれるように する必要あり • 配信を行っていないユーザーでホーム画面 を起動する • 6ユーザー表示されることを確認して、下に スクロール 検証手順
21. • ユーザーを8件以上作成する ◦ 初期表示6ユーザー ◦ ページングで追加される1ユーザー ◦ ホーム画面を表示するユーザー • 7ユーザー以上で配信を開始する ◦ ※全員がフィルターに含まれるように する必要あり • 配信を行っていないユーザーでホーム画面 を起動する • 6ユーザー表示されることを確認して、下に スクロール 検証手順 ちょっと大変そう....
22. モバイルアプリのテスト戦略 • テストのスコープによって次のパラメーターが変化する ◦ 実行時間 ◦ 忠実度(実環境・実アプリにどこまで近いか) ◦ 信頼性・安定性 • 基本的にはトレードオフになっているので、バランスを取りながら 手段を選択する
23. Unit testだったら どんなテストができそう？ • ページングのロジックの確認 ◦ 現在保持しているリストの 次のページを取得する ◦ 新たに取得したアイテムを保 持しているリストに追加する ◦ ページング終了の判定 • ページングを開始してから 読み込み中→読み込み完了 までの状態の変化の確認
24. Unit testだったら どんなテストができそう？ • ページングのロジックの確認 ◦ 現在保持しているリストの 次のページを取得する ◦ 新たに取得したアイテムを保 持しているリストに追加する ◦ ページング終了の判定 • ページングを開始してから 読み込み中→読み込み完了 までの状態の変化の確認 API通信している箇所をテストダブルに置き換 えて、テストデータを返すようにする 実際にユーザーを作成したり、別端末で配信を 開始しなくてもよくなる
25. テストダブル • テストしたい対象が依存しているコンポーネントを本物そっくりに振 る舞う代役(ダブル)と差し替えることで、自分の期待する挙動や値の 返却をできるようにする • SWET blog:「テスタビリティの高いGoのAPIサーバを開発しよう」と いうハンズオンを公開しました ◦ https://swet.dena.com/entry/2021/12/07/123000
26. Unit testの場合のトレードオフ 実行時間 • 速い ◦ UIの操作やAPI通信が含まれないため高速に実行できる 忠実度 • 低い ◦ 画面やAPIとの連携は含まれない 信頼性 • 高い ◦ 独立性が高く実行ごとに変化する要素が少ないため壊れに くい
27. Integration testだったら どんなテストができそう？ • Unit testで確認した範囲に プラスしてリストの操作の確認 • 7件と言わず大量にデータを用意 してスクロールしつづけると いったことも簡単にできそう テストデータを返すように API通信部分を置き換える
28. Integration testの場合のトレードオフ 実行時間 • やや遅い ◦ アプリと画面の起動、UIの操作が含まれるためやや遅い 忠実度 • そこそこ高い ◦ UI操作とページング処理が確認できる 信頼性 • 中くらい ◦ API通信がない分独立性が高いが、端末の状態や同じ画面内 の別の処理の影響を受ける可能性はある
29. End-to-end testだったら どんなテストができそう？ • Integration testで確認した 範囲にプラスして、APIとの 疎通確認 ◦ API通信の仕組みの実装 ◦ リクエスト・レスポンス の誤り ◦ API自体が動いているか • ライブ配信しているユーザー がホームに表示されているか 確認
30. End-to-end testの場合のトレードオフ 実行時間 • 遅い ◦ アプリと画面の起動 + UIの操作 + API通信 ◦ 検証したい項目に辿りつくまでの準備の時間 忠実度 • 高い ◦ ユーザーがアプリを触るのとほぼ同じ状態で検証できる 信頼性 • 低い ◦ 端末の状態と同じ画面内の別の処理以外にも、通信状態や APIサーバーの状態の影響をうける
31. 表にするとこうなった 実行速度 忠実度 信頼性 Unit 速い 低い 高い Integration やや遅い そこそこ高い 中くらい End-to-end 遅い 高い 低い
32. トレードオフ以外に考慮するべきこと • 確認したいことがテストできているか？ • テストの難易度 ◦ テストを実装する難しさ ◦ 検証したいパスに到達するための難しさ • テスト実行以外の時間
33. 確認したいことがテストできているか？ • 何を検証したいかによって、結合する範囲や手段は変わってくる ◦ 例えば、実ユーザーが触るときの使用感はEnd-to-endと手動の組み 合わせでないと確認ができない ◦ 最小単位でテストすることにこだわりすぎた結果、スタブが正しい 値を返すことのテストになってしまっている、みたいな場合もある • テストの目的を忘れないことはとても大事で、それにあわせて スコープを決定する
34. テストを実装する難しさ • テスト実装の難易度が選択する手段に影響する場合がある ◦ テストしたい内容によっては自動テストだと難しく、手動での検証 を選択したほうがよい場合がある ◦ Unit testは実装が簡単と考えられるが、テスタビリティが低い設計 の場合は、大きいスコープのテストよりも難易度が上がる ◦ テストに必要なデータの準備コストは、スコープの大きさと比例し て難しくなるとは限らない
35. テスタビリティ • テスタビリティが高い設計は、戦略通りのテストスコープの実現やス コープの変更に対応できるようになっている • SWET blog:「テスタビリティの高いGoのAPIサーバを開発しよう」と いうハンズオンを公開しました(2回目の宣伝) ◦ https://swet.dena.com/entry/2021/12/07/123000
36. 検証したいパスに到達するための難しさ • 単体でみると数ケース見ればよくても、結合する範囲が広がると通り 得るパスの数が膨れ上がっていき、網羅するのが難しくなる • 結合範囲が広がると、特定のケースに到達するにはどうしたらいいか を把握することが難しくなる • テストのスコープによっては、検証したいパスに到達するのが難しい 場合がある ◦ 例えばAPIから返却されうるエラーパターンの確認
37. 検証したいパスに到達するための難しさ 関数A 関数B 関数C 関数D 処理の分岐 関数E 関数F 関数G 関数H 関数H
38. 検証したいパスに到達するための難しさ 関数A 関数B 関数C 関数D 処理の分岐 関数E 関数F 関数G 関数H 関数H ユニットテストの場合 関数のパターンをみればいい パターンを網羅してテストケースが増えても 実行時間が短いためスケールしやすい
39. 検証したいパスに到達するための難しさ 関数A 関数B 関数C 関数D 処理の分岐 関数E 関数F 関数G 関数H 関数H スコープを広げると通りえるパ ターンが膨れ上がる 実行時間も長いため、確認できる ケースが限られてくる
40. 検証したいパスに到達するための難しさ 関数A 関数B 関数C 関数D 処理の分岐 関数E 関数F 関数G 関数H 関数H ここを検証したい
41. 検証したいパスに到達するための難しさ 関数A 関数B 関数C 関数D 処理の分岐 関数E 関数F 関数G 関数H 関数H ユニットテストの場合 関数Eに着目すればよい
42. 検証したいパスに到達するための難しさ 関数A 関数B 関数C 関数D 処理の分岐 関数E 関数F 関数G 関数H 関数H スコープを広げると ここの分岐も考慮する必要がある
43. テスト実行以外の時間 • スコープの小さいテストは時間の面で優位 ◦ 完全に実装が終わっていなくても一部を切り出してテストでき、 動作確認がはじめられるまでの時間が短い ◦ プロジェクトを分割することでテストしたい対象のみビルドをする といったことが可能になり、ビルド時間の短縮も見込める • 時間が短いことは、テスト活動を継続していく上でとても大事 ◦ Developer Experience(開発体験)に直結する
44. モバイルアプリのテスト戦略 • スコープの異なるテストをバランスよく選択する ◦ スコープが大きいテストだけだと実行速度や信頼性が課題になり、 スケールしない・メンテナンスが難しいといった問題に直面する ◦ スコープが小さいテストだけだとUI/操作性/結合時といった問題を 取りこぼしてしまう • スコープ以外にも、確認したいことがテストできているか・テストの 難易度・実行までの時間といったポイントを考慮する
45. モバイルアプリのテストのハードルを 下げるための様々な工夫
46. モバイルアプリのテストをやっていて難しいと感じること • UIが絡むことで発生する問題が多い ◦ 特定のUIパターンの表示・特定のUI操作をトリガーに発生するもの ◦ テストのスコープを広げないと見つかりづらい • アプリをビルドするのに時間がかかる ◦ UIの動作確認したいのに、それをするにはアプリをビルドしないと いけなくて時間がかかるというジレンマ
47. • UIが絡むことで発生する問題が多い ◦ 特定のUIパターンの表示・特定のUI操作をトリガーに発生するもの ◦ テストのスコープを広げないと見つかりづらい • アプリをビルドするのに時間がかかる ◦ UIの動作確認したいのに、それをするにはアプリをビルドしないと いけなくて時間がかかるというジレンマ モバイルアプリのテストをやっていて難しいと感じること このハードルを乗り越えるために様々なチームで様々な工夫が行われている どんな工夫している事例があるのかを紹介していきます(Android多め)
48. ミニアプリ化 • アプリを機能ごとに分割して起動できるようにする • アプリ全体をビルドするよりもビルド時間が短縮され、動作確認にか かるコストと機能に行き着くまでのコストを下げる • クックパッド開発者ブログ: 大規模なiOSアプリの画面開発を効率化 するために動作確認用ミニアプリを構築する ◦ https://techlife.cookpad.com/entry/2020/08/05/090000
49. Jetpack composeやSwift UIのプレビュー機能 • モバイルアプリにおいて新たに登場した宣言的UIフレームワークは、 既存のViewシステムにはない高度なプレビュー機能が実装されている • UIのバリエーションを目視で確認する時間の削減が見込める • DroidKaigi 2021: Let's Preview！ Jetpack Compose ◦ https://speakerdeck.com/mochico/title-lets-preview-jetpack-compose
50. UIカタログ • UIコンポーネントを一覧化し、各コンポーネントの表示パターンを 確認できるようにする • UIのバリエーションを目視で確認する時間の削減が見込める • CyberAgent Developers Blog: Android向けUI Catalog Library – Katalogを公開しました ◦ https://developers.cyberagent.co.jp/blog/archives/33059/
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/
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
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
54. モバイルアプリのテストの今後 • モバイルアプリのテストはまだまだ伸びしろがある ◦ もっと使いやすくできる ◦ もっと多くの人に使ってもらえる ◦ もっと多くのことができるようになる • DeNAのSWETチームでは、そういったことを模索している
55. まとめ
56. まとめ • モバイルアプリのテストはトレードオフになっているパラメータのバ ランスを取りながら戦略を立てる必要がある • UIが絡む動作確認は難易度が高く、ハードルを下げるために様々な 工夫がされている • モバイルアプリのテストはまだまだ伸びしろがあるので、発展に貢献 していきたい
57. ご清聴ありがとうございました！