Appiumと最新のモバイルフレームワーク：自動化における課題の理解

モバイル自動化は過去10年間で大きく成熟しました。これは主に、使い慣れた言語とツールを使ってアプリを自動化できるAppiumのようなフレームワークのおかげです。同時に、React Native、Flutter、Jetpack Composeといった最新のUIフレームワークは、ネイティブUIレイヤーの多くを抽象化することで、モバイルアプリケーションの構築方法を大きく変革しました。

これらのフレームワークは開発を加速させる一方で、特にUI要素が動的に生成される場合や、安定した識別子を持たない場合など、テスト自動化において予期せぬ課題をもたらす可能性もある。

最新のフレームワークがUI要素を自動化ツールにどのように公開しているかを理解することで、チームは開発者にとって使いやすく、かつ自動化にも適したアプリケーションを設計できるようになります。

モバイル自動化ツールがUI要素を識別する方法

自動化フレームワークなど アピウム オペレーティングシステムが提供するネイティブの自動化フレームワークを介して、モバイルアプリケーションと連携する。

具体的な例を挙げますと、以下の通りです。

• Android: UIAutomator2
• iOS: XCUITest

これらのネイティブフレームワークは、アプリケーションのUI階層を自動化ツールに公開します。テストスクリプトは、次のようなロケーターを使用して、この階層内の要素とやり取りします。

• アクセシビリティID
• リソースID
• XPath式
• クラス名

中でも、アクセシビリティ識別子は、ビルドやUIの変更後も安定性を保つ傾向があるため、広く推奨されています。

Appiumを初めて使う読者は、概要をご覧ください。 Appiumアーキテクチャはこちら.

最新のUIフレームワークとロケーターの安定性

React Native、Flutter、Jetpack Composeなどのフレームワークは、開発者がより効率的にUIコードを記述できるようにする抽象化レイヤーを提供します。しかし、これらのフレームワークは多くの場合、実行時にネイティブUIコンポーネントを動的に生成します。

結果として：

• UI階層の構造はビルドごとに変更される場合があります。
• 一部の要素は安定した識別子を公開しない場合があります
• 自動生成されたビュー構造は、ロケーターの信頼性に影響を与える可能性があります。

これは、これらのフレームワークの自動化が難しいという意味ではありません。むしろ、 UI要素の安定識別子を明示的に定義する 自動化テストが依存するもの。

これは、AIベースの自己修復などの新しい機能にも影響を及ぼします。これらのシステムは、ロケーターが実際に変更されたことを認識するために、アプリケーション構造にある程度の安定性を必要とします。識別子やUI階層がビルド間で大きく変化すると、実行ごとに「修復」が必要になる可能性があり、自動復旧メカニズムの有効性が低下します。

ビルド間で識別子が不安定になる

自動化の不安定性の一般的な原因の一つは、UI要素がビルド間で変化する識別子に依存している場合に発生します。

例としては以下の通りです：

• アクセシビリティ識別子が定義されていない要素
• 動的に生成されるビュー構造
• 内部コンポーネント階層から派生した識別子

このような場合、基盤となるUI構造が変更されたために、あるビルドでは自動化テストが合格しても、別のビルドでは失敗する可能性があります。

これは、レイアウトの更新やフレームワークの最適化によってレンダリングされるネイティブコンポーネントが異なる場合がある、最新のUIフレームワークで特によく見られる現象です。

例：React Nativeにおける安定した識別子

React Nativeのようなフレームワークは、開発者が自動化のために安定した識別子を公開できるようにするプロパティを提供します。

具体的な例を挙げますと、以下の通りです。

<Button 
  testID="login_button" 
  title="Login" 
/>

この識別子は自動化フレームワークからアクセス可能になり、テストが要素を確実に特定できるようになります。

このような明示的な識別子を使用することで、UIレイアウトが時間の経過とともに変化した場合でも、テストの安定性が確保されます。

アクセシビリティとテスト容易性はしばしば密接に関連している

アクセシビリティ識別子を使用することは、自動化に役立つだけでなく、スクリーンリーダーなどの支援技術を利用するユーザーのユーザビリティ向上にもつながります。

両方 Apple の三脚と グーグル 意味のあるアクセシビリティラベルと識別子を公開することを推奨します アクセシビリティを向上させるためのモバイルアプリケーション.

実際には、これはアクセシビリティを念頭に置いてUI要素を設計すると、多くの場合、 自動化の信頼性を同時に.

実用的なデバッグのヒント：UI階層を検査する

ロケーターの動作がビルド間で一貫性を欠く場合、UI階層を調査することで、要素が自動化ツールにどのように公開されているかを明らかにすることができます。

これに役立つツールには以下のようなものがあります。

• Appiumインスペクター
• Xcodeアクセシビリティインスペクター
• Android UIAutomator ビューア
• Android Studio レイアウトインスペクター

これらのツールを使用すると、テスターはUIツリーを調べて検証できます。

• 要素が安定したアクセシビリティ識別子を公開するかどうか
• 識別子がビルド間で変更されるかどうか
• UI階層に動的に生成されたコンポーネントが含まれているかどうか

多くの場合、UI階層を単純に調べるだけで、ロケーターの不安定性の根本原因をはるかに簡単に特定できます。

QAエンジニアのためのベストプラクティス

QAエンジニアは、いくつかの重要な実践方法に従うことで、自動化の信頼性を向上させることができます。

• 好む アクセシビリティ識別子 XPathロケーターを介して
• 複数のビルド間でロケーターの安定性を検証する
• 開発者と協力して、安定した識別子を定義する
• UI検査ツールを使用してロケーター戦略を検証する

自動化フレームワークは強力ですが、アプリケーションがUI要素をどのように公開するかに大きく依存します。

モバイル開発者のためのベストプラクティス

開発者は、UI開発時に自動化を検討することで、テスト容易性を大幅に向上させることができる。

役に立つプラクティスは次のとおりです。

• 重要なUI要素に対して明示的なアクセシビリティ識別子を定義する
• 動的に生成される識別子を避ける
• ビルド間で識別子の一貫性を保つ
• 自動化テストで使用される識別子の文書化

開発者がテスト容易性をUI設計プロセスの一部として捉えることで、自動化ははるかに安定し、保守しやすくなる。

自動化の一環として Continuous Testing

現代のデリバリーパイプラインでは、モバイル自動化は多くの場合、より広範な継続的テスト戦略の一部であり、開発ライフサイクル全体を通して自動テストが実行されます。

大規模なデバイス群全体で自動化を拡張したいチームは、Appiumのようなフレームワークと、大規模なモバイル自動化実行をサポートするデバイスファームプラットフォームを組み合わせることがよくあります。これにより、複数のデバイスやOSバージョンにわたるテストが可能になります。

詳細については、こちらから Digital.ai テストプラットフォームはこちら： https://docs.digital.ai/continuous-testing/

結論

React Native、Flutter、Jetpack Composeといった最新のモバイルフレームワークは、開発者の生産性を劇的に向上させてきました。しかし、開発段階でテスト容易性を考慮しないと、これらのフレームワークの抽象化レイヤーが自動化において課題となる場合があります。

信頼性の高い自動化を実現するには、QA エンジニアと開発者の両方が、 UIデザインの中核部分としてのテスト識別子後から考えるのではなく。

安定したアクセシビリティ識別子は、Appiumなどのツールを用いた自動化の信頼性を向上させると同時に、実際のユーザーにとってのアクセシビリティも向上させます。

チームが早い段階からテスト容易性について協力し合うことで（安定した識別子を公開し、動的なロケーターを避け、UI階層を検証することで）、モバイル自動化はビルド全体を通してはるかに予測可能で保守しやすくなります。

多くの場合、脆弱な自動化と信頼性の高い自動化の違いは、テストツールそのものではなく、アプリケーションのUIがどれだけテストしやすいように設計されているかにある。