做移动端自动化的人，多多少少都经历过这样的场景：脚本在本地跑得好好的，一上持续集成环境就满屏飘红；早上刚验证通过的用例，下午同一个机型就给我报"no such element"。Appium的报错信息写得又长又绕，真正解决问题往往靠翻log、猜原因、问同事，最后实在不行就重启服务碰运气。这篇文章不做那种陈列式的文档复述，我想从这几年跑真机、调各种诡异失败案例的实际经验出发，把Appium测试里最常见的坑、最有效的排查路径、以及一套能支撑你长期稳定跑自动化的问题处理体系，一次性讲清楚。
Appium本质上是一个基于WebDriver协议的移动端自动化服务，它把你的自动化指令翻译成iOS和Android系统各自理解的触摸事件、控件查询和页面状态请求。这意味着它夹在测试脚本、驱动中间件、系统底层服务这三层之间，任何一层出问题，表现到脚本里都是各种看似随机实则必然的报错。所以排查Appium问题，最忌讳的就是只盯着脚本本身看。先把错误形态分清楚，再沿着调用链路一层层往下挖，你会发现大部分问题都不是"代码逻辑写错了"，而是环境、配置、设备状态、时序竞争这些东西在捣乱。
这篇文章适合什么人看？一类是刚把Appium环境搭起来、正被各种capabilities和session错误折磨的新手，另一类是已经跑了一段时间自动化、被稳定性问题反复摩擦的进阶者。文中涉及的所有排查思路和代码片段，都是我实际在项目里用过的方案，有些地方用了一些虚构的示例项目来演示，但处理办法是通用的，你直接照搬不会有问题。
1. 先把三种"不是你的锅"错误分清楚
Appium的报错信息虽然很长，但绝大部分归根结底就是三类：环境连接类、元素解析类、状态同步类。这三类错误的处理方式完全不同，如果一开始就把它们混在一起排查，你会浪费很多时间。
环境连接类错误最常见的特征是：session创建失败、adb devices看不到设备、WebDriverAgent启动超时、端口被占用。这类错误和你的业务代码基本没关系，纯粹是服务和设备之间的沟通出了问题。元素解析类错误典型表现是"An element could not be located on the page"或者"no such element: Unable to find element"这一挂。状态同步类错误则是元素找到了、动作也发了，但结果不对，比如点击没有生效、页面跳转后断言失败、弹出框挡住了操作。
我见过很多刚入行的测试同学，遇到no such element就拼命加sleep，加到三秒不够就五秒，五秒不够就十秒。这是一种典型的错误归因。你根本没有区分这个元素到底是不存在、没加载出来、还是压根没进对页面。正确做法是先看截图和当前页面结构，确认页面状态是否符合预期，再去讨论等待策略的问题。
还有一个容易被忽略的点：Appium日志的level。默认情况下Appium的日志输出是info级别，很多关键细节根本看不到。我推荐在启动服务的时候加上--log-level debug，虽然日志量会变大，但排查问题的时候这些细节非常救命。尤其是session创建时的desired capabilities回显、driver连接时的握手过程、元素查询时发送的具体选择器，这些在debug级别下都能看到。
appium --log-level debug --log-file ./appium-debug.log这里有个小技巧：日志文件最好单独指定，别把所有appium日志都打到终端里，否则和脚本print混在一起非常难翻。我自己习惯把日志按日期归档，appium-debug-20250101.log这样命名，出问题的时候直接翻对应日期的文件就完事了。
2. 启动阶段最容易翻车，先从这里查
session创建失败是所有问题里频率最高的，尤其是新手刚配好环境跑第一次脚本的时候。我统计过，这类问题里大概有六成是desired capabilities配置不对，两成是设备连接状态有问题，剩下一成是端口冲突，还有一成是奇怪的环境问题。
先看清楚你的capabilities。Android端最常见的错误是把appPackage和appActivity写错，或者只写了app参数指向APK路径，但没有告诉driver启动后要进入哪个页面。Appium确实可以通过appActivity直接指定入口Activity跳过硬编码路径的问题，但这个写法在不同版本的系统上表现不太一样。
caps = { "platformName": "Android", "appium:udid": "emulator-5554", "appium:appPackage": "com.example.mockdemo", "appium:appActivity": ".MainActivity", "appium:noReset": True, "appium:automationName": "UiAutomator2" }这里的noReset非常关键。如果你设置了noReset: True，驱动不会清理app数据，启动速度会快很多，适合回归测试；但如果你跑的是安装后的首次启动用例，或者需要验证登录态相关的场景，就得考虑noReset: False，让系统恢复到干净状态。
连接类的坑也很多。最常见的是adb设备显示offline。用adb devices看一眼，如果设备后面跟着的是"offline"，先别急着重启Node服务，执行一下adb kill-server然后再adb start-server，多半能救回来。如果还不行，大概率是真机USB连接松动或者模拟器的ADB端口冲突，拔插设备线或者重启模拟器是最快的解法。
iOS端的问题更麻烦一点。真机跑iOS自动化需要WebDriverAgent（WDA）能正常签名、安装并启动，任何一环出了问题都会报session创建超时。最常见的是证书信任弹窗没点掉，或者WDA的bundle id与测试工程配置不一致。这里建议先单独用一次构建验证WDA能不能正常启动，再回到Appium里跑session，否则你根本分不清是Appium的问题还是WDA自身的问题。
端口占用也值得一提。Appium默认端口是4723，但你如果同时开了多个Appium服务，或者上一个进程没有完全退出，新的session就会尝试去占用同一个端口然后失败。排查方式很简单，看日志里有没有EADDRINUSE字样。解决起来更快：要么换端口，要么杀掉残留进程。
注意：启动服务时我习惯给每个session分配独立端口。多台设备并行测试时，
--port 4723、--port 4724这样递增，避免互相抢资源。这个问题等到后面讲并发的时候还会再展开。
3. 元素定位报错的一大半根因在"等"上
聊完启动阶段的session问题，接下来就是实际跑用例时最烦人的元素定位报错。这里我得说一句得罪人的话：大部分no such element问题，根因不是定位方式不对，而是等待策略没写好。
很多测试脚本里最常见的写法是：定位前随便加一个sleep(3)，感觉不够就往上加。这种写法看似简单粗暴有效，实则是一种自我欺骗。慢的网络环境下3秒不够，你会看到偶发性失败；机器性能好的时候其实1秒就能加载完，你平白多等了2秒。正确做法是把固定的sleep换成显式等待，让脚本自己去判断页面元素是否已经处于可交互状态。
from appium.webdriver.common.appiumby import AppiumBy from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC wait = WebDriverWait(driver, 10) target_btn = wait.until( EC.element_to_be_clickable( (AppiumBy.ID, "com.example.mockdemo:id/btn_submit") ) ) target_btn.click()这段代码的意思是：最多等10秒，每500毫秒检查一次，直到按钮处于可点击状态才继续。如果10秒内都没等到，就抛出异常。这种机制远比sleep可靠，因为你等待的是一个明确的业务条件，而不是一个拍脑袋决定的秒数。
隐式等待和显式等待的区别也值得单独拎出来讲。隐式等待是全局的轮询机制，driver.implicitly_wait(10)设置了之后，后续每一次findElement操作都会在元素没出现时反复查找直到超时。它写起来方便，但有个问题是：当页面元素确实不存在时，每次定位都会等满超时时间才会报错，这会让失败用例的执行时间变得非常长。
显式等待则可以针对单个元素、单个条件精确控制。比如页面加载完成后，某个操作按钮5秒内可点击，另一个提示文案可能需要8秒才出现，你用全局的隐式等待只能按照一个统一节奏来，用显式等待就可以各自独立设置。Appium官方推荐的做法是：全局设一个较短的隐式等待兜底，对关键元素用显式等待精细化控制。
除了等待策略，定位方式本身的选择也很讲究。我是以accessibility id优先，其次是id，再其次是xpath。为什么？accessibility id在iOS和Android两端的映射都相对稳定，代码改动的概率低；id稍微差点，但足够快；xpath虽然功能最强，但一旦页面结构小改动就可能挂掉，而且查询性能最差。
说到xpath，有一个脏活但我经常干：用Appium Inspector或者uiautomatorviewer转储当前页面UI层级，然后挑一个相对稳定的父节点，配合子节点的text或者resource-id做组合定位。比如这样一个表达式：
//android.widget.LinearLayout[contains(@content-desc, "mock_item")] //android.widget.TextView[@text="确认"]意思是：先找到一个包含"mock_item"描述的区域，再往下找文本为"确认"的TextView。这种相对路径比写死索引稳定得多，因为列表顺序变化时，index会变，但父子关系和文本特征通常不会变。
还有一类元素定位报错的特例：页面还在加载，但某个框架层的"假元素"已经被渲染出来了。比如WebView混合应用里，H5页面还没完全加载完的时候，原生容器已经存在，但里面的内容还没有。这种情况下用原生定位可能能拿到一个空壳，但点进去什么都没有。换个思路，用context切换进入WebView后再基于css selector定位，或者等待WebView的url变成目标地址后再执行后续步骤。
4. driver会话的生命周期比你想的更脆弱
Appium的driver实例一旦创建，就会跟服务端建立一条长连接。这条连接可不是牢不可破的。长时间不操作、网络切换、设备锁屏、系统弹窗，任何一个因素都可能让这条连接悄悄断掉。接下来你再调用driver.find_element()，得到的就不是业务报错，而是session is not available这一类的连接异常了。
在测试框架设计上，我强烈建议把driver的初始化和销毁封装成独立的工具类，而不是在每个测试方法里随手new。这样做的直接好处是：你可以在统一的地方处理连接异常、初始化失败、截图取证这些横切逻辑，而不是散落在一百个测试用例里各写各的。
实际项目里我给某跨平台系统封装过一个driver管理类，核心逻辑大概是这样：
class DriverFactory: def __init__(self, caps, command_executor): self.caps = caps self.executor = command_executor def create_session(self, max_retries=3): for attempt in range(max_retries): try: driver = webdriver.Remote( command_executor=self.executor, desired_capabilities=self.caps ) return driver except Exception as exc: log.warning(f"session创建失败，第{attempt + 1}次重试: {exc}") time.sleep(2) raise RuntimeError("Appium session创建失败，已达最大重试次数") def safe_quit(self, driver): try: if driver is not None: driver.quit() except Exception: pass注意safe_quit里那个try-except。因为你没法保证quit的时候连接还活着，如果连接已经断了，quit本身就会抛异常，反而把原本正常完成的测试流程污染了。很多人没意识到这个细节，结果测试报告里多了一条最没意义的"teardown失败"。
还有一个非常常见的会话问题：你在测试用例里创建了多个driver实例，但中间的driver没有quit，导致旧session一直占用着手机。手机在设备管理器里就会被标记为"in use"，你下一个测试用例哪怕是全新的session也可能会被卡住。遇到这种情况，去Appium日志里搜一下有没有多个session记录共享同一个设备udid，如果有，说明你的脚本里有一个driver泄漏了。
另外，录制脚本工具生成的代码偶尔也会埋雷。有些自动化录制工具会为同一个测试流程创建两次session，一次是录制时的预连接，一次是实际执行。如果你直接在录制产物基础上随便改改就跑，可能连session被切换了都感知不到。录制脚本可以当参考，但别直接拿来做基准。
说一个我亲身踩过的坑。某个项目的Android测试脚本里，用例A跑完后driver没有立即销毁，而是把同一个driver对象传给了用例B复用。结果用例B一执行页面跳转操作，就报"element is not attached to the page document"。因为移动端App页面跳转后，旧页面里的元素引用全部失效，你以为你在操作一个新page的元素，实际上操作的是旧页面的残留引用。解决方式很粗暴：每个用例尽量独立创建自己的页面对象和driver会话，不跨用例复用。
5. capabilities配错，多设备适配怎么调都白搭
Appium的capabilities表面上看是一堆键值对，实际上每个键背后对应着driver不同的行为模式。很多教程给的示例配置，放到你的项目里不灵光，原因很可能是你们项目跑的机型、系统版本、自动化后端都不一样，配置细节没有跟着调。
Android端我这边排查下来最影响稳定性的三个capabilities分别是automationName、appium:uiautomator2ServerInstallTimeout和appium:shouldTerminateApp。
automationName不写的话默认是UiAutomator1（老版本）或者UiAutomator2（新版本），但明确写出来总归是安心。它决定了driver使用哪一套自动化后端去驱动设备。切到UiAutomator2之后，如果你还在用老掉牙的resource-id之外的定位方式，某些页面元素在UI树里的层级结构会发生变化，需要重新评估已有的定位器。
appium:uiautomator2ServerInstallTimeout这个参数很多人不知道。UiAutomator2服务每次在设备上启动前都要先在设备端安装一个server APK，这个安装过程在某些低端机上特别慢，默认值经常不够用。我一般设成30000毫秒，三十秒内装不上才判失败，这样就把很多"莫名奇妙的session启动失败"问题挡在了门外。
appium:shouldTerminateApp是控制每次session结束后是否强制停掉被测App的。默认false意味着你的被测App可能会带着上次测试的状态进入下一次测试，有缓存、有弹窗、有未完成的页面跳转。单用例没问题，跑全量回归的时候，前面用例污染后面用例的状态会非常难查。我建议回归套件里把它设为true，确保每个用例开头都是干净状态。
iOS端对应的坑也不少见。真机测试时要关注xcodeOrgId、xcodeSigningId这些签名相关的参数，还有appium:wdaLocalPort。多个真机并行测试时，不要把wdaLocalPort设成同一个值，否则多个WDA进程会抢端口，表现就是其中一个session的指令全部超时。
还有一个非常容易被忽略的参数：appium:newCommandTimeout。这个值定义了driver在多久没有收到新的指令后自动退出。如果你写了一段比较耗时的测试逻辑，比如等待一个网络请求完成，期间没有任何driver操作，一旦超过这个超时时间，driver就会自动销毁，后续操作全部报错。本地调试时设成300秒很舒服，但跑CI的时候如果超时设置过短，你会看到测试在长时间等待后突然断连。
经验之谈：capabilities不是抄过来就能用的。每接一个新的真机型号或者系统大版本，我都会花半天时间把核心capabilities过一遍，组合着调。尤其是从Android 12升级到Android 13之后，权限弹窗交互模型变了，如果还想沿用旧的那套"系统弹窗一律点允许"的逻辑，得先确认你的自动化后端是否能识别到新版弹窗的控件结构。
6. 稳定性差、偶发失败多？往这几个方向排查
如果你已经能稳定地跑通单个用例，但一到全量回归就出现各种随机失败，那恭喜你，已经进入自动化测试最考验功力的阶段了。这类问题通常不是某个具体的bug，而是系统性、结构性因素导致的。下面是我按出现频率排的排查重点。
第一，设备状态没有回收干净。上一轮测试结束后，App没被强制停止、弹窗还挂在页面上、输入法软键盘挡住了按钮，这些都会让下一个用例的状态不对。我用的一套标准清理流程是这样的：测试结束后的钩子里，先把App切到后台再杀掉，杀掉进程后再执行一次系统级清理操作，比如Android执行adb shell pm clear或者通过driver重置App状态。iOS端则通过driver.terminate_app()先终止再重新启动。这个步骤不要省略，哪怕一个用例跑完你都意识不到有残留，跑到第一百个用例时问题就会爆发出来。
第二，并发调度时adb冲突。多台Android真机并行跑测试，底层其实是多个adb连接同时在工作。如果同时执行adb install或者adb push，adb server可能会处理不过来，出现设备假死。这种情况下我会引入串行化的操作槽，让安装、初始化这类重操作分时执行，不对测试速度造成明显影响，但稳定性提升非常大。
第三，页面渲染时序竞争。同一个测试用例在多台设备上执行时，页面加载速度可能差很多。一台设备2秒加载完的页面，另一台要5秒。如果断言时机卡在2秒上，慢的那台必挂。这个问题的本质还是等待策略是否规范，需要统一收敛到显式等待模型里，坚决抵制sleep。
第四，被测App本身的质量问题。自动化跑多了，你慢慢会发现有些失败其实是开发提测时的低级问题，比如某个页面偶发崩溃、数据展示异常。这类问题不用在测试框架层面过度优化，识别出来直接提单反馈就行。很多人追求自动化通过率，结果在用各种workaround去掩盖这个页面本身不稳定的事实，这是本末倒置了。
我见过一个比较典型的情况：一个团队想在两周内把自动化通过率从80%提到95%，结果发现折腾了很久提升不了，原因是某个页面存在内存泄漏问题，长时间跑下来早晚会崩溃。他们花了大量时间在脚本里加各种"防崩溃"逻辑，最后我帮他们定位到问题根因时，开发改了十行代码就解决了。
稳定性问题还有一个隐形杀手：空闲等待策略。Appium在iOS端默认会等待应用空闲后才执行下一步操作，但某些应用存在持续动画、轮播图或者定位信息更新，导致App永远处于"忙碌"状态，driver指令就一直卡住直到超时。遇到这种App，可以在capabilities里调整appium:waitForIdleTimeout，或者退一步，在iOS端考虑直接操作层面的方式绕过空闲等待的判断限制。
7. 日志、截图和失败现场是解决问题的三板斧
调试Appium问题，讲究一个现场还原。如果报错时没有留下任何现场资料，后续排查基本靠猜。所以我始终认为，测试框架里日志模块和截图取证模块的优先级，要高于业务用例本身的编写效率。
Appium的日志体系分为服务端日志和客户端日志。服务端日志记录的是driver与设备底层服务之间的交互过程，客户端日志记录的是测试代码自身的执行情况。两者都很重要，但很多人只盯着客户端控制台输出，服务端日志压根没开，结果session失败的原因只能靠猜。
我建议在测试框架里加一个统一的事件钩子：测试失败时自动抓取以下五类信息，并按用例名归档：
1. 驱动会话当前页面截图（PNG格式，原始比例） 2. 页面层级结构转储（Android的page_source / iOS的AX hierarchy） 3. Appium服务端日志片段（从用例开始到报错结束） 4. 设备系统日志（Android logcat / iOS syslog） 5. 发生错误前最后五次操作记录这套取证体系建好之后，排查问题的时间至少能缩短一半。比如no such element报错，你直接看截图就知道当时页面上到底有什么；如果截图显示弹窗遮住了目标元素，那就去查弹窗逻辑；如果截图上压根没有目标页面，那就去查上一步跳转是否成功。
def capture_failure_snapshot(driver, case_name): timestamp = datetime.now().strftime("%Y%m%d_%H%M%S") filename = f"{case_name}_{timestamp}" driver.save_screenshot(f"./artifacts/{filename}.png") with open(f"./artifacts/{filename}_source.xml", "w", encoding="utf-8") as f: f.write(driver.page_source)除了静态截图，视频录制也非常有用。Android端用adb shell screenrecord可以录脚本执行过程，iOS端用xcrun simctl io可以录制模拟器画面。我一般不会每次都开录制，因为视频文件比较大、录制过程本身也会消耗设备资源，但连续出现偶发失败，实在定位不到规律时，录像是最后的王牌。回放视频时重点观察：点击前页面状态、点击后的响应、断言时刻的页面内容。
日志这块还有一个经常被忽略的点：logcat是系统级的日志，它会记录App崩溃时的堆栈。很多自动化失败怀疑是App崩溃，但又拿不到证据。其实你只要在失败后立刻导一段adb logcat -d的日志，搜索关键词"FATAL EXCEPTION"或者"AndroidRuntime"，一眼就能看到是不是有Java Exception。
我见过最有意思的一次排查：某App的WebView混合页面在自动化测试中点击一直不符预期，最终发现是页面里的一段JS代码在不停刷新页面导致元素状态一直在变。这种问题，光看Appium日志根本发现不了，但Android的系统日志里能看到WebView的刷新记录。所以取证体系一定不要只盯着driver层面的日志看，系统级信息也很关键。
8. 异常处理的编程范式：别把崩溃当意外
Appium和WebDriver系工具的异常体系跟普通业务代码的异常体系不太一样。你写业务代码的时候，异常往往意味着逻辑分支走到了预期之外的分支；但在自动化测试里，很多异常其实是可以事先预见、提前处理的状态。
比如页面弹窗处理。无论是Android的权限弹窗还是iOS的定位授权弹窗，它们出现的时间点是不固定的。你可以在每个关键操作步骤前统一封装一个"弹窗处理"函数，每次操作前顺手跑一遍，有弹窗则关掉，没弹窗则跳过。这样处理下来，弹窗导致的中断性失败基本就能消灭掉。
def dismiss_permission_alert_if_present(driver): try: alert_btn = driver.find_element( AppiumBy.ID, "com.android.packageinstaller:id/permission_allow_button" ) alert_btn.click() except Exception: pass这段代码里有个非常核心的思路：用try-except去捕捉"元素不存在"的异常，把这种情况当作正常状态来处理。如果你不这样写，弹窗出现的那一次用例必挂，你需要把它当作一个正常的流程分支来管理。
更进一步，异常处理不能只做try-except，还要考虑异常时的恢复动作。我常用的一种恢复策略是：遇到no such element时，先把当前页面截图保存，然后用driver.back()或者重新进入当前页面，等待页面加载完成后重试一次。如果重试仍然失败，再抛出异常。这种"失败重试一次"的策略能吸收掉不少偶发性的页面渲染抖动，让整体通过率往上涨。
def find_with_retry(driver, by, value, retries=2, timeout=10): last_exc = None for attempt in range(retries): try: return WebDriverWait(driver, timeout).until( EC.presence_of_element_located((by, value)) ) except Exception as exc: last_exc = exc time.sleep(2) raise last_exc这里要注意的是，不要把这个重试策略过度使用。如果一个元素真的永远不在页面上，重试两三次就已经尘埃落定了，重试太多只会拖慢失败用例的执行时间。我一般重试次数上限是2~3次，每次间隔2秒，再失败就直接报错进入后续的取证流程。
还有一个关于异常处理的思路容易被忽略：自动化用例的失败信息要尽量"人类可读"。Appium原始的报错信息对普通测试人员来说并不友好。我建议在断言处统一封装自定义的失败提示，比如"提交按钮不可点击，当前页面可能仍在加载中，耗时超过15秒"，这样上报到测试报告里，执行人员一看就知道是页面加载慢的问题，而不是需要去翻Appium源码。
9. 真机与模拟器：用对了能省掉一半的麻烦
真机测试和模拟器测试的差异，在Appium环境下被放得非常大。很多团队图省事，一直用模拟器跑，结果发布前一到真机就各种翻车。反过来，有些团队所有用例都在真机上跑，效率又低得让人崩溃。我的建议是：功能逻辑类用例优先用模拟器，传感器、性能、键盘输入、以及系统级交互类用例必须用真机。
Android模拟器跑Appium有个非常舒服的地方：启动快、可以方便执行snapshot的快照回滚，快速恢复到某个干净的测试状态。缺点是模拟器上的页面渲染速度通常比真机快，部分性能缺陷根本发现不了。而且模拟器默认的gpu模式可能跟真机不一样，某些动画效果在模拟器上完全正常、到真机上就会卡顿，导致等待超时。
iOS端的模拟器稍微有点不一样。模拟器里跑WDA不需要签名，这是很大的便利。但模拟器不支持某些系统能力体验，比如真正的推送通知、震动反馈、陀螺仪等。而且模拟器上的Appium定位树和真机有一定的差异，部分系统弹窗在模拟器上根本不会出现，你要在模拟器上排除弹窗逻辑就会踩坑。
真机测试最大的痛点在于设备管理。多个真机测试时，每台设备的屏幕可能都亮着，有的息屏了，有的弹出了通知，这些都会影响脚本执行。我都会用一个设备管理服务统一监控设备状态：设备离线时自动重启adb桥接，长时间无响应时自动拉起Appium服务，设备剩余空间不足时自动清理缓存。这个服务不大，但稳定性收益却是实打实的。
还有网络因素。同一台真机连着同一台Wi-Fi，测试过程中发生网络抖动，App请求超时、页面加载一半停住，这些在模拟器上很少遇到，因为模拟器和宿主机共享网络栈。处理方式也很直接：用例里提前编排好弱网或断网的重试逻辑，或者干脆把网络相关用例独立出来专门跑，避免影响普通功能用例。
10. 我最后想分享的实践经验
写到这里，差不多把Appium日常问题处理的几个主要方向都过了一遍。如果说要总结一句话，那就是：自动化测试的问题排查，本质上是一个围绕证据链的推理过程。报错信息只是入口，真正的根因往往藏在capabilities、设备状态、页面渲染时序、甚至被测App自身的行为里。你面前有一堆日志和数据，怎么组织、怎么分析、怎么看穿表象，这才是能力所在。
我自己有一个习惯：每解决一个奇怪的问题，就在团队的公共文档里记录一份排查笔记，内容包括问题现象、根因分析、解决过程和后续防范措施。这个文档三个月后就成了团队的"疑难杂症手册"，很多新人在遇到重复问题时，翻一下手册就能自己定位。省下来的时间不是一点半点。
还有个小技巧非常想分享。调试Appium用例时，不要从头到尾一整条跑，用分步隔离的方式排错。把一条用例拆成三段：进入页面、执行操作、验证状态。每一段独立验证是否通过，哪一段失败就只排查哪一段。这样做的好处是，你不会因为最后一段的断言失败，而去怀疑第一段里已经跑得好好的页面跳转代码。很多花了几个小时排查的问题，其实用这种分段方式十几分钟就能定位到。
最后说一句掏心窝的建议：别执着于追求自动化用例100%通过率。Appium的定位是UI自动化，它的用途是快速发现回归问题、覆盖核心流程，它代替不了单元测试、性能测试和人工探索性测试。如果一个用例时不时就失败但每次定位都很费劲，先停下来想想这个用例本身的设计是否合理，是不是真的应该被自动化覆盖。先把用例池精简到合理范围，再花精力打磨稳定性，这条路走下来，你手里的这套自动化框架才真正有价值。
