Androidデバイスのファーム管理。 Yandexでの講義

アプリケーションの人気が高いほど、実行するデバイスのリストが長くなります。 ある時点で、これが問題になります。特定のモデルでのみいくつかのバグが神秘的に再現され、ますます多くのデバイスで製品をテストする必要があります。



複数のデバイスをサポートする問題は、ファームの助けを借りて解決できます。 このレポートでは、一般的なファームと、それらを開発およびテストプロセスに統合する方法について説明しています。





-私の名前はPavel Novikovです。NewCloud Technologies社で働いています。 「My Office」製品に取り組んでおり、このオフィススイートのAndroidバージョンを作成しています。 アプリケーション自体は非常に大きいです。 まず、すべてがアーキテクチャの観点からどのように配置されているかを説明します。その後、ファームが必要な理由に移ることができます。 多くのコードと外部の依存関係があるときにイベントがあるかどうか、またはそのようなイベントがないかどうか、そしてそれが必要かどうかを理解することができます。 ファームがクールで必要であるという決定をより正確に行うことができます。 かどうか。



前のスピーカーは、フラッターは内部的にSKIを使用していると述べました。 また、ネイティブを使用し、すべてのドキュメントが完全にSKIで描画されます。 事は非常に高速で、優れたライブラリです。



My Office Documentsアプリケーションの中心にはネイティブコアであるCOREがあります。これは社内で行われますが、チーム全体が作成します。 純粋なC ++で記述されているため、再利用できます。 製品ラインで作業するすべてのチームで再利用されます。



これは、デスクトップ、ウェブ、Android、iOSです。 Tizenでさえ、それは完全かつ非常にうまく行われています。



最も重要なことは、COREを行う人は、このCOREを使用するすべての人と非常に密接に結びついているということです。 たとえば、モバイルクライアント、iOS、Androidなどの便利な機能を要求する状況がありますが、デスクトップではあまり役に立ちません。 そのようなことがあります。



これから非常に予想通りにバグが現れることが非常に予想されます-デスクトップがこの関数を要求し、それ自体がAndroidで使用される別の関数の動作をわずかに変更したためです。 これは非常に一般的な状況であり、私たちの仕事は、たとえばすべてのモバイルプラットフォームで、子供たちを助け、協力し、バグをすばやく修正するために、そのような場所をすばやく見つけることです。







3つのコンポーネントがあります。ネイティブCORE、このCOREがラップされているAndroidライブラリ、およびJavaアプリケーションです。 ネイティブCOREは純粋なC ++です。 さらに、ソースコードの形式では、Androidモジュールに送られ、ネイティブのすべてのバインディングが行われ、小さなレイヤーが追加され、何らかのロジックが追加されます。 さらに、SKIが使用するすべてのレンダリングもこのモジュールで行われます。 次に、標準のARライブラリとしてのモジュールがアプリケーションに挿入され、それを使用します。



何でも起こります-ネイティブ、CORE、バインダーにバグが現れることがあります。 Javaクラスがネイティブクラスに誤ってバインドされ、ネイティブメソッドを呼び出したときにアプリケーションがクラッシュする状況を受け取ったときの、同じ不満足なリンク例外。 そして、バグはJavaコードにあります。



最も重要なことは、問題がどこにあるかをできるだけ早く理解して、解決しやすくすることです。 バインダーで発生するバグをすぐにキャッチして、UIに到達しないようにするのは良いことです、手動テスト。 これは時間であり、非常に単純な間違いであり、簡単に見つけて修正できます。



これを行うには、テストが必要です-この状況でできる最高のもの。 私たちのタスクは、アプリケーションとして機能するコードを作成することです。 動作することを確認する最も簡単な方法は、テストを作成することです。 テストはまったく異なります。 ユニット、UI、統合テストのすべてを作成します。



テストがあるという事実に加えて、テストを実行する必要があります。 アプリケーションの開発時に作成したテストは忘れて実行されず、嘘をつき、意味がありません。その後、コードが変更されます。 2か月が経ち、これらのテストを実行することにしましたが、組み立てさえしませんでした。 これは間違っています。テストは常に機能するはずです。



CIでテストを定期的に実行する必要があります。 そうでなければ、それらは無意味です。 嘘のテストがある場合、テストはありません。







単体テストでは、すべてが非常に簡単です。 grluテスト、タスクを開始します。 CIで実行されます-すべてが正常で、アプリケーションの単体テストが実行され、レポート、レポートが表示されます。



Androidテストは、接続Androidテストとして実行されます。そこでは同じユニットテストが必要であり、デバイスでのみ追跡されます。 そして、ここで問題が発生します。UIおよび統合テストは実際のデバイスで実行する必要があります。 また、CIは実際のデバイスではありません。 この問題はいくつかの方法で解決できます。



たとえば、デバイスをCIサーバーに接続します。 私は自分で試したことはありませんが、うまくいくはずです。 サーバーがあり、それは次のテーブルまたはテーブルの下にあり、デバイスをそれに接続し、システムのあるデバイスがそれらを認識し、すべてが正常で、すべてが開始します。



CIでエミュレーターを実行できます。 これは非常に機能するバージョンで、同じJenkinsはエミュレータを実行できるプラグインをサポートしていますが、問題はエミュレータが86番目のエミュレータである可能性が高いことです。 統合による統合テストについて説明している場合、この場合、私は外部依存関係を意味します。特に、ネイティブコードがたくさんあるため、それはネイティブコードです。 統合テストとは、「プラス」の論理をテストするテストを意味します。



その結果、これを行うことは可能ですが、あまり便利ではありません。 デバイスを直接接続するオプションはあまり便利ではなく、エミュレータは役に立ちません。 古代の「Armovskiy」を使用できますが、これはまあまあのアイデアです。



次に、Open STFプロジェクトがシーンに入ります。



多くのデバイスがあります。すべてを1台のコンピューターに接続し、すべてのデバイスを一元的に操作できるように、このコンピューターにアクセスする方法を学びましょう。



こんな感じです。 写真はプロジェクト自体から取得されます。 デバイスのリストが利用可能であり、私たちは皆に接続し、彼と完全に連携することができます。 表示されているのは、ファームに接続されており、Webインターフェイスを介して完全に制御され、完全に機能するライブデバイスです。



Open STFプロジェクトはオープンソースであり、いくつかの利点があります。 まず、実際のデバイスで作業します。 ほとんどのAndroid開発者と同様に、デバイスでコードをチェックする必要があることを理解しています。 エミュレーターは優れていますが、実際のデバイスで確認する必要があるものがたくさんあります。同じネイティブ、SSLで動作します。 動作が異なる可能性のあるものがたくさんあります。 ファームはこの問題を解決します。







すばらしいことは、このファームで作業するためにデバイスのルートが必要ないことです。 デバイスをファームに接続するだけで、作業に使用できます。



これは便利なデバッグです。 単純にIPを介してネットワーク上で見えるデバイスにDB経由で接続することを妨げるものは何もありません。動作中のコンピューターに接続されているデバイスのように動作します。 常にデバイスの画面が表示され、指だけでなくマウスでも操作できます。



デバイスはいくつかのコマンドを使用できます。 私たちの場合、これは興味深いケースです。 社内には広範なデバイス群と、それらと連携する複数のチームがあります。 私たちは開発者、テスターであり、全員が近くに座っており、仕事にはデバイスが必要です。 2番目のチームは自動化で、別のフロアに座っていますが、Androidを含むすべてのユーザー向けに独自の技術スタックを使用して自動化されたテストを作成しています。 また、社内のすべてのデバイスにアクセスできます。 3番目はサポートサービスです。 また、できるだけ多くのデバイスが必要です。 製品の問題について書くとき、それらを再現する必要があります。 問題は異なる場合があります。 利点は、会社のすべてのデバイスにアクセスできることです。 これはプラスです。デバイス上でアプリケーションを実行し、より高速なサポートを提供できます。



リモートで作業すると便利です。 楽しい結果、QAはこれを行います：誰かが病気であるか、オフィスに行くことができない場合、これは彼らが働くことができないという意味ではありません。 彼らは農場に入り、デバイスが彼らの隣に横たわっているかのように、いつものように働きます。



スクラムに取り組み、定期的にデモを実施しています。 約1年間、ファームでのみAndroidチームのすべてのデモを実行しています。 これは、作成される複数の機能、複数のストーリー、デバイス画面の表示、タブレットに関する1つのストーリー、次のストーリーの表示、別のデバイスへの切り替え、タブレットの表示が必要な場合に非常に便利です。 このアプローチは時間を節約し、実際のデバイスよりも便利です。



Rest APIがあり、自動化について考えることができます。



すべてのデバイスは、1か所で順番に充電され、常に充電されています。 1台のデバイスで何かをプレイする必要がある場合がありますが、FIGの周りに横たわっているので、放電された場所がわかります。







他のプロジェクトと同様に、欠点があります。 すべてのデバイスがサポートされているわけではありません。 正確なルールに名前を付けることはできません。 デバイスをファームに接続すると、検出されないことがあります。 これはめったに起こりません。文字通り1つまたは2つのデバイスがありました。 公園全体の95％が正常に機能しています。 一部の中国人には例外があります-それは未定です。 86番目のプロセッサ上の1つのデバイス、FIGはその理由を知っています。



更新するにはあまり便利ではありません。 STF製品自体の更新の問題について：それはオープンソースであるため、DevOpsチームは当社の更新に取り組んでいます。 ボタンをクリックして更新するのは簡単ではありません。 しかし、不可能なことは何もありません。 私たちはオープンソースについて話しているので、プロセスを促進することができます、問題は重大ではありません。



内部ネットワーク外へのリリースは望ましくありません。 このファームはネットワーク内で回転していますが、実際にはデバイスに完全にアクセスでき、制限はなく、デバイスを操作するだけでよいので、インターネット上で輝かないことをお勧めします。 。 実際のデバイスを使用して何かを実行できる場合は、ファームでこれを実行できます。 したがって、内部で使用するために残しておくことをお勧めします。







どのように見えますか？ 外側には、ファーム自体が実行されているサーバー、アクセスできるWebパネルがあります。



このWebパネルはノードについて知っています。 各ノードは、デバイスが接続されているコンピューターです。 複数のノードが存在する可能性があります-スケーリングの問題。 デバイス自体は、Webバージョンが実行されているデバイスではなく、ノードに接続されています。 私たちのケースでは、2つのノードがチーム内にあり、もう1つがサポート中であるように見えます。これは単にノードが近いためです。 物理的には、すべてのデバイスが1か所にあるわけではありませんが、このような単一のインターフェースを介してすべてにアクセスできます。







すべてのデバイスには、製品の種類、OSバージョン、SDKレベル、このデバイスのアーキテクチャが書き込まれます。 そして彼の場所は私が話していたプロバイダーです。 2つのプロバイダーがあります。 これらは、サポートデバイスおよびデバイスです。 後者には触れないようにします;これらは単一のインターフェースからアクセス可能なデバイスです。



ファーム自体はGitHubにあります 。 最初のリンクは、広告的なものです。







それを上げる方法、開始する方法、作業する方法についてのすべての指示があります。 すべての長所と短所が説明されており、プロジェクトはかなりよく文書化されています。



問題は、どういうわけか、これら2つのことの友達を作らなければならなかったことです。 テストとファームがあります。







CIサーバーは、あなたが一番好きなサービスです。 私たちはJenkinsを使用しています。Jenkinsについてのインターフェイスの例はありますが、あなたは何にも結びついていません。



STFサーバー（サーバー自体、プロバイダー、デバイス）があります。



それらを組み合わせる方法は？ 明らかに、最も簡単な方法はGradleプラグインで、テストを実行するときにファームへの接続を構成できます。



彼は何ができますか？ かなり基本的なもの。 彼は、テストを実行するのに必要なデバイスを選択し、開始する前にそれらに接続し、最後に接続を解除します。デバイスをロックしたままにしておくのは良くないからです。



適切なデバイスは何ですか？ プラグインを介して、必要なデバイスを正確に柔軟に構成できます。 名前でフィルタリングしたり、NexusやSamsungを使用したり、フィルタリングする量を選択したりできます。 これは1つの小さなテストセットである可能性があります。2つのデバイスで実行し、何も壊れていないことを確認するということです。 または、毎晩実行します。これにより、すべてのデバイスが使用され、すべてが開始され、すべてが表示されます。



建築 特定のアーキテクチャでテストを実行する必要がある場合があります。 場合もありますが、これはしばしば必要ではありません。



プロバイダーは私たちにとって便利です。私たちは、サポートのデバイスに触れないようにして、それらを損なうことなく、互いに干渉しないことを約束します。 私たちは言うことができます：サポートでデバイスに触れないでください。



APIレベルで並べ替えることも便利です。 何らかの理由でAPI 21以降でテストを実行する場合は、できます。







接続はとても簡単です。 Grandleプラグインと同様に、同様の構文で統合されます。 適用プラグインを作成すると、accessibleに表示されます。







これで、次のステップが実行されました。 起動時に、プラグインが機能するように、CIで実行されるテスト実行タスクにバインドする必要があります。 このようにして行われます。 不便かもしれませんが、そのままです。 改善は問題ではありません。 主なことは、connectToSmartphoneTestFarmタスクにアタッチできることです。 これは主要なタスクであり、デバイスへの接続とデバイスの解放を担当します。







さて、3番目-ファームパラメーターの設定。 baseUrlは、ファームが配置されているパスです。 apiKey-REST経由で接続するためのキー。これはファームコンソールで構成されます。 adbPath-見つかったすべてのデバイスでadbConnect操作が実行されるようにします。 タイムアウト-システム設定、デフォルトは分です。 何らかの理由でデバイスが使用されない場合、ファーム自体がデバイスを解放するために必要です。







これが、ファームを使用したテストの実行の様子です。 connectedDebugAndroidTestはすべてのテストを実行し、パラメーターはサポートを使用しないためにここに渡されると言います。 ティルダ-この場合、拒否。 さらに、5つのデバイスが必要であり、それらはすべて-DK21、つまりLollypop以上である必要があります。







Jenkins内でジョブをセットアップすると、次のようになります。 ここで、これらのパラメーターが構成されて送信されます。 これはプラグインの一部ではなく、Jenkinsでの作業は自分で行う必要があります。 これらすべてのパラメーターを指定することはできませんが、皮肉なことに設定される1つのジョブを作成します。 気にする必要がない場合は、ビルドボタンだけを使用します。 将来的に同じことをするかもしれません。







その結果、すべてのテストを実行した後、GUnitを起動するための最も標準的なHTMLレポートが表示されますが、1つだけの側面があります。それらは異なるデバイスで実行されたことがわかります。 実行したすべてのテストの名前が表示され、各デバイスで実行されたことがわかります。 何らかのリグレッションを探すために、この分析に基づいて実行するのにどれだけ時間がかかるかを確認することもできます。 ここに想像力の飛行があります-同じコードを100回実行し、それを測定するテストを考えることができます。 また、86番またはARMのコードがどのように動作するかがわかります。高速または低速です。 ファームはこれに役立ちますので、手で接続することはできませんが、自動モードで接続できます。







プラグイン自体はGitHubでも入手できます。簡単なドキュメントがありますが、少なくともいくつかあります。 簡単に接続します。 すべてのフィードバックを歓迎します。 自分用のプラグインを作成しました。 これが、ファームを正常に使用できなかった唯一の理由です。 最後に、これを喜ぶことができました。



Gradleは客観的な理由でどこにも存在しないことに言及する価値があります。 たとえば、Appiumの場合があります。 Appiumテクノロジに関するテストを作成する自動化エンジニアのチームがあることを前に述べました。 Gradleはそこで臭いがしませんでしたが、農場を使用する必要もありました。



端末である可能性があります。 ファームがあり、デバイスで何らかのクラッシュが発生しました。そこからログを切り取って、ファイルをダウンロードするなど、何でもいいでしょう。 どうする デバイスを取り出して接続します（ただし、ファームの魔法はすべて失われます）か、何らかの追加のクライアントを使用します。







彼らは同じことをするシンプルなツールを開発しましたが、ターミナルを介して動作します。 また、デバイスに接続し、切断し、リストし、adbで使用できるように接続することもできます。このコマンドは、デバイスを見つけたら5つのNexusが必要です-全員に接続します。 コマンドを実行すると、adbで5つのデバイスが使用可能になります。 ターミナルから何でもできます。また便利です。 主な利点は、手で行うよりも高速です。 また、GitHubでも利用できます 。



純粋に技術的には、GradleプラグインとクライアントはSTLクライアントライブラリを一緒に使用します。 サーバー全体はJavaで記述されています。作業中にUIスタジオからデバイスを直接選択できるように、スタジオ用のプラグインを追加する計画がさらにあります。 私自身の気持ちでは、過去6か月間、手でデバイスに触れていません。 デバイスはファーム上にあり、Webインターフェイスを介してデバイスに接続し、adbに接続し、ファーム上のパスをコピーします。手でデバイスに触れないでください。 別のデバイスに接続するだけで、別のデバイスと連携します。



開発中にあまり違和感はありません。 ゆっくりと、私たちのチームでは他の開発者もほぼ同じことをしていることに気づきます。 唯一のこと、QAキック、彼らは言う-不快。







少しだけですが、テストについても。 私は主にテストのコンテキストでファームを使用します。 UIテストは統合テストではありません。 これは一部の人にはキャプテンに思えるかもしれませんが、UIテストはデバイスに依存する可能性があるという結論に従います。 私は、スマートフォンで画面をテストするスマートフォンでのみ実行すべき迅速なテストについて話している。 タブレットでは、意味がありません。逆も同様です。 タブレット用、タブレット用の特定のテストがあります。 スマートフォンでは、起動しないか、変更された場所から起動する必要があります。 実行すると、テストに欠陥が生じ、出力が偽陰性となり、干渉します。 理論的には、テストは合格する必要があり、すべてが正常であるか、客観的な理由で合格しません。 そして、彼らが合格したように見えるが、偏った理由で合格した場合、これはプロセスを妨害し、情報コンテンツは失われます。



タスクはそれらを分離することです。 これは、ファームでの作業プロセス全体と、説明したすべての自動化を統合し始めたときに遭遇したことです。 統合テストとUIテストの両方があります。



いくつかの方法があります。 最も単純なものが知られています。 そして、好むすべての労働者。



独自のテストランナーを作成して、クラス名などを分析できます。 作業オプションはかなりです。 TestIntegrationまたはTestUIで終わるクラスに名前を付けてください。 これは有効なオプションです-テストランナーがこれを解決します。



Gradle. , Gradle, . Stack Overflow , .



JUnit Suit — , . , . , — Gradle test runner , .



. — IntegrationSuite — , . : .







, , suite, . , . , . , adb instrumentation frame. , , « ». . . , , .



Jenkins , , . , CORE. , , , , AR. , . .



, , , - - , , — , restore. , , - — ? . 私たちは理解し始めます。 , .



, . , Jenkins . , — , , , .



? — , . , — , . , , , . , … — , , , . , , - .



, , . , .



, — , , , , , - SSL, , , UI . GUnity CI , , .



. : , , - . , , , job . «». .



それだけです GitHub , — , , . , -.



— 2 , Python, REST . , .



, . , . -, REST -, , , , . , .