做UI自动化测试的人都会有这种感觉点击、输入、断言这些基础操作玩顺手之后真正的门槛往往出现在“手势”类场景上。像滑动刷新、长按删除、拖拽排序、双指缩放这些在真实App里高频出现的人机交互恰恰是普通定位加click替代不了的部分。这一篇咱们把Appium的TouchAction高级手势API好好拆一遍它到底能模拟哪些手势、动作链怎么设计、坐标怎么算、和现在主推的W3C Actions是什么关系以及实际项目里最容易踩的坑在哪。从这个标题的编号也能看出来这已经是UI自动化测试系列的进阶内容适合那些已经能独立写用例、开始处理复杂交互的自动化测试同学。1. 为什么 TouchAction 能解决“普通点击搞不定”的手势场景1.1 手势测试为什么天然比点击脆弱用Appium做自动化常规的套路其实是通过findElement找到控件click一下sendKeys输一段文案再拿text去断言。这套流程有个大前提就是被测控件必须稳定存在而且交互是“点一下就完事”。但真实App里的高级交互几乎都不是这种单点离散事件。比如短视频App上滑加载下一个视频这个动作的起点是屏幕下方某个坐标终点是屏幕上方中间手指一直在快速移动你无法指着某一个控件说“操作它”。手势测试脆弱就脆弱在它描述的是一个连续过程而不是两个状态。连续过程的中间环节一旦被干扰比如系统弹了个权限框、页面还在加载、列表布局错位手势的起点和终点就会跟着跑偏。有些时候页面已经变了但你计算的坐标还是旧坐标滑出去的效果就是点到别的地方去了。因此处理手势问题不能再用“找一个元素再对它操作”的思维得切换到“模拟屏幕上的物理操作轨迹”这个维度。1.2 手势的本质按下、移动、抬起三件套手机上的所有触摸手势底层拆开了看就是三个阶段手指按下、手指移动、手指抬起。点击是按下后立刻抬起长按是按下之后保持一个时间再抬起滑动是按下后移动一段距离再抬起双指缩放就是两路“按下-移动-抬起”同步执行。TouchAction在设计上就遵循这个模型。它把一次手势拆成一条指令链press是按下moveTo是移动release是抬起中间的wait用来控制动作之间的时长。你把这几个动作按顺序串起来最后调用perform()交给Appium去执行驱动端就会把它翻译成对应的触摸事件发给设备底层。这个思路和人在屏幕上操作的本质是完全一致的理解了这一点后面写任何手势都不会觉得是在死记API。1.3 三类最常被要求自动化的手势场景如果平时在维护企业级App的自动化你会很快发现测试用例里出现频次最高的手势其实集中在三类。第一类是列表滑动。不管是新闻列表、电商商品流还是消息列表滑动加载更多、滑动到顶部都属于典型的坐标型手势因为你根本不知道列表里有多少条目也不好每次都用元素定位去等一个目标项出现。第二类是长按操作。长按删除、长按进入编辑状态、长按拖动排序这类手势需要的不是快速滑走而是稳定按住一段时间再配合移动或者等待菜单弹出来。第三类是双指手势最常见的是地图缩放、图片预览放大缩小、某些双列表单调整。双指手势在自动化里复杂度最低但做起来最烦因为它是两个手指的并发动作必须用Appium的MultiAction搭配TouchAction才能实现。能把这三类场景覆盖住基本上真实项目的UI自动化考核就能过关。下面我挨个拆解TouchAction的核心方法和实操。2. TouchAction 成员方法逐个过press、moveTo、release、wait 与 MultiAction2.1 方法速查表和相关参数TouchAction在Appium的不同语言客户端里方法名会有细微差别比如Java里是press、moveTo、releasePython里是press、move_to、releaselongPress在Python里是long_press。这里先按概念层讲方法是死的核心是理解每个动作的含义。方法参数含义典型用途press坐标点或元素对象手指按下不抬起滑动手势的起始点longPress坐标点或元素对象时长按住不放并持续一段时间触发长按菜单、编辑模式moveTo坐标点或元素对象手指从当前位置移动到目标位置滑动、拖拽wait毫秒数当前动作执行后等待指定时长控制手势快慢等待系统响应release无手指抬起手势结束tap坐标点或元素对象轻触一次替代click处理坐标点击注意这里的坐标既可以传绝对坐标也可以是相对于某个元素的位置。实际项目里我更多是基于元素定位来传参因为纯坐标太容易受屏幕尺寸和布局变化影响。比如长按某个列表项我会先拿到元素对象再对元素执行press和wait而不是去死记这个列表项的像素坐标。后面讲实操时这一点会反复出现。2.2 动作链的串联执行逻辑TouchAction最典型的用法是把多个动作组装成一条链。打个比方它不是单独发一个“按下”指令而是先把“按哪里、按多久、移到哪里、什么时候抬手”写成一串编排好的剧本最后喊一声action perform()Appium驱动才一次性把剧本提交给设备执行。之所以这样设计是为了保证动作的连续性不被拆散毕竟屏幕上的手势是一个完整的过程如果中间插了别的指令手指的轨迹就会断掉。举个例子滑动操作在代码逻辑上就是press(x1,y1).wait(200).moveTo(x2,y2).release()。press确定起点wait确保手指在起点停留一点时间避免系统误判成点击moveTo完成位移release收尾。很多人刚开始写会漏掉最后的perform()结果发现脚本既不报错也没效果因为前面的动作只是被记录下来根本没有真正发到设备上。2.3 坐标计算为什么你总觉得手势跑偏了手势跑偏八成是坐标计算出了问题。移动端的坐标系原点在屏幕左上角x轴向右y轴向下单位是像素。少了状态栏安全区不同机型分辨率不同实际可用的高度也不同。如果直接写死一个像素坐标换一台测试机大概率就偏了。稳定做法是先用driver.get_window_size()拿到当前窗口的宽高再按比例计算起点和终点。比如要做“从右下往左上滑动”的效果就取窗口宽度的80%、高度的70%作为起点宽度的20%、高度的30%作为终点这样在多数机型和分辨率下都能保持手势方向和距离相对一致。比例的方式不能完全解决布局差异但至少比写死坐标稳得多。手势类的坐标还有一个特点元素位置会随着滚动变化。你定位一个元素的时候它在当前屏幕有一个坐标但页面一滑动这个坐标旧了手势还是按旧坐标去操作就会点错地方。所以涉及滚动手势时先决定好滑动方向和距离再重新定位目标元素不要复用之前的坐标值。2.4 MultiAction 处理双指手势MultiAction专门用来并行执行多个TouchAction也就是多指操作。它的逻辑是为每根手指创建一条独立的TouchAction链然后把两条链add到MultiAction里最后perform()驱动会尽量同一帧把二者提交到设备达到“两指同时动作”的效果。最典型的双指缩放是“捏合”和“张开”。假设屏幕中心坐标是(midX, midY)手指A从中间往左上角移动手指B从中间往右下角移动组合起来就是两张手指向外张开画面就会被放大。反过来从两个角往中心移动就是捏合缩小。MultiAction写出来的代码结构其实不复杂麻烦的是它要求两个手指的时间起始点尽量同步否则手势会变成先动一根手指再动另一根效果就不自然。3. 从元素定位到全手势落地保姆级实操3.1 第一步用 Appium Inspector 把元素属性抓明白动手写TouchAction之前先得把手势的对象或者坐标搞清楚。Appium Inspector是绕不开的工具它可以实时连接设备、加载当前页面层级、让你直接看到控件的位置和属性。这里补一句Appium Inspector可以获取到xpath、id、accessibility id这类元素定位信息是写手势用例时最顺手的信息来源。常见的操作流程是先通过adb连接测试机在Inpector里填好Appium的启动参数比如platformName、appPackage、appActivity点击连接之后左边是这个设备的实时屏幕右边是控件的层级树。选中一个控件下面会自动展示它的id、class、accessibility id、xpath等信息。决定用手势的时候在界面上点一下控件的中心Inspector会显示它当前的精确坐标方便你反推相对偏移量。实际经验是Inspector的信息并不总是实时准确有些App的控件层级要等页面完全渲染才会出来有些自定义View在层级树里显示不出来。遇到这种情况先手动操作页面刷新一下再重新拉取层级千万不建议开着动态跳动的页面直接用手势去按坐标那大概率会扑空。3.2 第二步写一个“长按删除”的 TouchAction 测试选一个很常见的场景在某个列表条右上角长按弹出删除菜单。假设已经通过Inspector拿到了列表条目的accessibility id代码可以这样写以Python客户端为例from appium.webdriver.common.touch_action import TouchAction from appium.webdriver.common.mobileby import MobileBy # 先定位列表项 target driver.find_element(MobileBy.ACCESSIBILITY_ID, row_item_张三) # 长按1.5秒 actions TouchAction(driver) actions.long_press(eltarget, duration1500) actions.release() actions.perform()这段代码里long_press传入的是元素对象不是坐标这是推荐方式。它的含义是先找到这个元素当前在屏幕上的位置然后一直按住它1500毫秒再松开。长按的时长要根据App的实际逻辑来调系统默认的长按识别时间一般在500毫秒左右如果App是长按1秒才触发菜单duration给到1500毫秒会更稳。这里有个小细节在执行长按之前最好先确认元素在屏幕内并且没有遮挡。有些列表项被其他浮层挡住长按会作用到遮挡层上菜单弹不出来。我在项目里一般会先加一步检测元素是否可见不可见就先滚动到可见区域再执行手势。3.3 第三步坐标型滑动手势的封装滑动手势不依赖某个具体元素它的目标是“让屏幕内容移动”所以用坐标来定义会更灵活。下面是一个封装好的通用滑动方法def swipe_up(driver, duration500): size driver.get_window_size() start_x size[width] * 0.5 start_y size[height] * 0.8 end_x size[width] * 0.5 end_y size[height] * 0.2 actions TouchAction(driver) actions.press(xstart_x, ystart_y) actions.wait(duration) actions.move_to(xend_x, yend_y) actions.release() actions.perform()这个滑动方向是从下往上模拟的是“上滑翻下一页”。start_y取高度80%的位置是为了尽量在屏幕下半区域按住符合人手的操作习惯end_y取20%保证移动距离足够大不至于被系统识别成一次慢速拖动。wait里的duration控制速度想要快速滑动就传小一点想要模拟缓慢浏览就调大。实际执行时别一下传300毫秒以下太快容易在部分设备上触发惯性滚动导致结果不稳定。有人会问为什么press不用元素引用因为滑动的目标就是屏幕本身不是某个控件。给一个元素绑定滑动动作最多只能从元素中心按下去但元素会随着滚动移出屏幕后续的move_to坐标就失效了。坐标型手势最大的价值是在不依赖页面内容的情况下完成固定轨迹操作。3.4 第四步双指缩放手势的例子双指手势在多指操作场景里很有代表性。假设要在地图上做放大操作可以这样组织from appium.webdriver.common.multi_action import MultiAction size driver.get_window_size() mid_x size[width] * 0.5 mid_y size[height] * 0.5 # 手指1从屏幕中心向左上方移动 finger1 TouchAction(driver) finger1.press(xmid_x, ymid_y) finger1.move_to(xmid_x - 100, ymid_y - 100) finger1.release() # 手指2从屏幕中心向右下方移动 finger2 TouchAction(driver) finger2.press(xmid_x, ymid_y) finger2.move_to(xmid_x 100, ymid_y 100) finger2.release() # 并行执行 multi MultiAction(driver) multi.add(finger1) multi.add(finger2) multi.perform()缩放比例由移动距离决定。上面这个例子中两根手指各自向外移动了差不多141像素属于一个相对明显的放大动作。如果你想让缩放手势更细腻就把100改成50。反过来想要缩小就改成向内收缩的移动方向。这个用例在模拟器上未必能每次都成功因为有些安卓模拟器对多点触控的支持有限所以我建议双指手势优先在真机上验证跑通过再进回归用例集。4. 别再只用 TouchAction升级 W3C Actions 的正确姿势4.1 为什么 TouchAction 会被弃用说到这儿有个绕不开的现实情况。Appium官方虽然在很长一段时间里都在大力推荐TouchAction但W3C WebDriver规范后续标准化了一套基于“输入源”的Actions API同一套动作描述可以在不同WebDriver实现之间复用。相比之下TouchAction是Appium自己为了兼容早期移动测试需求做的一套封装很多行为没有完全对齐W3C标准后续维护和跨浏览器能力都比较吃亏。从Appium 2.x开始官方对TouchAction的态度转为保留兼容但强烈不建议新项目继续使用。体现在客户端上很多旧版方法会打出弃用警告。虽然你硬写也能跑但到了依赖环境升级或者需要新特性的时候就会卡住。新项目做技术选型建议直接把W3C Actions作为默认方案。4.2 W3C Actions 的入门迁移W3C Actions的核心思想是指定“指针输入源”比如一根手指或者一块鼠标然后给这个输入源定义一个动作序列。拿前面长按的例子来说W3C版本大概长这样from selenium.webdriver.common.actions.action_builder import ActionBuilder from selenium.webdriver.common.actions import interaction from selenium.webdriver.common.actions.pointer_input import PointerInput finger PointerInput(interaction.POINTER_TOUCH, finger1) action ActionBuilder(driver, mousefinger) action.pointer_action.move_to_location(x, y) action.pointer_action.pointer_down() action.pointer_action.pause(1500) action.pointer_action.pointer_up() action.perform()Java客户端也有对应的Sequence写法通过PointerInput创建一根手指把pointerMove、pointerDown、pause、pointerUp这些动作加进Sequence最后调用driver.perform()提交。这就是从TouchAction模型向标准动作描述模型转换的过程。转换时你会发现原来press对应现在的pointerDown原来moveTo对应pointerMove结构上几乎是平移的只是入口变了。这里不推荐硬记API名称因为各家客户端版本迭代比较快更好的方式是查阅当前Appium Python Client或Java Client对应版本的官方文档把TouchAction的每个动作映射到W3C Actions的同名语义上迁移会顺畅很多。4.3 新旧 API 共存老项目怎么平稳过渡老项目里已经写了一堆基于TouchAction的用例不太可能为了一行“推荐用新版API”全部推翻重写。我在实际迁移时先做封装抽象把长按、滑动、双指缩放这些高频手势封装成一个独立类内部保留一个implement_mode参数。modew3c时走新的ActionBuildermodetouch时走旧的TouchAction。这样既能保证现存用例按旧路径跑又能逐步把手势层切到新API上每改一个手势都能单独回归。切换过程中的排查思路也很重要。旧代码里常见的是直接拿着driver实例操作改成封装类后所有手势入口统一走同一个方法万一出了问题可以快速定位到是封装层的问题还是调用方的问题。我个人觉得封装是手势测试稳定性的一个重要前提裸写API一时爽后面维护永远在吃苦。5. 我踩过的手势测试的坑以及排查思路5.1 坐标偏移状态栏、导航栏和异形屏一起搞事做安卓手势测试时最容易踩的就是坐标偏移。明明按计算出来的坐标滑动结果手势起点根本没落到页面上而是落到了状态栏或者系统导航栏上。这背后的原因是get_window_size拿到的是整个窗口的尺寸但App的内容区域可能并不包含状态栏和导航栏坐标换算出来是全局坐标而控件的是内容坐标中间有一个固定差值。排查方法也很简单先手动在Inspector里选中一个已知控件查看它显示的中心坐标再和代码里通过元素定位拿到的坐标做对比。如果两者不一致说明坐标基准不同需要手动调整偏移量或者改用元素中心作为手势起点。对异形屏和全面屏设备我一般会单独维护一组边界参数避免在默认数据上栽跟头。5.2 滑动速度控制快了变惯性滚动慢了变成拖动很多人在TouchAction里不写wait直接press然后moveTo结果实际行为和自己预期不一样。这是因为系统区分“滑动、滚动、拖动”很重要的一个指标就是手指移动的速度和持续时间。太快的手势会让页面进入惯性滚动可能一下从顶部滑到底部太慢的手势会让系统认为你在拖动某个控件触发拖拽逻辑而不是滚动。所以在做滑动类手势时我给press和moveTo之间加的wait一般控制在200到600毫秒。想要页面滑动一段距离停下来取400毫秒左右比较中庸想要快速翻页可以缩短到200毫秒但要注意目标位置的偏差可能会变大。如果你看到手势执行逻辑上没问题但页面变化结果不符合预期优先考虑调动作链中wait的时长。5.3 元素过期滚动之后旧引用真的太阴了用手势去操作列表时很常见的问题是你先拿到了一个元素引用然后手势滚动列表接下来你想再次操作同一个元素但用的还是旧引用。此时Appium会报“element not found”之类的错误因为那个元素已经离开当前布局或者被回收了。这不是手势本身的问题而是整个用例里元素管理的问题。我的习惯是滚动前拿到元素A是为了确认它存在滑动完成后如果需要操作某个具体项必须重新执行findElement定位用心的引用去操作。要避免这种坑可以把“滑动到目标元素可见”封装一个方法循环滑动判断元素可见性每次滑动后都重新定位直到目标出现或者达到最大滑动次数。5.4 真机与模拟器双指手势和长按效果的差异Android模拟器上执行双指手势很多时候会直接失效或者动作别扭因为模拟器对多指触摸事件的合并不如真机自然。iOS模拟器上存在部分系统能力受限的手势做起来也不稳定。所以涉及双指缩放的用例最佳策略是直接打上真机标签不进模拟器冒烟集。除了双指长按在模拟器和真机上的判定也有差异模拟器有时会把长按识别成普通点击。排查这个问题时先确认设备真实的触摸上报正常其次检查App对长按时长的判定阈值别一上来就怀疑代码写错。顺手说一句跑手势用例前最好先在设置里开启开发人员选项里的“显示点按位置”能直观看到脚本到底按在了哪里调试效率会高很多。5.5 手势过程中页面状态变化弹窗和权限请求不可不防还有一类问题手势本身执行得没问题但页面在手势执行过程中插入了系统弹窗、权限请求或者加载遮罩导致手势坐标被其他UI截获。最典型的就是第一次安装App后弹出的定位权限框自动化脚本刚滑动到一半权限框冒出来整个手势全部白费。解决办法有两个方向一是把这种弹窗定位和关闭封装成前置步骤在跑手势用例前先清理到可控状态二是在手势执行前加一个兜底判断检查是否存在阻塞元素存在就先处理掉再执行手势。这个方法看起来笨但在真实回归里非常管用能少掉一大半因为环境弹窗导致的用例失败。后来我养成一个习惯就是在项目里做一套手势工具的封装把滑动方向、长按时长、双指距离这些参数全部配置化用例里不直接写坐标而是写“从底部滑到顶部”“长按编号为3的列表项”这种语义化的调用。每次App改版只需要调整工具类里的默认参数几十条手势用例不用跟着逐个改。这个习惯帮我省了很多重复工作量也让我对手势自动化的信心大幅提升。自动化测试走到后面拼的其实不是会多少个API而是能不能把API组织成一套经得起版本迭代的稳定方案。
做UI自动化测试的人都会有这种感觉点击、输入、断言这些基础操作玩顺手之后真正的门槛往往出现在“手势”类场景上。像滑动刷新、长按删除、拖拽排序、双指缩放这些在真实App里高频出现的人机交互恰恰是普通定位加click替代不了的部分。这一篇咱们把Appium的TouchAction高级手势API好好拆一遍它到底能模拟哪些手势、动作链怎么设计、坐标怎么算、和现在主推的W3C Actions是什么关系以及实际项目里最容易踩的坑在哪。从这个标题的编号也能看出来这已经是UI自动化测试系列的进阶内容适合那些已经能独立写用例、开始处理复杂交互的自动化测试同学。1. 为什么 TouchAction 能解决“普通点击搞不定”的手势场景1.1 手势测试为什么天然比点击脆弱用Appium做自动化常规的套路其实是通过findElement找到控件click一下sendKeys输一段文案再拿text去断言。这套流程有个大前提就是被测控件必须稳定存在而且交互是“点一下就完事”。但真实App里的高级交互几乎都不是这种单点离散事件。比如短视频App上滑加载下一个视频这个动作的起点是屏幕下方某个坐标终点是屏幕上方中间手指一直在快速移动你无法指着某一个控件说“操作它”。手势测试脆弱就脆弱在它描述的是一个连续过程而不是两个状态。连续过程的中间环节一旦被干扰比如系统弹了个权限框、页面还在加载、列表布局错位手势的起点和终点就会跟着跑偏。有些时候页面已经变了但你计算的坐标还是旧坐标滑出去的效果就是点到别的地方去了。因此处理手势问题不能再用“找一个元素再对它操作”的思维得切换到“模拟屏幕上的物理操作轨迹”这个维度。1.2 手势的本质按下、移动、抬起三件套手机上的所有触摸手势底层拆开了看就是三个阶段手指按下、手指移动、手指抬起。点击是按下后立刻抬起长按是按下之后保持一个时间再抬起滑动是按下后移动一段距离再抬起双指缩放就是两路“按下-移动-抬起”同步执行。TouchAction在设计上就遵循这个模型。它把一次手势拆成一条指令链press是按下moveTo是移动release是抬起中间的wait用来控制动作之间的时长。你把这几个动作按顺序串起来最后调用perform()交给Appium去执行驱动端就会把它翻译成对应的触摸事件发给设备底层。这个思路和人在屏幕上操作的本质是完全一致的理解了这一点后面写任何手势都不会觉得是在死记API。1.3 三类最常被要求自动化的手势场景如果平时在维护企业级App的自动化你会很快发现测试用例里出现频次最高的手势其实集中在三类。第一类是列表滑动。不管是新闻列表、电商商品流还是消息列表滑动加载更多、滑动到顶部都属于典型的坐标型手势因为你根本不知道列表里有多少条目也不好每次都用元素定位去等一个目标项出现。第二类是长按操作。长按删除、长按进入编辑状态、长按拖动排序这类手势需要的不是快速滑走而是稳定按住一段时间再配合移动或者等待菜单弹出来。第三类是双指手势最常见的是地图缩放、图片预览放大缩小、某些双列表单调整。双指手势在自动化里复杂度最低但做起来最烦因为它是两个手指的并发动作必须用Appium的MultiAction搭配TouchAction才能实现。能把这三类场景覆盖住基本上真实项目的UI自动化考核就能过关。下面我挨个拆解TouchAction的核心方法和实操。2. TouchAction 成员方法逐个过press、moveTo、release、wait 与 MultiAction2.1 方法速查表和相关参数TouchAction在Appium的不同语言客户端里方法名会有细微差别比如Java里是press、moveTo、releasePython里是press、move_to、releaselongPress在Python里是long_press。这里先按概念层讲方法是死的核心是理解每个动作的含义。方法参数含义典型用途press坐标点或元素对象手指按下不抬起滑动手势的起始点longPress坐标点或元素对象时长按住不放并持续一段时间触发长按菜单、编辑模式moveTo坐标点或元素对象手指从当前位置移动到目标位置滑动、拖拽wait毫秒数当前动作执行后等待指定时长控制手势快慢等待系统响应release无手指抬起手势结束tap坐标点或元素对象轻触一次替代click处理坐标点击注意这里的坐标既可以传绝对坐标也可以是相对于某个元素的位置。实际项目里我更多是基于元素定位来传参因为纯坐标太容易受屏幕尺寸和布局变化影响。比如长按某个列表项我会先拿到元素对象再对元素执行press和wait而不是去死记这个列表项的像素坐标。后面讲实操时这一点会反复出现。2.2 动作链的串联执行逻辑TouchAction最典型的用法是把多个动作组装成一条链。打个比方它不是单独发一个“按下”指令而是先把“按哪里、按多久、移到哪里、什么时候抬手”写成一串编排好的剧本最后喊一声action perform()Appium驱动才一次性把剧本提交给设备执行。之所以这样设计是为了保证动作的连续性不被拆散毕竟屏幕上的手势是一个完整的过程如果中间插了别的指令手指的轨迹就会断掉。举个例子滑动操作在代码逻辑上就是press(x1,y1).wait(200).moveTo(x2,y2).release()。press确定起点wait确保手指在起点停留一点时间避免系统误判成点击moveTo完成位移release收尾。很多人刚开始写会漏掉最后的perform()结果发现脚本既不报错也没效果因为前面的动作只是被记录下来根本没有真正发到设备上。2.3 坐标计算为什么你总觉得手势跑偏了手势跑偏八成是坐标计算出了问题。移动端的坐标系原点在屏幕左上角x轴向右y轴向下单位是像素。少了状态栏安全区不同机型分辨率不同实际可用的高度也不同。如果直接写死一个像素坐标换一台测试机大概率就偏了。稳定做法是先用driver.get_window_size()拿到当前窗口的宽高再按比例计算起点和终点。比如要做“从右下往左上滑动”的效果就取窗口宽度的80%、高度的70%作为起点宽度的20%、高度的30%作为终点这样在多数机型和分辨率下都能保持手势方向和距离相对一致。比例的方式不能完全解决布局差异但至少比写死坐标稳得多。手势类的坐标还有一个特点元素位置会随着滚动变化。你定位一个元素的时候它在当前屏幕有一个坐标但页面一滑动这个坐标旧了手势还是按旧坐标去操作就会点错地方。所以涉及滚动手势时先决定好滑动方向和距离再重新定位目标元素不要复用之前的坐标值。2.4 MultiAction 处理双指手势MultiAction专门用来并行执行多个TouchAction也就是多指操作。它的逻辑是为每根手指创建一条独立的TouchAction链然后把两条链add到MultiAction里最后perform()驱动会尽量同一帧把二者提交到设备达到“两指同时动作”的效果。最典型的双指缩放是“捏合”和“张开”。假设屏幕中心坐标是(midX, midY)手指A从中间往左上角移动手指B从中间往右下角移动组合起来就是两张手指向外张开画面就会被放大。反过来从两个角往中心移动就是捏合缩小。MultiAction写出来的代码结构其实不复杂麻烦的是它要求两个手指的时间起始点尽量同步否则手势会变成先动一根手指再动另一根效果就不自然。3. 从元素定位到全手势落地保姆级实操3.1 第一步用 Appium Inspector 把元素属性抓明白动手写TouchAction之前先得把手势的对象或者坐标搞清楚。Appium Inspector是绕不开的工具它可以实时连接设备、加载当前页面层级、让你直接看到控件的位置和属性。这里补一句Appium Inspector可以获取到xpath、id、accessibility id这类元素定位信息是写手势用例时最顺手的信息来源。常见的操作流程是先通过adb连接测试机在Inpector里填好Appium的启动参数比如platformName、appPackage、appActivity点击连接之后左边是这个设备的实时屏幕右边是控件的层级树。选中一个控件下面会自动展示它的id、class、accessibility id、xpath等信息。决定用手势的时候在界面上点一下控件的中心Inspector会显示它当前的精确坐标方便你反推相对偏移量。实际经验是Inspector的信息并不总是实时准确有些App的控件层级要等页面完全渲染才会出来有些自定义View在层级树里显示不出来。遇到这种情况先手动操作页面刷新一下再重新拉取层级千万不建议开着动态跳动的页面直接用手势去按坐标那大概率会扑空。3.2 第二步写一个“长按删除”的 TouchAction 测试选一个很常见的场景在某个列表条右上角长按弹出删除菜单。假设已经通过Inspector拿到了列表条目的accessibility id代码可以这样写以Python客户端为例from appium.webdriver.common.touch_action import TouchAction from appium.webdriver.common.mobileby import MobileBy # 先定位列表项 target driver.find_element(MobileBy.ACCESSIBILITY_ID, row_item_张三) # 长按1.5秒 actions TouchAction(driver) actions.long_press(eltarget, duration1500) actions.release() actions.perform()这段代码里long_press传入的是元素对象不是坐标这是推荐方式。它的含义是先找到这个元素当前在屏幕上的位置然后一直按住它1500毫秒再松开。长按的时长要根据App的实际逻辑来调系统默认的长按识别时间一般在500毫秒左右如果App是长按1秒才触发菜单duration给到1500毫秒会更稳。这里有个小细节在执行长按之前最好先确认元素在屏幕内并且没有遮挡。有些列表项被其他浮层挡住长按会作用到遮挡层上菜单弹不出来。我在项目里一般会先加一步检测元素是否可见不可见就先滚动到可见区域再执行手势。3.3 第三步坐标型滑动手势的封装滑动手势不依赖某个具体元素它的目标是“让屏幕内容移动”所以用坐标来定义会更灵活。下面是一个封装好的通用滑动方法def swipe_up(driver, duration500): size driver.get_window_size() start_x size[width] * 0.5 start_y size[height] * 0.8 end_x size[width] * 0.5 end_y size[height] * 0.2 actions TouchAction(driver) actions.press(xstart_x, ystart_y) actions.wait(duration) actions.move_to(xend_x, yend_y) actions.release() actions.perform()这个滑动方向是从下往上模拟的是“上滑翻下一页”。start_y取高度80%的位置是为了尽量在屏幕下半区域按住符合人手的操作习惯end_y取20%保证移动距离足够大不至于被系统识别成一次慢速拖动。wait里的duration控制速度想要快速滑动就传小一点想要模拟缓慢浏览就调大。实际执行时别一下传300毫秒以下太快容易在部分设备上触发惯性滚动导致结果不稳定。有人会问为什么press不用元素引用因为滑动的目标就是屏幕本身不是某个控件。给一个元素绑定滑动动作最多只能从元素中心按下去但元素会随着滚动移出屏幕后续的move_to坐标就失效了。坐标型手势最大的价值是在不依赖页面内容的情况下完成固定轨迹操作。3.4 第四步双指缩放手势的例子双指手势在多指操作场景里很有代表性。假设要在地图上做放大操作可以这样组织from appium.webdriver.common.multi_action import MultiAction size driver.get_window_size() mid_x size[width] * 0.5 mid_y size[height] * 0.5 # 手指1从屏幕中心向左上方移动 finger1 TouchAction(driver) finger1.press(xmid_x, ymid_y) finger1.move_to(xmid_x - 100, ymid_y - 100) finger1.release() # 手指2从屏幕中心向右下方移动 finger2 TouchAction(driver) finger2.press(xmid_x, ymid_y) finger2.move_to(xmid_x 100, ymid_y 100) finger2.release() # 并行执行 multi MultiAction(driver) multi.add(finger1) multi.add(finger2) multi.perform()缩放比例由移动距离决定。上面这个例子中两根手指各自向外移动了差不多141像素属于一个相对明显的放大动作。如果你想让缩放手势更细腻就把100改成50。反过来想要缩小就改成向内收缩的移动方向。这个用例在模拟器上未必能每次都成功因为有些安卓模拟器对多点触控的支持有限所以我建议双指手势优先在真机上验证跑通过再进回归用例集。4. 别再只用 TouchAction升级 W3C Actions 的正确姿势4.1 为什么 TouchAction 会被弃用说到这儿有个绕不开的现实情况。Appium官方虽然在很长一段时间里都在大力推荐TouchAction但W3C WebDriver规范后续标准化了一套基于“输入源”的Actions API同一套动作描述可以在不同WebDriver实现之间复用。相比之下TouchAction是Appium自己为了兼容早期移动测试需求做的一套封装很多行为没有完全对齐W3C标准后续维护和跨浏览器能力都比较吃亏。从Appium 2.x开始官方对TouchAction的态度转为保留兼容但强烈不建议新项目继续使用。体现在客户端上很多旧版方法会打出弃用警告。虽然你硬写也能跑但到了依赖环境升级或者需要新特性的时候就会卡住。新项目做技术选型建议直接把W3C Actions作为默认方案。4.2 W3C Actions 的入门迁移W3C Actions的核心思想是指定“指针输入源”比如一根手指或者一块鼠标然后给这个输入源定义一个动作序列。拿前面长按的例子来说W3C版本大概长这样from selenium.webdriver.common.actions.action_builder import ActionBuilder from selenium.webdriver.common.actions import interaction from selenium.webdriver.common.actions.pointer_input import PointerInput finger PointerInput(interaction.POINTER_TOUCH, finger1) action ActionBuilder(driver, mousefinger) action.pointer_action.move_to_location(x, y) action.pointer_action.pointer_down() action.pointer_action.pause(1500) action.pointer_action.pointer_up() action.perform()Java客户端也有对应的Sequence写法通过PointerInput创建一根手指把pointerMove、pointerDown、pause、pointerUp这些动作加进Sequence最后调用driver.perform()提交。这就是从TouchAction模型向标准动作描述模型转换的过程。转换时你会发现原来press对应现在的pointerDown原来moveTo对应pointerMove结构上几乎是平移的只是入口变了。这里不推荐硬记API名称因为各家客户端版本迭代比较快更好的方式是查阅当前Appium Python Client或Java Client对应版本的官方文档把TouchAction的每个动作映射到W3C Actions的同名语义上迁移会顺畅很多。4.3 新旧 API 共存老项目怎么平稳过渡老项目里已经写了一堆基于TouchAction的用例不太可能为了一行“推荐用新版API”全部推翻重写。我在实际迁移时先做封装抽象把长按、滑动、双指缩放这些高频手势封装成一个独立类内部保留一个implement_mode参数。modew3c时走新的ActionBuildermodetouch时走旧的TouchAction。这样既能保证现存用例按旧路径跑又能逐步把手势层切到新API上每改一个手势都能单独回归。切换过程中的排查思路也很重要。旧代码里常见的是直接拿着driver实例操作改成封装类后所有手势入口统一走同一个方法万一出了问题可以快速定位到是封装层的问题还是调用方的问题。我个人觉得封装是手势测试稳定性的一个重要前提裸写API一时爽后面维护永远在吃苦。5. 我踩过的手势测试的坑以及排查思路5.1 坐标偏移状态栏、导航栏和异形屏一起搞事做安卓手势测试时最容易踩的就是坐标偏移。明明按计算出来的坐标滑动结果手势起点根本没落到页面上而是落到了状态栏或者系统导航栏上。这背后的原因是get_window_size拿到的是整个窗口的尺寸但App的内容区域可能并不包含状态栏和导航栏坐标换算出来是全局坐标而控件的是内容坐标中间有一个固定差值。排查方法也很简单先手动在Inspector里选中一个已知控件查看它显示的中心坐标再和代码里通过元素定位拿到的坐标做对比。如果两者不一致说明坐标基准不同需要手动调整偏移量或者改用元素中心作为手势起点。对异形屏和全面屏设备我一般会单独维护一组边界参数避免在默认数据上栽跟头。5.2 滑动速度控制快了变惯性滚动慢了变成拖动很多人在TouchAction里不写wait直接press然后moveTo结果实际行为和自己预期不一样。这是因为系统区分“滑动、滚动、拖动”很重要的一个指标就是手指移动的速度和持续时间。太快的手势会让页面进入惯性滚动可能一下从顶部滑到底部太慢的手势会让系统认为你在拖动某个控件触发拖拽逻辑而不是滚动。所以在做滑动类手势时我给press和moveTo之间加的wait一般控制在200到600毫秒。想要页面滑动一段距离停下来取400毫秒左右比较中庸想要快速翻页可以缩短到200毫秒但要注意目标位置的偏差可能会变大。如果你看到手势执行逻辑上没问题但页面变化结果不符合预期优先考虑调动作链中wait的时长。5.3 元素过期滚动之后旧引用真的太阴了用手势去操作列表时很常见的问题是你先拿到了一个元素引用然后手势滚动列表接下来你想再次操作同一个元素但用的还是旧引用。此时Appium会报“element not found”之类的错误因为那个元素已经离开当前布局或者被回收了。这不是手势本身的问题而是整个用例里元素管理的问题。我的习惯是滚动前拿到元素A是为了确认它存在滑动完成后如果需要操作某个具体项必须重新执行findElement定位用心的引用去操作。要避免这种坑可以把“滑动到目标元素可见”封装一个方法循环滑动判断元素可见性每次滑动后都重新定位直到目标出现或者达到最大滑动次数。5.4 真机与模拟器双指手势和长按效果的差异Android模拟器上执行双指手势很多时候会直接失效或者动作别扭因为模拟器对多指触摸事件的合并不如真机自然。iOS模拟器上存在部分系统能力受限的手势做起来也不稳定。所以涉及双指缩放的用例最佳策略是直接打上真机标签不进模拟器冒烟集。除了双指长按在模拟器和真机上的判定也有差异模拟器有时会把长按识别成普通点击。排查这个问题时先确认设备真实的触摸上报正常其次检查App对长按时长的判定阈值别一上来就怀疑代码写错。顺手说一句跑手势用例前最好先在设置里开启开发人员选项里的“显示点按位置”能直观看到脚本到底按在了哪里调试效率会高很多。5.5 手势过程中页面状态变化弹窗和权限请求不可不防还有一类问题手势本身执行得没问题但页面在手势执行过程中插入了系统弹窗、权限请求或者加载遮罩导致手势坐标被其他UI截获。最典型的就是第一次安装App后弹出的定位权限框自动化脚本刚滑动到一半权限框冒出来整个手势全部白费。解决办法有两个方向一是把这种弹窗定位和关闭封装成前置步骤在跑手势用例前先清理到可控状态二是在手势执行前加一个兜底判断检查是否存在阻塞元素存在就先处理掉再执行手势。这个方法看起来笨但在真实回归里非常管用能少掉一大半因为环境弹窗导致的用例失败。后来我养成一个习惯就是在项目里做一套手势工具的封装把滑动方向、长按时长、双指距离这些参数全部配置化用例里不直接写坐标而是写“从底部滑到顶部”“长按编号为3的列表项”这种语义化的调用。每次App改版只需要调整工具类里的默认参数几十条手势用例不用跟着逐个改。这个习惯帮我省了很多重复工作量也让我对手势自动化的信心大幅提升。自动化测试走到后面拼的其实不是会多少个API而是能不能把API组织成一套经得起版本迭代的稳定方案。
