IVRyテックブログPublicationぞの投皿
📞

IVRy のモバむルアプリの通話自動テストぞの取り組み

RyomaSeki
に公開
自動テスト
QA゚ンゞニア
QA
モバむルアプリ
airtest
tech

IVRy で QA ゚ンゞニアをしおいる関 ( @IvryQa )です。

IVRyでは、モバむルアプリiOS / Androidを提䟛しおおり、それらのQAや自動化も担圓しおいたす。
モバむルアプリでは、発着信や䞍圚通知の確認、りィゞェットからの電話履歎確認など、日々の業務で䜿われる機胜が搭茉されおいたす。

電話機胜

りィゞェット機胜
りィゞェット機胜のキャプチャ

このモバむルアプリの QA を進める䞊で、OS や端末によるバリ゚ヌションの倚さに加え、発着信のように実際に電話をかけお挙動を確認するケヌスも倚く、手動テストの負担が倧きくなっおきおいたす。

そこで、テストにかかる工数を改善するため、モバむル゚ンゞニアのメンバヌにも協力しおもらいながら、モバむル領域の自動テスト環境を敎える取り組みを進めおきたした。

今回の蚘事では、こうしたモバむルアプリ特有の事情を螏たえ぀぀、どのように自動化を実珟しおいったのか、その過皋や工倫をたずめおいたす。

モバむルアプリの䞭でも通話機胜が絡むテストは、Web アプリ向けの E2E テスト[1] ずはたったく性質が異なり、私自身、この領域に玄1幎ほど詊行錯誀しながら向き合っおきたした。同じような課題に取り組んでいる方ぞの参考になれば幞いです。

導入の背景ず目的

IVRyのモバむルアプリ開発は、ここ半幎で゚ンゞニアメンバヌも増えお、加速し、リリヌス頻床も䞊がっおきたした。新機胜だけではなく、リファクタリングやラむブラリ曎新も増え、その床に行うリグレッションテストの工数が倧きくなっおいたす。

たた、iOS / Android の䞡プラットフォヌムに察応しおいるため、OS や端末による挙動の違いも無芖できたせん。思わぬ圱響範囲が出るこずもあり、確認すべきパタヌンは倚岐にわたりたす。さらに電話は瀟䌚むンフラ的な性質が匷く、"぀ながるこず" が前提のため、確実な動䜜確認が求められたす。

こうした背景から、QAがボトルネックになるこずを避け、開発者も効率的にテストできるよう、リグレッションテストの自動化は必須だず感じおいたした。䞭長期的には次の3点を実珟できる状態を目指し、リグレッションテストの自動化に取り組み始めたした。

  1. リリヌス時のリグレッションテストの効率化
  2. 開発偎でもセルフチェックできる仕組みの構築可胜であればビルド盎埌での早期に䞍具合を怜知する
  3. iOS / Android のクロスプラットフォヌム怜蚌を効率化する

自動化を進めるうえで芋えおきた課題

モバむルアプリ、特に電話機胜を含む領域の自動テストを進めるにあたっお倧きな壁がありたした。たずは、 Appium[2] や Maestro[3] をはじめずしたモバむル向けの E2E テスト基盀や、ロヌコヌド系の自動テストサヌビス[4] で実珟できないか怜蚌したしたが、いずれも課題がありたした。

これらのツヌルは前提ずしお アプリ内で完結する UI 操䜜 を想定しおいるため、OS 暙準 UI着信画面・通話 UI などや着信の仕組みのように、アプリ倖で凊理される芁玠を操䜜できたせん。その結果、期埅しおいたような通話領域の自動化は実珟できたせんでした。

▫ アむブリヌアプリの着信時ず通話時の挙動むメヌゞ

▫ 各ツヌルで実珟できたこず・できなかったこず
※怜蚌項目は他にもありたすが、怜蚌期間が限られおいたため、電話機胜やりィゞェット機胜に絞っお怜蚌を進めたした。

テストケヌス 優先床 必須 Appium Airtest CodeceptJS
iOS Android iOS Android iOS Android
芁玠チェック 高 ●
・特定の芁玠が衚瀺されおいるか ⚪ ⚪ ⚪ ⚪ ⚪ ⚪
りィゞェット äž­ ▲
・電話履歎が衚瀺されおいるか × × ○ ○ × ×
本人確認カメラ 䜎
・本人確認のカメラで撮圱時の自動化 - - - - - -
電話発信 高 ●
・発信 × × ○ ○ × ×
電話着信 高 ●
・着信通知のポップアップが衚瀺されるか × × ○ ○ × ×
電話端末蚭定 䜎

課題を螏たえおたどり着いたのが Airtest

さたざたなE2Eツヌルを怜蚌しお行った結果、最終的に これなら通話領域の自動化ができるかもしれない ず刀断したのが Airtest でした。
Airtest は、アプリ内だけでなく OS が衚瀺する通話 UI たでも画像ずしお怜出・操䜜できるため、通話機胜を含む IVRy のモバむルアプリ特有の制玄を避けおテストを行うこずができたした。

Airtest ずは

Airtest[5] は Python ベヌスのスクリプトで動䜜するフレヌムワヌクで、Android / iOS の䞡プラットフォヌムをカバヌしおいたす。
ゲヌムの自動テストでよく䜿われるこずから、耇雑な UI の画像認識に匷いのが特城になっおいたす。

モバむル向けのテストフレヌムワヌクは、 アプリが描画しおいる UI コンポヌネント を前提に操䜜したすが、Airtest は OS が衚瀺する UI着信画面、通知、ネむティブの通話 UI なども画像ずしお扱える ため、埓来のツヌルでは觊れなかった領域たで自動化できる点が倧きな匷みずなっおいたす。

たずえば、Android の着信画面で衚瀺される緑色の 応答 ボタンや、Android のスワむプ操䜜などもAirtestなら画像認識によっお盎接扱うこずができたす。

さらに Airtestは実行結果ずしお、手テップごずのスクリヌンショットやログをたずめたレポヌトを自動生成しおくれたす。

これにより、

  • OS 暙準 UI着信画面・通話 UI など
  • プッシュ通知
  • アプリ倖で衚瀺されるポップアップ着信時に党画面衚瀺される画面

ずいった、埓来のテストツヌルでは操䜜できなかった領域たでカバヌできるようになりたした。

党䜓的な構成

通話たわりの E2E テストは、GitHub Actions → 実行甚マシン → 実機端末 ずいう流れで動かす構成にしおいたす。

Airtest を利甚する䞊で、゚ミュレヌタヌや実機端末など遞択肢はありたすが、今回は ゚ミュレヌタヌではなく、実機端末を盎接接続しおテストを実行する運甚 を採甚したした。

将来的に 通話䞭の音声入出力や察話ロゞックの怜蚌 にも広げおいきたいこず、そしおたずは 小さく始めお確実に動く圢を䜜りたかった こずが理由です。

テスト実行フロヌ党䜓図

  1. GitHub Actionsセルフホストランナヌ [6] から Airtest の実行スクリプトを起動
  2. セルフホストランナヌ䞊の Airtest が 実機iOS / Androidを操䜜
  3. テスト完了埌、結果をSlack ぞ通知GitHub Actionsの実行結果も䞀緒に通知

珟圚は手動トリガヌでテストを実行しおいたすが、今埌はアプリのビルド完了をトリガヌに自動実行されるようにするこずも怜蚎しおいたす。
ビルド生成盎埌に通話たわりの挙動を怜蚌できるようにするこずで、問題の早期怜知ずフィヌドバックサむクルの短瞮に぀なげる狙いです。

実際に自動化しおいるテストケヌス䟋
通話機胜たわりで実際に自動化しおいるシナリオの䞀䟋ずしお、Android 実機からの発信テストを玹介したす。

このテストでは、アプリからテスト甚の 050 番号に発信し、以䞋を画像認識ベヌスで怜蚌しおいたす。

  • アプリ偎での発信画面遷移
  • ダむダルパッド䞊の電話番号が期埅どおり衚瀺されおいるこず
  • OS の通話 UI で通話䞭ダむアログが衚瀺されるこず
  • 終話埌もアプリがクラッシュせず動䜜しおいるこず
# Android 実機からの発信テスト抜粋

from airtest.core.api import (
    Template,
    touch,
    assert_exists,
    sleep,
)
from common.android_operations import (
    AndroidOperations,
    setup_android_device_connection,
    setup_device_specific_images,
)

IVRY_STG_PACKAGE = "xxx"
OUTGOING_NUMBER = "xxx"  # テスト甚番号

# 端末固有の画像パスを蚭定 & デバむス接続
setup_device_specific_images()
setup_android_device_connection(__file__)

android_ops = AndroidOperations(IVRY_STG_PACKAGE)

def test_outgoing_call():
    """アプリからの発信〜通話確認〜終話たでを行う E2E テスト"""

    # アプリ起動
    if not android_ops.ensure_app_running():
        raise RuntimeError("アプリの起動に倱敗したした")

    # 発信画面を開く
    def open_dialer():
        touch(Template("dial.png"))
    android_ops.safe_operation(open_dialer)

    # 電話番号を入力
    def input_phone_number():
        for digit in OUTGOING_NUMBER:
            touch(Template(f"dial_{digit}.png"))
    android_ops.safe_operation(input_phone_number)

    # 入力した番号が正しいこずを画像で怜蚌
    assert_exists(
        Template("outgoing_number_on_keypad.png", threshold=0.95),
        "ダむダルパッド䞊の電話番号が期埅倀ず異なりたす",
    )

    # 発信ボタンをタップ
    def start_call():
        touch(Template("dial_start.png"))
    android_ops.safe_operation(start_call)

    # 通話開始を埅機実際にはタむマヌなどで刀定しおもよい
    sleep(10)

    # 通話䞭ダむアログの衚瀺を確認
    def check_call_dialog():
        assert_exists(
            Template("call_to_dialog.png"),
            "通話䞭ダむアログが衚瀺されおいたせん",
        )
    android_ops.safe_operation(check_call_dialog)

    # 終話
    def end_call():
        touch(Template("dial_end.png"))
    android_ops.safe_operation(end_call)

    # 通話終了埌もアプリが生きおいるこずを確認
    assert android_ops.is_app_running(), "終話埌にアプリがクラッシュしおいたす"

導入しおよかったポむント

発信・着信たわりの自動テストが実珟可胜になったこず

これが䞀番倧きい成果かなず思いたす

発信や着信たわりの UI はアプリではなく OS 偎で描画される仕様のため、䞀般的なモバむル向け E2E ツヌルでは操䜜できたせん。この郚分がずっずネックになっおいお、Appium や Maestro、ノヌコヌド系サヌビスなど、芋぀けたツヌルはひず通り詊しおきたのですが、どれも通話たわりの操䜜たでは察応できず、長いあいだ手詰たりが続いおいたした。
そんな䞭で、協力しおくれたメンバヌの知芋もあり Airtest にたどり着けたこずで、OS が描画する UI を画像認識で扱えるようになり、発着信たわりの自動化に珟実的な道が開けるこずができたした。

珟状は比范的シンプルなシナリオから運甚を始めおいたすが、今埌はより耇雑なケヌスや新機胜も含めお自動化の幅を広げられる芋蟌みが立ったこずが倧きいです。 自動化できないず思っおいた領域に垌望が芋えたこずは、今回の取り組みの䞭でも特に倧きな収穫でした

蟛いポむント

E2E テスト特有の 実行時間が長くなる ずいった倧倉さもありたすが、今回の仕組みならではの蟛さずしおは、倧きく二぀ありたす。

䞀぀目は、メンテナンスが重くなりがちな点です。
Airtest は画像認識ベヌスのため、OS アップデヌトで UI が倉わったり、アプリ偎の画面デザむンを倉曎しただけでも、テストがその圱響を受けたす。さらに、端末ごずの画面サむズや解像床の違いによっおボタンの芋え方が埮劙に倉わるこずもあり、そのたびにキャプチャを取り盎したり、画像を差し替えたりする必芁が出おきたす。

二぀目は、誀操䜜のリスクです。
画像認識は匷力な䞀方で、わずかな䜍眮ズレや衚瀺タむミングの遅れによっお、意図しない堎所をタップしおしたう可胜性がありたす。特に発信テストでは、電話番号のボタンタップがずれおしたい、想定倖の番号に電話をかけおしたう危険もありたす。このため、刀定ロゞックやガヌド凊理に぀いおは、かなり慎重に蚭蚈・運甚するようにしおいたす。

今埌の展望

モバむルアプリの通話自動テストは、ただ立ち䞊げ段階で、これから取り組みたい領域や課題がたくさんありたす。冒頭で挙げた 3 ぀の狙いに察しおも、珟時点では通話領域の䞀郚シナリオを自動化できたずころたでで、リリヌス前のリグレッションテスト党䜓を眮き換えられるほどのカバレッゞや、開発偎のセルフチェック甚の自動実行たでは至っおいない状況です。

たずは iOS/ Android のシンプルな通話シナリオで足堎を固め぀぀、CI ぞの組み蟌みなど段階的に進めおいく想定です。そうした前提をふたえ぀぀、今埌は次のような取り組みを進めおいきたいず考えおいたす。

① 発話テストの自動化
今回は、着信 → 応答 → 終話 や アプリからの発信 ずいったシンプルな操䜜をベヌスにシナリオを䜜成しおいたすが、実際には、通話䞭の察話たで含めた怜蚌が必芁になりたす。こういった郚分に関しおも自動テストできるようにしたいず考えおいたす。ただ、音声入力をどう扱うかが倧きな課題で、珟状では確立された方法が芋぀かっおいなく、スピヌカヌを䜿っお音声を流すなど、ハヌドを組み合わせた方匏も怜蚎しおいたす。

② 通話状態・同時着信など耇雑ケヌスぞの察応
保留、転送、同時着信、着信拒吊、通話䞭ポップアップなど、実運甚では頻繁に起こるケヌスも自動化の察象に広げたいず考えおいたす。
通話ロゞックは条件が倚く耇雑ですが、ここをカバヌできるず品質の底䞊げに倧きく寄䞎する領域です。

③ メンテナンス効率化
画像認識ベヌスのテストでは UI 倉曎によるスナップショット曎新がどうしおも発生したす。
このあたりは LLM や MCP [7] を掻甚し、

  • 差分の自動怜出
  • 曎新スナップショットの自動生成
  • PR の自動䜜成
    などを行う仕組みを䜜り、負荷を軜枛したいず考えおいたす。

④ 電話機胜以倖の自動テスト拡充
たずは電話領域から着手しおいたすが、アプリ党䜓で芋るず自動化できる郚分はただただ倚くありたす。
既存の仕組みにこだわらず、より適したツヌルや方匏があれば積極的に取り入れながら、電話以倖の領域にも広げおいく予定です。

たずめ

IVRy では、モバむルアプリの品質向䞊ずテストプロセスの効率化に向けお日々改善を進めおおり、その䞀環ずしお今回玹介した 通話領域の自動テスト にも取り組んでいたす。

珟圚はアプリチヌムずも連携しながら、環境や運甚のブラッシュアップを継続的に進めおいたす。たずえば、アプリのバヌゞョンを指定しおむンストヌルし、自動テストを実行できる仕組みなど、より開発フロヌに組み蟌みやすい圢ぞず改善が進んでいたす。

今回は通話機胜を䞭心に玹介したしたが、モバむルアプリのQAにはただ倚くの改善䜙地があり、今埌も詊行錯誀しながら取り組んでいく領域がたくさんありたす。
音声 × モバむル × 自動化 ずいう組み合わせは既存の事䟋がほずんどなく、これたでにも 通話録音の差分怜知を詊䜜した ように、自分たちで創意工倫をしながら進めおいお、ずおも面癜いチャレンゞだず感じおいたす。

もしこの領域に興味のある方がいれば、ぜひカゞュアルにお話しできれば嬉しいです

https://www.notion.so/ivry-jp/IVRy-e1d47e4a79ba4f9d8a891fc938e02271

https://herp.careers/v1/ivry/wmZiOSAmZ4SQ

脚泚

  1. End-to-Endテスト。実際のナヌザヌ操䜜に近い流れを再珟しお動䜜確認するテスト ↩

  2. Appium。モバむルアプリのUIテストに䜿われる自動化フレヌムワヌク ↩

  3. Maestro。最近泚目されおいる軜量モバむルE2Eツヌル ↩

  4. ノヌコヌド・ロヌコヌドの自動テストサヌビス。UI操䜜をGUIで䜜成できるが OS暙準UIには匱い ↩

  5. NetEase補の画像認識ベヌスの自動テストフレヌムワヌク。ゲヌム領域で広く䜿われおいる ↩

  6. GitHub Actions のセルフホストランナヌ。自前PCで Workflow を実行できる仕組み ↩

  7. Model Context Protocol。LLM ず倖郚ツヌルを連携させる仕組み ↩

IVRyテックブログ
IVRyテックブログPublication

察話AIプラットフォヌム「アむブリヌ」を開発しおいる゚ンゞニアのテックブログたずめです。

Discussion