T-DASHで生成AI（Gemini 2.0 Flash）を使ったAndroidアプリの自動テストに関する記事です。
Qiita Advent Calendar 2024 【今年もT-DASHを使ってみた！ by T-DASH Advent Calendar 2024】の21日目の記事になります。
T-DASHを用いたユニークな取り組みとして、先日発表されたばかり、Googleの生成AI「Gemini 2.0 Flash」を統合したAndroidアプリの自動テスト方法を紹介します。これから生成AIを活用したアプリが増えていく中で生成AIの自動テストをモバイルアプリでどのように実現するのかは大きな課題ですよね？
この記事では、Gemini 2.0 Flashを活用した「サマリー生成アプリ」の環境構築から実行までの簡単な流れと、それをどのようにT-DASHに統合して自動テストを行うのかを知ることができます。
最終的にこちらのサンプルアプリとT-DASHを使って検証していきます。
「その１」の記事「T-DASHを使ってGemini最新版を使ったAndroidアプリの生成AI自動テストを行う手順(その１)」ではmacでT-DASHのモバイル機能が使えなかったのでWineで無理やり動かした話
「その２」はAmazon EC2上でVirtual Desktop環境を構築してWindows上で正規の手段でT-DASHのWindows版を動かしてみました。
「その３」ではAmazon EC2上で動かしたバーチャル環境上に開発環境をセットアップし、T-DASHの設定も全て終わらせました。前回こそはこのプロジェクトが完了する予定でしたが、Androidエミュレーターが動作しないという問題にぶち当たってしまいました。
「その４」はAmazon EC2のベアメタルインスタンスを使って、Windows環境を構築し、エミュレーターも無事に動くようになり、T-DASHを通してモバイルアプリの自動テストを実行することができました。
「その５」となる本日の記事は画面操作をどのように行うかT-DASHの中身にいよいよ入っていきます。
T-DASHとは？
一言でいうとノーコードのテスト自動化ツールです。競合のツールとしてはMablやAutifyがあります。
T-DASHの特徴としては
日本語で書いたテストケースがスクリプトになる
というのが特徴となっています。この記事ではコストや機能で競合ツールと比較したわけではありませんが、月額4,840円というのはテスト自動化をノーコードで始めるにはお手軽な価格帯に設定されていると思います。
要素をタップ
画面名と要素名をタップとのことですが、何を入れたらよいかわからず、一旦何も入れずに動かしたのがこちらの状態です。
画面定義で要素名と値を定義
左のメニューにある「画面定義」をクリックしてみましょう。画面一覧で「画面」を定義します。例えば「ホーム画面」「購入画面」「ログイン画面」などのようにわかりやすい画面名にするのが良いです。
次に右側で「要素名＝ボタンやテキストなどのパーツ」の名称を決めて登録します。キャプチャでは「Try」となっていますが、今回、「Try」というテキストをタップする操作になるので、このような表示にしていますが、パーツ類等含め、他の方が読んで簡単に理解できるようにするというのはとても重要なので、例えば「テキストリンク(Try)」「画面遷移リンク」など、目的に応じたわかりやすい名称にするように心がけましょう。
表右側にはxpathを指定します。
Appium Inspector
要素の特定にはxpathを用います。xpathとは何でしょうか？そんなとき役に立つのがAppium Inspectorです。
Appium Inspectorの使い方はこちらの動画がとてもわかり易いです。日本語字幕も出せるので英語の動画ですが、気になる方はぜひこちらを見てみてください。
要約するとAppium Inspectorとは、モバイルアプリ（ネイティブ・ハイブリッド・ウェブ）のUI要素を可視化し、テストに必要な情報を効率的に取得できるツールです。主な機能は次のとおりです。
-
UI要素の可視化・階層表示
- アプリ画面上の各要素をツリー構造で表示し、ID・クラス名・XPathなどの属性を簡単に確認できます。
-
要素選択・操作
- 画面上をクリック（Select Elements）すると、対応する要素がハイライトされ、情報を取得できます。
- 座標を直接タップ（Tap by coordinates）する機能もあり、要素が取得できない場合でも強制的に操作できます。
-
Recorder機能でのコード生成
- 画面操作（タップ・テキスト入力など）をリアルタイムで記録し、Java/Python/JavaScriptなどのサンプルコードを自動生成します。
- 作成したコードをテストスクリプトにすぐ活用でき、開発効率を高めます。
-
画面のリフレッシュ・スクリーンショット更新
- アプリの状態を更新したい場合にRefreshボタンで最新の画面構造を取得し、要素情報を再度確認できます。
-
要素検索・XMLソースコピー
- IDやXPathなどで要素をピンポイントに検索可能。
- 画面全体のXMLソースをコピーし、アプリの要素構造をローカルで分析することもできます。
簡単に言えば、「どの要素をどう操作すればいいか」を可視化しつつ、自動テスト用のコードまで手早く生成できる便利なツールです。
入力エラー
テストを実行してエラーになるとこのようにエラーメッセージが表示されます。この場合は指定したフィールドに入力を行おうとしたところ、何らかの設定値に問題があるために実行できなかったというエラーになります。入力した値を確認してください。
以下のように一連の操作を一つづつ指定します。最初一つの機能を実行するまでは結構手間がかかりますので、これをどうやって効率化するのかは課題ですね。ただ、Appiumでコードを書いて指定するよりは、エンジニアが関わらずにChromeやAppium Inspectorでの操作で完結しますので、慣れてしまえば簡単な作業です。
テストケースを実際にいくつか作ってみるとわかりますが、多少エクセルを操作できる程度のパソコン力で設定することができますので、大量にテストケースを増やすときにはアルバイトを雇って大量にテストケースを作成することも安価にできるでしょう。
テストラン
テストランはここまでで作成したテストケースの組み合わせを作ることができる機能です。
自動テストとはいえ、UIを含む場合、大量のテストケースがあるとテストの実行にもそれなりに時間が必要となります。テストの設計をしていたりインシデントがあるととにかくテストを増やしてカバーしようとする方もいますが、本来事業の推進のために、必要なテストケースが何であるか、しっかりと整理を行い、通常の運用では最小限のテストを実行するようにしたり、開発した機能によりテストケースの組み合わせを分けるなど、様々な使い道があります。その組み合わせや実行順を自在に扱うことができるのがこちらの機能になります。
| テストラン一覧 | テストラン作成 |
|---|---|
 |
 |
詳しい使い方や説明はこちらの公式サイトを参照してください
テストケースエクスポート
テストスイートのページからテストケースをダウンロードすることができます
エクセルファイルの中身
テストケース項目と手順を取得することができます。
それぞれの該当ページは以下の通りです。
| 1 | 2 |
|---|---|
 |
 |
T-DASHで出力されたコードがそのままAppiumのコードが出力されると嬉しいのですがそういう機能は見つけることができませんでした。ただし、実行可能なテスト命令は限定的なので、出力されたエクセルファイルを元に機械的に出力することはできそうです。
T-DASHのカスタマイズ
左のメニューから動作定義でどのような機能を実行することができるか確認できます。
次に「カスタム動作」を見てみましょう。デフォルトではカスタム動作は存在しませんが、右上の新規カテゴリ作成から新たな機能を追加することが可能です。
新規カテゴリ作成
必須項目を入力します。
左側の「変更」と書いてある枠内をタップすると以下のダイアログが表示され、アイコンを選択することができます。
試しにハートを選ぶと以下のような表示に切り替わります。
一覧にも表示されます。
カスタム動作を追加
変数の利用方法について以下のように設定をします
| 画面定義を使用 | 通常の変数として使用 |
|---|---|
 |
 |
動作種類
そのような動作をするかを設定します
Pythonコードの設定
pipで必要なライブラリを指定します。T-DASHはPythonで動作していることがわかりますね。pipとはPythonのライブラリを管理する仕組みです。
自作ライブラリを設定して実行できるようにします。ここに自作の独自検証コードを設定します。
カスタム動作での可能性
T-DASHを触り始めた当初、機能も制限されていて、やりたいことが実現出来ない可能性が高いと考えていました。
しかし、Pythonでコードを自由に実行できるということは、Pythonで実現しうることであれば何でも自由に検証することが出来そうです。
ただし、問題点はノーコードのSaaSとして導入をする場合、エンジニアがあまり工数をかけられないという問題があるためにノーコードのテストツールを導入することが多いと思います。この場合、コードを書ける人材がQAチームには存在しない可能性が高いため、ハードルが上がりますが、エンジニアの手を借りることができる環境であれば、複雑な検証も一度コードを書くだけで自動化できるようになります。
例えば、スクリーンショットを撮ることが出来ますが、画面ごとのスクリーンショットを保存してその画像を比較するということも出来ますし、入力された値や出力された値を元にPythonでその値を操作して処理することも可能です。
カスタム例
- 名前などをランダムに生成して入力用の値として利用する
- 郵便番号を入力して正しい住所が補完されていることを確認
- 実行途中経過をSlackに通知
- 操作の途中で送信されるメール等の検証
- アプリ操作の途中でAPI処理を同時実行した自動テスト
- 実行結果や途中経過を生成AIに渡して検証内容を動的に操作
まとめ
ここまで５回に渡ってT-DASHのモバイルアプリ検証を行ってきました。Macで動かないところから始まり、EC2で動かすこと、エミュレーターが動かなかったことなど、手元にWindows環境がないことにより、様々な問題にぶつかってきましたが、今回の検証を通してT-DASHの良いところや改善の余地があるところなど様々な側面が見えてきました。
良い点
- 非エンジニアでも簡単にテストケースを組むことができる
- Pythonコードを自由に書けるので、エンジニアがいると思いつく限りの複雑な検証も実現可能
改善希望
- macでは動かない
改善希望は私の個人的な環境によるものなのですが、非エンジニアが中心に触ることを考えるとmac対応が必要なのかどうなのか、周りを見渡してもQAを業務として行う皆さんはwindowsユーザーが多いのでmac用まで作り込むよりはwinようでブラッシュアップしていくのが良さそうです。この個人的な点以外はツールとして素晴らしく出来ていますし、テスト自動化に関して、やりたいと思えるようなことは一通りできるようになっていると感じました。
ぜひこの記事を読んでいるみなさんもT-DASHを利用してみてはいかがでしょうか。