从框架选型到性能监控，一个学习机App的测试进化之路

01 “我刚来两周，领导让我搞稳定性”
“老师你好，我这边有两个方面的问题。”

电话那头，学员的声音带着一点紧张，也带着一点急切。

“第一个是关于安卓App的稳定性测试，我以前没接触过这方面。现在公司需要我去落地，我自己写了一份方案，但总觉得没什么优化的思路。”

“第二个是……”

他顿了顿。

“我主要是对安卓的技术栈不太熟。以前做的是BS架构的SaaS平台测试，现在来了新公司，做学习机。遇到问题了，不知道问题出在前端还是安卓应用层，感觉整个人都懵了。”

这是霍格沃兹私教服务里很常见的一幕：一个优秀的测试同学，被扔到一个全新的领域，需要快速扛起大旗。

领导要的是结果，而他要的是方向。

02 先聊框架：你的UI自动化用的是什么？
“你们现在UI自动化用的是什么框架？”老师问。

“用的是UIAutomator2 ，但只有之前离职同事写的一个demo，就一两条用例。”

老师听完，很直接地说：“我觉得你可以试一下别的框架。UIAutomator2 有点过时了，现在主流的是另外两套。”

“哪两套？”

“一个是Appium ，另一个是网易的Airtest 。你接触过吗？”

“Airtest我有了解过。”学员说。

“对，我个人比较推荐Airtest。第一，用户多，社区活跃，稳定性好。第二，它本身就是做游戏测试的，图像识别能力很强 。”

学员追问：“我们可能会用到图像识别，因为学习机上有些画面需要验证。”

“那就更合适了，”老师说，“图像识别的好处是，对版本改动不敏感。按钮位置变了、代码结构改了，只要画面变化不大，它都能认出来。UIAutomator2 那种基于控件定位的，代码一重构，用例全废。”

科普小贴士：UI自动化框架的三代进化

第一代 ：基于坐标点击。最原始，屏幕分辨率一变就完蛋。
第二代 ：基于控件属性（resource-id、xpath）。比坐标稳定，但代码重构时维护成本高。
第三代 ：基于图像识别 + AI。不关心控件树，只认画面。Airtest就是这一代的代表。
03 “Airtest的图像识别太严格了，能调吗？”
学员又问了一个很细的问题：“我看前同事留的文档说，Airtest的图像识别太过严格。这个可以调相似度吗？比如90%相似就算通过？”

“可以调的，”老师说，“它本身就有阈值参数。而且还有一个更高阶的用法——建一个图像库 ，存多张参考图，它会去做匹配和校准。”

“不过这个有一定学习成本，要去翻一下源码或官方文档。但思路是有的：比如同一个按钮在不同分辨率下可能有细微差别，你可以存多张图，让它去匹配最像的那个。”

学员记下了。

这里插一句：很多测试同学在选型时，只看框架“能不能用”，而忽略了“好不好维护”。Airtest这种图像识别方案，对于多机型、多分辨率、UI变化频繁 的项目来说，维护成本远低于控件定位方案。

04 用例怎么管？脚本怎么写？
“那它的用例是怎么管理的？本身提供管理工具吗？”学员问。

“有的。它自己有IDE，可以录制脚本，也可以手写代码。录制完后可以注入一些逻辑，上手比较容易。”

“而且现在网上资料很多，很多项目都是开源的，可以直接参考。”

学员松了口气：“那就好，我就怕从头造轮子。”

老师在这里传递了一个很重要的理念：不要重复造轮子。 用好现有的开源生态，把精力花在解决自己业务特有的问题上，才是聪明的做法。

05 转折：其实领导要的不是UI自动化
聊到这里，老师说了一句：“但是说实话，很多公司现在不太愿意搞UI自动化。维护成本太高了。”

“是的！”学员像找到了知音，“我以前就是做接口自动化的，接口稳定多了。但是这家公司……功能业务太重了，功能测试占了绝大部分精力，性能专项都没怎么做。”

“那你们领导到底想要什么？”

“领导说的是稳定性 ，不是UI自动化。UI只是其中一块，用来覆盖一些固定的用户路径。他想要的是：崩溃、卡顿、掉帧、响应慢这些问题能提前发现。”

老师说：“明白了。那UI自动化只是你的一个手段，不是目的。你真正要做的是稳定性测试体系 。”

06 一份方案的诊断
学员打开了屏幕共享，展示自己写的稳定性测试方案。

方案里写了：用Monkey做随机遍历，用UIAutomator2 做固定路径覆盖，监控崩溃、丢帧、GC、交互响应等指标。

“你这里有个问题，”老师指着屏幕说，“Monkey确实能跑，但它有个致命缺点——覆盖面不够 。”

“对！”学员说，“我们的应用页面层级很深，Monkey很难点到深层页面，覆盖率上不去。”

“是的，Monkey是纯随机事件，对复杂的业务场景基本无能为力。市面上也有一些自动遍历工具，比如Fastbot、AppCrawler，但它们的适用场景也有局限。”

“那怎么办？”学员问。

“要么你们自研一套基于深度遍历的工具，要么——用数据驱动 。”

老师接着说：“你们可以做埋点采集，拿到用户的真实操作轨迹，然后转成自动化用例。用户怎么点，你就怎么测。这个比你自己拍脑袋想的路径要真实得多。”

“埋点……我刚来两周，不太清楚公司埋了哪些信息。”

“可以去找产品和研发要，APM的数据通常都会埋。埋点越精细，你越能知道用户真实是怎么操作的。很多用户的操作是反人类的——进去就退出、狂点、杀后台……这些你自己是想不出来的。”

这其实就是“基于用户行为的稳定性测试”，比盲目的Monkey高效得多。

07 性能指标怎么拿？工具链怎么串？
“老师，还有两个实操问题。”

“第一个，我怎么用脚本把30多个自研应用的启动时间、帧率这些指标批量跑出来？总不可能手工一个一个测吧？”

“第二个，Monkey这种工具，跑完之后的结果怎么自动生成报告？我不想手工分析log。”

老师笑了：“这些问题都不难解决。”

“性能指标这块，启动时间、渲染性能、GPU占用……市面上都有现成的工具。比如adb shell am start -W 可以拿启动时间，GPUView 或一些开源工具可以看渲染性能。你完全可以把这些命令封装到Python脚本里，一次性跑完所有应用，把数据收集起来。”

“报告这块，Airtest本身就集成了报告能力。Monkey跑完后，你也可以写个脚本解析log，把崩溃、ANR、异常抓出来，生成HTML报告。这些都不是难事。”

学员听得眼睛亮了：“那就是说，我可以串起来？”

“对，Python可以做胶水语言。调用adb命令、启动Monkey、解析结果、发报告——一套流程跑下来。”

08 “你要不要考虑云真机？”
聊到后面，老师问了一个前瞻性的问题：“你们后面会建云真机平台吗？”

“硬件那边有自己的实验室，可以连设备。软件这边好像还没有。”学员说。

“建议你们搞一下，”老师说，“云真机不一定要买新的设备，就是把现有的真机集中管理起来，远程连接。这样你可以同时跑多台设备的稳定性测试，不用在自己电脑上插一堆线。”

“而且云真机配上你的脚本，晚上跑、早上看报告，效率翻倍。”

学员说：“这个我回头跟leader提一下。”

09 尾声：方向对了，剩下的就是执行
这场辅导持续了将近30分钟。

从一个模糊的“我要做稳定性测试”，到框架选型、工具链串接、埋点采集、云真机规划，老师帮学员把整个地图画了出来。

学员最后说：“我明白了，回去研究一下。”

老师说：“其实你们这种情况，最大的难点不是技术，是你要先搞清楚领导真正要的是什么 。他要的是UI自动化吗？不是。他要的是崩溃少一点、用户不骂人。你把指标量化出来，把问题提前发现，你的价值就体现了。”

“好的，谢谢老师！”

给读者的三点总结：

UI自动化框架没有银弹 。如果UI变化频繁，图像识别方案（如Airtest）比控件定位方案维护成本低得多。
稳定性测试 ≠ UI自动化 。它包含性能、兼容性、异常场景、长期运行等多个维度。Monkey只是工具之一，不是全部。
用数据驱动测试 。埋点采集的用户行为比你自己设计的路径更有价值。想办法拿到真实数据，让你的测试逼近真实场景。
如果你也在做安卓稳定性测试，或者在测试框架选型上卡住了，欢迎来霍格沃兹约一次私教。有经验的老师帮你指一下方向，可能比你闷头摸索一个月都管用。