動的プラグインシステムに基づくモバイルテスト用のブラックテクノロジー

ダイナミックプラグインシステムに基づくモバイルテストブラックテクノロジー

Baidu MTC は、業界をリードするモバイルアプリケーションテストサービスプラットフォームで、モバイルアプリケーションテストで開発者が直面するコスト、テクノロジー、効率の問題に対するソリューションを提供します。同時に、業界をリードする Baidu テクノロジーが共有され、執筆者は Baidu の従業員と業界のリーダーから構成されています。

この記事の著者: hyxbiao & tony xin
著者メール: hyxbiao@gmail.com&&jiankangxin@gmail.com

背景

モバイル APP プラグインは、システム制限 (65535)、モジュールを解決するプラットフォームベースの製品ですデカップリング、および複数のチームコラボレーションのためのツール。その最大の特徴は、製品に明白な利点をもたらすモジュールの動的な配信ですが、Baidu では、このシステムはモバイル端末のテスト技術に新しいアイデアをもたらします

モバイル端末のオンライン問題箇所のいくつかのシナリオ:

シナリオ。 1: クラウドユーザーは、特定の機能が利用できないと報告しています。RD は、オンラインで収集されたクライアント管理ログ情報が不完全であり、問題を完全には確認できません。無限ループに陥って、オンラインユーザーは問題を露呈し続けますが、オフラインユーザーは安定して再現できず、問題をタイムリーに特定できません。どうやって壊すのか？
シナリオ 2: クライアント側の事前埋め込みによるユーザーの行動の管理は、不完全な管理につながることがよくあり、オンラインの問題を特定するには、問題を特定するための適切な再発手順を提供するためにこれらの行動ログが必要になることがよくあります。コーディングを行わずに技術的手段ですべてのユーザーとクライアントの対話ログを取得するにはどうすればよいでしょうか?
シナリオ 3: 多くの優れたオフラインツールを SDK に変換すると、オンラインでの問題の発見と特定に多くのプラスのメリットがもたらされます。ただし、テスト機能自体が統合アプリや開発チームのパフォーマンスに影響を与えるためです。統合できないため、多数のオンライン問題を完全に明らかにすることができません。この問題をうまく解決するにはどうすればよいでしょうか?
シナリオ 4: Baidu のオンラインクライアントの小規模トラフィック実験では、オンラインの問題は実際には正規分布するランダムイベントであることが多く、すべてのユーザーに影響を与えるいくつかのシナリオを必要とせず、少数のユーザーをサンプリングするだけで済むことがわかりました。

シナリオ 1: クライアントテストは単純ですが複雑です。クライアントテスターの単純なスキルツリーには、ANR、クラッシュ、ラグ、メモリリーク、メモリ、 CPU使用率、電力分析、起動速度分析と一連のスキル。また、多くの場合、QA 担当者の中にはフルスタックではない人もいます。そして、これらのツールの使用自体は、ツールの大きなコレクションです。クライアントテスターや非プロフェッショナルテスターが、バックグラウンドなしで数回クリックするだけでクライアントの問題を完全に分析できるようにする方法

シナリオ 2: 先ほど述べたオンラインの問題の特定と同様に、多くの優れたオフライン機能をすべてのユーザーに適用することはできません。ユーザー自身が敵に 800 の損害を与え、自分自身に 1,000 の損害を与える能力を持っているためです。ユーザーエクスペリエンスの損失を最小限に抑えながら、できるだけ多くの問題を思い出すにはどうすればよいでしょうか?

モバイル端末上でオンラインの問題を特定する新しい方法:

プラグインシステムに基づいて、便利なすべてのオフラインテスト機能を組み込むテストプラグインを作成し、同時に適切に統合します- 業界で既知の優れたフレームワーク (dexused、leackcanary など)、および一部のシステムはオープンですが、メインバージョンではパフォーマンスに影響を与える、traceviewer、Choreographer、ActivityLifecycleCallback などの優れた機能が使用されています。すべてはクラウドプラグインにダウンロードされ、クラウド内に構築された動的モジュールの低トラフィックシステムを通じて特定のターゲットユーザーの携帯電話に配布され、継続的に問題が明らかになります

ナイスジョブ! ！

クラウドプラグインの仕組み:
クラウドプラグイン自体はホストの単なるプラグインであり、そのテスト機能を実際に発揮できるのは、オフラインで構築された多数のテストシナリオと、その動的読み込みメカニズムです。このようにして、テストシナリオをオンラインで使用できます。こうなったら、新しい鍋で古い米をかき混ぜなければなりません:

親の委任メカニズム: Java のクラスローディングメカニズムの下では、子クラスローダーは親クラスローダーのローディングコンテンツを検索することができ、それによって提供されます。ホストのさまざまなクラス情報を動的に検索するクラウドプラグイン。前提条件 (マルチプロセスプラグインシステム...無視してください)
dexclassloader: 任意の JAR (dex ファイルを含む)、zip をロードできます。、ファイルシステム内のapkファイル
patchclassloader: multi-dex分割プロジェクトでよく使用される/app/のデータapkファイルのみをロードできます
dexfile: 動的ファイルをロードし、ファイル内のクラス情報を抽出できます同時に、これは dexclassloader にはないものです
シェルの破壊: クラウドプラグイン独自のシーンは情報アップロードクラスを統合する必要がありますが、コンパイル時に対応するクラスをプラグにコンパイルすることができません。 -パッケージ内。このようにして、シーンプラグインがロードされた後、ホストのログシステムをコールバックして情報を収集できます。その後、下の図の JAR または APK にパッケージ化されたシーンプラグインを動的にロードできます。クラウドプラグインと同時に、システム内のホスト、ローカルスペース、およびホスト関連の情報のさまざまなクラスを読み取り、収集します。フック、リフレクション、コードインジェクション、例外キャプチャ、インストルメンテーションなどに関しては、これらは 1 つの方法にすぎません

例:

注: 次のケースはクラウドプラグインの問題特定のシナリオに関するものですが、これはクラウドプラグインだけではありません。この部分のテクノロジーは後ほど SDK の形でオープンソース化します。したがって、この SDK を統合するアプリでもこれを行うことができますが、プラグインシステムから脱却するには、統合開発者が独自のセキュリティに注意を払う必要があります。もちろん、ルート化された携帯電話では、アプリ自体がハッカーに完全にさらされています (幸いです…)

テキスト: 流暢さを例として、クラウドデバッグプラグを構築する方法を見てみましょう。

流暢さ: Android システムが UI を描画する速度として理解できます。理論的には、人間の目は 1 秒以内に 60 フレームの画像を受信した場合にのみプログラムがスムーズであると感じます。 Android システムの初期において、流暢さは常に批判の対象でした。Android 4.1 システムになって初めて、プロジェクトバッファーが明確になり、VSYNC (垂直同期)、トリプルバッファー、およびコレオグラファーという 3 つの主要な要素が導入されました。。その中で、Choreographer が今日の議論の目標です。これはメカニズム全体のコーディネーターであり、すべてのルーパーは Choreographer オブジェクトを共有します

Choreographer は、システムが描画するたびに、doFrame 関数をコールバックして計算できます。 1 秒以内、現在のページの描画数。しかし、ここで問題が発生します:
動的プラグインシステムに基づくモバイルテスト用のブラックテクノロジー_PHP チュートリアル上の図を見ると、この製品は良いものですが、開発者には使用しないことをお勧めします。。。これをどうやって再生するのですか? 当初は流暢性モニターに入れようと思っていました。。この時点で、クラウドデバッグプラグインがあると思うでしょう。

ビルドは非常に簡単で、次のように、このコードを任意の Android プロジェクトにコピーしてパッケージ化するだけです。NutXError はコンパイルの依存関係としてのみ使用されることに注意してください。プラグインシステムがある場合は、このコードをロードしてパッケージ化することができます。直接実行

public class     NutFrameMonitor extends BaseCase {  private static final String TAG = "NutFrameMonitor";  @Override  public void invoke(Context context) {    int sdkVersion = 0;    try {      sdkVersion = Build.VERSION.SDK_INT;    } catch (Exception e) {      // TODO     }     if (sdkVersion >= 16) {       try {         Choreographer.getInstance().postFrameCallback(NutFrameCallback.callback);       } catch (Exception e) {         // TODO       }     }   }   private static class NutFrameCallback implements Choreographer.FrameCallback {     static final NutFrameCallback callback = new NutFrameCallback();     private long mLastFrameTimeNanos = 0;     private long mFrameIntervalNanos = (long)(500000000) - 1;     @Override     public void doFrame(long frameTimeNanos) {       if (mLastFrameTimeNanos != 0) {         final long jitterNanos = frameTimeNanos - mLastFrameTimeNanos;         if (jitterNanos > mFrameIntervalNanos) {           NutXError error = new NutXError(TAG);           error.setDetailMessage("frame Choreographer waste more than 500ms");           error.dump();         }       }       mLastFrameTimeNanos = frameTimeNanos;       Choreographer.getInstance().postFrameCallback(NutFrameCallback.callback);     }   } }

ログイン後にコピー

結果

以下のスクリーンショットは、クライアントの実行中に発見された流暢性の問題です (監視ケースはクラウドプラグインを通じて動的にロードされることに注意してください)。同時に、描画の問題を監視した後、ユーザーが滞在した各インターフェイスも描画されたこともわかります。その後、このトレースをたどって結果をオフラインで再現できます~
素敵ですね~~~

動的プラグインシステムに基づくモバイルテスト用のブラックテクノロジー_PHP チュートリアル

追記

以上でBaiduのモバイルテストに関する技術的な議論を終わります。しかし、実際には、どのような自動化ケースが構築されているか、このメカニズムがどの程度互換性があるかなど、言及されていないことがたくさんあります。さらに、鋭い観察力を持つ学生は、システム自体に互換性の問題がある可能性もあります。問題管理の仕事を強化し、クラウドデバッグプラグイン (実際には Nut Cloud と呼んでいます) が効果的かつタイムリーにリサイクルされるようにします。実際、私たちはこのことをオンラインで試すのに十分な自信を持っています。工場ラインには、動的モジュールの小規模トラフィックシステムの完全なセットがあり、オンラインで問題が発生した場合、クラウドプラグイン自体が実際に動的モジュールとして使用されます

。詳細有益な情報を共有するには、「Baidu MTC Academy」http://mtc.baidu.com/academy/article にご注目ください

を解決する、業界をリードするモバイルアプリケーションテストサービスプラットフォームです。