Androidアプリケーションの例での手動テストのプロセスで自動化を実装した経験

批判的思考能力を備えた優秀なテスターを自動化に完全に置き換えることはできません。 より効率的に機能させるのは簡単です。 この確信を持って、私は新しいタスクでテスト部門に行き、Pavelと一緒にその実装を始めました。 その結果を見てみましょう。

パートナーとともに、Android、iOS、Windowsなどのさまざまなプラットフォーム向けのアプリケーションファミリを積極的に開発、テスト、サポートしています。 アプリケーションは活発に開発されており、それに伴い、テストの量が増加しています。主に回帰です。

ほとんどのテストケースを自動化することで、テストを容易にし、高速化することにしました。 同時に、手動のテストプロセスを完全に放棄するのではなく、変更する必要がありました。

このアプローチの実装は、Androidアプリケーションの1つから始まりました。 この記事は、主にモバイルアプリケーション向けのUIテストの作成者や、手動テストプロセスをある程度自動化したい人にとって興味深いものになります。

行こう！

出発点

プラットフォームごとに、アプリケーションの同じメインビジネスプロセスを実行する同様のプラットフォームがいくつかあります。 ただし、小さな補助機能のセットが互いに異なり、顧客に応じて異なるブランドの下で作成されます（そのため、インターフェイスはアプリケーションごとに変わるため）。ビジネスプロセスは、追加のステップを追加することでカスタマイズできます。

対処する必要がある特定の問題に直面しています。 私たちとは異なる状況でも同様の困難が生じる可能性があります。 たとえば、複雑なビジネスロジックを持つ1つのかさばるアプリケーションがある場合、多くのテストで大きくなりすぎます。

問題＃1：多くの回帰テスト

各アプリケーションのテストスクリプトのセットは、同時に類似しており、互いに異なるため、回帰の増加に寄与し、さらに退屈になります。 ただし、すべてのアプリケーションは個別にテストする必要があります。

すでに実行されているアプリケーションが定期的に更新され、将来的にはさらに多くのアプリケーションが追加されることを考えると、テストの総数は容赦なく増加します。

問題番号2：モバイルOSのすべてのバージョンでテストする必要がある

重要な要件は、広範なオペレーティングシステムバージョンでのモバイルアプリケーションの可用性です。 たとえば、執筆時点のAndroidの場合、これらは17〜28のAPIレベルです。

理想的には、Androidの各バージョンでテストする必要があり、これにより回帰がさらに複雑になります。 アプリケーションの直接テストのプロセスでは、追加のルーチンにデバイスの数を掛けて取得します。アプリケーションをインストールして実行し、個々のテスト、削除の後にアプリケーションを元の状態にします。 同時に、独自のデバイスファームの維持は非常に労働集約的です。

ソリューション：自動化を手動テストプロセスに統合する

典型的なテスト自動化タスクは、回帰テストを自動化することです。 そのため、今日のテストプロセスの効率を改善し、明日の成長の可能性のある結果を防止したいと考えています。

同時に、自動化による手動テストを完全に根絶することは不可能であり、不要であることを十分に認識しています。 批判的思考と人間の目を何かに置き換えることは困難です。 Michael BoltonのブログThe End of Manual Testing （またはAnna Rodionovaからの翻訳 ）には、このテーマに関する良い記事があります。

アプリケーションの安定した部分をカバーする一連の自動化されたテストを用意し、将来、見つかったバグと新しい機能のテストを作成することが有用だと考えました。 同時に、自動テストをテスト管理システムの既存のテストスイートに関連付け（TestRailを使用）、テスターがクラウド物理デバイスで簡単に自動テストを実行できるようにします（クラウドインフラストラクチャとしてFirebase Test Labを選択しました）。

始めて試すために、Androidアプリケーションの1つを取り上げました。 ソリューションが成功した場合、他のプラットフォームを含む他のアプリケーションにそのベストプラクティスを適用できることを考慮することが重要でした。

結果として得たいもの：

1. 回帰テストの自動化。
2. テスト管理システムとの統合。
3. クラウドデバイスでの自動テストのパラメーター化された手動開始の可能性。
4. 将来的にソリューションを再利用する可能性。

次に、これらの各ポイントの実装について個別に説明しますが、技術的なコンポーネントには少し浸ります。

一般的なソリューション実装スキーム

しかし、最初に、私たちが得たものの一般的な概要：



自動テストは2つの方法で実行されます。

1. マスターへのマージまたはプル要求の後のCIから。
2. Jenkins Job Webインターフェースから手動でテスター。

手動で起動する場合、テスターは対応するビルドの番号を指定するか、コンピューターから2つのAPKをダウンロードする必要があります。アプリケーションとテストを使用します。 このメソッドは、使用可能なデバイスで必要なテストをいつでも実行できるようにするために必要です。

テスト中、その結果はTestRailに送信されます。 これは、テスターが手動でテストを実行し、自分に馴染みのある方法で結果を入力した場合と同じ方法で発生します。

したがって、手動テストの確立されたプロセスを残しましたが、特定のテストセットを実行する自動化を追加しました。 テスターは自動的に行われたことを「ピックアップ」します。

• 選択された各デバイスのテストケースの結果を確認します。
• テストケースを手動で再確認できます。
• まだ自動化されていないか、何らかの理由で最適化できないテストケースを実行します。
• 現在のテスト実行で最終決定を行います。

次に、約束された実装の説明に移りましょう。

1.自動テスト

ツール

ユーザーインターフェイスと対話するために3つのツールを使用しました。

• エスプレッソ。
• バリスタ。
• UI Automator。

主なツールと私たちが始めたものはエスプレッソです。 彼の選択を支持する主な議論は、Espressoを使用すると、Android Instrumentationへのアクセスを提供するホワイトボックスメソッドを使用してテストできることです。 テストコードは、アプリケーションコードと同じプロジェクトにあります。

テストでメソッドを呼び出すには、Androidアプリケーションコードへのアクセスが必要です。 適切な状態で実行することにより、事前に特定のテスト用にアプリケーションを準備できます。 それ以外の場合、原子性テストを奪い、相互に依存するようにし、単純に多くの時間を浪費するインターフェースを介してこの状態を達成する必要があります。

実装中に、別のツールがEspressoに追加されました-UI Automator。 両方のフレームワークは、 GoogleのAndroidテストサポートライブラリの一部です。 UI Automatorを使用すると、さまざまなシステムダイアログや通知ドロワーなどと対話できます。

そして、私たちの武器の最後はバリスタフレームワークでした。 これはEspressoのラッパーであり、一般的なユーザーアクションを実装するときに定型コードを保存します。

他のアプリケーションでソリューションを再利用できるようにしたいということを念頭に置いて、リストされているツールはAndroidアプリケーション専用であることを覚えておくことが重要です。 テスト対象のアプリケーションのコードにアクセスする必要がない場合は、別のフレームワークを使用することをお勧めします。 たとえば、今日非常に人気のあるAppiumです。 バックドアの助けを借りてアプリケーションコードにアクセスすることもできますが、これはBadooブログの良い記事です。 選択はあなた次第です。

実装

設計パターンとして、Jake Whartonが同名のレポートで提案したTesting Robotsを選択しました。 このアプローチの考え方は、Webシステムのテストで使用される一般的なページオブジェクトのデザインパターンに似ています。 プログラミング言語はJavaです。

アプリケーションの各独立したフラグメントに対して、ビジネスロジックが実装される特別なロボットクラスが作成されます。 フラグメントの各要素との相互作用は、別の方法で説明されています。 さらに、このフラグメントで実行されるすべてのアサーションについても説明します。

簡単な例を考えてみましょう。 説明したフラグメントには、データとアクションボタンを入力するためのいくつかのフィールドが含まれています。



ログイン機能自体のコードは次のとおりです。



ここでは、入力された認証データが正しい場合の肯定的なシナリオを確認します。 データ自体が入力テストに送信されるか、デフォルト値が使用されます。 したがって、テスターはテストデータの観点からパラメーター化することができます。

このような構造は、スクリプト全体がメインの実行ステップに分割されている場合、まず第一にテストに優れた可読性を与えます。 また、対応するロボットの個々のメソッドにアサーションを取り入れるというアイデアもとても気に入りました。 アサートは、一般的なチェーンを壊すことなく同じステップになり、テストはまだアプリケーションについて何も知りません。

前述のレポートでは、Jake WhartonはKotlinでの実装を提供していますが、それは有限です。 私たちはすでに別のプロジェクトで試してみましたが、本当に気に入りました。

2.テスト管理システムとの統合

自動化の導入前に、すべてのテストをTestRailテスト管理システムで実施しました。 良いニュースは、かなり良いTestRail APIがあることです。これにより、システムで既に確立されているテストケースを自動テストに接続することができました。

JUnit RunListenerを使用したテスト実行中に、 testRunStarted 、 testFailure 、 testFinishedなどのさまざまなイベントがキャッチされ、その結果がTestRailに送信されます。 AndroidJUnitRunnerを使用する場合は、公式ドキュメントに記載されている特定の方法でRunListenerについて通知する必要があります。

また、さまざまなTestRailエンティティとそのIDで通信する必要があります。 そのため、テストを対応するテストケースに接続するために、単純なアノテーション@CaseIdを作成しました。その使用方法は、上記のテスト実装例に示されています。

注釈自体を実装するためのコード：



説明から適切な場所に値を取得するためにのみ残ります：

3.クラウドデバイスでの自動テストの手動開始

Jenkins Jobの起動パラメーター化

自動テストの手動開始を整理するには、 フリースタイルのJenkins Jobを使用します 。 このオプションが選択された理由は、同社がすでに他の分野、特にDevOpsエンジニアと喜んで共有しているJenkins Jobと同様の仕事をした経験があるためです。

Jenkins Jobは、Webインターフェースから転送されたデータに基づいてスクリプトを実行します。 したがって、テスト実行のパラメーター化が実装されます。 この場合、BashスクリプトはFirebaseクラウドデバイスでテストの起動を開始します。

パラメータ化には以下が含まれます。

• 対応するビルドの番号を指定するか、手動でダウンロードして、目的のAPKを選択します。
• あらゆる種類のテストデータを入力します。
• TestRailの追加のカスタムデータを入力します。
• Firebase Test Labで利用可能なリストから、テストを実行するクラウドベースの物理デバイスを選択します。
• 実行するテストキットの選択。

デバイスの選択とテストスイートのインターフェイスの例を使用して、Jenkins JobのWebページの一部を見てみましょう。



データを入力または選択できる各要素は、特別なJenkinsプラグインによって実装されます。 たとえば、デバイス選択インターフェイスは、 Active Choicesプラグインを使用して作成されます。 Firebaseのgroovyスクリプトを使用して、使用可能なデバイスのリストが取得され、Webページに目的の形式で表示されます。

必要なデータがすべて入力されると、対応するスクリプトが起動され、その進行状況はコンソール出力セクションで確認できます。



ここから、テスト実行を開始したテスターは、受信したURLを使用してTestRailまたはFirebaseコンソールにアクセスできます。これには、選択した各デバイスでのテストの実行に関する多くの有用な情報が含まれます。

Firebase Test Labの最終テストマトリックス

Firebaseのデバイスマトリックスには、実行されたデバイスによるテストの分布が含まれています。



デバイスごとに、完全なログ、テスト実行のビデオ、さまざまなパフォーマンスインジケーターを表示できます。 さらに、テストの実行中に作成された可能性のあるすべてのファイルにアクセスできます。 これは、デバイスからテストカバレッジインジケーターをダウンロードするために使用します。

Firebaseを選択したのは、すでにこのサービスを使用して他の問題を解決しており、価格設定ポリシーに満足しているためです。 1日にテストするための純粋な時間の30分以内に維持する場合、まったく支払う必要はありません。 これは、特定のテストのみを実行できることが重要な追加の理由かもしれません。

テストプロセスに適した別のクラウドインフラストラクチャを好む場合があります。

4.再利用

これを将来どのように使用できますか？ コードベースの観点から、このソリューションはAndroidアプリケーションにのみ適用できます。 たとえば、実装中に、ヘルパークラスEspressoExtensionsおよびUiAutomatorExtensionsを追加しました。このクラスでは、インターフェイスと対話するさまざまなオプションをカプセル化し、要素の準備が整うまで待機します。 これには、TestRailとの統合を担当するRunListenerクラスも含まれます。 それらはすでに別のモジュールに配置されており、それらを使用して他のアプリケーションを自動化します。

他のプラットフォームについて話す場合、得られた経験は、同様のプロセスを構築して実装するために非常に役立ちます。 私たちはiOSラインで積極的にこれを行っており、Windowsについて考えています。

おわりに

テスト自動化を実装および使用するための多くのオプションがあります。 私たちは、自動化は主に、「人間」のテストの伝統的なプロセスを容易にするために設計されたツールであり、それを根絶するためではないと考えています。