Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

今日の発表のゴール

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

アプリの内部構成

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

モバイルアプリのテストって何をするの？ 端末にアプリを入れて、それぞれの機能が問題ないか 操作して確認すればいいかな？

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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/

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

まとめ

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

ご清聴ありがとうございました！