做测试这行不会点自动化很多工作真的没法推进。我见过太多人一上来就抓着Selenium猛学结果项目里全是跑不动的脚本也见过有人动不动就说要自研平台最后连个接口用例都没维护明白。Python自动化测试这个方向资料多、工具多、坑也多网上的教程不是太零散就是太理论。这篇内容我不打算给你灌水就按我自己从功能测试转自动化、再从写脚本到搭框架这条路上趟出来的经验把接口自动化、UI自动化、移动端自动化、框架设计串成一条完整的学习和实践主线全程带真实案例和踩坑记录照着做能少走很多弯路。1. 自动化测试到底值不值得做先想清楚再动手很多人问我自动化测试是不是已经卷得没边了我的看法是自动化测试不是灵丹妙药但不会自动化的测试工程师这两年的处境会越来越尴尬。企业招人不管岗位写的是功能测试还是测试开发面试必问自动化项目迭代一快回归测试全靠手工点一个人一天最多点几百个用例而机器一晚上能跑几千条。这不光是效率问题是测试这件事本身能不能跟上研发节奏的问题。1.1 什么项目适合自动化什么项目碰都别碰我见过最坑的建议是“把所有用例都自动化”。这话谁信谁倒霉。自动化测试有它的适用边界我吃了不少亏之后总结出三条硬标准。第一项目要足够稳定。UI频繁改版、接口动不动调整参数的项目自动化脚本的维护成本会直接把收益吃掉。我接手过一个后台管理系统两个月内前端框架换了三次前面写的两百多条UI用例基本全废最后只能保住核心冒烟用例。第二用例要能长期重复执行。你做一次性的上线验证手工点两下就完事了写脚本反而慢。第三需求相对清晰、输入输出可预期。自动化本质上是拿“确定性”换“重复劳动力”如果预期结果天天变脚本就是在跟需求赛跑永远追不上。反过来看适合自动化的场景很明显接口回归、核心业务链路的冒烟验证、大批量的数据构造、跨端兼容验证、以及性能测试里的脚本驱动。这些场景的共同点是重复性极高、人工成本大、结果可以明确断言。记住一句话自动化负责把人从重复劳动里解放出来去干探索性测试和风险评估而不是把人变成脚本管理员。1.2 技术选型接口、UI还是单元先测哪一层自动化测试圈有个很著名的金字塔模型底层是单元测试数量最多中间是接口/服务层测试顶层是UI测试数量最少。我看了无数项目之后得出的结论是国内绝大多数团队的发力点应该放在接口层和UI层单元测试更多是开发团队的事测试团队主要去做接口自动化和端到端自动化。顺序上我强烈建议先做接口自动化再做UI自动化。原因很简单接口是系统内部最稳定的契约只要后端设计不变接口测试脚本就能长期稳定运行而且接口测试能直接覆盖业务逻辑的异常分支、参数校验、权限控制这些用UI去测操作路径长、执行慢、还容易受前端渲染影响。UI自动化更适合做关键用户路径的冒烟验证比如登录、下单、支付、购物车结算这些核心流程。工具选型也别盲目跟风。接口层我用过requests、httpx、RestAssuredJava生态Python这边requests就足够配上pytest做用例管理链路打通之后效率极高。UI层Web端主流是Selenium但我现在新项目会优先看Playwright移动端Appium是跨平台的老大哥Airtest在国内团队用得很顺尤其是游戏和原生App混合的场景SikuliX这种基于图像识别的工具适合处理验证码、图片按钮这些特殊元素但稳定性看环境别当主力。后面我会逐个说清楚它们各自的适用边界和坑。2. 环境搭建与核心工具链把地基打牢很多初学者学自动化死在第一步不是代码写不好是环境装不明白。Python版本、pip源、虚拟环境、浏览器驱动、IDE配置、依赖包安装这一套东西如果理不顺后续每个环节都会冒出一堆莫名其妙的报错。我见过有人在Windows上装了四五个Python版本环境变量一团糟连python和pip到底指向哪个版本都分不清。这块我多说几句你照着做能省一天时间。2.1 Python环境与依赖管理的正确姿势先说Python安装。我自己在Windows和LinuxUbuntu/CentOS上都配过环境Windows下安装包直接去官网下载装的时候有一步“Add Python to PATH”一定要勾上这一步漏了后面各种“不是内部或外部命令”的报错全来了。Linux下别用系统自带的旧版本建议用apt装python3-pip和python3-venv然后通过update-alternatives把默认Python版本指到你要用的版本上。再说pip源国内直连官方源下载依赖包经常超时我一般直接配清华或者阿里云的镜像源。命令行执行一次生效的方式pip install -i https://pypi.tuna.tsinghua.edu.cn/simple requests想永久生效在用户目录下建一个pip.iniWindows或pip.confLinux/macOS写入[global] index-url https://pypi.tuna.tsinghua.edu.cn/simple trusted-host pypi.tuna.tsinghua.edu.cn依赖管理这块强烈建议用虚拟环境隔离项目依赖。我早期图省事直接在全局环境里装包结果不同项目依赖打架今天装这个把那个降级了明天跑脚本直接ImportError。用虚拟环境之后这些破事少了一大半。创建虚拟环境的方式python -m venv venv激活Windows下是venv\Scripts\activateLinux/macOS下是source venv/bin/activate。项目依赖固化成requirements.txt新机器上一条命令就能复现环境pip freeze requirements.txt pip install -r requirements.txtIDE这块VSCode配置Python环境有件事容易被忽略右下角或命令面板里选解释器的时候一定要选到虚拟环境那个路径不然你装了包VSCode用的解释器还是全局的代码里依然飘红。PyCharm相对省心直接New Project选已有的虚拟环境就行社区版免费就够用。2.2 自动化工具全家桶Selenium、Appium、Airtest、Playwright、Cypress怎么选工具选型是个大话题我这些年每个都摸过给你一个相对客观的对比。Selenium是目前Web自动化生态最成熟的框架支持多语言、多浏览器资料多到数不清遇到问题随便一搜就有答案。缺点是安装需要对应版本的浏览器驱动ChromeDriver、GeckoDriver这些而且Chrome更新后驱动不匹配是高频问题报错通常是SessionNotCreatedException。我现在的处理方式是写个小脚本启动时自动检查驱动版本和浏览器版本是否一致不一致就自动下载匹配版本省得每次手动搞。Playwright是后起之秀最大的优势是免驱动安装它自己内置了浏览器下载管理而且API设计比Selenium现代得多支持自动等待、多标签页操作、网络拦截这些Selenium写起来很费劲的功能。我做爬虫和复杂Web交互测试现在优先选Playwright。Cypress在纯前端团队特别流行但它的定位偏开发自测测试跑在Node环境里对测试人员写Python的习惯不太友好除非团队统一用JS否则我不太推荐测试团队直接上Cypress。移动端这块Appium的跨平台能力没得说iOS/Android一套代码框架。但Appium在Android上要依赖UIAutomator2、Appium Server、ADB这一串工具链真机调试时还要处理授权弹窗、版本兼容问题环境坑比较多。Airtest在国内团队用得很普遍它是基于图像识别加Poco控件树的双引擎对游戏、App混合场景覆盖好脚本上手比Appium快很多。我的判断是纯Native应用、要求代码可控性高的用Appium快速落地、有游戏或者图像元素介入的用Airtest。SikuliX的定位更特殊它完全靠图像匹配对验证码拖拽、图片按钮这类元素有奇效但执行慢、对分辨率敏感只能当辅助工具别当主力。接口层面requestspytest是我最稳的组合。requests处理HTTP请求pytest做用例组织、断言、参数化和fixture管理再配合pytest-html或Allure出报告这一套下来基本能满足绝大多数公司的接口自动化需求。3. 接口自动化测试从零到落地一次完整的实战接口自动化是性价比最高的自动化投入这个观点我在这行混了十几年一直没有变过。一个系统可能有几十个页面但接口往往就几百个算上各种参数组合和异常分支用代码维护几百条接口用例比维护几十条UI用例轻松得多。我们来完整走一遍接口自动化的落地过程。3.1 requests核心用法从GET到Session维持requests库说简单就一个传参发请求的过程说复杂实际项目里涉及登录态、签名、加解密、文件上传、重试机制一堆细节要处理。先看基础用法。GET请求最常见参数直接放在params里requests会自动做URL编码import requests url https://api.example.com/v1/user/info params { user_id: 10086, fields: name,avatar,level } headers { Authorization: Bearer your_token_here, Content-Type: application/json } resp requests.get(url, paramsparams, headersheaders, timeout10) print(resp.status_code) print(resp.json())POST请求一般提交JSON或者表单注意json参数和data参数的区别json会自动设置Content-Type: application/json并对字典做序列化data则是表单格式。如果接口要求application/x-www-form-urlencoded用data如果是JSON Body用json。混用会得到415或者参数解析错误。登录态的维持是接口自动化里第一个大坑。很多接口需要在Header里带Token每个请求手写Authorization太蠢而且Token一般有过期时间。我用requests.Session来解决这个问题Session对象会自动保存Cookie配合自定义的认证封装整个测试过程不需要关心Token怎么刷新的问题session requests.Session() login_resp session.post( https://api.example.com/v1/auth/login, json{username: test_user, password: your_password} ) token login_resp.json().get(data, {}).get(token) # 把token注入默认请求头 session.headers.update({Authorization: fBearer {token}}) # 后续请求全部用session自动携带登录态 resp session.get(https://api.example.com/v1/user/orders)文件上传也是接口自动化里经常碰到的场景用files参数files { file: (report.xlsx, open(report.xlsx, rb), application/vnd.openxmlformats-officedocument.spreadsheetml.sheet) } resp session.post(https://api.example.com/v1/upload, filesfiles)3.2 pytest数据驱动测试用例不再是一堆函数单独用requests发请求那叫脚本不叫测试框架。真正让接口自动化具备工程化能力的是pytest。pytest最核心的几个能力是断言、fixture和参数化。断言就是判断实际结果是否符合预期。接口测试里我习惯三层断言第一层状态码第二层业务状态码或业务码很多接口HTTP状态码永远是200真正对错看响应体里的code字段第三层关键业务字段值。比如def test_create_order_success(): resp session.post(/v1/order/create, json{product_id: p001, quantity: 2}) assert resp.status_code 200 body resp.json() assert body[code] 0 assert body[data][order_status] CREATED assert body[data][total_amount] 199.98参数化是我用得最多的pytest功能没有之一。接口测试的用例本质上就是“不同的输入参数组合对应不同的预期结果”用pytest.mark.parametrize一条数据一组用例数据直接外置到YAML或JSON文件里测试代码和数据彻底分离import pytest pytest.mark.parametrize(username,password,expected_code, [ (admin, 123456, 0), (admin, wrong_password, 1001), (, 123456, 1002), (admin, , 1002) ]) def test_login_cases(username, password, expected_code): resp session.post(/v1/auth/login, json{username: username, password: password}) assert resp.json()[code] expected_code数据驱动的价值不只是代码变干净更重要的是新增用例的成本降到最低。团队成员不会写代码没问题往YAML文件里加一行数据就行。这在团队协作里特别实用。fixture是pytest的另一大神器用来做测试前置和后置处理。我最常用的fixture包括全局Session初始化、测试数据准备、清理测试数据pytest.fixture(scopesession, autouseTrue) def global_session(): 整个测试会话初始化一次会话 s requests.Session() login_resp s.post(https://api.example.com/v1/auth/login, json{username: test_user, password: your_password}) token login_resp.json().get(data, {}).get(token) s.headers.update({Authorization: fBearer {token}}) yield s s.close()fixture的scope参数很重要session级别整个测试过程执行一次class级别每个测试类执行一次function级别每个用例执行一次。登录这种重操作必须用session级别不然几百条用例每次重新登录测试时长直接翻好几倍。3.3 接口依赖与签名复杂项目里的硬骨头实际项目里的接口很少是独立的经常是你调下单接口需要先登录拿Token调支付接口需要先有订单号调退款接口又得有支付单号。这种接口依赖关系如果处理不好用例之间就会互相牵着走一个挂了后面的跟着全挂。我的处理方案是conftest.py里放一个全局数据的fixture前面用例执行完把关键数据订单号、支付流水号存到上下文里后面的用例直接从上下文取而不是在用例里硬编码。这类“中间数据”还经常会过期所以我不会把它们写死在脚本里而是每次执行前重新生成。接口依赖的用例我会尽量把它放在同一级测试模块里按顺序执行用pytest的-p no:randomly关掉随机排序插件防止依赖顺序被破坏。还有一类更头疼的是接口签名。有些接口为了保证安全要求请求参数按规则进行MD5或HMAC加密加上timestamp和nonce。做这类接口的自动化关键是把签名算法封装成一个工具函数不要让每个用例自己算import hashlib import time def generate_sign(params: dict, secret_key: str) - str: 按参数名ASCII码排序拼接后再做HMAC-MD5签名 sorted_keys sorted(params.keys()) raw_string .join([f{k}{params[k]} for k in sorted_keys]) raw_string fkey{secret_key} return hashlib.md5(raw_string.encode(utf-8)).hexdigest()这类签名封装是通用能力不管被测系统是Web端、App端还是硬件网关只要是HTTP接口这套思路都能复用。4. UI自动化测试Selenium与移动端实战接口自动化解决的是后端逻辑正确性的问题但用户真正能感知到的体验问题UI层的验证也逃不掉。比如按钮置灰、弹窗提示文案、页面跳转逻辑接口层根本覆盖不到。UI自动化虽然成本高、稳定性难维护但做深了它就是回归测试的底气。4.1 Selenium元素定位与等待机制稳定性的基石Selenium最核心的痛点有两点元素定位和等待。这两个问题不解决脚本就像在雷区跑步随时可能挂。元素定位上我用得最多的是ID和CSS Selector。ID是首选因为页面上全局唯一没有ID就找name、class name、XPath。我坚决不推荐新手一上来就复制绝对路径XPath形如/html/body/div[2]/div[3]/div[1]/form/input[1]这种页面结构稍微一动就全废。我写XPath的习惯是尽量用相对定位结合稳定的属性组合from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC driver webdriver.Chrome() driver.get(https://example.com/login) # 相对XPath基于placeholder属性定位 username_input driver.find_element(By.XPATH, //input[placeholder请输入用户名]) # 或者用CSS选择器定位更简洁 password_input driver.find_element(By.CSS_SELECTOR, input[typepassword])更头疼的是动态元素页面里很多元素的class和属性是前端框架运行时生成的一串随机字符串类似classant-btn css-1a2b3c。这种别直接拿完整class去匹配老老实实用稳定的属性组合或者通过父元素和兄弟元素的相对关系定位。等待机制是UI自动化里另一个决定成败的细节。无数新人一上来就time.sleep(3)固定等待是稳定性的天敌慢一点的机器3秒不够快一点的机器白白等了3秒几百条用例累积下来的时间浪费很可怕。我全部用显式等待轮询判断元素状态条件满足立刻继续wait WebDriverWait(driver, 15) login_btn wait.until( EC.element_to_be_clickable((By.XPATH, //button[contains(text(),登录)])) ) login_btn.click()显式等待最常用的几个条件是visibility_of_element_located元素可见、element_to_be_clickable元素可点击、presence_of_element_located元素存在于DOM。用显式等待之后脚本的整体稳定性能从惨不忍睹提升到基本能看。注意等待时间不要设太长10~15秒合理超过这个时间还没有跑出来的大概率就是真Bug了不用死等。4.2 电商购物车自动化完整案例一条主链路的教科书操作就拿电商购物车的完整流程来说这是搜索热词里出现频率很高的场景也是UI自动化的典型代表。一条完整的购物车用例要覆盖搜索商品、加入购物车、修改数量、勾选商品、结算提交订单、生成订单号。我拿这个流程给你拆解一遍完整的脚本思路。第一步打开电商首页搜索商品。这里有个细节搜索框的定位要稳我用显式等待保证搜索框可输入后再操作search_input wait.until( EC.presence_of_element_located((By.CSS_SELECTOR, input#key)) ) search_input.send_keys(测试商品) search_input.send_keys(Keys.ENTER)第二步在搜索结果页点击“加入购物车”。这里多了一个麻烦页面上的商品卡片很多我得选第一个商品。用相对路径定位到商品区块再去找“加入购物车”按钮first_product wait.until( EC.presence_of_element_located((By.CSS_SELECTOR, div.product-item)) ) add_cart_btn first_product.find_element(By.XPATH, .//div[contains(text(),加入购物车)]) add_cart_btn.click()第三步进购物车页面修改商品数量。这里注意数量框的值可能有动态状态改数量前先清空输入框cart_link wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, a[href*cart]))) cart_link.click() quantity_input wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, input.cart-quantity))) quantity_input.clear() quantity_input.send_keys(3)第四步勾选商品并点击结算这里通常有遮罩层或异步计算金额一定要等到“结算”按钮处于可点击状态再点calculate_result wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, div.cart-total-price))) assert 预期金额 in calculate_result.text checkout_btn wait.until(EC.element_to_be_clickable((By.XPATH, //button[contains(text(),去结算)]))) checkout_btn.click()最后一步提交订单并断言UI自动化的终点必须是一个明确的断言不然跑完也不知道对不对submit_btn wait.until(EC.element_to_be_clickable((By.XPATH, //button[contains(text(),提交订单)]))) submit_btn.click() order_no wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, span.order-number))) assert order_no.text.startswith(2024) # 订单号有年份前缀整个案例的关键经验是每一步操作前后都要有明确的等待和状态确认不要假设页面瞬时就绪。这套思路从搜索关键词里那个selenium 自动化测试 购物车页面的热搜来看是很多人都在死磕的点希望这个案例能帮你们把流程串起来。4.3 Appium与Airtest移动端自动化的两条路线移动端自动化比Web端麻烦的地方在于多了一层设备管理和原生环境依赖。我在真机上跑Appium的时候Android需要开启USB调试iOS需要Xcode和WebDriverAgent这套环境配起来很折腾。Appium的核心思路和Selenium一脉相承本质上是把移动端的元素树暴露出来用driver.find_element去定位。Android原生的元素属性包括resource-id、text、content-desc。一个典型的iOS/Android跨端登录用例在Appium里长这样desired_caps { platformName: Android, deviceName: emulator-5554, appPackage: com.example.app, appActivity: .MainActivity, noReset: True, automationName: UiAutomator2, unicodeKeyboard: True, resetKeyboard: True } driver webdriver.Remote(http://localhost:4723/wd/hub, desired_caps) username_input driver.find_element(By.ID, com.example.app:id/username) username_input.send_keys(test)注意unicodeKeyboard和resetKeyboard这两个配置中文字符输入在Android真机上不配置这两个值经常会输入不上或者乱码。这是我踩过的坑值得记一下。Airtest的路线不太一样它核心是图像识别截图定位元素。它的优势在于对游戏、WebView、小程序这些非原生控件场景支持更好。我实际用下来最大的感受是Airtest的上手成本低不需要懂太多元素树结构但用图像识别跑大规模回归执行速度比控件定位慢而且对屏幕分辨率变化很敏感。所以我的方案是原生控件能定位到的优先用Airtest的Poco控件树实在处理不了再上图像匹配双引擎配合着用。5. 自动化测试框架设计从脚本到体系脚本写多了就会遇到一个坎散落各处的几百个脚本互相之间没有组织、没有统一处理、跑完没有报告维护成本高到想删库跑路。这时候就要上框架了。框架不是用什么神秘技术堆出来的它的本质是对测试代码进行模块化、工程化的组织。5.1 分层设计与POM模式测试代码不是越少越好我接触过的自动化测试框架最健壮的基本都遵循分层设计思想自上而下分为测试用例层、业务操作层、基础封装层。底层封装请求或元素操作中间层封装业务动作比如登录、下单、加购物车顶层只描述测试场景和断言。UI自动化里对应的是Page Object ModelPOM这个模式我强烈建议所有做Web/App自动化的人用起来。它的核心思想是把每个页面的元素定位和页面操作封装成一个独立的Page类测试用例里不出现driver.find_element这类具体定位代码只调用业务方法。class LoginPage: def __init__(self, driver): self.driver driver self.username_input (By.ID, username) self.password_input (By.CSS_SELECTOR, input[typepassword]) self.login_btn (By.XPATH, //button[contains(text(),登录)]) def login(self, username, password): self.driver.find_element(*self.username_input).send_keys(username) self.driver.find_element(*self.password_input).send_keys(password) self.driver.find_element(*self.login_btn).click()这样做的直接好处是页面元素变了只需要改Page类测试用例完全不用动。页面元素定位散落在用例里改一个元素要全局搜索替换这是维护地狱的根源。接口自动化的分层也是同样的逻辑。底层封装一个BaseRequest类处理所有请求的公共逻辑Header注入、超时处理、异常捕获、日志记录业务层封装每个模块的操作登录、下单、支付用例层只做场景编排和断言。分层之后新增一个接口用例通常只需要在业务层加一个方法然后写两层代码调用方法、写断言。5.2 数据驱动与关键字驱动什么时候用什么框架设计里绕不开数据驱动和关键字驱动这两个概念。我的经验是绝大多数团队用数据驱动就够了关键字驱动除非有大量不懂代码的测试同学需要参与用例编写否则不上。数据驱动的核心是“用例数据外置”。接口用例的参数和预期结果放到YAML、JSON、Excel里测试代码用参数化循环执行。拿我之前做过的一个例子几百条下单用例的参数组合全都维护在YAML文件里- name: 正常下单-标准商品 data: product_id: p001 quantity: 1 coupon_id: expected: code: 0 order_status: CREATED - name: 下单-超买数量限制 data: product_id: p001 quantity: 10000 coupon_id: expected: code: 5001 error_msg: 超过单次购买数量限制关键字驱动是在数据驱动基础上把每个操作也变成了可配置的“关键字”比如login、click、assert都变成一行行的配置。这东西灵活是灵活但调试起来能让人崩溃配置一层套一层出错后定位问题的难度直线上升。我的建议是团队里全是会写代码的人就老老实实写代码关键字驱动是给特殊场景准备的。5.3 报告输出与持续集成让自动化跑出价值自动化框架最后一个关键拼图是报告和CI集成。脚本跑完如果没有一个直观的报告你没法跟研发和项目组交代结果也没法快速定位失败原因。我推荐给pytest配Allure报告pip install allure-pytest然后运行pytest --alluredir./reports/allure allure serve ./reports/allureAllure报告能直观展示用例通过率、失败截图、每个用例的执行时间、步骤日志比干巴巴的控制台输出强太多。对于UI自动化用例我还会在失败时自动截图并挂到报告里pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs.get(driver) if driver: driver.save_screenshot(freports/screenshots/{item.name}.png)持续集成是自动化测试发挥真正价值的场景。我把自动化测试脚本放到Jenkins或GitLab CI的流水线里每天晚上定时跑全量回归每次研发提交代码后自动跑冒烟用例。跑完自动发邮件或推送到企业微信钉钉。一旦某个用例失败它会精准定位到哪个接口、哪个页面、哪一步出的问题。到这一步自动化测试才算真正融入了研发流程而不是只在“有空的时候”跑一跑。热词里提到的hil自动化测试体系和uds自动化测试属于汽车电子、硬件在环测试领域用的是Python写上位机脚本驱动仪器或总线通讯思路跟业务系统自动化完全不同但框架设计理念是相通的分层、数据驱动、自动报告。如果你身处硬件行业可以把这套思路迁移过去。6. 常见问题与排查技巧实录这些坑我替你踩过了做自动化测试这几年总结下来踩过最多的坑集中在环境、定位、等待、数据这四个方面。我把真正常见、报错信息容易误导人的问题整理成一张速查表你遇到类似问题直接对照着排查。现象可能原因排查思路与解法运行时报错ModuleNotFoundError: No module named selenium解释器不对包装到了别的Python环境在VSCode/PyCharm里检查当前解释器路径确认激活了虚拟环境pip list看有没有对应包Selenium启动浏览器报SessionNotCreatedExceptionChrome版本与ChromeDriver版本不匹配Chrome地址栏输入chrome://version看版本号到ChromeDriver官网下载完全一致的版本替换本地驱动元素定位报NoSuchElementException但页面肉眼可见元素在iframe里或需要先展开折叠区域先driver.switch_to.frame()切换到对应iframe再定位定位完记得switch_to.default_content()切回点击报错ElementClickInterceptedException页面有遮罩层或弹窗挡住元素用WebDriverWait等遮罩层消失或改用driver.execute_script(arguments[0].click();, element)强制点击脚本跑着跑着突然全部超时前一天数据被清理或环境被重置自动化用例执行前尽量自己构造数据不要依赖外部已有数据推荐每次执行前跑数据准备脚本接口测试返回500/503但手动请求正常可能没带签名、Token过期、或者请求Header缺了指定字段把请求的完整Header和Body打日志对比手动工具Postman/Apifox的请求逐个字段差异排查Windows下pip不是内部命令Python未添加PATH环境变量重新安装Python勾选Add to PATH或在系统环境变量里手动添加Python安装目录和Scripts目录Appium启动应用秒退appPackage或appActivity配置错误真机执行adb shell dumpsys package com.example.appUI自动化在无头模式下找不到元素无头浏览器窗口尺寸导致响应式页面变化设置--window-size1920,1080参数后再跑必要时用有头模式先调试一次除了这张表我再分享一个通用排查法看到报错先看完整堆栈不要只看最下面一行。自动化测试的报错经常是“果”不是“因”比如元素读不到真正原因是页面加载完后JS一直在改DOM你等待的条件选错了报告里看到登录失败不是登录接口坏了可能是前面获取的Token已经过期。我排查问题的时候习惯把print打在关键节点上把Element、页面URL、Response Body都输出到日志里能极大缩短定位时间。另一个高频问题是测试数据的脏数据污染。我见过最典型的情况是一套用例跑完以后没有清理测试产生的订单第二次跑的时候同一个用户已经有几百条未支付订单页面翻页顺序全变了断言就挂。我的做法是每次执行用例前先调接口清理测试数据或者强制用唯一的用户身份时间戳或UUID生成用户名来隔离数据跑完以后再清理一次。测试数据管理的好坏直接决定自动化用例能稳定运行多久这块花时间建设是值得的。7. 最后说点实在的自动化测试做到最后你会发现它拼的不只是代码能力更是对业务的理解和工程化的思维。代码能力解决的是“脚本能不能跑”业务理解解决的是“用例该覆盖什么”工程化思维解决的是“脚本跑完怎么被人用得顺手”。这三样缺一样自动化测试都做不成体系。我个人在实际操作中最深的体会是别想着一步到位搭一个什么都能干的万能框架先从一个接口、一个核心流程跑起来解决团队最痛的那个回归问题让自动化测试产生实际价值后再去慢慢扩充场景和工具链。很多人一开始就全盘铺开做了一堆页面和接口的自动化结果收益撑不起维护成本最后整个项目被砍掉。换个思路从一个点突破、验证收益、再横向扩展这条路我走了无数次每次都走得通。最后再分享一个小技巧如果你在纠结某个自动化方案到底行不行别花一周时间查资料花半天时间做个小样实验。拿Playwright也好拿Airtest也好挑一条真实业务链路跑通数据说话。实验跑通了就干跑不通立刻换方案这比任何理论分析都高效。