東芝 Advent Calendar 2025

株式会社東芝

iPhone Webアプリテスト戦略まとめ

Last updated at 2025-12-16Posted at 2025-12-16

スマホWebアプリ（特にiPhone Safari）のテストを行う際、
「どうやって実機やブラウザを操作するか」という観点で、４つのアプローチを試してみましたので、各々の特徴や導入方法、用途、課題についてまとめます。

どうやって実機やブラウザを操作するか

動機
ことの発端はスイッチコントロールという機能を使うと、外部デバイス(Macやスイッチ)からiPhoneの画面操作を行えるということを知って、「iPhoneのアプリのテスト自動化にも使えるのでは？」と思い至ったところにあります。

普段スマホアプリの開発をしているわけではないですが、気になって色々試した内容をまとめてみました。至らない点もあるかと思いますが、これからスマホアプリの開発やテストに関わる方の一助になれば幸いです。

📌 目次

今回試した４つの方法はざっくりとこんな感じです。分量が多くなっているので、特徴や用途と、導入方法へのリンクをつけました。特定の方法だけ知りたい方はリンクをご活用ください。

ちなみに、この動機への結論は、スイッチコントロールを利用したiPhoneテストの自動化が有効になるケースは限定的となります。

1. スイッチコントロールを利用した操作自動化
2. シミュレーション環境でのテスト
3. Webインスペクタによるテスト
4. UIテストフレームワーク(Appium)による実機自動化
比較表
導入方法まとめ

アプローチ一覧

1. スイッチコントロールを利用した操作自動化

まずはスイッチコントロールを利用した操作の自動化についてです。
iPhoneで画面操作(タップやスワイプ)のシナリオを用意しておいて、その実行タイミングや順序、ループをMacのAutomatorで制御してみました。

所感
Webアプリテストの観点で考えると、実機のしかもタップ、スワイプ動作を利用できるため、最もユーザ操作に近い部分のテストができるという点が良い点だと感じました。
一方で、所定のポイントをタップし続けるだけでよければいいのですが、テストのための一連の操作が複雑な場合や、Web画面のボタン配置などが変わった場合には、シナリオを作り直さないといけないというのが大変な点だなと感じました。

他の利点としては、iPhoneとMacさえあれば追加ソフトのインストールケーブルなども不要なため、用意するものが少なくて済むというのはあるかと思います。
そのため、Webアプリ開発の最終的段階で、長時間動作の試験を行う場合であれば、この方法もアリなのかなと思いました。
(そもそもWebアプリは長時間の連続動作を想定していない場合が多いですが。。。)

今回の題目からは外れてしまいますが、通常ストアで配布されているアプリが動作してる画面上でスイッチコントロールを動かせば、推しのライブ配信の「いいね」を連打したり、ゲームの周回操作を自動化できたりといったことはできそうです。
※スイッチコントロールを禁止しているアプリの場合はできないみたいです。

以上が、スイッチコントロールとMacで画面操作を自動化してみた感想になります。

要点はこちらにまとめておきます。
スイッチコントロールを用いたiPhone実機Webアプリのテスト自動化

特徴
- 実機画面を物理的に自動操作可能
- 単調操作の繰り返しに強い
- iPhoneとMacがあれば他にソフトのインストールなどは不要
用途
- 負荷的検証
- 長時間の同一操作
課題
- 座標依存で保守性が低い
- 結果判定が難しく、メンテナンスコスト高

2. シミュレーション環境でのテスト

次に、XcodeのiOSシミュレータを用いたテストについてです。

所感
シミュレータと書いている通り、実機ではありませんので、実機固有の挙動についてはテストできません。
ただ、MacにXcodeさえインストールすればシミュレータを起動することができ、複数OS、複数シミュレータを立ち上げることが可能なため、Webアプリがある程度動くようになったタイミングでとりあえず動作検証をしたい場合や、iPhone実機が用意できない場合、異なるOSバージョンでの動作検証を行いたい場合には向いていると感じました。
特徴
- Mac上で簡単に起動でき、開発者が即座に再現可能
- ネットワーク条件やCookieのリセットが容易
- 同時に複数シミュレーション可能
- 複数バージョンのOSで確認可能
用途
- UI確認
- 基本動作検証
課題
- 実機特有の挙動（IME、日本語入力、通知、センサー）は再現不可
- 自動化は標準では弱く、追加ツールが必要

3. Webインスペクタによるテスト

次にWebインスペクタを使ったテストについてです。

所感
元々Webインスペクタでは画面サイズをスマホサイズにして動作確認やデバッグができると思いますが、iPhone側でWebインスペクタを有効にすることで、iPhone実機のWebアプリの状態を確認することができます。
コンソールからAPIを叩いて負荷のテストなどはできるかもしれませんが、「Webアプリのテスト」というよりは、「何か問題があったときのデバッグ用」という位置付けが良いかと感じました。
特徴
- DOM、ネットワーク、JSエラー解析に強い
- 実機Safariでの挙動を直接確認可能
用途
- 原因調査
- パフォーマンス計測
課題
- UI操作の完全自動化には不向き

4. UIテストフレームワーク(Appium)による実機自動化

最後に、Appiumを利用した実機Webアプリテスト自動化についてです。

所感
Appium は、スマートフォンのネイティブアプリ・Web アプリを自動操作するためのオープンソーステストツールです。操作対象が iOS でも Android でも同じ WebDriver ベースの API を使える点が特徴で、実機・シミュレータのどちらにも対応しています。
iOS では WebDriverAgent を介してクリック・入力・スクロールなどの UI 操作を実端末に送信でき、手動では時間のかかる検証作業を自動化できます。
また、Appiumの利点は、クラウド型デバイスファームを利用すると、複数端末の同時テストも実現可能という点です。これにより、複数端末・複数OSバージョンの同時検証を効率的に行え、回帰テストの品質とスピードの向上が期待できます。

導入コストはかなり高いと感じましたが、スマホのサービスの開発がメインの場合は、導入を検討する価値はあるなと思います。
特徴
- 実機SafariやWebViewでE2E操作を自動化
- CI/CD連携、複数端末対応(クラウドサービス利用)、要素ベースで保守性高
用途
- 回帰テスト
- 品質保証
課題
- 初期構築が重い（証明書、権限設定など）
- iOSアップデートでメンテナンスが必要

比較表

各アプローチごとの導入難易度などについて、筆者の感覚で比較してみたので表にまとめます。

アプローチ	導入難易度	実機再現性	自動化適性	保守性	CI/CD対応
シミュレータ	低	△	▲	○	△
Webインスペクタ	低	◎	△	○	△
スイッチコントロール	中	◎	○	▲	×
Appium	高	◎	◎	◎	◎

凡例

◎：非常に適している
○：適している
△：やや弱いが工夫すれば可能
▲：ほぼ不向き（現実的には難しい）
×：不可能、または選択肢にならない

導入方法

ここからは各アプローチの導入方法について記載します。

スイッチコントロール + Automator

※ Mac のキー入力を iPhone のスイッチコントロールに外部入力として認識させられるようになったのは比較的最近のバージョンなようです。筆者が以前使用していたmacOS Monterey (12.x) では、iPhone を検知できませんでした。

1. Mac のキーを iPhone のスイッチとして認識させる

■ Mac 側設定

🍎 → システム設定 → アクセシビリティ → スイッチコントロール → スイッチ
「＋」から新規スイッチ作成
スペースキー・Enter キーなどを押して動作を登録

【スイッチ設定画面】

この設定により、Mac のキーを押すと iPhone 側のスイッチ動作が実行できます。

2. スイッチの認識（接続）

■ iPhone 側

設定 → アクセシビリティ → スイッチコントロール → 有効化

■ Mac 側

スイッチコントロールを有効化
「接続」を押す
先ほど登録したキーを押す

※ 接続順が重要です
私の環境ではiPhone → Mac の順で有効化しないと検知しませんでした。

【デバイス接続画面】

3. レシピの作成

スイッチを登録すると、iPhone 側でレシピが作成可能になります。

新規レシピを作成
スイッチを割り当て
アクションを選択
レシピトップ画面で「レシピを起動」に割当て
- 標準アクションにない動作は カスタムジェスチャ で登録可能

【iPhone スイッチ設定画面】

4. レシピの実行

iPhone：スイッチコントロール有効
Mac：スイッチコントロール有効
Mac 側で割り当てたキーを押す

これで設定したレシピが実行されます。
レシピとキーを組み合わせることで Web アプリの操作試験が可能です。

5. レシピ実行の自動化（Automator）

Mac のキー入力で iPhone を操作できるため、Automator を使えば 繰り返し実行・自動化ができます。

Automator の詳細説明は割愛しますが、以下のような設定でレシピを繰り返し実行可能です。

【Automator 設定画面】

tell application "System Events"
    -- スペースキー入力
    key code 49
    delay 0.1
end tell

iOSシミュレータ(Xcode)

Xcode をインストールすると自動的に iOS シミュレータも導入されます。
以下の手順で起動できます。

ターミナルを開く
下記コマンドを実行し、表示された iOS Simulator.app をクリック
※ 起動には時間がかかります。

cd /Applications/Xcode.app/Contents/Developer/Applications
open .

Web インスペクタ

iPhone の Safari を 実機デバッグするための Web インスペクタの設定方法をまとめます。

■ 用意するもの

Mac
iPhone
デバイス接続用ケーブル

■ Mac 側の設定

Safari を開く
左上メニュー Safari → 設定 → 詳細
画面下部の 「Webデベロッパ用の機能を表示」 をチェック

【Safariの詳細設定画面】

■ iPhone 側の設定

設定 → Safari → 詳細（一番下）
Webインスペクタを有効化

■ デバッグの開始手順

Mac と iPhone をケーブルで接続
iPhone の Safari でデバッグ対象ページを開く
Mac の Safari → メニューバー開発 → 表示された iPhone 内のページを選択

【開発タブ画面】

【Webインスペクタ画面】

【実機 iPhone 画面】

Mac 側で開発者ツール、iPhone 側で実際の操作画面を表示しながらデバッグできます。

Appium

appium による iPhone 実機自動テストの基本的な流れ、サンプルコード、詰まりポイントについて紹介します（全体像のみ）。

■ iPhone Safari 自動テストの流れ

appium のサーバ・検証ツール・クライアントをインストール
テストコード作成
必要に応じて WebDriverAgentRunner を手動インストール
Mac と iPhone を接続
appium サーバ起動
テストコード実行
iPhone の Safari がテストコードどおりに操作される

main.py

from appium import webdriver
from appium.options.ios import XCUITestOptions
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
import time

#Safariを実機で動かす時のAppiumサーバ側の起動コマンド
#appium --address `python3 -c "import socket; print(socket.gethostbyname(socket.gethostname()))"` --port 4723 --relaxed-security


def test_safari():
    options = XCUITestOptions()

    options.platform_name = "iOS"
    options.automation_name = "XCUITest"
    options.device_name = "XXXXXXX"  #実機のデバイス名「〇〇のiPhone」など
    options.platform_version = "18.6"      # 実機のOSバージョン
    options.browser_name = "Safari"

    # ★★★ 必須：実機UDIDを追加
    options.udid = "XXXXXXXX-XXXXXXXXXXXXXXXX"   # ←実機UDIDに置き換え(Xcodeから確認可能)

    # 署名情報（WDA用）
    options.set_capability("xcodeOrgId", "teamID") #teamIDを入力(無料の開発者アカウントで可)
    options.set_capability("xcodeSigningId", "Apple Development")

    # WDA の Bundle ID を指定（推奨）
    options.set_capability("wdaBundleId", "XXXX.XXXXXX.WebDriverAgentRunner") #一意の値を設定

    driver = webdriver.Remote("http://127.0.0.1:4723", options=options)

    driver.get("https://qiita.com")
 
 # ---- ① Web コンテキストに切り替える ----
    time.sleep(3)  # 少し待つ

    print("Contexts:", driver.contexts)

    for ctx in driver.contexts:
        if "WEBVIEW" in ctx:
            driver.switch_to.context(ctx)
            break

    # ---- ② Element が表示されるまで待つ ----
    link = WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((By.LINK_TEXT, "リリースノート"))
    )

    link.click() #ここでQiitaのリリースノートがクリックされる
    time.sleep(5)


    driver.quit()


if __name__ == "__main__":
    test_safari()

選択フロー図（おまけ）

今回取り上げた手法の選択フローを記載しておきますので、必要に応じてご活用ください。

おわりに

本記事では、iPhoneのWebアプリテストを実機やブラウザでどのように操作するかという観点から、4つのアプローチ（スイッチコントロール、iOSシミュレータ、Webインスペクタ、Appium）について特徴・用途・課題を整理しました。

それぞれの手法にはメリットと制約があり、テストの目的や開発フェーズに応じて最適な選択肢は異なります。今回の内容が、皆さまの検討や実務における参考になれば幸いです。

最後までお読みいただき、誠にありがとうございました。

iPhone、Safari、Mac、macOS、Xcode、iOS、Automator は、米国およびその他の国における Apple Inc. の商標または登録商標です。
Qiita は、Increments株式会社の登録商標です。
Appium、WebDriverAgent は、各開発コミュニティの商標または登録商標です。
その他記載されている会社名、製品名は、各社の商標または登録商標です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up