shell@HWNXT:/$dumpsysactivitytop|grepACTIVITYACTIVITYcom.tencent.mm/.ui.LauncherUI44c445fpid=7593通过命令查看，当前top进程是7593，确实是com.tencent.mm。
看一下top进程：
shell@HWNXT:/$dumpsysactivitytop|grepACTIVITYACTIVITYcom.tencent.mm/.plugin.appbrand.ui.AppBrandUI15a772pid=9896shell@HWNXT:/$当前top进程是9896，果然是com.tencent.mm:appbrand0。
shell@HWNXT:/$ps|grepu0_a539u0_a5396688533175121286184SyS_epoll_0000000000Scom.tencent.mm:pushu0_a53975935332187672263352SyS_epoll_0000000000Scom.tencent.mmu0_a53980475332336360224436SyS_epoll_0000000000Scom.tencent.mm:tools进程没有变化，看看top进程:
shell@HWNXT:/$dumpsysactivitytop|grepACTIVITYACTIVITYcom.tencent.mm/.plugin.webview.ui.tools.WebViewUI1502038pid=14685网页居然是在com.tencent.mm:tools进程里面打开的，并且两者的Activity也不一样，小程序是.plugin.appbrand.ui.AppBrandUI，网页是.plugin.webview.ui.tools.WebViewUI。
目前Android自动化测试框架主要分6大类：
铁鞋踏破仍无路，靓女帅哥也踌躇啊，忽然间灵感一现，腾讯自家会不会有什么奇葩产品可用啊，知行合一谷歌百度，搜索腾讯自动化立马看到腾讯优测的介绍，到官网里翻了一下找到一款叫XTest的自动化测试工具，看到简介目前只支持Android平台，想想前面历程这般痛苦，还要啥自行车啊。于是乎赶忙下载了一套热气腾腾的XTest，安装完毕，一切准备就绪，关门，放XTest。在经过一番折腾后基本领悟了XTest的使用心法，下面我就从大家平时经常开展的性能测试走起。
使用XTest录制从体验上确实简单便捷，简单到不用插线不用PC，可以躺着录走着录，即使撩妹都不耽误测试，跟平时操作App无异。对比早期录制脚本又抓控件又摸路径受的罪，幸福感大增。录制很容易上手，就是在录制模式下，按照case跑一遍就OK了，脚本自动生成，这里不做赘述，为了让测试更加充分，我又徒手一口气在复杂路径加了50个循环。真的是徒手，因为就是用手机端的脚本编辑功能就实现了。
搞定脚本后可进行本地回放或多机联测，由于是基于控件的录制技术，所以回放过程比较顺利。测试结束后在手机/sdcard/kat/result路径下会生成kat_Performance.csv文件，这就是测试过程的性能数据了，具体信息如下：
性能数据比较中规中矩，内存，cpu，电池温度，流量，帧率数据都有，页面切换滑动点击均无丢帧现象（不过这也可能跟XTest脚本回放速度比较慢有关，这点是这款工具目前看来一个比较让人吐槽的点）。
仅此结果就能满足小生的欲望么？那是绝对不可能的，没有设备耗电信息怎么能算是一个完整的性能测试呢。
通过前期学习，了解到XTest可以导出脚本进行二次编辑并且支持130多个API作为复杂测试任务的扩展，长话短说我将录制的脚本导出到sublime编辑器，加入电量测试代码（自定义的代码，写的不完美不欢迎吐槽）
1.脚本开头加入电池数据清空代码
--电池数据清空 shell('dumpsysbatterystats--reset&&echoTrue')2.脚本结束将电量信息输出到logcat
--输出耗电结果shell("dumpsysbatterystats>/sdcard/kat/Result/batterystats.txt&&echoTrue") --读取txt文件的代码 localf=io.open('/sdcard/kat/Result/batterystats.txt','r')forlineinf:lines()doprint(line)shell('log-pi-tgetbatterystats"'..line..'"&&echoTrue')endf:close()3.重新启动测试，测试完成后到logcat日志中收割电量测试结果，目标文件就在/sdcard/kat/result目录下(logcat.txt)如下：
好吧，看起来也都正常，我只是想说嗯这个也可以测，因为这个xtest可以摆脱usb线束缚无线回放脚本，这样才能获取到较为精准的电量信息。当然，希望今后类似的专项测试也能有个好的报表展现方式。
PS：注意这是耗电测试，所以充电压脉带，也正是XTest这种可无线测试的自动化引擎，才能方便搞定之前需要频繁插拔usb线才能完成的测试任务。
1、小程序的Hybrid控件
小程序对当前已支持的组件给出了演示程序，首先看下这些控件的真面目
使用XTest辅助工具对控件抓取可知，在X5WebView内，控件也是如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=99y=777x2=171y2=831E/Kat:top-result:168,1016,[99,990,72,54],-2,top=[SPAN,text],valid=[SPAN,text],30000000,0,0,weight=0E/Kat:@0%1:android.widget.FrameLayout%1:android.widget.FrameLayout%1:android.widget.FrameLayout%1:android...例如控件的resource-id属性字段为”SPAN”;text属性字段为”text”,以及控件的矩形坐标范围值和layout层级结构，这些数据使用XTest都可以准确获取。
2、特殊控件也可以获取到对象属性么？
switch、video、canvas、map等组件都可以获取到对象属性，基于这些数据，可以完成UI自动化的控件抓取。
1、视频接口测试
小程序演示中除了提供组件之外也展示了部分接口功能，从中抽取代表性的“选择视频”这一较为复杂用例进行测试：（接口类型：媒体--视频）
通过前导路径进入当点选图片中的+控件后，进入系统相机，什么？什么！……..，XTest失控了，失控了，无法录制系统相机操作过程。Demo宣传里面提到什么跨进程，这回怎么跨到沟里去了？带着愤恨跟疑问勾搭了一下XTest开发同学，他们提到工具本身确实支持跨进程测试，前提是需要把涉及到的apk也通过他们的工具上传到手机端，给到我的具体建议是：
1)用其他相机应用替换掉默认系统相机，然后将此apk上传到手机端测试2)采用自动化+人工交互方式
我对后者十分好奇，什么是自动化+人工？搞搞试试，于是乎根据他们的帮助还真的搞定了，具体就是在脚本里面插入一条语句：完成自动化与人工的交互过程，结束后按音量键上报测试结果，之后自动化接管任务继续执行。看来今后测试行业也要走工厂流水线了，想想富士康工厂里愈来愈像人的设备与愈来愈像机械的人，小生不仅打了一个冷颤。
2、多账号分发测试
3、联测报告展示
完成多账号分发多机联测后，就可直接在server端查看测试报告了。
上图是用Xtest进行多机联测后一台设备的性能数据展示。从截图可以看到当进入小程序的视频界面开始播放后（第6步），曲线图的红色线（CPU）开始斜坡上升，随着视频加载缓存（第7、8步），代表上下行流量的绿色线（NetFlow）开始陡增。嗯，还是比较符合人类宏观认知理论的。如果配合脚本的场景编写，应该很容易就可以完成压测中的性能数据收集，并根据图片手顺定位哪步操作会导致性能数据异常。
看到这里小生不仅感叹，一套免费的工具做到如此程度，夫复何求啊！
经过了以上由浅入深又由深到销魂的测试过程，看似陌生神秘的小程序，在我们测试工程师的眼里变得如此熟悉与亲密。无论从性能数据获取、专项测试布局，到多机联测、多账号分发，再到最后丰富的报告结果展示，XTest仿佛早已为小程序做好了准备。这一切到底是天意还是巧合？或者干脆就是腾讯早已为我们布好了完整的局，这烧脑的悬疑已经完全超出了小编单核cpu所能承载的计算量。我只知道面对小程序测试我已经做好了充足的准备，让小程序的暴风雨来得更猛烈些吧。