コンテンツへスキップ

Appiumの動作原理

メインページで述べられているように、Appiumはオープンソースプロジェクトであり、多くのアプリプラットフォームのUI自動化を容易にするために設計された関連ソフトウェアのエコシステムです。Appium 2のリリースに伴い、Appiumは以下の主要な目標を持っています。1

  • プラットフォーム固有の自動化機能をクロスプラットフォームの標準APIで利用できるようにする
  • このAPIにあらゆるプログラミング言語から容易にアクセスできるようにする
  • Appium拡張機能の便利なコミュニティ開発を可能にするツールを提供する

iOSやAndroidなど、ご存じのアプリプラットフォームを例に考えてみましょう。Appiumは、開発者やテスターが単一の統一されたAPIに従って、そのプラットフォームのUI自動化コードを記述できる方法を提供することを目指しています。Appiumの目標に基づいて、すべてを機能させるために多くの疑問点を解決する必要があります。

  • その「単一の統一された」APIにはどのAPIを使用すべきか？
  • そのAPIを特定のプラットフォームの自動化動作にどのようにマッピングするか？
  • そのAPIを複数の一般的なプログラミング言語からどのようにアクセス可能にするか？

iOSやAndroid以外にも多くのアプリプラットフォームが存在することを考えると、背景にはもう一つ大きな疑問が残っています。

  • すべてのプラットフォームの自動化をどのように実現するか？

Appiumがこれらの疑問点に対する回答を探求することは、Appiumが何であるかを学ぶ最速の方法ではないかもしれませんが、間違いなく良い方法です！それでは、詳しく見ていきましょう。

Appiumが選択したAPI

Appiumは、UI自動化の分野で長年のパイオニアであるSeleniumという技術に先行されたことは非常に幸運です。Seleniumプロジェクトの目標は、WebブラウザのUI自動化をサポートすることであり、この点において、Appiumの目標のサブセットを占めていると考えることができます。その過程で、Selenium（そして、合併後にWebDriverと呼ばれる別のプロジェクト）は、ブラウザ自動化のための比較的安定したAPIを開発しました。

長年にわたり、Seleniumは様々なWebブラウザベンダーとW3C標準化団体と協力して、そのAPIをWebDriver仕様と呼ばれる公式のWebブラウザ標準にしました。主要なブラウザはすべて、Seleniumチームが実際の自動化を実行するソフトウェアを維持する必要がないように、WebDriver仕様に沿った自動化機能を実装しています。標準化万歳！

Appiumの初期の目標は、モバイルアプリ（iOSとAndroid）の自動化標準を開発することでした。私たちは新しいものを作り出すこともできましたが、力を合わせるという精神と、標準を、まあ、標準のまま維持するという精神から、AppiumのAPIとしてWebDriver仕様を採用することに決めました。2 ウェブサイトとモバイルネイティブアプリでのユーザーインタラクションは完全に同一ではありません（たとえば、シンプルなリモコンで制御されるテレビプラットフォームを考慮すると、さらに大きな違いが生じます）。しかし、ほとんどのソフトウェアUIはほぼ同じです。これは、WebDriver仕様が、あらゆるプラットフォームにほぼ対応する自動化APIプリミティブ（要素の検索、要素とのインタラクション、ページや画面の読み込みなど）を提供することを意味します。

もちろん、AppiumはユーザーインタラクションがWebからモバイル、またはWebからテレビに異なる場合をサポートしたいと考えており、そのためAppiumはWebDriver仕様の組み込みの拡張性も利用しています。その結果、自動化したいプラットフォームが何であれ、Appiumを使用する際には、標準のWebDriver仕様を使用することになります。ただし、2つの注意点があります。

  • 特定のプラットフォームでは、特定のWebDriver APIコマンドをサポートする方法がない場合があり、そのため一部のコマンドはサポートされない場合があります（たとえば、ネイティブモバイルアプリ自動化の世界では、Cookieの取得や設定は不可能です）。
  • WebDriver APIコマンドリストにあるものを超える自動化動作をサポートする場合がありますが、そのようなコマンドはすべて有効であり、WebDriver APIへの仕様に準拠した拡張機能となります。

WebDriver APIを実際にどのように使用するか、特にAppiumのコンテキストではどうするか？Appiumが普遍的なプログラミング言語アクセスを提供する方法については、下記のセクションで説明します。現時点では、Appiumが普遍的なUI自動化インターフェースを導入する方法が、WebDriverプロトコルを実装することであることを知っておくだけで十分です。

プラットフォームの自動化動作

次の疑問は、Appiumがこのプロトコルを幅広いプラットフォームの自動化動作にどのようにマッピングするかということです。トリックは、厳密に言えば、Appiumはそうしないことです！この責任は、Appium *ドライバ*と呼ばれる一種のソフトウェアモジュールに委ねられています。次に読むことができるドライバの紹介全体がありますので、ここでは動作の詳細については説明しません。

現時点で理解する必要があるのは、ドライバはAppiumのプラグイン可能なモジュールのようなもので、Appiumに特定のプラットフォーム（またはドライバの目標に応じて、プラットフォームのセット）を自動化させる機能を与えます。最終的に、ドライバの責任は、WebDriverプロトコルを表すAppium内部インターフェースを実装することだけです。このインターフェースを実装する方法は、特定のプラットフォームで自動化を行うための戦略に基づいて、ドライバに完全に委ねられています。通常、そして詳細ははるかに複雑で困難ですが、ドライバはプラットフォーム固有の自動化テクノロジーに依存することでこれを行います。たとえば、AppleはXCUITestと呼ばれるiOS自動化テクノロジーを維持しています。iOSアプリ自動化をサポートするAppiumドライバはXCUITestドライバと呼ばれます。なぜなら、最終的に行うことはWebDriverプロトコルをXCUITestライブラリコールに変換することだからです。

ドライバが独立したプラグイン可能なモジュールである理由の1つは、ドライバが互いにまったく異なる方法で動作することです。異なるプラットフォームのドライバの構築と使用のためのツールと要件は完全に異なります。そのため、Appiumでは、自動化タスクに必要なドライバだけを使用できます。ドライバを選択してインストールして、Appiumインスタンスで使用できるようにすることは非常に重要であるため、Appiumにはドライバを管理するための独自のCLIがあります。

したがって、元の質問に対する答えとして、Appiumが特定のプラットフォームの自動化機能へのアクセスを提供する方法は、Appiumチーム（またはその他の人々3）がそのプラットフォームのドライバを作成し、必要に応じてWebDriverプロトコルの多くまたは少ない部分を実装することです。その後、ドライバはAppiumを使用する誰でもインストールできます。

あらゆるプログラミング言語からのアクセス

しかし、そもそもAppiumを使用するとはどういう意味でしょうか？Appiumは最終的にはNode.jsプログラムであるため、Appiumとそのドライバを独自のNode.jsプログラムにライブラリとしてインポートするようなものになる可能性がありました。しかし、それはあらゆる一般的なプログラミング言語を使用している人々に自動化機能を提供するというAppiumの目標を満たすものではありませんでした。

幸いなことに、AppiumがSeleniumを基盤として開発されたため、私たちは初日からこの問題に対する解決策を持っていました。WebDriver仕様は実際にはHTTPベースのプロトコルであり、単一プログラムのメモリ内ではなく、ネットワーク経由で使用されるように設計されているのです。

この「クライアント-サーバー」アーキテクチャの主な利点の1つは、自動化の実装者（この場合は「サーバー」、自動化を実行するもの）と、自動化の実行者（この場合は「クライアント」、どのような自動化を実行すべきか、どのような手順で実行すべきかを定義するもの）を完全に分離できることです。基本的に、「難しい部分」（特定のプラットフォームで自動化を実行する方法を実際に解明すること）はサーバー側で一元的に処理でき、「薄い」クライアントライブラリは、サーバーへのHTTPリクエストを言語に適した方法でエンコードする、任意のプログラミング言語で記述できます。言い換えれば、高レベルのHTTPライブラリが存在する限り、その言語で基本的なHTTPクライアントをコーディングするだけで、Appium/WebDriverの基本機能を新しいプログラミング言語に比較的容易に導入できます。

Appiumユーザーである皆さんにとって、ここで重要なポイントがいくつかあります。

  • AppiumはHTTPサーバーです。自動化にAppiumを使用したい限り、あるコンピューターでプロセスとして実行する必要があります。ネットワーク経由で、自動化を実行するために使用するコンピューター（同一マシンでも世界中にあるマシンでも）からアクセスできる必要があります。
  • 生のHTTP呼び出しを記述したり、cURLを使用したりしない限り、Appiumを自動化に使用するには、選択した言語のAppiumクライアントを使用する必要があります。これらの各クライアントの目的は、WebDriverプロトコルをカプセル化することです。そうすることで、プロトコル自体を気にすることなく、自分の言語で自然に感じるオブジェクトとメソッドを使用できます。
  • AppiumサーバーとAppiumクライアントは、同じコンピューターで実行する必要はありません。クライアントからサーバーにネットワーク経由でHTTPリクエストを送信できれば十分です。これは、クラウドプロバイダーでのAppiumの使用を大幅に容易にします。クラウドプロバイダーはAppiumサーバーと関連するドライバーやデバイスをホストでき、ユーザーはクライアントスクリプトをそれらのセキュアなエンドポイントに向けるだけで済みます。

そしてもちろん、これらはすべて「テスト」そのものに関するものではなく、純粋にAppiumとそのクライアントライブラリの自動化用途に関するものです。「テスト」の目的で自動化を行う場合は、テストランナー、テストフレームワークなどを利用する必要がありますが、これらはAppiumとは無関係である可能性があります。Appiumの「普遍的なアクセス性」の利点の1つは、状況に応じて最適なツールセットと連携しやすいことです。

Appiumの巨大な範囲

Appiumのビジョン（単一のAPIによるすべての自動化）は巨大です！もちろん、オープンソースプロジェクトのコアメンテナンスチームよりもはるかに大きいです。では、Appiumはこの目標をどのように達成しようとしているのでしょうか？基本的に、コミュニティがプラットフォームとしてAppiumの上に機能を開発できるようにすることで実現しようとしています。これが、Appiumの「エコシステム」と呼ばれるものです。

Appiumチームは、いくつかのドライバー（例：先に説明したXCUITestドライバー）を公式に保守していますが、多くの異なるプラットフォームのドライバーを保守するプラットフォーム固有の専門知識や能力を持つことは期待できません。しかし、特にAppium 2から、コミュニティが私たちのビジョンに参加できるようにするためのツールを提供してきました。

  • 適切な規則に従い、WebDriverプロトコルの任意の（サブ|スーパー）セットを実装するNode.jsモジュールを作成するだけで、誰でもドライバーを作成できます。WebDriverプロトコルの詳細は抽象化され、多くのヘルパーライブラリが利用できるため（Appiumチーム独自のドライバーを動かすのと同じライブラリ）、ドライバーの作成には最小限のコードで済むことがよくあります。
  • AppiumドライバーCLIを使用すると、他の人とドライバーを簡単に共有できます。中央管理機関はありません。誰でも無料で、または有料で、公開または非公開でドライバーを共有できます。ドライバーはオープンソースでもクローズドソースでもかまいません（ただし、オープンソースを高く評価しています！）。

すべてのアプリプラットフォームの自動化のサポートを超えて、開発プラットフォームとしてのAppiumのビジョンは広がっています。人気の高い自動化ツールとして、Appiumをあらゆる種類の他のツールやサービスと統合する多くの機会があります。さらに、コアサーバーとして、またはさまざまなドライバーでの実装として、Appiumには多くの機能アイデアがありますが、コアチームには構築する時間がないでしょう。そこで、Appium 2では、Appiumの動作を変更するモジュールを誰でも構築して共有できるプラグインシステムをリリースしました！

ドライバーをAppiumドライバーCLIを介して簡単に共有および使用できるのと同様に、プラグインは並列のプラグインCLIを介して公開および使用できます。プラグインはあらゆる種類のことを実行できます。たとえば、テンプレート画像に基づいてAppiumが画面領域を見つけて対話できるようにする機能を追加できます（imagesプラグインのように）。プラグインでできることに制限はほとんどなく、Appiumで使用できるNode.jsでプラグインを構築する方法を学ぶことにも興味があるかもしれません。

これがAppiumです。拡張可能な、普遍的なインターフェースであり、潜在的にあらゆるもののUI自動化を実現します！詳細については、具体的な導入ドキュメントの一部を参照するか、さまざまなガイドを参照してAppiumのより一般的な概念と機能について詳しく調べてください。

  1. これらの主要な目標を達成するために、私たちは二次的な目標または方法論原則のセットも使用しており、Appium拡張開発者にも推奨しています。

    • 可能な限り、オープンソース技術に依存し（そして貢献し）ましょう。
    • 可能な限り、特定のプラットフォームのベンダー提供ツールに依存しましょう。
    • 可能な限り、変更されていないアプリの自動化を可能にする自動化ツールに依存しましょう（ユーザーが追加のSDKやソフトウェアを組み込む必要がなく、アプリのテストバージョンと本番バージョンとの間に不一致が生じるのを避けることを優先します）。
    • 可能な限り、新しいものを作成するのではなく、既存の標準に依存しましょう。

    ↩

  2. 技術的には、Appiumが最初に記述されたとき、私たちはJSON Wire Protocolと呼ばれるWebDriver仕様よりも古いものに取り組んでいました。それ以来、AppiumはW3C仕様とともに進化し続け、完全にW3C準拠となっています。↩

  3. 独自のドライバーを構築して共有できます！Appiumで使用できるNode.jsでドライバーを開発する方法については、ドライバーの構築を参照してください。↩