AIテストツールのMagic Podを使ってみた（かった）

こことか
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00359/071100004/

こことか
http://weekly.ascii.jp/elem/000/000/400/400673/

で話題になっていたAIテストツールMagic podというのが非常に興味深いので少し使ってみてレポートしたい。

まずこちらへGo
https://magic-pod.com

Githubのアカウントでログインできるので「無料版を使ってみる」から登録してみる。（Githubのアカウントなしでも普通にメールで登録可能。）

組織名とproject名とテスト名を聞かれるので適当に登録し、

Create。

・・・デフォルトで英語？？つらいので日本語に設定変更(^^♪
・・・あれ？見当たらない。。。動画等では日本語のインターフェースになっているようなので、日本語インターフェースも用意されてるんだと思うが、メニュー全部見ても日本語への設定変更の項目が私には見つけられなかった＠2018年7月現在。。。
しょうがないので今日は英語のまま行く。

今回はAndroid携帯を動かしてみようと思う。
まずはPC側の環境構築が必要。
「Magic Pod Desktop」なるパッケージが必要とのことでダウンロードしてみる。
https://www.trident-qa.com/magic-pod-help/

Android studioも必要
https://www.trident-qa.com/magic-pod-android-set-up/

この手順に従って、JavaとAndroid SDK一式(tools, platform-tools, build-tools, API)をインストール。

・・・と、恥かしながらここまでやってから気づいた「なお、Windows PCは未対応です。」との表記・・・( ；∀；)
うーん。最近MACのシェアが馬鹿にならないくらい上がってきているとは聞いていたが。。。うーん。

仕方がないので、実機を動かすのは諦めて、AIと呼ばれている部分、画面の画像からUIを抽出する部分を弄ってみたい。

まずは、Yahoo乗換案内。

この画像を読み込ませてみると・・・

こんな感じで読み込まれ、基本的にすべてのUIを識別出来ていた。すばらしい！

まぁこれは境界がくっきりしていてわかりやすいし、楽勝か。
もうちょっと難しそうなゲーム画像を用意してみる。

Age of CivilizationsというAndroidゲーム。

こちらも明確なボタン類は大体行けているようだが、地図の境界はやはりちょっと難しい様だった。
とはいえ人間と比べたらまだまだにせよ、かなり高確率でUIを認識してくれているように見える。

この後の作業としてはキーワード駆動テストの様な要領で、アクションを選択後、UIをドラッグ＆ドロップし登録することで、簡単にテストスクリプトが書ける様になっている。
↓こんなイメージ。

・・・というわけで環境の都合で（MAC持ってない）動作確認まではできなかったが全体の所感としては、現時点では「UI認識に画像解析AIを用いたキーワード駆動テストフレームワーク」といえるものであると理解できた。
（ASCIIの記事なんかを見ると「AIで自動ソフトウェアテストを実現するウェブサービス「Magic Pod」」等というタイトルが記載されており、テスト対象分析～テスト設計～実行までAIがカバーするかの様な印象を惹起させるが、これは少なくとも現時点では実現されておらず、誤解の元になりかねない。）

とはいえ、ゆくゆくはゲーム攻略AIみたいな仕掛けと組み合わせてテスト実行とかまでAIが支援できるようになると、素晴らしいことになりそうだ。

MicrosoftのリリースしたOSSテスト自動化ツールWinAppDriver UI Recorder

http://www.atmarkit.co.jp/ait/articles/1806/22/news036.html
率直に言うと上記の記事を読んで、まずこれがどういうものかについて、今一不勉強でよくわからなかったので調べてみた。

ざっくり言うとWebdriverというAPIを用いて自動テストを走らせるためのソフトである、WinAppDriver用のC#のソースコードを、操作を記録して自動生成するツールということになるようだ。

Webdriverというのは、ざっくりいうともともとはSeleniumという、Webに対する自動テストOSSで使われている、JAVAやC#を含む好きなプログラミング言語でテストを記述し、WebdriverAPIを使って、同じテストを
　Linux→Chromeドライバ
　Windows→IEドライバ
　etc...
というような各プラットフォームのドライバ（要するに自動操作を受け付けるためのサーバです）に実行させる仕組み。

このWebdriverの仕組みは前述の通りもともとはWebアプリケーションの自動テストで使われていましたが、現在ではAppiumという名称でAndroidやiOS用のドライバやWindows向けには WinAppDriver等々の各種プラットフォーム向けのドライバーが開発されて、モバイルやアプリケーションの領域まで拡張されてきた。
また、このWebdriverの仕組みはW3Cでも標準化されるなど（https://www.w3.org/TR/webdriver/）テスト自動化ツールではかなり主流といって良い仕組みになっている。

例えば電卓を起動して123+456を計算し、電卓を閉じるという操作を行った場合の出力コードは次のようなものになっているようだ。

// KeyboardInput VirtualKeys="Keys.Command+ "" + Keys.Command"calc"Keys.Return" CapsLock=False NumLock=True ScrollLock=False
Console.WriteLine("KeyboardInput VirtualKeys=\"Keys.Command+ \"\" + Keys.Command\"calc\"Keys.Return\" CapsLock=False NumLock=True ScrollLock=False");
winElem0.SendKeys(Keys.Command+ "" + Keys.Command);
winElem0.SendKeys("calc");
winElem0.SendKeys(Keys.Return);

// KeyboardInput VirtualKeys=""123+456"Keys.Return" CapsLock=False NumLock=True ScrollLock=False
Console.WriteLine("KeyboardInput VirtualKeys=\"\"123+456\"Keys.Return\" CapsLock=False NumLock=True ScrollLock=False");
winElem0.SendKeys("123+456");
winElem0.SendKeys(Keys.Return);

// MouseHover on "表示は 579 です" at (193,2)
Console.WriteLine("MouseHover on \"表示は 579 です\" at (193,2)");
string xp3 = "/Pane[@Name=\"デスクトップ 1\"][@ClassName=\"#32769\"]/Window[@Name=\"電卓 ‎- 電卓\"][@ClassName=\"ApplicationFrameWindow\"]/Window[@Name=\"電卓\"][@ClassName=\"Windows.UI.Core.CoreWindow\"]/Text[@AutomationId=\"CalculatorResults\"][@Name=\"表示は 579 です\"]";
var winElem3 = MyDesktopSession.FindElementByXPath(xp3);
if (winElem3 != null)
{
   //TODO: Hover at (193,2) on winElem3
}
else
{
    Console.WriteLine($"Failed to find element {xp3}");
    return;
}

一見してわかる通り、そのまま使えるケースはよくあるキャプチャ＆リプレイ系のツールと同じく、恐らく稀で、現実的にはプログラミング言語によるテストコードの開発を支援するツールという位置づけになりそうだ。

開発プロセスにもよりそうだが、Webdriver回りのフレームワークでは、基本的に開発者がテストコードを作るあるいは、テストコードを先に作ってそれを満たすソフトを開発するというのが想定されているようで、従来こういったキャプチャリプレイ系のツールというのはこれまであまり出てきていない様に見える。

SeleniumではSelenium IDEやSelenium builderというキャプチャ＆リプレイツールが存在するものの、あまり活発とは言えない状況に見える。
半ば想像ではあるがこの理由は開発者がテストコードを作るのであれば、基本的にキャプチャツールはそれほど必要ないのと、キャプチャは当然ながらある程度動くプロトタイプが仕上がってからでないと使い物にならないため、開発初期の単体テストやフォーム単位の動作確認等ではあまり役に立たないという事情があるのではないかと思う。
そういった意味では今後、Microsoftがどのくらいこれをメンテナンスし続けていくかは注目に値しそうだ。

※もしご存じの方で理解が違う点があれば、突っ込みいただければ幸いです。