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

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

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 秒以内、現在のページの描画数。しかし、ここで問題が発生します:
上の図を見ると、この製品は良いものですが、開発者には使用しないことをお勧めします。 。 。これをどうやって再生するのですか? 当初は流暢性モニターに入れようと思っていました。 。この時点で、クラウド デバッグ プラグインがあると思うでしょう。

ビルドは非常に簡単で、次のように、このコードを任意の 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);     }   } } 

結果

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

追記

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

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

http://www.bkjia.com/PHPjc/1083919.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/1083919.html技術記事ダイナミック プラグイン システムに基づくモバイル テスト ブラック テクノロジーである Baidu MTC は、開発者がモバイル アプリケーション テストで直面するコスト、テクノロジー、...

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