最初に開始したミニ プログラムは、WeChat の公式テスト デモです。Android API デモと同様に、公式ミニ プログラムでは、さまざまなコントロールの使用法と共通インターフェイスの拡張機能も示します。開発者の WeChat アカウントを追加した後、QR コードをスキャンして WeChat アプレットを開くことができます。
1. ミニプログラム実行時間分析
1. まず、WeChatを起動し、WeChatがどのようなプロセスを持っているかを確認します。
shell@HWNXT:/ $ ps | grep u0_a539 u0_a539 6688 533 1751392 84976 SyS_epoll_ 0000000000 S com.tencent.mm:push u0_a539 7593 533 2228476 252492 SyS_epoll_ 0000000000 S com.tencent.mm u0_a539 8047 533 1984672 854121 SyS_epoll_ 0000000000 S com.tencent.mm:tools u0_a539 8117 533 1770972 86280 SyS_epoll_ 0000000000 S com.tencent.mm:sandbox shell@HWNXT:/ $
現在 WeChat 画面を表示しているプロセスを見てください。名前から判断すると、com.tencent.mm であるはずです。
shell@HWNXT:/ $ dumpsys activity top | grep ACTIVITY ACTIVITY com.tencent.mm/.ui.LauncherUI 44c445f pid=7593
コマンドで確認すると、現在のトッププロセスは 7593 で、確かに com.tencent.mm です。
2. 次に、公式 WeChat ミニ プログラム デモを開始した後のプロセスの変更を見てみましょう。
u0_a539 6688 533 1750852 84420 SyS_epoll_ 0000000000 S com.tencent.mm:push u0_a539 7593 533 2223164 272116 SyS_epoll_ 0000000000 S com.tencent.mm u0_a539 9853 533 2092872 117492 SyS_epoll_ 0000000000 S com.tencent.mm:tools u0_a539 9896 533 2351160 212336 SyS_epoll_ 0000000000 S com.tencent.mm:appbrand0 shell@HWNXT:/ $
もう 1 つのプロセス、com.tencent.mm:appbrand0 があります。WeChat アプレットはどのプロセスで実行されますか?
最上位プロセスを見てください:
shell@HWNXT:/ $ dumpsys activity top | grep ACTIVITY ACTIVITY com.tencent.mm/.plugin.appbrand.ui.AppBrandUI 15a772 pid=9896 shell@HWNXT:/ $
現在の最上位プロセスは 9896 で、実際には com.tencent.mm:appbrand0 です。
ミニ プログラムのリソースと独立性を確保するために、WeChat がミニ プログラム用に別のプロセスをオープンしたことがわかります。
3. WeChat アプレットと WeChat で Web ページを開くことは同じモジュールによって実装されていますか?
WeChat で Web ページを開いてプロセスを確認します:
shell@HWNXT:/ $ ps | grep u0_a539 u0_a539 6688 533 1751212 86184 SyS_epoll_ 0000000000 S com.tencent.mm:push u0_a539 7593 533 2187672 263352 SyS_epoll_ 0000000000 S com.tencent.mm u0_a539 8047 533 2336360 224436 SyS_epoll_ 0000000000 S com.tencent.mm:tools
プロセスは変更されていません。最上位のプロセスを確認してください:
shell@HWNXT:/ $ dumpsys activity top | grep ACTIVITY ACTIVITY com.tencent.mm/.plugin.webview.ui.tools.WebViewUI 1502038 pid=14685
Web ページは実際には com.tencent.mm:tools プロセスで開かれ、アクティビティが表示されます。アプレットは .plugin.appbrand.ui.AppBrandUI であり、Web ページは .plugin.webview.ui.tools.WebViewUI です。
WeChat アプレットと単純な Web ページの間には違いがあるようです。
2. ミニプログラムの画面構成
UIAutomatorを使用してWeChatミニプログラム画面を構成するコンポーネントを分析します
UIAutomatorを使用して画面を分析し、WeChatミニプログラムのデモは 3 つの部分で構成されており、中央は Tencent 独自の WebView であり、Tencent が独自に開発した X5 コアを使用します。下は X5 WebView でアプレットのコンテンツを表示します。
WeChat アプレットのページ表示には、Android ネイティブ コントロールと WebView の H5 ハイブリッド ディスプレイ ソリューションが使用されていることがわかります。これは、市場で非常に一般的な H5 ハイブリッド アプリケーションと同等です。
3. WeChat ミニプログラムの自動テストを行う方法
現在、Android 自動テスト フレームワークは主に 6 つのカテゴリに分かれています:
Robolectric は単体テストによく使用されます。実装計画では、JVM で実行できる一連の Android コードを実装し、単体テストの実行中に Android 関連のコード呼び出しをインターセプトし、その実装コードに切り替えて呼び出しプロセスを実行し、多くの拡張インターフェイスを強化します。 Android の標準クラスに基づいているため、単体テストのプロセスが非常に容易になりますが、機能レベルに重点を置くテスト学生にとっては少し混乱するため、実用的な意味はあまりありません。
Monkey は、Android システムに付属する安定性テスト ツールで、その名前が示すとおり、シンプルで使いやすく、便利で高速な、多くのメーカーが組み込み製品の安定性許容度測定ツールとしても使用しています。結局のところ、サルは依然としてサルです。機能的な使用例を決定するためのテストプロセスを完了できず、サルが人間に進化するまで待たなければならないのは残念です。
UIAutomator は、Android で正式にサポートされている数少ない自動テスト フレームワークの 1 つで、最も初期にリリースされたバージョンは API レベル 17 です。 UIAutomator は、コントロールベースの自動化フレームワークとして、明確なインターフェイスを備えており、使いやすいです。UIAutomator をベースにして、有名なオープンソース自動化フレームワークである Appium も開発されており、業界での地位は非常に高いです。ただし、UIAutomator を使用するための前提条件は、UIAutomatorViewer を使用して操作前コントロールの属性情報を表示できることです。上記の分析から、ミニ プログラム内の一部のコントロールの親コンテナーが weview であることがわかりました。標準構造ではなく、Tencent が独自に開発した X5 である必要があります。 appium UIAutomator を使用して自動化を実行するという考えはその後放棄されました。
Instrumentation のような Android ジェノタイプ テスト ソリューションも考えられます。有名な Robotium 自動テスト フレームワークはここで生まれました。しかし、ある程度理解した後、Instrumentation または robotium ではテストに製品のソース コードまたは署名が必要であることが徐々にわかりました。プロジェクトは通常、製品のソース コードと同じプロジェクト ディレクトリに配置されます。それでは、誰が WeChat のソース コードを私に提供してくれるでしょうか。私もそれを持っていますか?ねえ、ねえ、誰か私の声が聞こえますか？ !@#@%&^
初期には、Baidu のカフェや Alibaba の arthrun など、システム権限のエスカレーションとインジェクションによって実現される自動テスト機能があり、そのほとんどは xposed アーキテクチャ モデルをコピーし、強力なシステム制御機能を備えていました。 。しかし、これらのフレームワークは現在どこにあるのでしょうか? Android のルートがますます困難になってきているため、バージョン 6.0 は現在ほぼ不可能であることが判明しました。そのため、このタイプのオープンソース フレームワークは、2014 年頃にはメンテナンスを中止しました。他の方法を見つける必要があります。
基于图像识别也有一些自动化测试框架，例如sikuli还有testin的自动化工具，然而小生之所以直接就把这类框架pass掉是因为这种测试脚本基本不具备扩展性，系统ui风格变更，想要做断言验证，以及日后用例维护等等，想都不敢想。
铁鞋踏破仍无路，靓女帅哥也踌躇啊，忽然间灵感一现，腾讯自家会不会有什么奇葩产品可用啊，知行合一谷歌百度，搜索腾讯自动化立马看到腾讯优测的介绍，到官网里翻了一下找到一款叫XTest的自动化测试工具，看到简介目前只支持Android平台，想想前面历程这般痛苦，还要啥自行车啊。于是乎赶忙下载了一套热气腾腾的XTest，安装完毕，一切准备就绪，关门，放XTest。在经过一番折腾后基本领悟了XTest的使用心法，下面我就从大家平时经常开展的性能测试走起。
一、录制脚本，加入循环等操作
使用XTest录制从体验上确实简单便捷，简单到不用插线不用PC，可以躺着录走着录，即使撩妹都不耽误测试，跟平时操作App无异。对比早期录制脚本又抓控件又摸路径受的罪，幸福感大增。录制很容易上手，就是在录制模式下，按照case跑一遍就OK了，脚本自动生成，这里不做赘述，为了让测试更加充分，我又徒手一口气在复杂路径加了50个循环。真的是徒手，因为就是用手机端的脚本编辑功能就实现了。
二、开始回放查看结果
搞定脚本后可进行本地回放或多机联测，由于是基于控件的录制技术，所以回放过程比较顺利。测试结束后在手机/sdcard/kat/result路径下会生成kat_Performance.csv文件，这就是测试过程的性能数据了，具体信息如下：
性能数据比较中规中矩，内存，cpu，电池温度，流量，帧率数据都有，页面切换滑动点击均无丢帧现象（不过这也可能跟XTest脚本回放速度比较慢有关，这点是这款工具目前看来一个比较让人吐槽的点）。
仅此结果就能满足小生的欲望么？那是绝对不可能的，没有设备耗电信息怎么能算是一个完整的性能测试呢。
三、导出脚本，追加耗电信息输出
通过前期学习，了解到XTest可以导出脚本进行二次编辑并且支持130多个API作为复杂测试任务的扩展，长话短说我将录制的脚本导出到sublime编辑器，加入电量测试代码（自定义的代码，写的不完美不欢迎吐槽）(o^^o)
1.脚本开头加入电池数据清空代码
-- 电池数据清空
shell('dumpsys batterystats --reset && echo True')
2.脚本结束将电量信息输出到logcat
--输出耗电结果
shell("dumpsys batterystats > /sdcard/kat/Result/batterystats.txt && echo True")
--读取txt文件的代码
local f = io.open('/sdcard/kat/Result/batterystats.txt', 'r')
for line in f:lines() do
print(line)
shell('log -p i -t getbatterystats "' .. line .. '" && echo True')
end
f:close()3.重新启动测试，测试完成后到logcat日志中收割电量测试结果，目标文件就在/sdcard/kat/result目录下(logcat.txt)如下：
好吧，看起来也都正常，我只是想说嗯这个也可以测，因为这个xtest可以摆脱usb线束缚无线回放脚本，这样才能获取到较为精准的电量信息。当然，希望今后类似的专项测试也能有个好的报表展现方式。
PS：注意这是耗电测试，所以充电压脉带，也正是XTest这种可无线测试的自动化引擎，才能方便搞定之前需要频繁插拔usb线才能完成的测试任务。
一、小程序分析
弄完了性能测试，我们切回主题，搞一下小程序，着手开展小程序UI自动化前，我们需要关注一下XTest是否可以轻松撸到小程序的控件
1、小程序的Hybrid控件
小程序对当前已支持的组件给出了演示程序，首先看下这些控件的真面目
使用XTest辅助工具对控件抓取可知，在X5 WebView内，控件也是如Android原生控件一样具有属性字段的。
E/Kat: setString=={name:SPAN,type:notFound,X:99,Y:777,X2:171,Y2:831}
E/Kat: name = SPAN;type=notFound;label=text; x=99 y=777 x2=171 y2 = 831
E/Kat: トップ結果:168,1016,[99,990,72,54],-2,top=[SPAN,text],valid=[SPAN,text] ],30000000,0,0,weight=0
E/Kat:@0%1:android.widget.FrameLayout%1:android.widget.FrameLayout%1:android.widget.FrameLayout%1:android...
たとえば、コントロールの resource-id 属性フィールドは「SPAN」、テキスト属性フィールドは「text」であり、コントロールの直交座標範囲値とレイアウト階層も同様です。 XTest を使用して正確に取得されます。
2. 特殊なコントロールもオブジェクトのプロパティを取得できますか?
スイッチ、ビデオ、キャンバス、マップ、その他のコンポーネントはすべて、これらのデータに基づいてオブジェクトのプロパティを取得でき、UI オートメーション コントロールのキャプチャを完了できます。
2. ミニプログラムテストの実践
1. ビデオインターフェーステスト
ミニプログラムのデモでは、コンポーネントの提供に加えて、いくつかのインターフェース機能も示します。抽出された「このより複雑な使用例をテストします: (インターフェイス タイプ: メディア-ビデオ)
先頭のパスから入ります。画像内の + コントロールをクリックすると、システム カメラに入ります。何?何！ ……、XTest が制御不能になり、制御不能になり、システム カメラの操作プロセスを記録できません。デモのプロモーションでクロスプロセスについて触れられていたのに、なぜ今回は溝を越えたのでしょうか？憤りと疑問を抱いた私は、XTest 開発のクラスメートに連絡しました。彼らは、関連する APK をツールを通じて携帯電話にアップロードする必要があるという条件で、ツール自体がクロスプロセス テストをサポートしていると言いました。彼らが私にくれた具体的なアドバイスは次のとおりです。
1) デフォルトのシステムカメラを他のカメラアプリケーションに置き換え、テストのためにこの APK を携帯電話にアップロードします
2) 自動化 + 手動操作を使用します
私は後者について非常に興味があります。自動化+人工とは何ですか?私はそれを試してみました。彼らの助けを借りて実際に実行することができました。具体的には、自動化と手動作業の間の対話プロセスを完了し、終了後に音量ボタンを押してテスト結果を報告するというステートメントをスクリプトに挿入しました。その後、自動化がタスクを引き継ぎ、実行を継続します。 将来的には検査業界でも工場組立ラインが導入されるようだ、ますます人間らしくなっているフォックスコンの工場の設備と、ますます機械らしくなっている人々のことを考えると、シャオシェンは身震いした。
上の図では、WeChat プログラムのテストにはアカウントのログインが必要です。WeChat アプレットのログイン アカウントがサポートされています。これはサーバーによって均一に管理され、実行時に携帯電話に送信されてログインが完了します。
画像内の 4 つのアカウントがサーバーによって割り当てられた唯一のアカウントであることを確認してください。これらは異なるため、各デバイスがスムーズにログインできるようになり、フレームワークによって複数マシンの共同テストが推進されます。
3. 共同テストレポートの表示
マルチアカウント分散と複数マシンの共同テストが完了すると、サーバー側で直接テストレポートを表示できます。
上の写真は、Xtest を使用した複数マシンの共同テスト後の 1 台のデバイスのパフォーマンス データを示しています。スクリーンショットから、ミニ プログラムのビデオ インターフェイスに入って再生を開始した後 (ステップ 6)、ビデオがキャッシュにロードされるにつれて、曲線の赤い線 (CPU) が上向きに傾き始めていることがわかります (ステップ 6)。 7 と 8) では、緑色の線 (NetFlow) が急激に増加し始めていることを示しています。まあ、それは人間の巨視的認知理論とかなり一致しています。スクリプトのシナリオに従って記述すれば、ストレス テスト中にパフォーマンス データの収集を完了し、ピクチャ シーケンスに基づいてどのステップがパフォーマンス データに異常を引き起こすかを特定するのは簡単です。
これを見て、シャオシェンはため息をつくだけでなく、一連の無料ツールでこのようなレベルを達成できるのに、これ以上何を求めることができますか？
上記の浅いところから深いところ、深いところからエクスタシーへのテスト プロセスを経た後、一見見慣れない謎に満ちた小さなプログラムは、テスト エンジニアの目には非常に馴染み深いものになりました。パフォーマンス データの取得、特別なテスト レイアウトから、複数マシンの共同テスト、複数アカウントの配布、豊富なレポート結果の最終表示に至るまで、XTest はミニ プログラムの準備ができているようです。これはすべて神の意志ですか、それとも偶然ですか？あるいは単純に、テンセントはすでに完全な状況を私たちに提示しており、この頭が痛くなるようなサスペンスは、エディターのシングルコア CPU が処理できる計算量を完全に超えています。ミニプログラムテストの準備は万全だということだけはわかっているので、ミニプログラムの嵐はさらに激しく来るだろう。
WeChat ミニプログラムの自動化された親密な接触に関連するその他の記事については、PHP 中国語 Web サイトに注目してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
