刚入行做移动端测试的朋友几乎都会问同一个问题APP测试到底该怎么学网上搜到的资料要么是一堆工具的堆砌要么是面试题速记照着折腾一圈真到了项目里还是不知道从哪儿下手。我自己带过不少新人也踩过不少弯路这里把APP测试从功能到自动化再到专项的完整脉络整理出来算是一份可以直接照着走的攻略。这份内容适合三类人刚转行或准备转岗移动端测试的新人做了几年功能测试想往自动化方向提升的同行以及需要在团队里从零搭一套APP测试方案的人。我不会只丢工具名字会把每个环节“为什么要做”“怎么落地”“常见的坑在哪儿”一起讲清楚。1. 移动端测试的核心知识地图别在零散工具里迷路1.1 为什么移动端测试比Web测试难一截很多人从Web测试转过来第一感觉是“不都是点点点吗”实际上手才发现完全不是一回事。移动端测试最大的特点在于碎片化操作系统有iOS和Android两大阵营Android自身又有小米、华为、OPPO、vivo等各家定制ROM屏幕尺寸、分辨率、刘海屏、折叠屏五花八门网络环境从5G到弱Wi-Fi再到地铁里的高延迟随时在变用户的使用场景也不是坐在电脑前稳定操作而是边走边用、切后台、来电话、锁屏亮屏各种中断随时插入。这就是移动端测试的第一个核心认知你不能只测“功能通不通”还要测“在各种乱七八糟的环境下还通不通”。这也是为什么业内把移动端测试分成功能、兼容性、性能、弱网、稳定性、安全等好几个专项每个专项背后都有对应的工具和方法论。另一个难点是系统机制的复杂性。Android有生命周期管理App切到后台可能被回收恢复前台要处理状态推送来了要跳转指定页面权限弹窗第一次拒绝后第二次的文案和逻辑可能完全不同。这些机制本身就是一个巨大的测试维度如果只看表面功能漏掉的基本都是线上事故高发区。1.2 新人需要掌握的模块全景我建议新人先按三条主线搭知识框架不要一上来就钻进工具细节里。第一条是测试设计主线。包括用例设计方法等价类、边界值、场景法、正交实验、版本迭代中的回归策略、兼容性矩阵的建立。这条线决定你会不会测。第二条是自动化与工具链主线。包括ADB命令、Appium或Airtest这类UI自动化框架、Charles/Fiddler抓包、Postman/Apifox做接口测试。这条线决定你测得快不快。第三条是专项测试主线。包括性能CPU、内存、帧率、启动耗时、弱网、稳定性Monkey、遍历测试、日志分析与Bug复现。这条线决定你测得深不深。三条主线不是并列关系而是层层递进先把功能测试做扎实再考虑用自动化替代重复劳动最后再往专项深度走。测试维度核心问题常用工具优先级功能测试功能是否符合预期TestRail、Xmind、禅道最高兼容性测试不同机型/系统是否正常云真机、真机矩阵高接口测试前后端数据交互是否正确Postman、Apifox、JMeter高UI自动化核心路径回归是否稳定Appium、Airtest、uiautomator2中性能测试CPU/内存/帧率是否达标Perfdog、SoloPi、Profiler中弱网测试弱网下的表现是否可接受Charles、Network Link Conditioner中稳定性长时间运行是否崩溃Monkey、Maxim、WanAndroid中这张表不用背先记住一句话功能测试是地基自动化和专项都是在地基之上盖楼。地基没打牢后面全是空中楼阁。2. 功能测试打底用例设计是根回归策略是命2.1 用例设计的核心方法边界、场景、冲突很多新人写用例就是对着需求文档把正常流程走一遍这个习惯非常危险。移动端测试用例设计如果只能记住三件事那就是边界值、异常场景和状态冲突。边界值最容易理解也最容易被忽略。输入框的字符长度限制、金额的最小单位、列表加载的翻页临界点都属于边界。比如一个注册页的密码要求6到20位5位和21位各测一次6位和20位各测一次这四条就是核心边界。移动端还有个特殊边界——组件尺寸文本超长换行、按钮文字过长导致截断、图片拉伸变形这些在Web端常常无所谓在手机端就是实打实的体验Bug。异常场景要覆盖“用户不按套路出牌”的情况。比如登录接口超时后重复点击、断网后提交订单、支付过程中杀掉App、弱网下图片加载一半。这里有一个很实用的方法每写一条正常用例强制自己写三条异常用例——前置条件异常、操作过程异常、结果异常。比如“正常登录成功”对应“未连接网络登录”“输入错误密码登录”“登录中切换网络”。状态冲突是移动端独有的重点。电话和短信等系统级中断、前后台切换、分屏模式、横竖屏旋转、通知栏下拉、低电量弹窗、闹钟响铃——这些都是系统状态的变化会对当前页面产生干扰。测试时要专门设计一组“中断矩阵”把正在进行的操作看视频、填写表单、上传文件、游戏对战和各类中断事件来电、短信、推送、锁屏、切后台两两组合逐项排查状态是否错乱、数据是否丢失、恢复后是否还能继续。2.2 版本迭代中的回归与冒烟策略功能测试做得好不好一半看用例设计另一半看迭代中的回归策略。很多团队死在同一个坑里每次发版前全量回归测试时间不够就压缩压缩完上线就出问题。我实践下来比较有效的一套做法是这样每个版本先做影响范围分析拉出本次改动涉及的功能模块、改动相关的公共组件、底层数据结构变更影响的上游下游。有了这个清单先把冒烟用例集合跑一遍一般控制在30到50条核心用例覆盖登录、首页、主流程、支付等关键路径冒烟通过再安排全量回归。如果冒烟挂了直接打回开发修复不要在带病状态下做全量测试那是浪费时间。回归用例集本身也要维护。每次线上出Bug对应的复现用例必须沉淀进回归集每次新增核心功能也要补充对应用例。我见过很多团队用例库几百条全是三年前的旧功能新功能反而没有用例覆盖这种用例库就是摆设。2.3 兼容性测试、Bug提单与日志收集兼容性测试常被新人当作“用云测平台跑一遍就完事”实际上需要的是取舍和节奏。第一步确定测试矩阵原则是“Android按品牌占有率和系统版本覆盖率选iOS按主要机型选”。国产Android机建议覆盖高通、联发科、麒麟这三种主流芯片系统版本至少覆盖Android 10/11/12/13屏幕重点覆盖刘海屏和挖孔屏机型。如果预算有限优先做真机矩阵 云真机补漏的组合。真机覆盖日常开发机和主力发布机型云测平台用于大范围铺量。跑兼容性测试时除了功能主流程要特别关注相机调用、存储权限、悬浮窗权限这类和各厂商ROM深度绑定的能力国产ROM对后台权限的管控非常激进一个在原生Android上正常的App到了某厂商ROM上可能后台直接被杀。Bug提单是功能测试的基本功却常常被低估。一条高质量的Bug单至少要包含复现步骤从打开App开始一步步写、预期结果、实际结果、设备信息品牌、型号、系统版本、分辨率、App版本号、复现概率、抓取的日志或录屏。这里分享一个简单但有效的日志收集SOP复现Bug后立刻抓取logcat日志如果涉及网络再配合Charles抓一份请求记录最后用手机自带录屏功能录下操作过程。有了这三样开发定位问题的速度会快很多你的Bug单也会非常有说服力。提示给开发提单时尽量做到“可复现、可定位、可验证”三要素齐全。宁可多花两分钟补日志也不要丢一个只有一句“点击没反应”的Bug单这种单子只会消耗团队的信任。3. 从手工迈向自动化先想清楚再做选择3.1 什么样的项目才值得做自动化这是我觉得最值得展开说的问题。很多新人对自动化有执念觉得测试工程师不做自动化就不高级结果一上来就给一个还在频繁改版的项目写UI自动化写一个崩一个最后整个团队对自动化失去信心。判断项目是否适合做UI自动化核心看三个条件第一是版本迭代是否稳定。如果主流程的页面结构和业务逻辑每个版本都在变自动化的维护成本会高到无法承受。适合自动化的版本状态是“功能基本定型剩下的是细节优化和Bug修复”。第二是回归频率是否够高。自动化最大的价值是替代高频率的重复劳动如果核心路径每个版本都要回归那自动化的投资回报率就很高如果一个月才发一次版手动回归30分钟就能跑完自动化的意义就没那么大。第三是团队是否有维护意愿。UI自动化不是写完就完事它是一个持续投入的资产需要有人负责维护。如果团队没人愿意接这个活儿再好的框架也会在三个版本之后彻底腐烂。3.2 主流UI自动化工具怎么选移动端UI自动化工具主流的就那几个Appium、Airtest、uiautomator2加上iOS端的XCUITest。选工具不能只看名气要看项目实际场景。工具平台支持脚本语言特点适合场景AppiumAndroid iOSPython/Java等WebDriver协议社区最大生态全跨平台、需要和CI深度集成的团队AirtestAndroid iOSPython基于图像识别上手门槛低游戏或自定义控件难定位的Appuiautomator2AndroidPython轻量、速度快、API简洁Android-only项目、快速落地XCUITestiOSSwift/Objective-CApple官方框架稳定性好iOS专项自动化一点个人经验如果团队以Android为主、又需要快速看到成果uiautomator2是最容易落地的选择如果要跨Android和iOS统一维护选Appium更合适如果被测App大量使用自定义绘制游戏、地图类Airtest的图像识别方案是最能打的。工具本身不是越高级越好能稳定运行三个月不出大问题的就是好选择。3.3 自动化的正确分层UI、接口、专项对自动化的理解很多人的误区是“自动化 UI自动化”。其实一套健康的移动端自动化体系应该是分层配合的接口自动化是占比最大的一层。移动端大部分业务逻辑都在服务端接口层的自动化投入小、执行快、稳定性高。我见过不少团队先把核心业务接口做成自动化覆盖率达到70%以上后很多通用回归根本不用碰UI。接口层的框架选择Java用RestAssuredPython用requests pytest工具选Apifox或JMeter都能起步。UI自动化是占比最小但价值最直观的一层。只覆盖最核心的几条用户路径比如注册登录、首页浏览、加购支付、消息刷新。执行频率也不需要每个版本跑关键版本发版前跑一遍就够了。UI自动化的定位不是替代手工而是作为发版前的最后一道保险。第三层是移动端特有的专项自动化比如用脚本批量执行弱网场景、用Monkey做稳定性测试、用Perfdog采集性能数据并自动生成报告。这一层自动化程度越深测试的深度价值越明显。4. app自动化测试环境搭建从零到第一个可跑通的脚本4.1 环境清单与版本兼容环境搭建是自动化入门的第一道坎也是劝退最多人的地方。核心原因多数不是操作复杂而是版本不匹配。这里先给一套经过验证的Java Appium方案JDK8或11都行注意Appium对JDK版本有要求JDK 17在某些旧版本Appium上会有兼容问题Android SDK通过Android Studio安装配置ANDROID_HOME环境变量把platform-tools和emulator目录加进PATHNode.jsAppium 2.x基于Node运行建议装14以上版本Appium Server2.x版本通过npm安装Appium Inspector是2.x配套的元素查看器Python3.8以上配合Appium-Python-Client使用。这套组合我踩过最大的坑是Appium 1.x和2.x的差异。Appium 2.x把driver的管理方式改了需要单独安装驱动安装命令是appium driver install uiautomator2Android和appium driver install xcuitestiOS。如果你按网上的老教程执行了appium desktop之类的命令会直接提示不存在这就是版本文档没对齐的典型症状。4.2 真机/模拟器联调环境装完最兴奋也最容易卡住的就是设备连接。模拟器选型上Android官方模拟器和Genymotion都可用但做自动化测试我更推荐真机原因很简单模拟器跑不出真实设备的很多问题而且部分国产ROM在模拟器上兼容性很差。真机连接四步走用数据线连接电脑手机上弹出的USB调试授权弹窗要选择“允许”终端执行adb devices能看到设备序列号且状态为device就说明连接成功执行adb shell getprop ro.product.model验证能正常读取设备信息如果设备状态显示unauthorized拔线重插或在手机上撤销USB调试授权后重新允许。这里有个小细节够提一句开发者选项里的“不锁定屏幕”建议打开自动化跑用例时如果手机锁屏连接会中断用例会大面积失败这个坑很容易让人误以为是框架问题。4.3 第一个Appium脚本环境通了以后跑通第一个脚本就是建立信心的关键一步。下面这段代码是我建议新人在自己手机上跑起来的第一个用例打开任意一个App后点击一个元素再退出的完整流程。这里以打开“设置”并点击搜索框为例from appium import webdriver desired_caps { platformName: Android, deviceName: Android Device, appPackage: com.android.settings, appActivity: .Settings, noReset: True, unicodeKeyboard: True, resetKeyboard: True, } driver webdriver.Remote(http://127.0.0.1:4723/wd/hub, desired_caps) driver.implicitly_wait(10) # 点击设置页的搜索图标 driver.find_element_by_id(com.android.settings:id/search_action_bar).click() # 在搜索输入框中输入文本 driver.find_element_by_id(com.android.settings:id/search_action_bar_query).send_keys(wifi) driver.quit()注意如果你用的是Appium 2.x访问地址改为http://127.0.0.1:4723而不是上面这个老地址/wd/hub路径在2.x已经弃用了。第一次跑不起来太正常了报错信息里如果有SessionNotCreatedException90%的情况是desired_caps里某个参数不对如果有AppiumDriver相关报错先检查appium doctor看看环境还缺什么。4.4 环境搭建中容易踩的坑环境坑是一个值得单独说的主题因为80%的新人都倒在这一步。我把最典型的几个列出来第一是Android SDK路径没配好。命令行执行adb --version能正常输出但uiautomator2驱动安装后找不到设备基本可以确定是ANDROID_HOME和PATH的问题。正确的配置是ANDROID_HOME指到SDK根目录PATH里加上$ANDROID_HOME/platform-tools和$ANDROID_HOME/emulator。第二是Appium Server端口被占用。默认4723端口经常被各种程序占用启动Server时如果提示端口冲突换一个端口启动脚本里remote的地址也要一起换。第三是元素定位不到。Appium默认启用原生控件定位如果你的App是H5页面WebView需要在代码里切换到WebView上下文才能定位元素。判断方法是先用Appium Inspector查看当前页面是原生控件还是网页元素不要在没搞清楚页面结构的情况下硬调脚本。第四是手机系统权限弹窗。自动化运行时如果App弹出系统权限请求且脚本没有对应的处理步骤后续所有操作都会卡住。推荐在desired_caps里设置autoGrantPermissions: TrueAppium 2.x支持一次性自动授予权限省去大量无意义的弹窗处理逻辑。5. 无线模式下的自动化与远程调试摆脱数据线的束缚5.1 adb无线连接手机连着数据线做自动化有一个很尴尬的场景用例跑到一半数据线被碰一下松了连接断开整个任务废掉。还有一种场景是设备在另一个办公室甚至另一个城市根本不可能插线。这时候就需要无线连接。adb无线连接分两步走前提是手机和电脑在同一局域网# 先用数据线连接手机执行一次tcpip命令开启无线调试端口 adb devices adb tcpip 5555 # 拔掉数据线通过手机IP和端口连接 adb connect 192.168.1.100:5555 # 验证是否连接成功 adb devices连接成功后后续所有adb命令和Appium脚本都不再依赖数据线。注意一点adb tcpip 5555之后手机重启会默认关闭无线调试需要重新执行一次。另外如果手机锁屏超过一定时间无线连接也可能会断所以“不锁定屏幕”这条在无线调试场景下同样重要。5.2 无线自动化执行无线模式跑自动化脚本本质上只是在Appium的desired_caps里把udid设为无线连接的地址比如192.168.1.100:5555其他代码逻辑完全一致。这意味着你可以把一批手机放到机房里统一充电、连上同一个Wi-Fi然后坐在工位上批量执行自动化测试。这里补充一个多设备并行思路启动多个Appium Server实例每个实例指定不同的端口比如4723、4725、4727每个脚本实例连一个不同IP的无线设备再通过pytest的并发插件分组执行就能实现一套设备矩阵的并行回归。我在实际项目里用这个方法把原本5个小时的六台设备全量回归压缩到了不到1小时。无线自动化的坑也有几个值得一提。第一是真的不能锁屏锁屏一次全部用例报废第二是Wi-Fi信号要稳定建议用5GHz频段避免2.4GHz频段的干扰第三如果手机连接数多路由器的DHCP租约时间要设置好否则设备IP变了一次所有脚本都要跟着改配置。5.3 云真机方案如果不想自己维护真机矩阵云真机是更省力的选择。国内主流的云测平台都提供远程真机服务按小时计费可以在网页上实时操作一台远程手机也可以直接跑自动化脚本。云真机的核心优势是一次性覆盖大量机型——测一个兼容性矩阵不再需要真的买二十台手机。我在项目里通常这样用日常开发自测用一两台身边的真机发版前用云真机跑一套覆盖主流机型的兼容性用例成本和效率都远优于自建机架。云真机也有明显的短板网络环境不在本地弱网测试无法完全模拟现场网络的真实表现部分涉及硬件能力的功能NFC、传感器、AR在云真机上体验很差高峰期排队也会耽误时间。所以我的建议是云真机做覆盖广度本地真机做深度验证两者结合。6. 专项测试不能跳过性能、弱网与稳定性落地套路6.1 性能测试关注CPU、内存、帧率、启动耗时性能测试在移动端几乎是一个独立的工种但作为测试必须要掌握核心的采集和判断方法至少要能回答“这个版本比以前卡了没有”。最常看的四个指标是CPU占用率、内存占用、界面帧率和启动耗时。采集工具的选择iOS端用Xcode自带的InstrumentsAndroid端可选择就比较多了。字节跳动的Perfdog支持Android和iOS能实时曲线显示CPU、内存、帧率带多设备对比功能腾讯的SoloPi则是纯Android端不需要连接电脑直接安装在测试机上后台运行。SoloPi这类不需要PC连接的工具特别适合快速排查现场问题因为不需要设备连着数据线。启动耗时是移动端一项专门的体验指标分冷启动和热启动。冷启动指进程从无到有热启动指从后台恢复到前台。测试方法并不复杂执行adb shell am start -W命令能看到TotalTime和WaitTime两个关键值前者是页面启动完成时间后者是加入了系统开销的时间。日常回归时把这个值跟上一版本对比涨了多少就能量化出来。帧率这个指标主要看列表滑动和页面转场这两个场景。理论标准是每秒60帧实际测试中只要大多数时间稳定在55帧以上且没有明显掉帧就可以接受。卡顿的瓶颈往往发生在列表混排图片、视频、文本混在一起和页面首次加载的场景测性能的时候要优先测这两个高风险点。6.2 弱网测试不是把速度调慢那么简单弱网测试是移动端最有“行业特色”的专项之一。很多新手以为弱网测试就是把网速调慢看看图片加载慢不慢这理解太浅了。弱网环境真正的杀伤力在于请求超时、连接中断、数据包延迟抖动、DNS解析异常。一个在正常网络下逻辑完美的App在弱网下可能出现重复提交订单、界面卡死、数据不一致、白屏等各种问题。做弱网测试最常用的工具是Charles和Fiddler通过代理模拟网络状况。Charles的Throttle Settings可以设置带宽、延迟、丢包率。这里给一组常用的弱网配置参考场景带宽延迟丢包率弱网1较慢1 Mbps100 ms1%弱网2很差256 Kbps300 ms3%极端弱网64 Kbps500 ms5%弱网测试的用例重点不是“能不能加载出来”而是“加载失败之后的处理对不对”。比如进入一个页面时断网页面应该显示错误提示和重试按钮而不是一直转圈提交订单时请求超时要检查用户是否被重复扣款或生成了重复订单图片加载一半断网重连后是重新加载还是能断点续传。这里的验证重点在于业务数据的正确性和一致性而不只是界面表现。6.3 稳定性测试Monkey与遍历式测试稳定性测试的核心目的是在短时间内暴露长时间运行才会出现的崩溃、无响应、内存泄漏等问题。最经典的工具就是Android的Monkey——随机向系统发送大量伪随机事件模拟用户各种乱点行为。简单用法是# 向被测App发送5000次随机事件 adb shell monkey -p com.example.app --throttle 300 -v -v 5000如果是首次跑Monkey你会发现它能在一分钟内点出你完全想不到的页面组合很多崩溃都是这么挖出来的。但Monkey的随机性也有一个明显的副作用执行过程中很容易离开被测App进入系统设置、通知栏甚至其他应用。所以Monkey跑着一直报错不一定是App的问题要看清楚崩溃堆栈是不是自己的包名。比Monkey更现代的做法是遍历式测试腾讯的Maxim就是典型的遍历类工具它的思路是不完全随机而是智能遍历页面元素覆盖率比Monkey高很多。稳定性测试跑完后要收集两类关键证据崩溃栈从logcat里抓FATAL EXCEPTION附近的内容和ANR日志/data/anr/目录下的traces文件。有了这两样开发才能快速定位问题。7. 给新人的学习路线和几条避坑建议7.1 一条主线从功能到自动化的学习路径讲了这么多最后落回到“怎么学”这个问题上。我的建议是严格按照这条主线推进不要跳级第一步是打好功能测试基本功。找一款市面上常用的App记账类、笔记类、天气类都可以给它写一份完整的测试用例文档覆盖正常流程、边界值、异常场景、中断场景然后在自己手机上按用例逐条执行记录结果。第二步是掌握抓包和日志分析。用Charles给自己的手机配好代理观察App的每个操作触发了哪些请求、传了什么参数、返回了什么结构。这一步能让你真正了解“功能背后发生了什么”。第三步是上手接口自动化。用Apifox或Postman把App的核心接口整理成自动化用例用Python的requests库跑一遍全链路。第四步是UI自动化。在接口自动化跑顺之后搭Appium环境把核心路径写成脚本理解PO模式Page Object每个页面封装成一个类让脚本跑在真机上。第五步才是专项测试。从弱网和性能开始逐步理解每个专项背后的业务目标。7.2 常见认知误区最后把这几年来新人最容易犯的几个认知误区一次性说透一个误区是“自动化测试不需要测试理论”。很多框架用得很熟练的人用例设计能力却是空的写出来的自动化脚本全是重复的正路径异常场景一个都没有。自动化只是放大你的测试设计能力而不是替代它。用例本身设计得差自动化只会更快地把错误逻辑固化下来。另一个误区是“学得越多越安全”。我见过简历上写Appium、Airtest、Selenium、JMeter全精通的人实际动手连一个不在文档里的元素定位问题都搞不定。真正有竞争力的不是工具数量而是遇到问题时独立排查和解决的能力。学习时每学一个工具都要问自己这个工具的报错体系是什么样的出问题时怎么查还有一个误区是“只学工具不学业务”。移动端测试跟业务绑定得异常紧密不懂电商的订单状态机根本测不好电商App的订单流程不懂社交产品的消息机制也测不好IM类App。我个人的做法是每接手一个新项目第一周不碰测试先把产品文档和原型图从头到尾读一遍画出核心业务的流程图这个习惯帮我发现过大量文档都没写清楚的逻辑漏洞。移动端测试这条路最大的特点是没有天花板。你能从点点点做到自动化再从自动化做到质量体系建设每一步都靠实践积累没有捷径。但好消息是每一步也都有清晰的路标只要踩着这条主线走方向就不会歪。
