安卓稳定性测试该怎么落地？

从框架选型到性能监控一个学习机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只是工具之一不是全部。用数据驱动测试 。埋点采集的用户行为比你自己设计的路径更有价值。想办法拿到真实数据让你的测试逼近真实场景。如果你也在做安卓稳定性测试或者在测试框架选型上卡住了欢迎来霍格沃兹约一次私教。有经验的老师帮你指一下方向可能比你闷头摸索一个月都管用。