Android 自動化フレームワークを使用したアプリテストチュートリアル
トーマス・ハミルトン
⚡ スマートサマリー
Android アプリテストは、断片化されたデバイス環境全体でビルドを検証するもので、単体テスト、統合テスト、運用テスト、システムテストを、デバイス上またはJVM上で直接実行される自動化フレームワークと組み合わせて行います。
Why Android テスト中？
Android 世界最大のオペレーティングシステムです。同時に、 Android 断片化されている: デバイスが山ほどあり、 Android アプリが互換性を持つ必要があるバージョン。
設計や実装にどれだけ時間を費やしても、ミスは避けられず、バグは必ず発生する。
Android テスト戦略
正しい Android テスト戦略には以下を含める必要があります。
- 単体テスト
- 統合テスト
- Opera試験
- システムテスト
単体テスト
単体テストとは、メソッドやクラスといったソースコードの最小単位を検証するために設計された一連のプログラムのことです。
その Android プラットフォームには、 JUnit 3.0フレームワーク。これは自動化のためのオープンソースフレームワークです。 単体テストそして、開発者が効果的な単体テストプログラムを作成できるようになります。
ユニットテストに加えて、ユーザーインターフェース（UI）テストがあります。これは、対象アプリケーションのUIコンポーネントを対象とし、デバイス上での一連のユーザー操作に対して正しい出力が返されることを確認します。
デバイス上でUIテストを実行する一般的な方法は Android セットアップ。しかし、これにはパフォーマンスの問題があります。 UI テストを実施するのに最適なツールの 1 つ Android is Robotium.
⚠️ バージョンノート： JUnit 3つのクラスなど インストルメンテーションTestCase API 24で非推奨になりました。現在のプロジェクトでは AndroidXテスト、 Espresso そしてUI Automator。 Robotium 2016年以降、新作はリリースされていない。
統合テスト
In 統合テストすべての単体テスト済みモジュールが結合され、検証されます。 Android これは多くの場合、サービス、アクティビティ、コンテンツプロバイダーなどのコンポーネントとの統合テストを行うことを意味します。
統合テストを実行するために多くのテストフレームワークが使用されています Androidトロイド、ロボレクトリック、 Robotium.
Opera国家試験
Opera機能テストまたは受け入れテストとも呼ばれる国家テストは、アプリケーションの完全性と正確性を確認する高レベルのテストです。
In Android, フィットネッセ は、対象アプリケーションに対して運用テストを簡単に実行できるようにするオープンソースのフレームワークです。
システムテスト
In システムテスト システムは全体としてテストされ、コンポーネント、ソフトウェア、ハードウェア間の相互作用がチェックされます。
In Android, システムテストには通常、次のものが含まれます。
- GUIテスト
- ユーザビリティテスト
- パフォーマンステスト
- ストレステスト
上記のリストでは、 性能試験 より焦点が当てられます。 次のようなツールを使用できます Trac概観 パフォーマンス テストを実施する Androidこのツールは、アプリケーションのデバッグとパフォーマンスのプロファイリングに役立ちます。 Traceview は現在非推奨となり、 CPU プロファイラ.
自動化 Android テスト
As Android 断片化されているため、多くのデバイスでのテストが必要であり、それには費用がかかります。自動化された Android 検査はこれらのコスト削減に役立つ。
自動化の利点 Android テスト
- テストケースの実行時間を短縮する
- 開発プロセスの生産性を向上
- バグを早期に検出し、ソフトウェアのメンテナンスコストを節約します
- 実装時のバグを迅速に発見して修正する
- ソフトウェアの品質を保証する
以下の2つのフレームワークを学習します
- Android テストフレームワーク
- ロボエレクトリックテストフレームワーク
Android テストフレームワーク
標準的なテスト フレームワークの 1 つ Android アプリケーションは Android テストフレームワーク。 Android SDKツールは、そのアーキテクチャが3つの部分から構成されている。
- アプリケーションパッケージとは、テスト対象となるアプリケーションのことです。
- InstrumentationTestRunner は テストケース 対象アプリケーション上でテストケースを実行するランナー。これには以下が含まれます。
- テストツール: テスト構築のためのSDKツール。IDEに統合されているか、コマンドラインから実行できます。
- モンキーランナー: 制御するプログラムを作成するための API を提供するツール Android 外部のデバイスまたはエミュレータ Android コード。
- テストパッケージはテストプロジェクトごとに整理され、命名規則に従います。テスト対象アプリケーションのパッケージ名が「com.mydomain.myapp」の場合、テストパッケージは「com.mydomain.myapp.test」となります。テストパッケージには次の2つのオブジェクトが含まれます。
- テストケースクラス： 対象アプリケーション上で実行されるテストメソッドを含める。
- モックオブジェクト： テストケースのサンプル入力として使用されるモックデータを含めます。
Android テストケースクラス
- テストケースには以下が含まれます JUnit 実行するメソッド JUnit test
- TestSuiteは、一連のテストケースを実行するために使用されます。
- InstrumentationTestSuiteは、InstrumentationTestCaseを実行する前に、Instrumentationを注入するテストスイートです。
- InstrumentationTestRunnerは、対象アプリケーション上でテストケースを実行します。
- AndroidTestCase は JUnit アクティビティコンテキストなどのリソースにアクセスするためのメソッドを含むテストケース。
- ApplicationTestCaseは、制御された環境でアプリケーションクラスを検証します。
- InstrumentationTestCaseは、アプリケーションのUI出力など、特定の機能や動作を検証します。
- ActivityTestCaseは、アプリケーションアクティビティのテストをサポートする基本クラスです。
- ProviderTestCase は、単一の ContentProvider をテストするためのクラスです。
- ServiceTestCaseは、テスト環境でサービス クラスをテストし、サービスのライフサイクルをサポートします。
- SingleLaunchActivityTestCaseは、InstrumentationTestCaseを使用して単一のアクティビティをテストするために使用されます。
- ActivityUnitTestCase単一の単離された活性をテストするために使用されます。
- ActivityInstrumentationTestCase2拡張する JUnit TestCaseクラスは、計測機能を使用してターゲットアプリケーションに接続するため、GUIコンポーネントにアクセスしたり、キーストロークやタッチなどのUIイベントを送信したりできます。
以下はActivityInstrumentationTestCaseの例です。このテストケースは、電卓アプリケーションのUI操作を検証し、UI出力の正確性を確認します。
ロボエレクトリック試験フレームワーク
テストに使用した Android デバイスやエミュレーターを使ったテストフレームワークの構築は困難です。テストの構築と実行には時間がかかり、開発にも多大な労力が必要です。この問題を解決するために、Robolectricテストフレームワークという選択肢があります。
Robolectric を使用すると、 Android デバイスやエミュレータを必要とせず、JVM上で直接テストを実行します。
Robolectric テスト ケース クラス
Robolectricは以下の動作を実行できます。
- Shadowクラスを登録して作成する
- の読み込みを中断します Android class
- あなたが使用します Javaメソッド本体をオーバーライドするには、 Android class
- シャドウオブジェクトをバインドする Android class
これにより、テスト対象のコードが Android 環境。
その他のテストフレームワーク
上記で挙げたテストフレームワーク以外にも、以下のような多くのフレームワークが存在します。
- Android ジュニットレポート、カスタム インストルメンテーション テスト ランナー Android 他のツールと統合するための XML レポートを生成します。
- Espresso
- Appium
の神話 Android テスト
多くの企業が発展 Android テスト よくある誤解に基づいた戦略。このセクションでは、いくつかのよく知られた通説と現実について考察します。 Android テスト。
神話その1：すべて Android デバイスは同じなので、エミュレータでのテストで十分です
アプリケーションはエミュレーター上では完璧に動作するのに、実際のデバイスで実行するとクラッシュすることがある。
エミュレーターだけではモバイル端末のテストには不十分です。アプリは実機でテストする必要があります。
神話その2：一般的なデバイスでのテストで十分
ハードウェア、画面サイズ、メモリ容量はデバイスによって異なるため、アプリケーションの表示もデバイスごとに異なります。様々なデバイス、OSバージョン、通信事業者ネットワーク、場所でテストを実施してください。
神話その3：発売直前の探索的テストだけで十分
- ほとんどのテストでは、まずテストケースを設計してから実行しますが、探索的テストでは、設計と実行が同時に行われます。
- 計画も準備も一切ないため、テスターは自分の好きなテストを実行する。一部の機能は繰り返しテストされる一方で、他の機能は全くテストされない。
神話その4：アプリケーションにバグがあっても、ユーザーは理解してくれるだろう
- アプリケーションが正常に動作せず、バグがある場合、ユーザーはアプリをアンインストールします。
- 品質の問題は、悪いレビューの最初の理由です Google 遊び方をすれば、評判を落とし、顧客の信頼を失うことになる。
したがって、適切な Android テスト戦略が策定済みです。
のベスト プラクティス Android テスト
- アプリケーション開発者は、コードの作成と同時にテスト ケースを作成する必要があります。
- すべてのテストケースは、ソースコードとともにバージョン管理システムに保存する必要があります。
- 継続的インテグレーションを使用し、コードが変更されるたびにテストを実行する
- エミュレータやルート化されたデバイスだけに頼るのは避け、検査ツールなどを使用して実際のハードウェアで結果を確認してください。 ウイオートマビューア
