導入
こんにちは、もんすんです。
Advent Calendar 2024の今年もT-DASHを使ってみた！ by T-DASH Advent Calendar 2024の10日目の記事をお届けします！
これまで私は、スマホアプリエンジニアとして、Unit Test / Widget Test / Integration Testといったテストコードをきちんと書いてテストを実行することはありました。
実際に現在の業務でも同様にテストコードは書くルールになっています。
しかし、実機やシミュレータを使った動作検証は打鍵で行うことが多く、何かいいツールはないものかと常々感じていました。
色々調べてみると、スマホアプリの自動テストとしてAppiumというツールがあることを知りました。
Appiumは、モバイルアプリケーションの自動テストを行うためのオープンソースツールです。
Seleniumと同様な感覚で、テストスクリプトを作成して、実機およびエミュレータを利用してテストすることができます。
しかし、、、
テストコードを書くのがしんどい！！
んですよね。
何か他にテストコードを書かなくてよいツールはないか調べていたところ、T-DASHに辿り着きました。
今回はT-DASHでのテスト自動化を試してみた体験を共有します。
会社の資産を使うことはできないので、個人的に開発しているスマホアプリに対してT-DASHを利用してみました。
T-DASHについて
T-DASHは、バルテス株式会社が提供するテスト自動化ツールです。
コードレスでテストを自動化できる点で注目を集めています。
特にモバイルアプリの開発・テストを業務でも個人でも行う私にとって、その有用性や課題を探る良い機会となりました。
概要
T-DASHは、バルテス株式会社が提供するクラウド型テスト管理ツールです。
テスト管理に関するさまざまな情報を一元管理でき、それをGUIで簡単に確認できます。
これにより、チーム間での情報共有がスムーズに行えるようになり、プロジェクト進行に合わせて柔軟に対応が可能です。
さらに、日本語で書いたテストケースがスクリプトになるということも謳っており、初心者・初学者にもハードルが低い設計になっていることも、利点に感じます。
ソースコードベースのテストでは、ソースだけでなく、ドキュメント化などの管理が必要になります。
この場合、ソースコードの変更がドキュメントに反映されないと、内容が古くなり、実際の仕様と乖離が生じることがあります。
また、コードとドキュメントを常に更新する必要があり、開発者の負担が増えてしまいます。
ドキュメントが更新されていない場合、信頼できる情報源が不明確になり、誤解やバグの原因となることもあります。
料金
T-DASHには、初めての導入をサポートするトライアル期間も提供されています。
私も今回は、トライアル期間で使い倒してみようと考えています。
プランは3つ用意されており、最も最安で運用する場合、1ライセンスで、
- 月額4,840円
で、利用することができるとのことでした。
T-DASHの魅力
具体的な体験談に入る前に、T-DASHの特筆すべき魅力をご紹介します。
-
導入の容易さ 🖥️
他のテストツールと比較して、インストールや初期設定が非常にシンプルです。
初めはMacに導入しましたが、スマホアプリのテストは現在Windowsのみ対応のため、Windowsに再インストールしました。それでも環境構築に詰まることはなく、スムーズに進められました🎉 -
コストパフォーマンス 💸
無料トライアル期間を利用しましたが、コストは非常に抑えられていると感じました。実際のコスパについては継続利用しないと評価が難しい部分もありますが、それでも魅力的な価格設定だと思います。 -
ユーザー目線の設計
私のチームには、プロダクションコードの開発に集中したいと感じているエンジニアが多くいます。T-DASHは、そうしたニーズに応える使いやすさと実用性を両立しています。また、日本語対応の直感的なUI/UXは、効率的に自動テストを進めるための強力なツールと感じました。
T-DASH体験
テスト対象のアプリと環境
テスト対象のアプリは、私が個人で開発している単語帳アプリです。
諸事情あって、日本語の単語帳になっていますが、その辺りの詳細は割愛します。
アプリ自体は、Flutterで開発しており、今回はAndroid用のAPKファイルを作成し、テスト実行しました。
環境
- Windows 10
- Androidシミュレータ: Pixel 9 Pro XL
- Android 14
テスト準備の流れ
まずテストを実施するためのテストケースを作成していきます。
こちらを参考にしました。
1. T-DASHの起動とプロジェクト作成
インストールしたT-DASHアイコンをダブルクリックすると、T-DASHがバックグラウンドで起動し、自動的にChromeのタブが新しく開かれました。(ポートは8686がデフォルトのようでした。)
画面の指示に従って、プロジェクトを作成しました。
2. AppiumとAppium Inspectorの起動
以下のコマンドを叩いて、Appiumを起動します。
Appiumを起動しておくことで、T-DASHがスマホ実機、もしくはシミュレータ上でスマホアプリを操作可能になります。
appium --allow-insecure chromedriver_autodownload
特にAppiumに問題がなければ、以下のようにコマンドプロンプト上に特にエラーが出ることなく、Appiumが起動します。
さらにAppium Inspectorをアプリケーションアイコンから起動します。
こちらのAppium Inspectorは、スマホアプリの画面の要素を抽出するのに利用します。
Appium Inspectorはテスト実行時には不要ですが、テストケースの準備には必須のものになります。
正確には「必須」ではありません。
画面要素を別の方法で取得できるのであれば、Appium Inspectorは不要です。
3. Androidシミュレータ起動
次にテストで使用するAndroidシミュレータを起動します。
Android Studioを開きます。
プロジェクトを選択する画面で「…」をクリックし、Virtual Device Managerから使用したいデバイスを選択して起動します。
今回は、Pixel 9 Pro XLを選択しました。
4. T-dashで画面要素取得準備
次は、T-DASHの画面で、「画面要素取得の準備」を行います。
以下の画像のように「画面定義」を選択し、画面名を入力します。今回は1画面「WordListScreen」という画面を定義しました。
ここで、黄緑の線の部分には何の要素も定義されていない空の状態です。
ここからAppium Inspectorで取得した値を追加していきます。
「端末を選択し、画面要素を取得」を押し、表示されたモーダルの一番下の「端末接続情報をコピーしてAppium Inspectorを起動」をクリックします。
5. シミュレータ上でアプリを起動
直前の画像の記載されている手順を参考に取得したJSONをAppium Inspectorに貼り付けます。
保存ができたら、「Start Session」を押すと、晴れて以下のようにシミュレータでアプリが起動し、Appium Inspectorで画面要素を取得できるようになりました。
上記画像の左側がシミュレータ、右側がAppium Inspectorになります。
6. 画面要素の取得
ここからは直感的に操作ができ、気楽に自由に操作することができます。
① Appium Inspectorで取得したい画面要素をクリックします。
② 右側に出てくるxpathをコピー。クリックするだけで、コピーされます。
③ T-DASHの画面要素の「値」にコピーしたxpathを貼り付けて、「要素名」を自由に設定します。
以上です！
必要な画面要素分、この作業を繰り返すだけで、画面要素を取得することができます。
画面要素取得後
今回はこんな感じに画面要素を取得しました。
画面要素名は、今回は適当につけました。
ですが、通常のプロジェクトでは、命名ルールなどを設ければ、特にチーム内の齟齬は発生させることなく、運用ができると思います！
7. テストシナリオ作成
次に左ペインから「テストスイート」を選びます。
ここでは、テストスイート・テストシナリオを作成していきます。
以下の画像では、すでに「WordListScreenシナリオ」というテストスイートを作成済みですが、画面の指示通りに操作するだけで、ここは特に躓くことはないと思います。
また、新たに作成する場合は、「+」ボタンから追加が可能です。
さらに右側のエリアでは、テストケースを作成していきます。
テストスイートと同じく「+」ボタンからテストケースを作成することができます。
テストケースの具体的な処理に関しては、さらに各テストケースのタイトル(上画像の「単語詳細ボトムビュー表示」の部分)から設定していく仕組みになっていました。
テストケースの作成は、以下のような画面になります。
テストケースの作成がとても簡単なのが、本当に魅力的です。
上の画像にあるように左(紫の枠)に定められた「動作」があります。
これには、スマホアプリであれば、タップ・スワイプといったものまで含まれます。
この「動作」をクリックすると、右のエリアの「動作」(黄緑の枠)にその動作が追加されます。
たったこれだけで、テストが作れるわけです。
「動作」によっては、「どこをタップするか」 などの指定が必要なので、上の画像における赤枠のところに、[6. 画面要素の取得]で取得した画面要素などを設定していきます。
繰り返しになりますが、この操作だけでテストケースが作成できることがとても簡単で良いです。
【他の方からの声】
この辺りのデモンストレーションを会社のチームに共有しました。
そのときは、この画面の操作容易性に関して一番盛り上がっていました。
プロダクションコードを書きたいエンジニアメンバーからは、とても嬉しいという声も聞くことができました。
テスト実行
さて、テストを実行していきます。
この辺りの操作も、画面に従えば容易なので、操作の説明は割愛します。
うーん、テストとしては失敗してしまいました。が、まぁ記事としては良かったかもしれません。
テスト結果
NGになるとこのような感じで、どこで失敗したか、とその際のスクリーンショットがレポートとして残るようです。
今回はアプリの起動時間が結構かかったみたいで、テストケースの判定に画面表示処理が間に合わなかったみたいです。
(おまけ)全てOKだった場合
結構シンプルですが、OKであれば全体的にグリーンになり、スクショなども特にないようでした。
(おまけ)テストケースをDLしてみた
テストケースはエクセルファイルとして出力できるので、ダウンロードしてみました。
試してはいませんが、逆にテストケースのインポートもできるみたいでした。
テスト実行してみた感想
良さそうな点
-
シナリオ作成の手軽さ
上述しましたが、シナリオ作成画面において、左側の選択項目から操作項目を選べるため、シナリオ作成が非常に簡単でした。(下画像の紫の枠)
特に初心者にも使いやすく、コードレスの恩恵を実感しました。
-
画面要素の可視化
テストシナリオ作成時に、設定した画面要素がT-DASH内の左下に表示される仕様は分かりやすかったです。(上画像の赤の枠)
どの要素に対して操作を行うのかが一目で分かりました。 -
Appiumとの連携
AppiumやAppium Inspectorを活用してスマホアプリの自動テストを実行できるのは大きな魅力でした。
従来の打鍵テストから大幅に効率化できる点が特に良かったです。 -
通知バーの操作などの対応
通知バーの操作やバックグラウンドからフォアグラウンドに切り替わる処理もシナリオに組み込めるみたいでした。これらの機能が新鮮で、ユニークな使い道が広がりそうだと感じました。
もうちょっと...な点
-
タップできない要素への対応
Appium Inspectorの仕様かもしれませんが、一部タップできない要素があり、その場合は座標指定で操作を行う必要がありました。
これがもう少し直感的に改善されると良いと感じます。 -
GUI操作の制限
GUIで操作が完結する点は魅力的ですが、複雑なシナリオや特殊な要件では柔軟性がやや不足している印象でした。 -
Windows限定の対応
モバイルアプリのテストは現状Windowsのみ対応で、Macユーザーには制約があります。
今後、対応環境が広がるとさらに使いやすくなりそうです。
最後に
今回、初めてT-DASHを使用してモバイルアプリのテスト自動化を試してみました。
コードレスで直感的に操作ができる点や、Appiumとの連携による柔軟なテストケース作成は、とても魅力的でした。
対応環境や柔軟性における課題は、T-DASHの将来的なアップデートや拡張によって解決されることを願っています。
これからもT-DASHを活用し、業務にも適用していけたらと思います。
そして、同じように「テストコードを書くのがしんどい」と感じている方にとって、この記事が少しでも役立つ情報になれば嬉しいです。
最後まで読んでいただき、ありがとうございました！😊
参考