1. 从零开始搭建你的iOS自动化测试环境想玩转iOS自动化测试第一步不是急着写代码而是要把“战场”准备好。很多新手朋友一上来就卡在环境配置上折腾半天连设备都连不上热情一下就浇灭了。我自己刚开始的时候也踩过不少坑今天我就把这些经验掰开揉碎了讲给你听让你能快速、顺畅地搭好环境把精力集中在更有趣的自动化脚本编写上。首先你得明白一个核心iOS自动化测试离不开一个“桥梁”这个桥梁就是WebDriverAgent简称WDA。你可以把它理解为一个安装在iPhone或iPad上的“服务端”我们的Python脚本则是“客户端”通过HTTP协议给这个服务端发送指令比如“点击那个按钮”、“在那个输入框里输入文字”。所以环境搭建的核心目标就是让这个WDA服务端在你的iOS设备上成功运行起来并且能被你的电脑访问到。第一步准备硬件和基础软件。你需要一台Mac电脑这是必须的因为需要Xcode来编译WDA一部用于测试的iOS设备iPhone或iPad以及一条靠谱的数据线。电脑上需要安装好Xcode并且确保你的iOS设备已经在Xcode的Devices and Simulators窗口中识别出来并且信任了这台电脑。这一步是基础就像盖房子前得先有块地。第二步获取并编译WebDriverAgent。这是最关键也最容易出错的一步。你需要从GitHub上把Facebook的WebDriverAgent项目克隆下来。打开终端找一个你喜欢的目录执行git clone https://github.com/appium/WebDriverAgent.git。克隆完成后用Xcode打开项目目录下的WebDriverAgent.xcodeproj文件。接下来需要配置签名在Xcode中分别对WebDriverAgentLib和WebDriverAgentRunner这两个Target设置你的个人开发者账号或者公司开发者账号进行签名。这里有个大坑如果你的设备系统版本较高可能会遇到“无法验证开发者”的问题。解决方法是在设备的设置 - 通用 - VPN与设备管理中找到你的开发者证书并信任它。配置好后将设备连接电脑在Xcode左上角选择你的真机设备作为运行目标然后运行Product - Run。如果一切顺利你会在设备上看到一个无界面的WebDriverAgent应用并且Xcode控制台会打印出一串包含IP地址和端口号通常是8100的日志信息这就说明服务启动成功了。第三步安装Python客户端库。WDA服务跑在设备上了我们还需要一个“遥控器”来控制它。这个“遥控器”就是facebook-wda这个Python库。在Mac的终端里用pip安装它非常简单pip3 install -U facebook-wda。我强烈建议你使用虚拟环境比如venv或conda来管理你的Python包这样可以避免不同项目间的依赖冲突。安装完成后你就可以在Python脚本里导入wda模块开始编写自动化脚本了。第四步使用工具进行元素定位辅助。写自动化脚本最头疼的就是找到元素的“身份证”定位符。纯靠猜或者看源码效率太低。这里我强烈推荐一个神器weditor。它是一个网页版的元素查看器可以实时看到设备屏幕的UI层级树。安装命令是pip install weditor。安装后在终端运行python -m weditor它会自动打开浏览器。在界面中选择“iOS”地址填写你设备上WDA服务的地址比如http://设备IP:8100点击连接。如果连接成功点击Dump Hierarchy你就能看到当前设备屏幕的完整UI结构了点击任何元素都能直接看到它的各种属性比如name、label、value等复制过来就能直接用在你的定位代码里非常直观高效。这一步能极大提升你编写定位语句的速度和准确性。1.1 连接设备的两种方式HTTP与USBWDA服务跑起来后我们的Python脚本怎么连接到它呢主要有两种方式通过网络HTTP和通过USB。这两种方式各有优劣适用于不同的场景。HTTP连接是最直观的方式。当你的WDA服务在设备上启动后它会开启一个HTTP服务默认端口8100。如果你的Mac和iOS设备在同一个Wi-Fi网络下你就可以直接用设备的IP地址进行连接。在Python中这样写import wda c wda.Client(http://192.168.1.100:8100) # 替换为你的设备IP print(c.status()) # 打印连接状态确认是否成功这种方式的优点是方便设备可以脱离数据线使用。但缺点也很明显依赖网络稳定性如果Wi-Fi信号不好自动化操作会有延迟甚至失败。而且首次需要手动在设备上启动WDA服务或者借助其他工具自动启动。USB连接则稳定得多它通过USB数据线建立连接速度极快几乎没有延迟。facebook-wda库提供了USBClient来简化这个过程import wda c wda.USBClient() # 默认连接第一台已连接的USB设备 print(c.status())使用USBClient时库底层会通过usbmuxd服务将本地端口如8100转发到设备的USB通道上所以你不需要关心设备的IP地址。它的优势就是稳定、快速是进行稳定自动化测试的首选。但要注意USBClient在Windows上可能无法直接使用因为它依赖Mac系统的服务。在Windows环境下你可能需要先通过其他工具如iproxy进行端口转发然后再用Client连接本机端口。在实际项目中我通常这样安排在脚本开发和调试阶段使用USB连接因为稳定打断点、看日志都顺畅。当脚本稳定后如果需要多设备并发测试或者设备需要移动位置则切换到Wi-Fi连接。你可以根据USBClient是否能够成功创建来判断使用哪种方式实现一个自动降级的连接策略这样脚本的适应性就更强了。2. 元素定位找到屏幕上的每一个“目标”自动化测试的本质是模拟人的操作而操作的前提是找到要操作的对象。在iOS应用里这个对象可能是一个按钮、一段文本、一个输入框。元素定位就是给我们的自动化脚本一双“眼睛”告诉它“去点击那个写着‘登录’的蓝色按钮”。定位不准后续所有操作都是白搭。WDA框架提供了多达七八种定位策略我刚开始学的时候也眼花缭乱但用久了发现最常用的也就那么三四种。掌握它们并了解各自的使用场景你就能解决95%的定位问题。首先我们必须了解iOS应用的UI结构。它是一棵层级树最顶层是XCUIElementTypeApplication代表应用本身下面有XCUIElementTypeWindow窗口再往下是各种视图控件比如XCUIElementTypeButton、XCUIElementTypeTextField、XCUIElementTypeStaticText等。weditor工具之所以重要就是因为它能把这棵树清晰地展示出来让你看到每个元素的类型、名称、值以及它在树中的位置。最直接的方式通过id和name定位。这里的id在iOS中通常指的是accessibilityIdentifier而name通常对应accessibilityLabel或label。如果开发同学在写代码时给控件设置了好的accessibilityIdentifier那你的自动化工作就幸福了因为这个属性基本是全局唯一的。定位写法非常简单c(idloginButton)或c(name登录)。但现实往往是骨感的很多应用并没有很好地设置这些辅助功能属性。这时候我们就需要借助其他属性。通过className定位这指的是控件的类型比如XCUIElementTypeButton、XCUIElementTypeStaticText。通常一个页面上同类型的控件非常多所以单独使用className定位往往不够精确但它非常适合用于获取元素列表或者作为组合定位的一部分。例如c(classNameXCUIElementTypeCell)可以获取当前页面所有的表格单元格。通过value和label定位value通常指控件当前的值比如输入框里的文字、滑块当前的值。label通常是控件显示的文字标签。这两个属性也经常用到尤其是定位那些有动态文本的控件。WDA还支持模糊匹配比如c(labelContains部分文字)这在文本内容可能变化时非常有用。2.1 组合定位与层级定位应对复杂场景当单一属性无法唯一定位一个元素时我们就需要“组合拳”。WDA允许你将多个属性组合在一起进行定位这要求所有属性都属于同一个元素。语法很直观用逗号分隔即可# 定位一个类型为按钮并且名字是“提交”的元素 submit_btn c(classNameXCUIElementTypeButton, name提交) if submit_btn.exists: submit_btn.click()这个组合定位的意思是找一个元素它同时满足是按钮类型并且名字是“提交”。这比只用name或只用className精确多了。但有时候即使组合了属性页面上可能还是有多个相似的元素比如一个列表里每一行都有一个“详情”按钮。这时候我们就需要引入“层级”的概念。WDA支持通过子元素定位和xpath来处理层级关系。子元素定位的写法是链式的c(className父元素类名).c(name子元素名)。这表示先找到父元素然后在它的直接子元素中寻找目标。这种方式非常直观符合我们对页面结构的认知。例如在一个设置列表中先定位到“通用”这一行可能是一个Cell再在这行里面找“关于本机”这个文本元素。XPath定位则是更强大、也更复杂的武器。它使用路径表达式来在XML/HTML文档中导航而iOS的UI层级树正好可以看作一种XML结构。XPath功能强大但执行效率相对较低。对于简单的层级我推荐使用classChain后面会讲但对于复杂的、需要“绕路”的定位XPath是最后的王牌。比如你想定位一个元素它的某个兄弟元素有特定的特征用XPath可以这样写# 定位一个label为“收入”的元素的父级下的另一个包含“银行”文字的label元素 c.xpath(//*[label收入]/..//*[contains(label, 银行)])这个表达式分解一下//*[label收入]找到label是“收入”的元素/..向上找到它的父元素//*[contains(label, 银行)]在父元素的所有后代中找到label包含“银行”的元素。这种“曲线救国”的定位方式在UI结构复杂时非常管用。2.2 高级定位策略Predicate与ClassChain当常规定位方法显得笨拙时Predicate和ClassChain这两种基于苹果原生NSPredicate的定位策略就能大显身手了。它们语法更简洁执行效率也比XPath高是我现在最常用的定位方式。Predicate定位使用一种类似SQL查询条件的字符串。它的优势在于可以进行复杂的属性比较和逻辑运算。举个例子你想找一个名字以“工资”开头并且label是“工资到账”的按钮用Predicate写起来非常优雅c(predicatename BEGINSWITH 工资 AND label 工资到账).click()Predicate支持丰富的运算符比较运算符,,,,,!字符串操作BEGINSWITH以...开头、ENDSWITH以...结尾、CONTAINS包含、LIKE通配符匹配、MATCHES正则匹配逻辑运算符AND,OR,NOT集合操作IN在某个集合中你还可以在字符串比较后加上[c]来忽略大小写加上[d]来忽略变音符号。例如c(predicatename CONTAINS[c] llo)会匹配名字包含“llo”、“LLo”、“LlO”等的元素非常灵活。ClassChain定位可以看作是Predicate和XPath优点的结合体。它使用iOS的类名XCUIElementType*和索引来描述层级路径语法比XPath更简洁执行效率更高。它的核心是能直接表达“某个层级下的第几个某种类型的元素”。# 获取第一个窗口下的第一个按钮元素 c(classChainXCUIElementTypeWindow[1]/XCUIElementTypeButton[1]).click() # 匹配任意层级下Cell元素内的、label为“工资收入”的静态文本元素 c(classChain**/XCUIElementTypeCell/XCUIElementTypeStaticText[label工资收入]).exists注意上面第二行代码**是通配符表示任意多级父节点。方括号[]里的条件是反引号括起来的Predicate表达式。ClassChain特别适合定位那些层级清晰、但同类型兄弟元素很多的情况比如列表中的特定行。你需要通过c.source()命令仔细查看页面结构才能写出准确的ClassChain路径。3. 元素操作让脚本“动”起来定位到元素之后我们终于可以开始“操作”它了。WDA提供了一套非常贴近自然交互的操作API从简单的点击、输入到复杂的滑动、缩放基本覆盖了所有用户手势。让脚本“动”起来其实就是调用这些方法的过程。最基础的操作点击与轻敲。click()和tap()在大多数情况下效果是一样的都是模拟手指的单击操作。它们的区别非常细微tap()可能更接近底层触控事件。我平时习惯用click()。这里有个实用的技巧click_exists()方法。它会先检查元素是否存在如果存在就点击并返回True如果不存在则直接返回False而不会抛出异常。这在处理一些可能出现也可能不出现的元素比如弹窗的确认按钮时非常有用可以让你的脚本更健壮。# 更健壮的点击方式 if c(name允许通知).click_exists(timeout3): # 等待3秒看按钮是否出现 print(已点击允许通知) else: print(未找到允许通知按钮继续执行)输入文本向输入框填内容使用set_text()方法。这里有个小坑需要注意有些输入框在set_text()之前需要先点击一下获得焦点否则可能输入不进去。清空输入框则用clear_text()。还有一个高级用法你可以通过发送\b退格键来删除字符或者用\n来模拟键盘的换行确定操作。search_field c(xpath//*[label搜索]) search_field.click() # 先点击获取焦点 search_field.set_text(自动化测试) # 输入文字 search_field.set_text(\n) # 模拟按下键盘的“搜索”或“换行”键滑动与滚动这是处理长列表、翻页等场景的核心操作。WDA提供了四个方向的便捷方法swipe_left(),swipe_right(),swipe_up(),swipe_down()。它们默认在屏幕中央进行一定距离的滑动适合全屏滚动。如果你需要更精确的控制比如从一个特定元素滑动到另一个元素可以使用swipe(x1, y1, x2, y2, duration)方法指定起点和终点的坐标以及滑动的持续时间。滚动scroll()和滑动swipe略有不同。scroll()通常是针对一个可滚动的容器如ScrollView进行操作你可以指定方向updownleftright和距离倍数。而swipe更偏向于一种手势不局限于可滚动容器。# 在某个列表元素上向上滚动2倍元素高度的距离 c(name消息列表).scroll(up, 2) # 从屏幕底部向上滑动常用于刷新 c.swipe_up()3.1 处理弹窗与等待机制弹窗Alert是自动化测试中最常见的干扰项。一个突然弹出的系统权限请求、一个应用更新提示都可能打断你预设的流程。WDA对弹窗有专门的支持。弹窗在UI树中的类型通常是XCUIElementTypeAlert。你可以通过c.alert.exists来判断当前是否有弹窗出现。c.alert.text可以获取弹窗的提示文字。处理弹窗通常就是点击上面的按钮c.alert.accept()会点击默认的第一个按钮通常是“确定”、“允许”c.alert.dismiss()会点击第二个按钮通常是“取消”、“拒绝”。更灵活的方式是使用c.alert.click(“按钮文字”)来点击指定文字的按钮。但更优雅的做法是使用“监视与点击”模式。WDA提供了一个上下文管理器c.alert.watch_and_click()它可以在一个代码块执行期间自动监视弹窗的出现并点击你预设的按钮列表中的第一个匹配项。# 假设在点击某个设置项后可能会弹出位置权限请求 with c.alert.watch_and_click([使用App时允许, 好, 允许]): c(label位置服务).click() # 在这个with代码块内如果出现了弹窗并且按钮文字是“使用App时允许”、“好”或“允许”中的一个就会自动点击它。等待是自动化脚本稳定的基石。没有恰当的等待脚本就会像无头苍蝇一样乱撞。WDA有两种等待强制等待c.sleep(秒数)和隐式等待c.implicitly_wait(秒数)。强制等待就是简单粗暴地让脚本暂停一段时间无论元素是否加载完成。隐式等待则更智能它会在你每次查找元素时生效如果在指定时间内找到了元素就立即返回如果超时还没找到才抛出异常。我通常会在创建客户端后设置一个全局的隐式等待比如c.implicitly_wait(10)这样脚本就不会因为网络或性能的微小波动而轻易失败。对于某些特别耗时的操作比如页面跳转、大数据加载再在关键位置加上c.sleep()进行强制等待。两者结合使用能让脚本既健壮又不至于太慢。4. 实战技巧与避坑指南掌握了定位和操作的基本功已经可以写出很多自动化脚本了。但要写出高效、稳定、易维护的脚本还需要一些实战技巧并且要避开我当年踩过的那些“坑”。第一封装与复用。不要把你的脚本写成流水账。把常用的操作封装成函数或类方法。比如一个“登录”操作可能包含输入用户名、密码、点击登录按钮、处理可能的弹窗等步骤。把它封装成一个login(username, password)函数。这样主测试逻辑会非常清晰而且当登录流程改变时你只需要修改这一个函数。同样对于复杂的元素定位语句也可以用一个有意义的变量名或函数来保存避免重复编写和修改。第二使用可靠的定位器优先级。这是我总结的一个经验法则id(accessibilityIdentifier) name(label) predicate/classChainxpath。如果开发提供了好的id优先使用因为它最稳定、唯一性最好。其次是name或label。在前两者都无法精确定位时考虑使用predicate进行属性组合查询或者用classChain描述层级路径。xpath功能强大但效率相对较低且对UI结构变化非常敏感应作为最后的选择。第三处理动态内容和异步加载。现代应用大量使用异步加载和动态内容。一个列表可能在你滑动时才加载更多项。你的脚本必须能应对这种情况。除了使用隐式等待还可以结合循环和条件判断。例如不断向下滑动直到找到某个特定的元素出现为止。def find_element_with_swipe(self, locator, max_swipes10): for i in range(max_swipes): if c(**locator).exists: return c(**locator) c.swipe_up() # 没找到就向上滑动再找 raise Exception(f元素 {locator} 在滑动 {max_swipes} 次后仍未找到)第四截图与日志你的救命稻草。自动化脚本在无人值守运行时如果失败了你很难知道失败那一刻屏幕上发生了什么。所以关键操作前后、特别是断言失败或发生异常时一定要截图保存。WDA的c.screenshot().save(‘path/to/file.png’)用起来非常方便。同时在脚本中合理使用print或logging模块输出关键信息比如“开始登录”、“进入主页”、“检查XX元素”这样在查看日志时就能快速定位问题发生的时间点。第五关于坐标操作的谨慎使用。WDA支持通过绝对坐标c.tap(x, y)或c.click(x, y)进行操作。这种方式看似直接但隐患最大。一旦应用UI布局发生变化或者换了不同分辨率的设备坐标就全错了。除非是操作一些无法通过常规属性定位的系统级控件比如某些键盘按键否则应尽量避免使用绝对坐标。如果非用不可尽量基于某个稳定元素的相对坐标来计算。最后保持耐心和细心。UI自动化测试本身就是和UI变化做斗争。元素定位失败了别急着怀疑框架先用weditor看看当前的UI树结构是不是和你写脚本时不一样了。多思考多实践慢慢你就会积累起一套自己的自动化测试方法论写起脚本来也会越来越得心应手。