Appiumテストで自動車プロジェクションを開始および停止する方法

テストがオートマチックモードに入るタイミングと出るタイミングを制御する — 最初からやり直す必要はありません

自動車アプリのテストは、単に投影された画面をテストするだけではありません。全体的なユーザー体験をテストすることが重要なのです。 

車載インターフェースを介してモバイルアプリをテストする場合、通常のモバイルテストとは構造的に異なることが起こります。デバイスは投影状態に入り、仮想ヘッドユニットとの永続的な接続が確立され、画面の制御が車のディスプレイシステムに引き渡されます。

これは、標準的なモバイル自動化には存在しないテスト上の問題を生み出す。 

ほとんどの車載アプリでは、投影を開始する前に、ユーザーが既にログインしていること、アプリが既知の状態にあること、または特定のデータ条件が満たされていることが必要です。しかし、デバイスがセッション開始時に投影モードに入ると、最初にこれらの設定を行う時間的余裕がありません。 

そして、テストが終了した時点でデバイスが投影モードのままだった場合（これは自動化された環境ではよくあることだ）、次のテストはその状態を引き継ぐ。  

チームがこれまで用いてきた回避策は、CI/CD環境では拡張性に欠ける。手作業の手順が増え、動作が不安定になり、テスト環境の維持管理が難しくなる。 

実際に変えるべきことは何か 

基本的な要件は単純明快です。チームは、テストセッション全体を通して投影をオンにするかオフにするかだけでなく、テストセッション内で投影が開始および停止するタイミングを制御する必要があります。 

これにより、2つのことが実現します。 

投影前の前提条件。  アプリのリセット、ログイン、データ設定を通常のデバイス環境で実行してください。その後、アプリが適切な状態になったら投影を開始してください。 

投影後にデバイスの状態をクリーンアップしてください。  テスト終了時に明示的に投影を停止することで、プール内のどのデバイスであれ、次のテストが予測可能なベースラインから開始されるようになります。 

これらは高度な要件ではありません。あらゆるCI/CDパイプラインが他の種類のテストに対して行うのと同じ前提条件です。問題は、自動車向け予測ツールがこれらの前提条件をサポートしていなかったことです。 

その結果、Appium互換のコマンドであるautomotive.startとautomotive.stopを新たに導入しました。これにより、チームは実行中のテストセッション内の任意の時点で、Android AutoとiOS CarPlayの投影状態をプログラムによって制御できるようになります。 

コマンドの機能 

automotive.start と automotive.stop は、Appium テストスクリプト内で直接呼び出されます。automotive.start は接続された車載ディスプレイへの投影を開始し、automotive.stop は投影状態を終了してセッションを標準のデバイスコンテキストに戻します。これらのコマンドは、Android Auto と iOS CarPlay の両方でサポートされています。 

テストは次のような形式になります。 

1. デバイスでアプリを開く
2. ログインし、データ条件を設定し、適切な画面に移動します。
3. 投影を開始する (automotive.start)
4. 車載スクリーンで自動ステップを実行する
5. 停止プロジェクション (automotive.stop)
6. 自動車以外の動作を検証する

プログラムで表現すると、次のようになります。 

# Pre-condition: launch app in standard device context
driver.activate_app('com.example.automotiveapp')
login(driver)                        # run login flow normally
navigate_to_map_screen(driver)       # set expected app state


# Enter automotive projection (Android Auto / CarPlay)
driver.execute_script('automotive.start')

# Interact with in-car display
driver.find_element(By.ID, 'com.example:id/nav_button').click()
assert_route_displayed(driver)

# Exit projection — device returns to standard context
driver.execute_script('automotive.stop')

# Continue validating non-automotive behavior
assert_app_state_preserved(driver)

各投影セグメントはそれぞれ独自のビデオを生成し、テストレポートの添付ファイルとしてアップロードされます。1回のテストで複数の開始/停止サイクルがサポートされており、それぞれが独自の録画を保持します。 

その結果、特別なデバイス処理、隔離された環境、または実行間の手動介入を必要とせずに、標準的なCI/CDパイプラインに適合する自動車テストのカバレッジが実現します。

これにより何が解放されるか 

自由を前提条件とする。  プロジェクションの前に必要なアプリの設定は、回避策なしで、同じセッション内でプロジェクションの前に実行できるようになりました。 

CI/CDの信頼性。  各テストは独自の投影状態を管理します。前のテストが残した状態に依存することはありません。共有デバイスプールとクラウドデバイスプールの両方で一貫して動作します。 

セグメントごとの動画。  各開始／停止サイクルごとに独自のビデオ録画が生成され、テストレポートの添付ファイルとしてアップロードされます。テストで複数の投影サイクルが実行された場合、それぞれのサイクルごとにレビュー用の録画が作成されます。 

複数サイクルセッション。  1つのテストで、自動車の投影モードに複数回出入りできるため、コンテキストスイッチをまたいだ動作のテストに役立ちます。 

Android AutoとiOS CarPlayの両方がサポートされています。単一のAppiumテストスクリプトから、両プラットフォームで同じようにコマンドを実行できます。 

コネクテッドカーアプリケーションの自動テストに既に投資しているチームにとって、automotive.startとautomotive.stopは最後のギャップを埋めるものです。これまで投影状態はテストの外部で管理されていましたが、今後はパイプライン内の他のすべての要素と同様に、テスト内部で管理できるようになります。 

準備完了 自動車のテストについて調べてみよう?