AIを活用したE2Eテスト実装効率化のあゆみ / ebisu-mobile-14-kotetu

Transcript

1. AIを活用した E2Eテスト実装効率化のあゆみ 栗山 徹 (@kotetu) Ebisu.mobile #14
2. 栗山 徹 モバイル開発本部/決済グループ @kotetu @kotetuco Ebisu.mobile #14 2 / 24
3. アジェンダ STORES決済のE2Eテスト自動化 – Appiumを使ったE2Eテスト自動化の仕組み – XPath 取得に関する AI を使った効率化 – 成果・まとめ – Ebisu.mobile #14 3 / 24
4. STORES決済のE2Eテスト自動化 Ebisu.mobile #14
5. STORES決済の E2E テストは「自動化のハードルが高い」 決済の手動操作が必要 端末・プラットフォームが多様 モバイルアプリは「一度リリースしたらロールバックできない」ため、QA品質を落とせない → QA がデリバリーの最大のボトルネックに 実際のクレジットカードをタッチ – QRコードを撮影 – 結果を端末の画面で確認 – プロダクト：アプリ / 決済SDK / スタンドアロンアプリ (決済端末2内で動作) – プラットフォーム：iOS/Android – 決済端末：2種類 – 決済方法：クレジットカード / 電子マネー / QRコード – Ebisu.mobile #14 5 / 24
6. 自動化の方針 → 完全自動化を目指さない Ebisu.mobile #14
7. 「完全自動化を目指さない」とは？ 半自動化 手動操作以外は Appiumが実行する 再現性 人間の操作ブレを最 小化し、誰でも同じ テストが回る 分散実行 複数人の実行結果を Qase(※)に集約して 可視化 見えているところまで自動化することで、まずは成果を取りに行った (※) Qase: STORESで利用しているテスト管理ツール Ebisu.mobile #14 7 / 24
8. Appiumを使ったE2Eテスト自動化の仕組み Ebisu.mobile #14
9. 技術スタック RSpec テスト Page Object Appium Server XCUITest (iOS) UiAutomator2 (Android) iOS 実機 Android 実機 Appium + RSpec で E2E テストを実装 – 実機 iOS / Android で動作 – .ipa / .apk を Bitrise / Xcode Cloud から取得 してそのままテスト – XCUITest / UiAutomator2 ドライバ – XPath でネイティブ UI ツリーの要素を特定 – Page Object パターンでOS 差分を 隠蔽 – テスト本体はiOS/Androidを意識しない – Ebisu.mobile #14 9 / 24
10. Page Object の基本実装 1 # Page Object のインスタンスを生成（driver: Appium, platform: :ios / :android） 2 # .tap は生成したオブジェクトをそのままブロックで操作する Ruby 構文 3 Page::App::CreditCardPaymentPage.new(driver, platform).tap do |page| 4 5 # RSpec のアサーション（XCTAssertEqual 相当） 6 # Page Object 経由で UI 要素を取得し、表示テキストを検証する 7 expect(page.financing_type_selector_button.text).to eq('1回払い') 8 expect(page.amount.text).to eq('¥512') 9 10 # [manual] 人間がカードをタッチ → レシート画面まで Appium が自動待機 11 page.wait_pay_by_contactless 12 13 end Ebisu.mobile #14 10 / 24
11. 半自動化の肝：人間に「声で」伴走する 物理カードのタッチは人間がやる。テストは 音声で指示を出して待つ。 1 def wait_pay_by_contactless 2 say('クレジットカードをタッチしてください') # 音声で次の操作を案内 3 4 # カードによっては署名画面が挟まる → 検知して自動でサイン入力 5 sign_if_signature_screen_appears 6 7 # Appium が画面ツリーを監視し、レシート画面を検知するまでポーリング 8 wait_until { receipt_screen? } 9 end 実行者は画面を凝視しなくてよい。 「いつ・何を」操作するかをテストが教えて くれる。 → プロダクトへの熟練度がなくてもテストを回せる状態に。 Ebisu.mobile #14 11 / 24
12. クロスプラットフォーム：1 テスト・2 OS Page Object 内で OS 差分を吸収。テスト本体は OS を意識しない。 1 def financing_type_selector_button 2 case platform 3 when :ios 4 driver.wait { it.find_element :xpath, 5 '//XCUIElementTypeButton[@name="financingOptionsButton"]' } 6 when :android 7 driver.wait { it.find_element :xpath, 8 '//android.widget.Button[@resource- id="...credit_card_payment_financing_type_selector"]' } 9 end 10 end 理想は 同じ locator で両 OS が取れること。ただし現状は OS ごとに XPath が異なるケースも多い。 Ebisu.mobile #14 12 / 24
13. 理想と現実：パスワード保存ダイアログ (iOS) 様々な条件により表示形式が異なるため、同じコードで処理できない。 シンプルな 2 択アラート パスワードマネージャーを含む 3 択シート Ebisu.mobile #14 13 / 24
14. 理想と現実：複雑な実装 1 def dismiss_password_save_alert 2 alert = driver.switch_to.alert 3 title = alert.text.lines.first.strip 4 5 case title 6 when /\Aパスワードを保存しますか\?\z/ 7 if alert.text.include?('パスワードの保存先を選択してください') 8 # 3択アラート → XPath で「今はしない」を直接クリック 9 driver.find_element(:xpath, '//XCUIElementTypeButton[@name="今はしな い"]').click 10 else 11 # 2択アラート → dismiss で OK 12 alert.dismiss 13 end 14 # ... 15 end Ebisu.mobile #14 14 / 24
15. XPath 取得に関する AI を使った効率化 Ebisu.mobile #14
16. XPath 探索がテスト実装のネック テストケースを実装するには、UI 要素の XPath を画面ごとに特定する作業が 必要。 iOS（XCUITest） Android（UiAutomator2） 1 //XCUIElementTypeButton 2 [@name="financingOptionsButton"] 1 //android.widget.Button 2 [@resource-id="...selector"] iOS/Androidそれぞれの XPath 探索が必要 – 画面数 × 要素数 × OS 数 だけ探索コストが積み上がる – Ebisu.mobile #14 16 / 24
17. XPath 探索効率化の変遷 ① 人力で探索 Appium Inspector で 手動探索 時間がかかる・属人的 ② 書き捨てコードで探索 探索用テストケースを AIに書かせてログ 出力しながら特定 自動化はされたが 探索効率悪い ③ Appium MCP AIがMCP経由で 実機へ直接アクセス して対話的に探索 探索効率が大幅向上 「目視で探索」→「ログ出力を見ながら自律的に探索」→「端末を操作しながら自律的に探索」 Ebisu.mobile #14 17 / 24
18. 要素探索① 人力で探索 目視でXPathを見つける必要があるので 時間がかかる Appium Inspectorを使い、 XPathのツリーを辿って要素を特 定 – iOS/Androidそれぞれ対応が必要 – Ebisu.mobile #14 18 / 24
19. 要素探索② 書き捨てコードで探索 テストケース実行の度にログインからやり直しなので 時間がかかる Yes No AI が探索用スクリプトを 作成 実行 要素が見つかった？ テストケースへ反映 AI に既存のテストコードを流用した 書き捨てコードを作らせる – ログで XPath を出力 – 探索できるまで何度もテストケースを実行し特定 – Ebisu.mobile #14 19 / 24
20. 要素探索③ Appium MCP 探索効率がさらに向上 Appium MCP 経由でAI が端末を 直接操作 – AI が画面遷移の操作をしつつ 適宜 XPath を収集 – Ebisu.mobile #14 20 / 24
21. 実行に失敗した場合の修正方法 失敗 成功 実行失敗 失敗ログを AI に渡す AI がコードを修正 再度試す 完了 失敗時に出力されるログをAIへ渡すのが 基本戦略 – コードが修正されるまで繰り返す – 必要に応じて XPath を辿り直してくれる – Ebisu.mobile #14 21 / 24
22. 成果 実装済みテストケース 運用の変化 12 2回実施 27% クレジットカード決済 (決済・返金) – 電子マネー決済・返金 (決済・返金) – QRコード決済・返金 (決済・返金) – Qase でテストケースの実行記録を 管理 – 毎リリース前にテストを実行する 運用フローを確立 – 実行後に挙がった課題をもとにテス トケース・運用フローを継続改善 – 実装済みテストケース テスト実行回数 ケース数ベースの半自動化率 「完全自動化」にこだわらず「回り続ける仕組み」を作れたことが一番の成果 Ebisu.mobile #14 22 / 24
23. まとめ 「半自動化」したE2E自動テストを導入することで テスト実施効率が向上した – テストケース実装だけでなく UIパーツの探索を AI によって効率化できた – 難しい問題を完璧に解こうとせず、見えているところまで解く。 そこで初めて次のビジョンが見えてくる。 Ebisu.mobile #14 23 / 24
24. ありがとうございました Ebisu.mobile #14