Blog株式会社インテリジェントテクノロジーの技術情報ブログです。記事中のAppiumのドキュメントへのリンク先は削除されてしまったようです。その代わりに公式サイトのドキュメントが整備されています。【追記2014/7/16】Appiumの新しいバージョン(1.2.0)に関する記事を書きました。こんにちは、間藤です。今回がiOS編の最後です。これまでは「アプリのテスト」だったのですが、今回のテスト対象はWebアプリケーションです。Safariを利用します。Programへの登録が必要だったりと、手動テストでは不要な環境、手続きが必要になります。Programへの登録はそもそも必要*1ですが、Webアプリケーションのテストのためにこういった環境を用意するのかという点は考えどころだと思います。Safariを利用した自動テストは、正常に動作させることができていません。詳細は後で書きますが、以下のような問題が起きています。Appiumのプログラムを1箇所(実機の場合は2箇所)修正しないと、テストがエラー終了してしまいますテスト終了時にアプリが終了しません(シミュレータも起動したまま)キャプチャ画像を取得することができません(解決策があり)実行環境等Safariを起動するために、SafariLauncherというアプリを利用します。このアプリがテスト対象というわけではありませんが、このアプリを利用するという意味で一覧に記載してあります。テストスクリプトは提供されているものを使いますが、何点か修正が必要です。sample-code/examples/java/junit/src/test/java/com/saucelabs/appium/SafariTest.java事前準備テスト対象アプリを"safari"と指定すると、AppiumはSafariLauncherというアプリをインストールしようとします。"safari");このアプリのzipアーカイブがAppiumサーバを起動したディレクトリ配下(./build/SafariLauncher)に配置されていなければならないようです。以下、Appiumが出力したログの抜粋です。./build/SafariLauncher/SafariLauncherSim.zipこのパスにzipアーカイブが配置されていないと、テストはエラー終了してしまいます。cloneしたディレクトリ配下でreset.shを実行することで、このzipアーカイブが作成されますので、以下のコマンドを実行してください。--real-safari実機用のzipアーカイブを作成するためには、--real-safariオプションをつけて実行する必要があるようです。詳細は、以下のドキュメントを確認してください。Device提供されているテストスクリプトもいくつか修正します。iOSバージョンを指定している箇所を、実際に起動されるシミュレータのバージョンに合わせるよう修正します。"7.0.3");これが揃っていないと、テストが正常に動作しなくなってしまいます。サンプルのテストシナリオを1行削除します。comment"));このシナリオでは、submit後に検証を行っているのですが、submit後のページロードを待機できていないため、このアサーションは大抵の場合失敗します。テストを動作させるだけなら、このアサーションは不要なので今回は削除します。事前準備その2(Appiumのバグ?)Appium本体のプログラムを2箇所修正します。テストスクリプトとAppium間でやりとりする際、Appium側でセッションIDを発行しています。詳細は、JsonWireProtocolの仕様を確認してください。AppiumのプログラムでセッションIDを発行している箇所を探すと、appium.jsに見つけることができます。UUID.create().hex;通常はこのセッションIDがそのまま利用されるのですが、Safariを利用する場合は、これが後で上書きされるようになっていました。}sessionIdOverrideに何が渡されるのか、プログラムを追いかけてみたところ、呼び出し元は以下のようなコードでした。});つまり、文字列ではなく、オブジェクトリテラルが渡されます。ログには、以下のように出力されています。Object]そして、このようなセッションIDが返されると、テストスクリプトでエラー終了してしまうようなのです。してこのようなプログラムになっているのか解析するのは諦めて、ひとまず上書きしている箇所をコメントしてみたところ、エラー終了しなくなりました。sessionIdOverride;GitHubにも似たような問題がレポートされていました。https://github.com/appium/appium/issues/1536実機で実行する場合、もう1つ問題が起きます。SafariLauncherのインストールです。Appium内部で、インストールにfruitstrapを利用しています。fruitstrapコマンド実行が異常終了するため、テストも失敗してしまいます。そこで、SafariLauncherの実機インストールは、Xcodeで行うことにして、fruitstrapコマンドが実行されないようにプログラムを書き換えました。//}.bind(this));};元のコードをコメントアウトして、コールバック関数をすぐに呼び出すようにしています。シミュレータで実行まず、Appiumサーバを起動します。前述のとおり、SafariLauncherのzipアーカイブが./build/SafariLauncher以下に配置されていなければなりませんので、起動時のカレントディレクトリに注意してください。appiumそして、テストを実行します。-Dtest=jp.co.iti.appium.SafariTestテストが終了しても、シミュレータは起動したままとなります。Safariがフォアグランドになっていて、Appleのホームページが表示されます。実機で実行する場合は、ios-webkit-debugger-proxyを起動しておきます。(実機のUDID):27753次に、Appiumサーバを起動します。(実機のUDID)そして、テストを実行します。-Dtest=jp.co.iti.appium.SafariTestテストが終了しても、Safariがフォアグランドになっています。ネイティブアプリやハイブリットアプリでは、起動したテスト対象アプリは、テスト終了と同時に終了しますが、Safariは間接的に起動しているだけなので、これは仕方のないことなのかもしれません。キャプチャできません(解決策あり)ネイティブアプリ編、ハイブリットアプリ編では、キャプチャ画像の取得は問題なく実現できました。Safariのテストでは、キャプチャが失敗します。ログを解析すると、気になる箇所を見つけました。frontmost"というメッセージの後、Instrumentsが終了しています。Instrumentsには、操作対象としてSafariLauncherを指定していますから、Safariがフォアグランドになっているのは想定外だ、ということなのだと思います。キャプチャを取得する際は、AppiumはInstrumentsにリクエストするので、キャプチャ取得できなくなっていると考えられます。Instrumentsを終了させないための対策、あるにはありました。SafariLauncherは、openURLでSafariを起動しているのですが、しばらく待って(カウントダウンして)からSafariを起動しています。「なぜこのようなことをやっているのだろう?」と思っていたのですが、実はこの「待ち時間」がInstrumentsを終了させないために重要だということに気付きました。待ち時間は、SafariLauncherの設定画面で変更できます。(以下のスライダーで変更)つまり、Instrumentsが起動されて対象アプリを確認するときにはSafariLauncherがまだフォアグランドにいる状態にして、その後Safariに移行することで、Instrumentsが終了しないようにする作戦です。私の環境では、デフォルトの設定だと待機時間が短すぎて、Instrumentsが対象アプリを確認する瞬間には、Safariに切り替わってしまって、上記のログのようになってしまっていました。そこで、待ち時間を長めに調整して何度かトライしてみたところ、Instrumentsを終了させずにテスト継続することができました。それにしても、無理やりな感は否めません。トラブルシューティングテストが失敗したときなどにInstrumentsのプロセスが残ってしまうことがあると書きましたが、シミュレータのプロセスが残ることもあるようです。この状態でテスト実行すると、以下のようなログが出力されて、テストは失敗します。com.apple.iphonesimulator.launchd.2c713540.この場合、問題のプロセスを見つけてkillしてください。launchd_simまとめ以上でAppiumに関する投稿は一区切りとします。余力があれば、Android編を続けたいと思いますが、他のトピックに興味が向いてしまう可能性もあるので、ひとまずはこれで終わりということにしておきます。今回の「Appiumお試し」は、簡単ではありませんでした。何かしら問題が起きて原因を調査するという繰り返しでした。現在も活発にアップデートが行われているようですから、将来はもう少し簡単に使えるようになるかもしれません。今回は実用面の評価はほとんどできませんでした。したテストを実施しようとすると、「あれができない」「これができない」といった問題に直面することになるでしょう。やって苦労して作成したテストシナリオが将来にわたっても利用可能かも気になるところです。モバイルデバイスのOSは、アップデートが激しいですから、自動テストツールがその変化に追いついていけるのか、キャッチアップのためのコストがかかりすぎないか、といったことも気にしなければならないでしょう。自動テストが動くさまは、見ていてなかなか気持ちが良いのですが、実際に導入するにはそれなりの覚悟が必要だなと感じました。CrashlyticsKitでベータ版配信(iOS編)こんにちは、間藤です。iOS編再び間藤です。前回に引き続きAppiumです。今年のはじめにAppiumをi...2014-07-10AppiumでChromeの自動テスト間藤です。前回はSelendroidについて取り上げましたが、モバイ...2014-07-07Selendroidに関する補足(おまけ)間藤です。先日Selendroidをなるべく簡単に試すための手順を紹...2014-07-03Monacaのセミナーに行ってきました間藤です。以前にこのブログでMonacaを紹介しました。読者になるはてなブログをはじめよう!IntelligentTechnologyさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。