[原文] 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リポジトリでチェックできます。よい（ロケーターイライラなし）テストを！ |
翻訳記事 >
