Colibri-ui-モバイルアプリケーションテスト自動化ソリューション

チームの成長に伴い、機能の数は必然的に増加し、同時に、回帰テスト中に確認する必要があるテストモデルとテストケースの数が増加します。 さらに、チームの数は理由で成長しています。この場合、ビジネスは品質を落とすことなく、より頻繁にリリースしたいと考えています。



アルファラボの方法は、速度、予算、品質のバランスを見つけるという問題を解決しました。今日はアルファモバイルの例で見ていきます。 今後、注意、ネタバレ!!! 私たちのソリューションはgithubで利用可能です： colibri-uiライブラリーとcolibri-ui-templateはクイックスタート用です。



Pavel pvivanovとLilia Lidiyatullinaは記事の執筆に積極的に参加しました

どうした

2013年には、回帰テストプロセスに両方のOS（iOS / Android）の1人のテスターが1日かかっていたため、テストの自動化について考えることすらありませんでした。



ただし、アプリケーションの積極的な成長、新しいサービスおよびサービスの追加により、手動テストのコストも急速に増加し始めました。



ここに絶えず新しい機能を生み出すチームの数を増やします（1から6）-そして回帰テストはプロセスの血栓となり、生産を壊して危険にさらす危険があります。



ある時点で、リリースのアプリケーションを準備する時点で、6つのチームすべてが「アイドル」であり、6人のテスター全員が疲れずにリリース候補を「退行」させているという結論に達しました。 一時的には、回帰テストの期間が8営業日（6人！）に増加しました。



この状況は、テスター自身に動機付けを加えません。 ある時点で、「休日のように退行する！」

どうする

問題は何らかの形で解決する必要があり、「bablishkoを接続する」には2つの方法がありました。

• テスターのランクに新しい人々を連れて行く;
• 手動テストを拒否するためのテスト自動化。

倫理的および経済的な理由から、2番目のオプションを選択しました。結局のところ、自動化のコストは、とにかくはるかに有益な投資です。



彼らは、モバイルアプリケーションのテストを自動化するためのパイロットプロジェクトで、選択した方向への動きを開始することにしました。 その結果に基づいて、将来の機器の要件を作成しました。

1. 自動化をテストするためのツールは、使用を開始するために開発に入るための可能な限り低いしきい値である必要があります。
   
   ツールの主なユーザーは自動化の経験のない製品チームのテスターであるため、コードの記述を最小限に抑えたり、複雑なロケーターを記述する必要がなくなります。
2. テストスクリプトは、開発者以外のユーザーが理解する必要があります。
3. ソリューションはクロスプラットフォームであり、2つのプラットフォーム（AndroidとiOS）で同時に動作する必要があります。
4. 接続されたモバイルデバイスのセットを持つファームを形成する必要があります。
5. ソリューションは、銀行の他のモバイルアプリケーションに対してスケーラブルでなければなりません。

受け取った要件に基づいて、自動化ツールを選択する必要がありました。

パイロットプロジェクトの一環として、以下を確認しました。

• ロボティウム
• エスプレッソ
• UIレコーダー
• 機能を維持する
• ひょうたん
• アピウム

クロスプラットフォームソリューションの要件により、リストの最後のペアに選択が絞り込まれました。 開発とサポートに関与するより活発なコミュニティのため、最終的な選択はAppiumを支持して行われました。

開発に入るためのしきい値を下げる

下位レベルのプロセスの自動化は、スクリプトとコードです。 ただし、誰もが開発ツールを理解したり、自分で何かを書いたりすることさえできません。 そのため、プロジェクトでBDD方法論を使用して、この瞬間をできるだけ単純化することにしました。



私たちのフレームワークはいくつかの抽象化レベルに分割され、上位レベルは人気のあるGherkinテスト記述言語で記述され、下位レベルは開発者がJavaプログラミング言語で記述します。 JBehaveはスクリプト用に選択されました。



では、ユーザー側の決定はどのように見えるのでしょうか？

Then   " " When   " "  "  " When    "  " Then   "  " When   "   "  " " When    " "
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、メイン画面からモバイル支払い画面への移行について説明します。 おそらく、誰かがビジネスプロセスの観点から、どの方法で目的の画面に到達するかは問題ではなく、彼は正しいと反対するでしょう。 実際、目的のセクションに移動することを妨げるものは何もありません。たとえば、次のように、前のスクリプトの最後の5行を1行に置き換えます。

 When    " "
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、このような手順は原子的ではなく、iOSとAndroidの両方のプラットフォームで再利用するのが難しくなります。 結局、開発に入るためのしきい値を下げたい場合、現在の手順を可能な限り再利用する必要があります。そうしないと、テスターは常に新しい手順を必要とし、その結果、その実装が必要になります。 そして、ここで思い出すように、テスターは必ずしも必要な開発スキルを持っているとは限りません。

画面について説明します

スクリプトですべてが非常に明確な場合、「シートから」読み取られ、アクションを説明します。ロケーターを明示的に使用しないで、どのように指定できますか？



エントリのしきい値を下げるという目標を達成する1つの方法は、複雑なロケーターの記述を単純化し、プロジェクトのすべてをより深く隠すことです。 そのため、説明でロケーターを作成し、検索に使用できるようにする2つの工場が誕生しました。 残念ながら、ロケーターを作成せずに実行できるとは限らないため、まれに作成する必要があります。 このような状況では、XPathで要素を見つける機会を残しました。



画面上の要素の説明は、4つのコンポーネントで構成できます。 4つのコンポーネントはすべて使用されることはありませんが、たとえば、最初に要素までスクロールしてからクリックする必要がある場合など、2つを使用できます。

要素のセットとしてのページ記述のコンポーネント：

• コンテンツの説明 -この識別子により、Android上の要素を見つけることができます。
• ResourceId / AccessabilityIdeitificator-一意の識別子。 アプリケーション開発者は識別子を入れないこともありますが、これはそれぞれAndroid / iOSのアプリケーションのマークアップで見つけることができる最も望ましい要素です。
• テキスト -たとえば、クリックできるボタン上の可視テキスト。
• XPath -xmlマークアップ用の通常のXPath。 これは、要素を明確に説明する前の3つの方法が機能しなかった場合に使用されます。

スクリプトで要素の名前（ストーリー内の名前）を使用し、そこからコンテンツの説明/ ResourceId / AccessabilityIdeitificator / Text / XPathを取得します。



すべての説明を.csvファイルに収集します。表形式で簡単に編集できます。 一方では、これは通常のPageObjectであり、他方では、テスターはコード内のロケーターを編集する必要がありません。







それははるかに簡単です！ 画面について説明し、スクリプトを作成し、自動テストを開始しましたが、重要なタスクについて少しお話しし、内部からcolibri-uiフレームワークを見てみましょう。

環境をカスタマイズする

Appiumを使用する場合、使用するモバイルデバイスを常に示す必要があります。 このソリューションでは、デバイスudid（一意の識別子）とその名前をプロジェクトに転送する必要があります。 名前は、何か問題が発生した場合にもログに記録されます。 udidを使用すると、ファーム全体があり、すべてが同じMacに接続されているため、プロジェクトは目的のモバイルデバイスで動作します。



現在、モバイルデバイスの説明は一連のフォルダーの形式で保存され、各フォルダーには.propertyおよびjson-objectタイプの設定ファイルが含まれています。 .propertyファイルタイプにはudidとデバイス名が含まれ、jsonオブジェクトにはクラスターモードで動作するためのノード設定の説明が含まれます（colibri-ui-templateを参照）。



小さなオフトピック、またはudd接続デバイスを取得する方法！



Androidでは、コンソールで「adbデバイス」、iOSでは「instruments -s devices | grep -v（シミュレーター| $（id -un））」を実行し、接続されたデバイスのリストを取得します。 Androidの場合、リストには実際のデバイスとエミュレーターの両方が含まれ、iOSの場合は実際のデバイスのみをフィルター処理します。 誰かがエミュレーターだけを取得する必要がある場合は、別のフィルタリングが必要です。「instruments -s devices | grepシミュレーター」。



このフォルダーのセットをデータベースまたは別のストレージに転送するか、環境を作成するプロセスで上記のコマンドを実行してリストを動的に受信することが計画されています。 現在、このような改善の必要はありません。



さらに、上記のコマンドをMacで動作させるには、ADBドライバーとXcodeをそれぞれインストールする必要があることに注意してください。 エミュレータで作業するときは、イメージを収縮させることを忘れないでください。

ユーザーを説明します

これまで、プロジェクトを最も単純なモードで起動するために必要なすべてを考慮に入れてきました。 スクリプト、画面の説明、デバイスの説明があります。 ただし、テストしているアプリケーションでは、これだけでは不十分です。 このアプリケーションでは、一部のユーザーがテストベンチにログインし、電話番号、ログイン、パスワード、アカウント番号などの資格情報を使用する必要があります。



ユーザー資格情報を持つファイルもプロジェクト内の別のフォルダーにあります。 将来的には、デバイスとともに、それらをデータベースまたは中央ストレージに転送します。

スクリプトとページの説明では、＃userName＃という形式のマーカーを使用します。これにより、ユーザーファイルからプロパティ値を取得し、実行中にこれらのマーカーを置き換えます。



したがって、異なるユーザーで同じスクリプトセットを同時に追跡できます。



ページの説明では次のように表示されます。







これは、user.propertyファイルでの表示方法です。

 paymentAccountRur=··0278 beneficiarAccountRur=··0163 beneficiarAccountUsd=··0889 beneficiarAccountEur=··0038
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キーと値を指定する必要があります。

Uberステップといくつかの副作用を形成します

テキストを入力したり、何かをクリックしたりするなど、かなり小さなステップの説明から開発を開始しました。 時間が経つにつれて、小さなステップでスクリプトを記述したり、メイン画面に戻るなどの複雑なステップを記述したりしても、コードを複製できないことに気付きました。 そこで、小さなステップを大きなステップに再利用するソリューションの検索を開始しました。

最初の試みは、DIの編成のためにプロジェクトにguieを追加することでしたが、その実装により、プロジェクトのほぼ全体のコアの処理が行われました。 また、appium-java-clientの依存関係には既にSpringが含まれているため、ソリューションが明らかになり、次のステップはSpringを実装することでした。



Spingをプロジェクトに導入したとき、変更の量は最小限でした。 プロジェクトの非常に奥深くでは、JBeHaveステップファクトリと、アリュールレポート接続の2、3行のみが変更されました。 ほぼすべてのクラスがコンポーネントとして宣言され、ほとんどの依存関係が削除されました。



実装の効果は、より小さなアクションを再利用できるステップ設計者だけでなく、ライブラリで一般的な決定を下す能力でもありました（githubへのリンクは最初にありました）。 このソリューションはいくつかのモバイルプロジェクトで使用しているため、これは私たちにとって重要です。



さて、最も珍しい効果は、テスト用のテストを作成できることです。 これがどんなに面白くて厄介であっても、それは楽器の品質に大きく依存するので、メンテナンスと開発も必要です。 現在、カバレッジはまだ進行中です。 プロジェクトのコアに変更を加えて、ライブラリ内のテストカバレッジを拡大します。

プロジェクトを開始します

既に述べたように、特定のデバイスセットでプロジェクトを並行して実行します。

コンソールからプロジェクトを開始する例：

 ./gradlew --info clean test --tests "*AndroidStories*" -Dorg.gradle.project.platform=Nexus6p_android6 -Dorg.gradle.project.user=6056789 -Dorg.gradle.project.testType=smokeNewReg -Dorg.gradle.project.buildVersion=9.0.0.7,development
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例からわかるように、テストはAndroidで実行されます（--tests "* AndroidStories *"）。 パラメーターとしても渡されます：



テスト実行が開始されるデバイスはNexus6p_android6です。 プロジェクトでデバイスを説明することを忘れないでください。これについては上で書きました。 それが私たちのやり方です。



device.propertiesファイルには次が含まれます。

 UDID=ENU14008659 deviceName=Nexus6p
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルtest_node.jsonには、ノードを実行するためのデータが含まれています。



データを使用するテストユーザー6056789。 プロジェクトには、テストを実行するために使用するテストユーザーのセットがあります。 ユーザーはuser.propertiesに記述されている必要があります。



テストの種類smokeNewReg、フレームワークは、メタタグのテストスクリプトを選択するためのロジックを実装します。 Metaブロックの各スクリプトには、ラベルのセットがあります。

 Meta: @regressCycle @smokeCycle
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

testCycle.propertiesファイルには、キーとラベル値が含まれています。

 smoke=+smokeCycle,+oldRegistration,-skip smokeNewReg=+smokeCycle,+newRegistrationCardNumber,-skip smokeNewAccountReg=+smokeCycle,+newRegistrationAccountNumber,-skip regress=+regressCycle,+oldRegistration,-skip regressNewReg=+regressCycle,+newRegistrationCardNumber,-skip
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、JBehaveにMeta Matcherが存在するおかげで、特定のテストサイクル用の一連のテストスクリプトを作成できます。



中央リポジトリから汲み上げているアセンブリの番号、およびアセンブリの汲み出し元のブランチ。 この場合、environmentAndroid.propertiesファイルにはワイルドカードリンクが含まれています。ワイルドカードリンクはパラメーターに基づいて形成され、コンソールから入力に送信されます。

 remoteFilePathReleaseAndDevelopment=http://mobile/android/mobile-%2$s/%1$s/mobile-%2$s-%1$s.apk
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、コンソールからプロジェクトを開始する方法がわかったので、プロジェクトをJenkinsに簡単に統合できます。 私たちのプロジェクトにはこのような統合があり、テスト担当者がJenkinsでジョブを作成して自動テストを実行するだけで十分です。



モバイルデバイスを備えたファームも形成されました。 これはMac Proであり、約10台のモバイルデバイスが接続されています。

レポートを生成します

このプロジェクトでは、アリュールレポートを使用してレポートが生成されます。 したがって、テストが完了したら、「結果を伴うディレクトリを生成」を実行するだけで十分です。



レポートでは、各シナリオのステータスを確認できます。 レポート内のスクリプトを開き始めると、各メソッドを呼び出す前に、テストが実行したステップを見つけることができます。 何かがバラバラになった場合、内部にエラーがあるステップで画面のスクリーンショットが表示されます。



以前は、スクリーンショットはすべてのステップにありましたが、それは無意味であると考え、画面は折りたたまれたスクリプトでのみ行われます。 さらに、自動化されたスクリプトの数が増えると、レポートはより多くのスペースを占有し始めます。

得られた結果

自分のために設定したタスクを要約します。

1. 開発に入るためのしきい値をかなり低くして、自動化をテストするためのツールを作成することができました。 平均して、実践が示しているように、テスターは自信を持って自動テストの作成と実行を開始するのに2週間しかかかりません。 テスターに​​とっての最大の困難は、appiumを構成する環境に関連しています。
2. テストスクリプトはすべてのチームメンバーに明確です。これは、プロジェクトでBDD方法論を使用する場合に特に重要です。
3. 私たちのフレームワークは、iOSとAndroidの2つのプラットフォームで同時に動作できます。
4. 現在、10台のモバイルデバイスとMac Proのファームを形成しています。 このプロジェクトはJenkinsと統合されており、すべてのテスターが10台すべてのデバイスで自動テストを並行して実行できます。
5. 私たちのソリューションはスケーラブルであり、いくつかのモバイルプロジェクトはすでにフレームワークで積極的に作業しており、自動テストを実行しています。

ボーナスとして：

1. モバイルプロジェクトの1つでは、自動化により、機能テスターがバックエンドとの後方互換性のためにフロントをテストすることを完全に省きました。 自動化の導入後、この場合のテスト時間は8倍に短縮されました（8時間から1時間に）。
2. 新しい自動テストは、モバイルアプリケーションの新しい機能の開発とともに、スプリントでテスターに​​よって作成されます。
3. その結果、回帰テストの一部はすでに自動化されており、回帰の時間が8日間から1日間に短縮されました。 これにより、より頻繁にリリースでき、テスターは回帰テストの期間中にチームから脱落することを止めました。 まあ、彼らは少し幸せになりました:)

結果は私たちの期待を満たし、自動化への移行の決定が正しいことを確認しました。



私たちは、githubで利用可能なソリューションを開発し続けています： コリブリUIライブラリとコリブリUIテンプレートは、クイックスタート用です。 さらにもっと！



Alpha Labのテスター （またはテスターだけではない）の1人になりたい場合は、 空席があります。