Android 自動化フレームワークを使用した APP テストのチュートリアル

なぜ Android テスト中？

Android 世界最大のオペレーティングシステムです。同時に、 Android 断片化されている。デバイスはたくさんありますし、 Android アプリが互換性を持つ必要があるバージョン。

設計と実装にどれだけの時間を費やしても、間違いは避けられず、バグも発生します。

Android テスト戦略

正しいAndroidテスト戦略には以下が含まれる必要があります

単体テスト
統合テスト
Opera試験
システムテスト

単体テスト

ユニットテストには、メソッドやクラスなどのソースコードの原子単位を検証するように設計された 1 つ以上のプログラムのセットが含まれます。

Android プラットフォームは事前に統合されていますジュニット 3.0フレームワーク。自動化のためのオープンソースフレームワークです単体テスト. Android テストフレームワークは、開発者が効果的な単体テストプログラムを作成するための強力なツールです。

単体テストに追加されるのは、ユーザーインターフェイス (UI) テストです。これらのテストは、ターゲットアプリケーションの UI コンポーネントに関連します。 UI テストは、デバイス上の一連のユーザーアクションに応じてアプリケーションが正しい UI 出力を返すことを確認します。

デバイス上で UI テストのパフォーマンスを行う一般的な方法は次のとおりです。 Android セットアップ。しかし、これにはパフォーマンスの問題があります。 UI テストを実施するのに最適なツールの 1 つ Android is ロボティウム.

統合テスト

In 統合テスト、すべての単体テスト済みモジュールが結合され、検証されます。で Android、統合テストには、多くの場合、Android サービステスト、アクティビティテスト、コンテンツプロバイダーテストなどのコンポーネント

統合テストを実施するために使用されるテストフレームワークは数多くあります。 Android トロイド、ロボレクトリック、ロボティウムなど。

Opera国家試験

Opera機能テストまたは受け入れテストとも呼ばれます。これらは、アプリケーションの完全性と正確性をチェックするために設計された高レベルのテストです。
In Android, フィットネッセ対象アプリケーションの運用テストを簡単に実施できるオープンソースフレームワークです。

システムテスト

In システムテストシステムは全体としてテストされ、コンポーネント、ソフトウェア、ハードウェア間の相互作用がチェックされます。

In Android, システムテストには通常、次のものが含まれます。

GUIテスト
ユーザビリティテスト
パフォーマンステスト
ストレステスト

上記のリストでは、 性能試験 より焦点が当てられます。次のようなツールを使用できますトレースビュー～についての性能テストを実施する Android このツールは、アプリケーションのデバッグとパフォーマンスのプロファイリングに役立ちます。

自動化されたAndroidテスト

Androidは断片化されているため、多数のデバイスでテストする必要があります。しかし、これにはコストもかかります。自動化 Android テストはコスト削減に役立ちます

自動化されたAndroidテストの利点

テストケースの実行時間を短縮する
開発プロセスの生産性を向上
バグを早期に検出し、ソフトウェアのメンテナンスコストを節約します
実装時のバグを迅速に発見して修正する
ソフトウェアの品質を保証する

以下の2つのフレームワークを学習します

Android テストフレームワーク
ロボエレクトリックテストフレームワーク

Android テストフレームワーク

標準的なテストフレームワークの 1 つ Android アプリケーションです Android テストフレームワーク。これは、強力で使いやすいテストフレームワークであり、 Android SDKツール。

アプリケーションパッケージ テストする必要があるターゲットアプリケーションです
インストルメンテーションTestRunner はテストケースターゲットアプリケーションでテストケースを実行するランナー。これには次のものが含まれます。

2a） テストツール: テストを構築するための SDK ツール。それらは以下に統合されています Eclipse IDE またはコマンドラインとして実行します。

2b） モンキーランナー: を制御するプログラムを作成するための API を提供するツール。 Android 外部のデバイスまたはエミュレータ Android コード。

テストパッケージ テストプロジェクトにまとめられています。このパッケージは命名規則に従っています。テスト対象のアプリケーションのパッケージ名が「com.mydomain.myapp」の場合、テストパッケージは「com.mydomain.myapp.test」である必要があります。テストパッケージには次の 2 つのオブジェクトが含まれます。

3a) テストケースクラス: ターゲットアプリケーションで実行するテストメソッドが含まれます。

3b) モックオブジェクト: テストケースのサンプル入力として使用されるモックデータが含まれます。

Android テストケースクラス

テストケース 含ま JUnit 実行するメソッド JUnit test
テストスイート 一連のテストケースを実行するために使用されます
計測テストスイート は、実行前に Instrumentation を InstrumentationTestCase に注入する TestSuite です。
インストルメンテーションTestRunner ターゲットアプリケーション上でテストケースを実行するテストケースランナーです。
Androidテストケース 拡張する JUnit テストケース。これには、アクティビティコンテキストなどのリソースにアクセスするためのメソッドが含まれています。
アプリケーションテストケース 制御された環境でアプリケーションクラスを検証します。
インストルメンテーションTestCase ターゲットアプリケーションの特定の機能または動作を検証します。たとえば、アプリケーションの UI 出力を検証します。
アクティビティTestCase アプリケーションアクティビティのテストをサポートする基本クラスです。
プロバイダーテストケース 単一の ContentProvider をテストするためのクラスです。
サービステストケース テスト環境でサービスクラスをテストするために使用されます。また、サービスのライフサイクルもサポートします。
SingleauchActivityTestCase InstrumentationTestCase を使用して単一のアクティビティをテストするために使用されます。
アクティビティ単体テストケース 単一の分離されたアクティビティをテストするために使用されます。
アクティビティ計測テストケース 2 拡張 JUnit テストケースクラス。インストルメンテーションを使用してターゲットアプリケーションに接続します。このクラスを使用すると、アプリケーションの GUI コンポーネントにアクセスし、UI イベント (キーストロークまたはタッチイベント) を UI に送信できます。

以下は ActivityInstrumentationTestCase の例です。これは、電卓アプリケーションの UI 操作を検証し、UI 出力の正確性をチェックします。

ロボエレクトリック試験フレームワーク

を使用したテスト Android デバイスやエミュレータを使用してフレームワークをテストするのは困難です。テストの構築と実行には時間がかかり、多くの開発労力がかかります。この問題を解決するには、別の選択肢があります – ロボレクトリック テストフレームワーク。

Robolectric フレームワークを使用すると、 Android テスト 直接に JVM上で無しデバイスまたはエミュレータの必要性。

Robolectric テストケースクラス

上記のように、Robolectric は次のアクションを実行できます。
Shadowクラスを登録して作成する
の読み込みを中断します Android class
javaassist を使用してメソッド本体をオーバーライドします。 Android class
シャドウオブジェクトをバインドする Android class
これにより、テスト対象のコードを問題なく実行できるようになります。 Android 環境。

その他のテストフレームワーク

上で説明したテストフレームワーク以外にも、次のようなテストフレームワークが他にもたくさんあります。

Android ジュニットレポート、カスタムインストルメンテーションテストランナー Android 他のツールと統合するための XML レポートを生成します。
エスプレッソ
Appium

の神話 Android テスト

多くの企業がAndroidを開発しているテストよくある誤解に基づいた戦略。このセクションでは、いくつかのよく知られた通説と現実について考察します。 Android テスト。

誤解 #1:すべて Android デバイスは同じです…エミュレータでのテストで十分です

簡単な例から始めましょう。アプリケーションはエミュレータでは完全に動作しますが、一部の実デバイスでは実行中にクラッシュします。

エミュレーターは 十分ではありません モバイルテスト用に。実際のデバイスでアプリをテストする必要があります。

誤解 #2: いくつかの一般的なデバイスでテストすれば十分である

デバイスが異なると、アプリケーションの外観も異なります。これは、デバイスごとにハードウェア、画面サイズ、メモリなどが異なるためです。アプリケーションは、さまざまなデバイス、OS バージョン、キャリアネットワーク、場所でテストする必要があります。

誤解#3: 発売直前の探索的テストで十分

通常、すべてのテストでは、テストケースを設計してから実行します。しかし、探索的テストでは、テストの設計と実行がすべて一緒に行われます。
探索的テストでは計画も準備もなく、テスターは自分がやりたいテストを実行します。一部の機能は繰り返しテストされますが、一部の機能は完全にはテストされません。

誤解#4: アプリケーションにバグがあったとしても、ユーザーは理解してくれる

アプリケーションが動作せず、バグがある場合、ユーザーはアプリケーションをアンインストールします
Google Play での悪いレビューの最初の理由は品質の問題です。それはあなたの評判に影響を与え、顧客の信頼を失います。

したがって、適切なAndroidテスト戦略を導入することが不可欠です。

のベストプラクティス Android テスト

アプリケーション開発者は、コードの作成と同時にテストケースを作成する必要があります。
すべてのテストケースは、ソースコードとともにバージョン管理に保存する必要があります。
継続的インテグレーションを使用し、コードが変更されるたびにテストを実行する
エミュレータやroot化されたデバイスの使用を避ける