翻訳記事
Appium Pro #39: Appiumテスト自動化への初期段階のAI
[原文] Appium Pro Edition 39: Early-Stage AI for Appium Test Automation [翻訳] 小笠原徳彦 翻訳者より： Appium ProはAppiumの創始者Jonathan LippsによるAppiumのトップコンサルタント企業Cloud Greyによるオンラインニュースレターです。Webでも読むことができますし登録するとメールで受信することができます。もしAppiumをお使い、あるいは関心をお持ちなら、ぜひ購読されることをおすすめします。
たぶん昨今の技術界でもっとも「バズっている」バズワードは “AI” (Artificial Intelligence；人工知能）または “AI/ML”（Machine Learning；機械学習が加わったもの）でしょう。我々のほとんどにとって、これらの語句は私たちの技術的な仕事の中の困難な部分をなくすことを約束してくれる妖精の魔法の鱗粉のように聞こえます。正確にいうと、AIは（私の考えでは）かなり誇大であるか、少なくともその方法論と応用はひどく誤解されており、実情よりもより魔術的だと考えられてしまっています。 そんなわけでAppium Proのこの号がAIをAppiumでどうやって使うかのすべてをお伝えすると言ったら驚かれるでしょうね。私自身にとってもちょっとした驚きなのですが、Test.aiの仲間たちとの作業により、Appiumプロジェウトは特にAppiumで用いることができるAIを利用した要素探索プラグインを開発して来ました。どんなものなんでしょうか？ 最初に、「要素探索プラグイン」というのはどういう意味かについて議論しましょう。Appiumの最近の機能追加で、私はAppiumに第三者開発者がAppiumに「プラグイン」を作ることができる機能を追加しました。これにより要素を見つけるために独自のケイパビリティと一緒にAppiumドライバーを使うことができます。以下に示すように、ユーザーはAppiumディレクトリ以下で単にプラグインをNPMモジュールとしてインストールすれば使えるようになり、thecustomFindModulesケイパビリティを用いてプラグインをAppiumサーバーに追加できます。（完全なスコープについてはelement finding plugin docs（要素検索プラグインのドキュメント）を読んでください） この新しい構造で、私たちが最初に作業したプラグインはTest.aiによる機械学習モデルを用いたもので、これはアプリケーションのアイコンを、オープンソース化されている教師データにより分類するものです。入力として一つのアイコンを取り、そのアイコンが表現している意味（例えば、ショッピングカートボタンとか、「戻る」の矢印ボタンなど）を我々に教えてくれるモデルです。このモデルにより私たちが開発したアプリケーションがAppium Classifier Pluginで、新しい要素検索プラグインフォーマットに従っています。 基本的には、このプラグインはスクリーン上にあるアイコンをその見た目から見つけるために使うことができ、アプリケーションの構造について知っていたり、セレクターとして用いるための内部的な識別子を開発者に聞いたりする必要はありません。いまのところは、このプラグインは要素を見た目から見つけることだけに限られており、そのためただ一つのアイコンを表示する要素だけに用いることしかできません。幸いなことに、モバイルアプリではそういった要素はとても一般的です。 このアプローチはすでにある要素検索ストラテジー（アクセシビリティIDやイメージによるもの）よりも多くの場合より柔軟です。AIモデルはコンテキストの情報なしで認識できるように訓練されており、またただ一つの正確なイメージスタイルとマッチするようにする必要もないからです。これが意味するところは、このプラグインで「カート」アイコンを見つけようとするとき、アプリケーションやプラットフォームをまたいで、細かな差異を気にせず利用できるのです。 では具体的な例で見てきましょう。ありうるユースケースで最もシンプルな物を表しています。iOSシミュレータを起動すれば、次のようなPhotos（写真）アプリケーションにアクセスできるはずです： 小さな拡大鏡アイコンが上の方の近くにあるのにお気づきでしょう。これをクリックすると検索バーが開きます： では新しいプラグインを用いてこのアイコンを見つけてクリックするテストを書いてみましょう。最初に、プラグインのREADMEにあるセットアップ手順に従う必要があります。それから、Photoアプリに対するテストを実行するためのDesired Capabilitiesを次のように設定します： DesiredCapabilities caps = new DesiredCapabilities(); caps.setCapability("platformName", "iOS"); caps.setCapability("platformVersion", "11.4"); caps.setCapability("deviceName", "iPhone 6"); caps.setCapability("bundleId", "com.apple.mobileslideshow");ここでいくつかの新しいケイパビリティ： HashMap<String, String> customFindModules = new HashMap<>(); customFindModules.put("ai", "test-ai-classifier"); caps.setCapability("customFindModules", customFindModules); caps.setCapability("shouldUseCompactResponses", false);customFindModulesが内部に構造を持つケイパビリティであることが見て取れます。このケースでは「ai」がテスト内部でつかうことができる短縮名で、「test-ai-classifier」が、要素の検索を我々が要求した時にAppiumがプラグインを見つけ、読み込むのに必要な完全修飾された参照です。これらをやってしまえば、要素を見つけるのはとってもシンプルです： driver.findElement(MobileBy.custom("ai:search"));ここで新しい custom ロケーターストラテジーを用いているので、Appiumは予めサポートしているロケーターストラテジーではなく、プラグインを私達が使いたいのだなと知ることができます。そして、セレクターの頭に「ai:」とつけているので、このリクエストで私達が使いたいプラグインを特に知ることができます（プラグインは複数存在しうるので）。もちろん、実際にはこのテストでは一つしかプラグインを使っていないので、この接頭詞は取り除くことができます（加えて、他のfindコマンド形式を用いることもできます）。 driver.findElementByCustom("search");（注： これらのコマンドをJavaクライアントコードで利用したいなら、まだリリースされていないmaster版のクライントを利用する必要があります。これらのコマンドはまだ入ったばかりだからです。どうやったらいいかは Appium Proの build.gradle を参照） それで、これだけです！ 先に述べたように、この技術は今のところ重大な制約があります。たとえば、モデルが検出できるようにあらかじめ訓練されているアイコン群のうちの一つである要素しか確実に見つけることはできません。その上、このプロセスは、プラグインのコード（画面上のすべての要素を、モデルに情報を送るために取り出さなければいけません）と、モデルそのもの、ともにかなり遅いです。しかし、これらの領域のすべては今後改善されていきます。そしてこのプラグインそのものがあなたの日々に役に立たなかったとしても、これはテスティング空間におけるAIの実際の応用は単に可能ということではなく、実際に動いているということをデモしているのです！ いつものように、完全（であると望みます）に動く例がAppium ProのGitHubリポジトリでチェックできます。よい（ロケーターイライラなし）テストを！ |
Appium Pro #33: 画像による要素検索 Part 2
[原文] Appium Pro Edition 33: Finding Elements By Image, Part 2 [翻訳] 小笠原徳彦 翻訳者より： Appium ProはAppiumの創始者Jonathan LippsによるAppiumのトップコンサルタント企業Cloud Greyによるオンラインニュースレターです。Webでも読むことができますし登録するとメールで受信することができます。もしAppiumをお使い、あるいは関心をお持ちなら、ぜひ購読されることをおすすめします。 この記事はAppiumにおける特定のイメージと一致する画面上のリージョンを操作する2部構成のシリーズの第2部です。まだ第1部(原文)を読まれていない方は、まずそちらをお読みください！ 今回は、 -imageロケーター戦略により利用できる、Appiumの「画像による要素検索」機能の高度な利用テクニックをいくつか紹介します。「高度な」テクニックが必要になるのはなぜでしょう？ 問題となるのは、画像認識というのはちょっとばかりややこしく、正しく画像一致をするためにはさまざまの方法があるからです。例えば、デバイスのスクリーンショットよりも大きなスケールの参照画像を使うということもありえます。これにより、（OpenCVライブラリによって実装されている）画像一致のアルゴリズムが爆発してしまいます（スクリーンショットよりも大きな参照画像が与えられたときに、どうやってスクリーンショットの中でその画像を見つけることができるんでしょう？）。あるいは、画像によって見つけられた要素が、それを見つけたあとから、 tap コマンドを送ろうとするまでの間に位置が動いたとしたら？ あなたが操作したい要素の一部分になっていない画面上の座標をクリックすることになってしまうでしょう！こういったそれぞれのケースについて、Appiumは助けとなるようなロジック（たとえば、参照画像を縮小したり、タップを実行しようとするときに自動的に画像を再検索して、必要なら位置を更新するようにしたり）を実行します。Appiumはそれ自体で、もっとも堅牢かつ信頼できる画像検索の体験を、あなたがそういった技法に詳しくなかったとしても、提供することができます。問題は、こういった「修正」のそれぞれにより、Appiumは、処理や、自動化エンジンとの対話に、見過ごせないほどの時間を費やしてしまう可能性があるということです。実行時間を考えて、デフォルトでは標準的な要素検索機能だけがオンになっています。ということで、その理由はともあれ、標準機能が十分でないときに、利用可能なオプションについて見ていきましょう。 これらのオプションはAppiumの設定（Settings）APIを通じて利用可能になっています。このAPIは、（Seleniumではなく）Appiumにおいてだけ利用可能なもので、ケイパビリティをテスト中に切り替えたり、リセットしたりできるものです。Desired Capabilitiesと同じような型のパラメータを用いることができますが、Appiumクライアントに任意のときに、望むときにはなんども設定を更新させることができることが違います。Javaクライアントでは、設定APIは HasSettingsインターフェースの背後に隠れています。AndroidDriverまたはIOSDriverオブジェクトを使っているなら、これらはこのインターフェースを実装しており、setSettingメソッドを提供しています。（いいかえれば、AppiumDriverオブジェクトを用いている場合は、最初にHasSettingsにキャストする必要があるということです）。使い方はものすごくシンプルです： driver.setSetting(setting, value);基本的に、設定名（実際には、 Setting列挙型の要素）と値を与えます。画像要素検索を操作するためにどうやってこれらを使うかを見ていきましょう。画像一致のしきい値の変更OpenCVでは、画像の一致というのは二値の結果として得られるわけではありません。代わりに、どれだけ一致しているかの尺度が、0から1の間の値として存在します。この値自体は恣意的ではありますが、1はピクセル単位で完全に一致していることを、0はまったく一致していないことを示します。経験的に、Appiumは標準の一致のしきい値を 0.4 に設定しています。これはつまり、デフォルトでは、0.4 より小さい一致度のどんな結果も不一致として判定されるということです。理由はともあれ、状況によっては 0.4 は厳しすぎる（要素を見つけることができない）と思ったり、あるいはゆるすぎる（要素がないのに、あると判定されてしまう）ということがあるでしょう。そのときには IMAGE_MATCH_THRESHOLD 設定を用いて調整できます：driver.setSetting(Setting.IMAGE_MATCH_THRESHOLD, 0.2);どんな値を入れたらいいかはどうやったらわかるでしょう？ 試行錯誤が必要でしょう。この値は恣意的（かつ非線形）だからです。幸いなことに、それぞれの画像検索操作のたびに上に示した設定APIを用いて異なったしきい値を設定できます。 画像要素タップ戦略の変更画像要素を見つけたとして、そこに対して element.click() を呼んだとき、Appiumはその要素をどうタップしたらよいかをどうやって知ることができるでしょう？ 残念ながら、魔法があるわけではなく、Appiumは単に一致したスクリーンの領域の境界を得て、その領域の中心座標に対してタップを行うだけです。Appiumにはある点をタップするためにいくつかの方法、例えばW3CのActions APIや、もっと古いTouch Actions API（これら二つのAPIにまつわる歴史的な説明についてはAppium Proのこの記事の冒頭をご覧ください）、があります。Appiumのデフォルトのタップ戦略（W3C Actionsを利用）を使うことができない場合（つまりW3C Actions APIをサポートするように更新されていないドライバーを使っている場合）、 IMAGE_ELEMENT_TAP_STRATEGY 設定を用いて、常に古いAPIにフォールバックさせることができます：driver.setSetting(Setting.IMAGE_ELEMENT_TAP_STRATEGY, "touchActions");（設定可能な値は "w3cActions” か “touchActions” の二通りです） スクリーンショットとデバイスサイズの不一致の修正Appiumの画像一致アルゴリズムは二つのイメージを操作します： ベース画像（その中の要素を探したいと思っているもの）と、参照画像またはテンプレート（探したい要素に紐付いているもの）です。ベース画像については気にする必要はありません: Appiumはデバイスのスクリーンショット、つまりそのときにスクリーン上で起きていることを示すもの、を利用するからです。しかし、ベースイメージ（スクリーンショット）とスクリーンそのもののディメンジョンが異なっていたらどうでしょう？ そのときは一致アルゴリズムはスクリーンショットを元に一致した座標を返しますが、それはデバイスのものとは異なってしまいます。もし不運にもデバイスがタップされていたなら、意図とは違うどこかに対してタップされてしまうでしょう。 スクリーンショットとスクリーン自体のディメンジョンが異なるというのはどうして起きるのでしょうか？ さまざまな理由がありますが、少なくともプラットフォーム間でピクセルの拡大縮小が扱われる方法によります。たとえばiOSでは、スクリーンは375ピクセル幅（「論理的」幅）だと返してきますが、ありがたいことに得られるスクリーンショットは750ピクセル幅になるのです（「Retina」幅！）。 これらのディメンジョンを正しくすることはとても重要なのでAppiumはデフォルトでそうするようになっています。しかし、このためにAppiumにCPUサイクルを費やせたくないというときは、これをオプトアウトできます： driver.setSetting(Setting.FIX_IMAGE_FIND_SCREENSHOT_DIMENSIONS, false);参照画像サイズの修正上でも述べたように、一致アルゴリズムが動くようにするには、参照画像（テンプレート）はスクリーンショットよりも小さくなくてはなりません。参照画像を作るとき（たとえば要素のスクリーンショットを手動で切り抜いたりするとき）、テンプレートのディメンジョンについて絶対に確信をもてないときもときどきあります。テンプレートをキャプチャーしたときのやりかたによってはAppiumが判定するスクリーンショットのディメンジョンよりも大きいディメンジョンを持つこともありうるのです。 もし、テンプレート画像のサイズによらず、正しく動作するようにしたいのであれば、Appiumにテンプレート画像をリサイズさせることができます： driver.setSetting(Setting.FIX_IMAGE_FIND_SCREENSHOT_DIMENSIONS, false);デフォルトでは、テンプレートが誤っている可能性があるということを示す有意義なフィードバックが得られなくなってしまう可能性があるので、Appiumはこのようなリサイズは行わないようになっています（リサイズに余計な計算時間とエネルギーが消費されることはともかくとして）。 画像要素のゾンビ性のチェックSeleniumの世界から来た人には、「ゾンビ（Stale）要素」というコンセプトをご存知の方もいるでしょう。これは、ある要素が見つかってから、なんらかの操作を行うまでのあいだに、どうにかしてなくなってしまったような要素のことを言います。このような場合、行いたかった動作（タップ、キー入力、など）を完了することはできず、 StaleElementException がスローされます。画像要素についても同じような状況が起こりえます。ある要素（画像一致アルゴリズムにより返された座標の組によって表現される）が、見つかってからタップされるまでの間に消えてしまったときはどうでしょう？ Appiumで要素がなくなったあとに座標をタップすることを考え、タップを要求されたときにはもう一度マッチを行うようになっています。マッチがもう一度成功し、前と同じ座標が得られたときに、そこをタップするようになっています。マッチが失敗したとき、あるいは座標が異なっていた場合は、代わりに StaleElementException が返されます。ちょっとしたパフォーマンス向上のためにこの安全チェックをやめたい場合は、以下のようにオフにできます： driver.setSetting(Setting.CHECK_IMAGE_ELEMENT_STALENESS, false);要素の自動的なリフレッシュデフォルトでは、Appiumはイメージがゾンビになった場合例外によってそれを知らせます。しかし、要素が消えたわけではなく、単に場所が移動しただけならどうでしょう？ その場合はたぶん前の位置の代わりに新しい位置で単にタップすればOKでしょう。タップを要求したときに自動的に新しい一致位置を決定してほしい場合は、 UPDATE_IMAGE_ELEMENT_POSITION 設定によって指定できます：driver.setSetting(Setting.UPDATE_IMAGE_ELEMENT_POSITION, true);この設定は通常は false になっており、要素の検出からタップまでの間になにかが変わったことを知らせることで、通常の状態を維持するようになっています。 |
Appium Pro #32: 画像による要素検索 Part 1
[原文] Appium Pro Edition 32: Finding Elements By Image, Part 1
[翻訳] 小笠原徳彦
翻訳者より： Appium ProはAppiumの創始者Jonathan LippsによるAppiumのトップコンサルタント企業Cloud Greyによるオンラインニュースレターです。Webでも読むことができますし登録するとメールで受信することができます。もしAppiumをお使い、あるいは関心をお持ちなら、ぜひ購読されることをおすすめします。 モバイル自動化の残念な現実の一つは、現実的にすべてのUI要素が自動化可能ではないということです！ これは、要素がアクセシビリティや自動化のサポートがないカスタムクラスから作られていることから起こりえます。ある要素に適用できる唯一に特定可能なロケーター戦略やセレクターがない（自動化エンジンの視点からはすべての項目がおなじに見えるけれども、ユーザーには違っている動的リストビューを考えてみてください）ことからも起こりえます。あるいは古典的なUIコントロールが一切ない2Dまたは3Dのゲームを想像してみてください--レンダリングエンジンによって描かれたピクセルがあるだけなんです！
 歴史的に、Appiumはこういったユースケースをサポートしようとしてきませんでしたし、XCUITestやUIAutomator2を通じた世界のサポートを提供するスタックしか持っていませんでした。もしこれらの技術で要素が見つけられないなら、Appiumは要素を見つけることができなかったのです。
しかし、これらの技術以外に、この問題を解決するのに用いることができるであろう巨大なハンマーが存在しています。ダモクレスの剣のように（ダモクレスのハンマー？）しばらく前からAppium開発者の頭から離れないでいたものです。使うべきか？ 使うべきでないか？ この巨大なハンマーとは、画像による要素検出です。要素を操作するために、その要素の画像的な特徴を用いるということが、これが巨大なハンマーである理由です。人間のユーザーが普通用いている戦略と同じなので、アプリケーションの種類も問いませんし、アプリ開発者がそれぞれの要素にテスト用のIDをつけるのを覚えているかどうかにもよらないのです。
Appiumチームはついにこの弾丸に噛み付いて、画像による要素検出機能の小さなセットをサポートすることに決めました。Appium 1.9.0から利用可能です。この記事では、これらの機能のもっとも一般的なユースケースを取り上げようと思います。画像による要素検索です。（このシリーズのPart 2では、この機能の変化形であるより高度なメソッドについて見ていきますが、いまのところは基本に限定します）。
画像要素（image element）とはなんでしょうか？ 画像要素はクライアントコードでは他の要素とまったく同じように見えますが、新しい
-image ロケーター戦略を用いていることだけが違います。典型的なセレクター（"foo" のような）の代わりに、この新しいロケーター戦略に用いられる文字列はBase64でエンコードされた画像ファイルなのです。特定の検索アクションに用いられるこのファイルは、Appiumが画面上の領域上から、あなたが探している要素にもっとも近いリージョンを探すためのテンプレートとして用いられます。つまり、もちろん、アプリの中で見つけたいものに一致するイメージを予め持っていなければならないということを意味します。Appiumはこのイメージを要素を見つけるのにどう使うのでしょう？ 裏側を覗いてみれば、用意した参照用/テンプレート画像にもっとも近く一致したスクリーンショット上のエリアを見つけるのに OpenCVライブラリーを用いています。OpenCVはとても洗練されているので、画面上のものとリファレンス画像がいろいろと異なっていてもマッチは成功するでしょう。たとえば回転していたりサイズが異なっている場合でもです。
例の準備はいいでしょうか？ では参りましょう。まだまだ新しい機能なのでクライアント、サーバーそれぞれの振る舞いはちょっと面取りされていないところがあります。それでも魔法のように働くんです！ まずはアプリ側ですが、アプリに写真のリストを、ランダムな順番で表示する新機能を作りました。ある写真をタップすると、アラートがポップアップして写真の説明が表示されます。こんな感じです：
 画像マッチングがなければ、こういったシナリオを自動化することはできませんでした。どのイメージもUIツリーの中で特定できる情報を持っていませんし、ビューをロードするたびに順番も変わってしまうので、特定のイメージをタップしたいと思ったときに要素のインデックスをハードコードすることもできません。画像による検索（find-by-image）が助けになります！ 実はこの戦略は、他の戦略を用いて要素を探すときと、同じように使います：
WebElement el = driver.findElementByImage(base64EncodedImageFile);el.click();ひとたび画像要素を得てしまえば、他の要素と同じようにクリックできます。（他のいくつかのコマンドも画像要素に対して動作しますが、当然、ほとんどの操作--例えば sendKeys--は利用できません。実際のUI要素への参照を持っているわけではなく、要素が位置していると信じている画面上のリージョンを持っているに過ぎないからです。）もちろん、こうやって書くためにはイメージファイルのBase64エンコード版を持っていなければなりません。Java 8なら単にこう書けます： // refImgFile という File があると仮定Base64.getEncoder().encodeToString(Files.readAllBytes(refImgFile.toPath())); 該当するコードは次のようになります（今のところ、ボイラープレートは省略しています）： private String getReferenceImageB64() throws URISyntaxException, IOException { URL refImgUrl = getClass().getClassLoader().getResource("Edition031_Reference_Image.png"); File refImgFile = Paths.get(refImgUrl.toURI()).toFile(); return Base64.getEncoder().encodeToString(Files.readAllBytes(refImgFile.toPath()));}public void actualTest(AppiumDriver driver) throws URISyntaxException, IOException { WebDriverWait wait = new WebDriverWait(driver, 10); try { // 写真ビューに移動 wait.until(ExpectedConditions.presenceOfElementLocated(photos)).click(); // 参照画像テンプレートを使って正しい画像が出てくるまで待機しクリック By sunriseImage = MobileBy.image(getReferenceImageB64()); wait.until(ExpectedConditions.presenceOfElementLocated(sunriseImage)).click(); // 正しいイメージをクリックしたかを結果として表示されたアラートを見て確認 wait.until(ExpectedConditions.alertIsPresent()); String alertText = driver.switchTo().alert().getText(); Assert.assertThat(alertText, Matchers.containsString("sunrise")); } finally { driver.quit(); }}上の例では、プロジェクトのリソースファイルとして格納された参照画像のBase64エンコード版を得るヘルパー関数があることをご覧になれます。もちろん、プロジェクト内にある参照画像を得るのに違う技法を用いても構いません。 |
Selenium 3がやってくる
Sauce LabsでAppium1.5がリリースされました
Appium1.5 Appiumチームは非常に自信を持ってAppium1.5のリリースをお知らせします。Appium1.5はこれまで半年以上計画されてきましたが，私たちにとってどれだけ重要なリリースなのかを共有させていただきたいと思います。Appium1.5では技術的なアーキテクチャを根本的に見直しています。プロジェクトが揺籃期から1.0に，そしてさらにバージョンを重ねて成長する中で，コアチームはコードが組織化されているよう維持し，新しい貢献者がプロジェクトに入りやすい状態を保ち，時流に応じてバグ修正と機能追加を行うことに注力してきました。しかしながら，多くのソフトウェアプロジェクトと同様に，私たちの努力にもかかわらず，私たちと足並みを揃えるのではなく，私たちに反するようにAppiumの基礎アーキテクチャが機能している時代が来たのです。 バージョン1.4.xは安定していたので，私たちは次代のAppium開発の速さに投資する良い時期だと感じました。Appium1.5の開発では，次の点をゴールに設定しました。
さらにたくさんの非常に特殊な技術的ゴールが設定されています。開発者の視点から現在どのようにAppiumが企画されているかについて詳しくは，developer's overviewをご参照ください。重要なことですが，私たちのゴールは新しい機能の追加ではありませんでしたので，書き直しは，新機能の追加で曇らされることなく行われていると考えました。内部的には刷新されていながらも，基本的にAppium1.5はAppium1.4.16と全く同じ振る舞いをします。もちろん，ここそこに多少の微調整を入れざるをえませんでした。書き直しの結果，長く放置されてきた，セッション操作を処理する様々な不具合が修正されましたので，私たちはサーバについての議論を非難し，URI経由でAndroidの意図を立ち上げる能力を追加しました。詳細，とりわけ今回のリリースで私たちが実装することにしたいくつかの変更点について，リリースノートをご覧ください。 Appium1.5はオープンソースコミュニティで何ヶ月間もベータ版で公開されていて，私たちは問題を活発に修正してきました。しかし，全てを書き直している以上，自動あるいは手動テストでカバーされていないエッジケースの存在が強く予想されますので，作成中のCIを使用する前に注意喚起しています。つまり，可能な限りハードに扱ってもよいのです。Appiumに関連した不具合はどんなものでもバグトラッカーにご報告ください。Sauce Labsで起こるのにローカルでは起こらない問題については，サポートにご連絡ください。Appium1.5をSauceで使うには，単純にご希望の機能をappiumVersionが「1.5」（この指定方法ですと1.5系のパッチがリリースされると自動的に取得します）もしくは「1.5.0」（こうした特定のリリースを指定する方法ですと，例えば1.5.1などの将来的なアップデートを手動で行う必要があります）にアップデートします。Sauce上で行うテストのためにちょうど求められる機能を取得するための詳細な情報は，Platform Configuratorご参照ください。 Appiumの未来 バージョン1.5はAppiumの将来にとって何か意味しているのでしょうか？ かなりたくさんのことを実際に示しているのです！ たくさんの新機能を搭載しているわけではないのにもかかわらず，プロジェクト史上の重要なターニングポイントであり，来たる数年間がどうなるかを私たちに提示しているのです。ここでは，Appium1.5で私たちが実現した仕事に基づき，前進することを楽しみにしている幾つかの事柄をご紹介します。
常にそうであったように，私たちが今後どうしていこうと考えているかがわかるAppiumプロジェクトのロードマップを確認できますし，現在準備しているリリース内容がわかるマイルストーンも見られます。私たちはAppiumプロジェクトの未来にとてもわくわくしていますし，Sauce Labsで開発を継続しています。続報をお待ちください。 Happy testing! |
AndroidとiOSのサポート
[翻訳] 伊藤 要約: 私たちは、Selendroid、iosdriver、Appiumを選択し、Selenium自体が持つAndroidDriverとiPhoneDriverはやめることにする。もしあなたがSeleniumのモバイル向けDriverを使っているのなら、3つのうちどのツールを代わりに使うか判断して欲しい。 長文版: 2007年、Steve JobsがiPhoneを発表し、珍しい存在だったモバイルにおけるWebを、メインストリームの人々が求め利用するものに変えた。現在のトレンドは、モバイルのWebの利用率が遠からずデスクトップからの利用率を上回ることを示している。それが遠回しに言っているのはつまり、モバイルのWebがあなたのサイトにおいて大きな比重を占めるようになり、それらのサイトをモバイルデバイス上でテストするのはとても賢明な考えだということだ。 Seleniumプロジェクトは、iOSとAndroid向けにWebDriverの実装を行うことで、モバイルWebの台頭に対応してきた。iPhoneDriverの最初のコード(iPad上でも動作する)は2009年の初めにプロジェクトに追加された。AndroidDriverは2010年の6月に追加され、主にGoogleのエンジニアによって開発されていた。現在でも、公式のAndroid SDKをダウンロードすると追加ダウンロードオプションの1つに「Google WebDriver」があることが分かる。 モバイルのDriverの最初の取り組みの後、おもしろいことが起こった。このDriverに対する実験的な拡張と修正が、Seleniumプロジェクトの外部で行われたのだ。最初に私が関わったのは、「nativedriver」だ。このツールは、慣れ親しんだWebDriverのAPIを使い、AndroidかiOSかによらず、奇抜なアプローチで、ユーザーがモバイル端末のネイティブUIとやり取りすることを可能にした。最初にこれを見た時、正気の沙汰じゃないと私は思ったが、nativedriverのエンジニアは、これが合理性のあるやり方であることをすぐに私に納得させた。そしてどうなったか?彼らは正しかったのだ。 残念ながら、このアイデアがうまくいくものだと証明された後、NativeDriverプロジェクトは失速してしまったが、このアイデアをモバイルテストツールをうまく動かすための部品として採用した3つのプロジェクトを誕生させることとなった。それがSelendroid、iosdriverそしてAppiumだ。これらはネイティブUIだけでなく、ハイブリッドや純粋なWebのUIのテストも可能だ。最近になり、Windows Phone 8のモバイルWebアプリケーションをテストするWindows Phone WebDriverも加わった。 3つのプロジェクトには共通点がある: それは、メインのSeleniumプロジェクトの同じモバイルのコードに比べて、はるかに活発で、はるかにうまく動作し、はるかに多くのPushがあるという点だ。事実、AndroidDriverとiPhoneDriverの両方に貢献しているSeleniumチームの何人かは、他の3プロジェクトでも活動している。ユーザーが、後でテストを書き直す心配をせずに安心して適切なフレームワークを選べるようにするために、異なるDriver間の相互運用性を維持するための作業も行われている。 これはつまり、Seleniumプロジェクト自体のAndroidとiPhoneのDriverをメンテナンスし続けてもユーザーの役に立たないということだ。もっと優れた代わりがあるし、「公式」のDriverがプロジェクト内にあることは混乱を招く。さらにまずいことに、Selenium開発者がこれらのDriverを修正するスピードは遅く、関わる人々はひどく不満を抱いている。このような理由から、SeleniumプロジェクトではこれらのDriverのコードをレポジトリから削除した。そしてユーザーには、他の代わりとなるツールの評価を行うことを勧める。 もちろん、削除されたコードはレポジトリの履歴には残っているので、自分でビルドをしたいのなら、それは今でも可能だ。iPhoneDriverの最後のバージョンはef9d578、Androidのソースの最後のバージョンは00a3c7dだ。ビルドの手間を省くために、このリビジョンからビルドしたAndroidDriverをダウンロードページにアップしてある。 これらの変更は、プロジェクトとしてモバイルをサポートしないという意味ではない。これが意味するところは、私たちはモバイルのWebDriverのベストな実装をサポートし、それらはSeleniumプロジェクトの一部として書かれたコードではない、ただそれだけだ。 |
モバイルのWebDriver
[翻訳] 伊藤 WebDriverのAPIは元々はWebブラウザの自動化のために誕生したのだが、この数年間でモバイルデバイス上でも動作するように拡張されてきた。Appium、iosdriver、Selendroidなどのプロジェクトが、このアプローチがとてもうまくいくことを示した。Webにおいては、Selenium WebDriverをある1つのブラウザ(たとえばFirefox)で使い始め、それを他のブラウザ(たとえばInternet ExplorerやChrome)に切り替えることは容易だ。モバイルでも同様に、Androidの自動化フレームワークから他に切り替えられたら、それは素晴らしいことだ。 Selenium3の開発の一環として、私たちはappiumとiosdriver間、appiumとselendroid間の相互運用性を確実なものにするためのテストスイートの作成に着手した。作業を始めるにあたり、各ツールの主な作者たち、Marionetteプロジェクト(Mozillaによる、FirefoxとFirefox OS向けのWebDriverの実装)を代表してDavid Burns、Seleniumプロジェクトを主導するSimon Stewart、といった人々が、ロンドンのMozilla HQにある小さな部屋に2日間閉じこもった。彼らは各プロジェクトでバラバラの領域をすり合わせ、確実な相互運用を可能にする方法について合意した。血と涙は最小限にとどまったが、困難な作業がたくさんあった。 |
Selenium3のロードマップ
[翻訳] 伊藤 Selenium2がリリースされたのは2011年の7月。それから実に2年が経った。Selenium2の主要なバージョンアップであったWebDriver APIは今やW3C標準の基礎となり、Google、Mozilla、Operaによる実装とサポートが行われている。公式にサポートされているJava、C#、Python、Ruby、JavaScriptのリリースは34におよび、コミュニティはPerlやPHPなどの言語バインディングを提供している。コードの修正をした人は57人におよび、数えきれない人がオンラインのフォーラムに参加し、手助けやアドバイスを行っている。 そのような状況の一方で、世界はどんどん進歩し、今やSeleniumプロジェクトが未来の方を向くべき時が来た。現在私たちはSelenium3に向けて開発を進めており、そのように宣言できることをとても嬉しく思う。 私たちは、Selenium3を「ユーザーに焦点を合わせたモバイルとウェブアプリケーション向けのツール」にしようとしている。 これはどういう意味か?モバイルのユーザーにとっては、既存のWebDriver APIをモバイル向けに拡張している多くの異なるプロジェクト間の互換性を高めるために、Seleniumプロジェクトがテストスイートをホスティングするということだ。Appium、ios-driver、selendroidなどのプロジェクトの開発者たちが、このテストスイートの実現のために作業を進めることになる。 私たちはまた、Seleniumのバックグラウンドのテクノロジーを、できる限り安定した有用なものにする作業を進めている。そのために、Selenium3では、初期のSeleniumコアの実装による実装を削除し、その結果Selenium RCのAPIを非推奨とすることになるだろう。古いバージョンのものは独立したダウンロードとして入手可能だが、極めて緊急度の高い修正を除いて開発はストップする。Selenium RCのAPIは、内部でWebDriverを利用した実装をまだ提供するので、現在あるテストを動かすことは依然として可能だ。しかし、今こそ、これらのテストをWebDriver APIを直接利用したものに移行する時ではないだろうか。 Selenium IDEからテストをエクスポートしてHTML形式のスイートを実行している利用者には、それらのテストを実行できる別のランナーを提供するつもりだが、それらはメインダウンロードで提供されるのと同様、内部でWebDriverを使った実装になるだろう。繰り返しになるが、これまでの実装のものをダウンロードすることは今後も可能だが、3.0がリリースされればそれらの開発はもはや活発には行われない。 現在の計画では、今年のクリスマスまでに3.0の配布を開始するつもりだ。とても楽しいことになるはずだ。 |
1-8 of 8