1. Web自动化的核心思路与Selenium选型分析做Python Web自动化绕不开Selenium这几乎是所有从手工测试转型自动化的人第一个接触的工具。项目标题里写的是“Python-web自动化-selenium(2)”默认你已经有第一部的底子至少跑起来过脚本、写过find_element。那么这一篇就不重复讲“什么是Selenium安装”了我们把注意力放在真正容易被卡住的地方元素定位的稳定性、等待时机、iframe和多窗口切换以及一个完整可落地的模拟场景——登录后自动查询并采集页面数据。1.1 为什么还是Selenium而不是Requests或Playwright有人会问现在Python生态里有Requests、Scrapy、Playwright这些方案为什么还要学Selenium我的回答是看场景。如果目标接口能直接抓到JSON用Requests肯定更轻但那不叫Web自动化叫写接口调用。Selenium的价值在于它驱动的是一个真实浏览器页面里的JavaScript会执行异步加载的DOM会渲染出来登录后种下的Cookie也不用手动管理。这意味着只要是人工在浏览器里能完成的操作Selenium基本都能模拟。Playwright确实是后起之秀API更现代速度也更快。但Selenium的生态沉淀时间最长社区资料最多遇到一个冷门报错往往搜索Selenium关键词能立刻看到前人踩坑记录。而且很多公司的测试基础设施基于WebDriver标准Selenium本身就是标准协议的实现方之一兼容性不是问题。1.2 WebDriver的原理为什么必须多一个driver文件很多初学者第一步就卡在“下载了一个浏览器驱动”这个事上。不理解原理就会觉得这个驱动文件很莫名其妙。简单说Selenium不直接操作浏览器进程它通过一套名叫WebDriver的协议与浏览器进行通信。Python脚本里的webdriver.Chrome()实际上是启动了一个本地的WebDriver服务由这个服务按照协议把命令翻译成浏览器能懂的操作指令。所以你用不同浏览器就得装对应的驱动。比如Chromium内核浏览器对应ChromeDriver火狐对应GeckoDriver。驱动版本和浏览器主版本必须匹配否则浏览器启动器报错常见的就是session not created。这是环境问题里的第一大坑后面会在环境准备部分详细说。1.3 本篇的实战主线一个典型的登录加查询流程我选了一个很容易复盘的场景模拟用户登录一个公开业务系统进入查询页面输入关键词点击搜索然后把列表数据逐页抓下来。之所以选这个是因为它涵盖了自动化里九成的高频操作文本输入、按钮点击、表格数据提取、翻页、等待异步加载可能还会遇到iframe和弹窗。你想一个脚本如果能处理完这些基本日常工作里80%的重复网页操作都能套用同样的套路。2. 环境准备版本匹配往往比安装本身更磨人很多人的Selenium脚本跑不起来不是代码问题而是环境问题。这里把我测试过多次的组合思路完整讲一遍。2.1 安装Selenium库直接用pip安装即可建议使用虚拟环境隔离项目依赖。Python 3.7以上都能用我一般习惯新建一个venv避免脏掉系统Pythonpython -m venv .venv source .venv/bin/activate # Windows下是 .venv\Scripts\activate pip install selenium装完后验证版本python -c import selenium; print(selenium.__version__)如果输出类似4.25.0的版本号说明库没问题。2.2 浏览器驱动与浏览器版本的匹配原则这是最磨人的环节没有之一。我见过太多人卡在selenium.common.exceptions.SessionNotCreatedException这个报错上。本质原因就是驱动版本和浏览器版本不在同一代。我的操作流程是这样的先看当前浏览器主版本号假设是120。然后去驱动下载页找对应的120.x版本。驱动不需要精确到小版本一致但主版本一定要对。如果你用代码自动管理工具也会省事很多但学习阶段我建议手动下载一次理解目录结构和路径配置后面遇到CI环境才能应对自如。下载完成后把driver文件放到一个你记得住的目录比如~/webdrivers/然后在代码里通过Service指定路径。不要靠把driver丢进PATH这种土办法虽然能运行但项目换机器就失效了。from selenium import webdriver from selenium.webdriver.chrome.service import Service service Service(executable_path/path/to/chromedriver) driver webdriver.Chrome(serviceservice)如果你用的是Selenium 4.6以上它内置了Selenium Manager可以自动匹配驱动很多场景下不用手动管。但自动匹配在网络受限的环境里可能失败所以理解手动匹配的原理依然重要。2.3 浏览器启动参数配置headless与稳定性选项写自动化脚本尤其是要跑在服务器上的脚本一般不会真开一个看得见的浏览器窗口而是用无头模式。但无头模式不是简单加个参数就万事大吉还得考虑资源释放和超时问题。我最常用的一组配置如下from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--headlessnew) # 新版无头模式 options.add_argument(--disable-gpu) # 某些环境避免GPU问题 options.add_argument(--no-sandbox) # Linux容器环境必须 options.add_argument(--window-size1920,1080) # 防止响应式页面元素被隐藏 options.add_argument(--disable-dev-shm-usage) # 容器环境共享内存不足时用 driver webdriver.Chrome(optionsoptions)这里有两个容易踩的细节。第一--window-size一定要设置。无头模式下默认视口很小很多页面的元素会被折叠或隐藏导致你觉得代码没问题但元素就是点不到。第二--disable-dev-shm-usage不是所有环境都需要但只要是Docker容器里运行基本都要加不然浏览器进程会无缘无故崩溃。2.4 设置合理的页面加载与脚本超时Selenium默认等待页面加载是无限的这在实际项目中很危险因为一个第三方资源加载慢你的脚本会卡死在get()这一步。所以我会在启动后立刻设置超时driver.set_page_load_timeout(30) driver.implicitly_wait(10)set_page_load_timeout限制的是页面整体加载时间超时后会抛TimeoutException。implicitly_wait后面再讲它是全局查找元素的兜底等待。这两个值不是越大越好我自己的经验是页面加载30秒足够元素等待10秒足够。设太大反而让问题暴露得慢。3. 元素定位与交互把“找元素”这件事玩明白如果说环境是稳定运行的地基那么元素定位就是Selenium的灵魂。很多脚本挂掉十有八九是NoSuchElementException。定位方式选错了、等待时间不够、元素在iframe里归根到底都是“没找到”。3.1 八大定位方式怎么选Selenium里常见的有八种定位策略ID、Name、Class Name、Tag Name、CSS Selector、XPath、Link Text、Partial Link Text。实际使用中我的优先级是这样能用ID就用IDID在页面里一般唯一定位速度最快。没有ID时优先用CSS Selector简洁且可读性高。XPath留到万不得已比如需要根据文本内容定位或者层级关系很复杂。Link Text只适合精确定位一个超链接Partial Link Text名字看着方便但容易误匹配能不用就不用。举两个实际定位例子。假设登录框的元素是这样input idusername nameusername typetext用ID定位是driver.find_element(By.ID, username)。如果页面上有多个相似输入框你可以用CSS组合driver.find_element(By.CSS_SELECTOR, form.login input[nameusername])XPath虽然万能但写得太长会导致两个问题第一页面稍微调整就失效第二维护起来像天书。我见过一个XPATH长得像这样//div[classa]/div[2]/div[3]/div[1]/span[...]看得人头皮发麻。这纯粹是用浏览器插件直接复制的锅能用短选择器解决的就别复制长路径。3.2 显式等待比sleep优雅一百倍的写法初学者最喜欢用time.sleep(5)硬等页面加载。效果是“大多数时候能跑偶尔抽风”。问题在于sleep不管你页面是否真正加载完时间短了不稳定时间长了浪费执行时间。Selenium官方推荐的是显式等待。用WebDriverWait结合expected_conditions等到某个条件成立才继续走。例如点击登录后页面会异步跳转这时可以等待某个元素出现from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By wait WebDriverWait(driver, 15) search_box wait.until(EC.presence_of_element_located((By.ID, search-input)))显式等待的核心优势在于它能精确表达“你等的是什么”。你要点按钮就等它element_to_be_clickable你要等页面跳转就等某个新元素的visibility_of_element_located。这不光让脚本稳定还让代码变得像注释一样清楚后面接手的人一眼就能看懂你在等什么。补充一下前面提到的隐式等待是全局的只要调用find_element就会在找不到时轮询等待一段时间。它写起来简单但有一个坑隐式等待和显式等待叠加后等待总时长会变长而且在某些Selenium版本里隐式等待会影响元素不可见状态的判断。所以我的习惯是能不用隐式就不用统一用显式等待做核心等待如果非要加隐式也把时间控制在5秒以内。3.3 常用交互操作点击、输入、下拉、多选框、文件上传自动化交互里最常用的几个操作每个都有一点细节。输入框操作注意要先clear()再send_keys()否则原值没清掉文本会拼接search_input driver.find_element(By.ID, keyword) search_input.clear() search_input.send_keys(自动化测试)点击按钮前最好先判断元素是否可点击或者直接用显式等待element_to_be_clickable。下拉选择框别用click加click那样硬点Selenium提供了专门的Select类from selenium.webdriver.support.ui import Select select_element Select(driver.find_element(By.ID, type)) select_element.select_by_visible_text(按名称查询)文件上传也是新手迷惑点。其实只要找到input typefile元素直接把本地路径通过send_keys传进去就完事了不需要真的模拟鼠标去点“选择文件”按钮upload_input driver.find_element(By.CSS_SELECTOR, input[typefile]) upload_input.send_keys(/path/to/file.xlsx)3.4 iframe和多窗口切换很多人在这里翻车操作iframe里的元素时如果你直接find_element大概率报找不到元素。原因很简单当前上下文不在那个iframe里。你需要先切入iframe操作完再切出来driver.switch_to.frame(frame-name-or-id) # 操作iframe内部元素 driver.switch_to.default_content()iframe的定位可以用index、name、id或者WebElement对象。最难缠的是嵌套iframe处理这种就像剥洋葱一层一层切进去用完一层切回父级switch_to.parent_frame()。多窗口切换也是高频场景。点击一个链接打开了新标签页这时driver还在旧页面你得切换到新window handle。记住这个固定写法original_window driver.current_window_handle # 点击导致新窗口出现的元素 link_button.click() # 等待新窗口出现 WebDriverWait(driver, 10).until(lambda d: len(d.window_handles) 1) # 切换到最新窗口 new_window [w for w in driver.window_handles if w ! original_window][0] driver.switch_to.window(new_window) # 操作完成后关掉新窗口回到原窗口 driver.close() driver.switch_to.window(original_window)这里最容易犯的错是driver.window_handles是动态的你要是提前把列表存到变量里新窗口还没打开时列表是旧的切换就会失败。4. 实战案例自动登录后查询并采集搜索结果数据有了前面的基础可以来看一个完整的案例。整个流程我用的是模拟项目X的业务后台用户登录后进入“订单查询”页输入关键词点搜索然后翻页采集查询出来的表格数据。目标是把结果保存成CSV文件。4.1 场景与流程拆解这个场景的核心流程拆成四步打开登录页输入用户名和密码点击登录。登录成功后进入查询页输入查询关键词点击查询按钮。等待结果表格渲染提取当前页表格数据。点击下一页继续提取直到没有下一页为止。流程看着简单实际写的时候有四五个容易卡住的细节。比如登录后页面跳转可能是异步的直接去点查询按钮会点了个寂寞又如结果表格的“下一页”按钮在数据量比较少时会变为灰色禁用状态再比如数据是异步接口返回的页面URL没变但DOM更新了。这些不能靠猜必须在代码里通过等待和状态判断来兜住。4.2 核心代码实现下面是完整脚本我按可运行的思路写里面加了比较详细的注释现实项目中可以根据你的页面结构调整定位方式import csv import time 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 from selenium.webdriver.chrome.options import Options from selenium.webdriver.chrome.service import Service def init_driver(): options Options() options.add_argument(--headlessnew) options.add_argument(--disable-gpu) options.add_argument(--no-sandbox) options.add_argument(--window-size1920,1080) service Service(executable_path/path/to/chromedriver) driver webdriver.Chrome(serviceservice, optionsoptions) driver.set_page_load_timeout(30) return driver def login(driver, username, password): driver.get(https://example.com/login) wait WebDriverWait(driver, 15) user_input wait.until(EC.presence_of_element_located((By.ID, username))) user_input.clear() user_input.send_keys(username) pwd_input driver.find_element(By.ID, password) pwd_input.clear() pwd_input.send_keys(password) login_button driver.find_element(By.CSS_SELECTOR, button[typesubmit]) login_button.click() # 等待登录完成后导航到查询页 wait.until(EC.url_contains(index)) def fetch_page_data(driver): wait WebDriverWait(driver, 15) # 等待结果表格出现且第一行数据渲染完毕 table_rows wait.until( EC.presence_of_all_elements_located((By.CSS_SELECTOR, table.result-table tbody tr)) ) rows [] for row in table_rows: cells row.find_elements(By.TAG_NAME, td) if len(cells) 0: rows.append([cell.text.strip() for cell in cells]) return rows def search_and_collect(driver, keyword): wait WebDriverWait(driver, 15) driver.get(https://example.com/search-page) search_input wait.until(EC.presence_of_element_located((By.ID, keyword))) search_input.clear() search_input.send_keys(keyword) search_button driver.find_element(By.CSS_SELECTOR, button.search-btn) search_button.click() # 等待表格重新渲染这里用数据行出现作为条件 wait.until(EC.presence_of_all_elements_located((By.CSS_SELECTOR, table.result-table tbody tr))) all_data [] while True: all_data.extend(fetch_page_data(driver)) # 找到下一页按钮判断是否可用 next_btn driver.find_element(By.CSS_SELECTOR, button.next-page) if not next_btn.is_enabled(): break next_btn.click() time.sleep(0.5) # 少量缓冲等待表格更新 wait.until(EC.presence_of_all_elements_located((By.CSS_SELECTOR, table.result-table tbody tr))) return all_data def save_to_csv(data, filename): if not data: return with open(filename, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerows(data) def main(): driver init_driver() try: login(driver, your_username, your_password) result search_and_collect(driver, 规格A-2024) save_to_csv(result, query_result.csv) print(f采集完成共 {len(result)} 行) finally: driver.quit() if __name__ __main__: main()4.3 关键环节的原理解读这个脚本里要注意几个设计选择。fetch_page_data里我用了present_of_all_elements_located而不是visibility_of_all_elements_located。区别在于前者只要求元素出现在DOM树里不要求可见。很多表格行虽然高度为0或者被隐藏但DOM里已经存在了如果你拿可见性做条件反而会卡住。当然如果你确实只需要采集用户能看到的数据那就换成可见性条件。翻页部分time.sleep(0.5)在很多老手眼里是“坏味道”但这里可以解释一下表格数据更新时行内容会替换如果用显式等待“行存在”它只会等待DOM里第一次出现行而数据变化后行依然存在所以单纯用元素存在条件区分不了“旧数据”和“新数据”。在这个场景下我会在点击下一页后先短sleep再配合一个“等待某个单元格文本改变”的显式条件比如wait.until(EC.text_to_be_present_in_element((By.ID, first-row-id), 期望值))这样比纯sleep稳。我在脚本里保留sleep只是为了演示“有时候必要缓冲”真上线时强烈建议改成等待业务数据特征比如“第一列第一个单元格的文本不再是上一页的最后一行”。4.4 合规与反检测的边界建议写自动化采集始终要记住“合法合规”四个字。只对你拥有权限的网站或公开数据接口使用不要对需要授权的系统做越权操作。代码里用无头模式不代表可以绕过访问控制。顺带说一个常被问起的点Selenium能不能伪装成真人浏览器绕过一些反爬检测。技术上有各种方案比如修改浏览器指纹、加入stealth脚本但这涉及灰色领域我不建议碰。理由很简单一是与合规底线冲突二是对方真想防你换着花样升级检测你只会陷入猫鼠游戏投入产出比极低。做自动化测试、做自己可控系统的数据汇总已经很够用了。5. 高频异常与排查技巧实录脚本写好后运行崩溃才是真正的学习开始。我把自己在项目里命中率最高的异常整理成了一份排查速查表每个都附上现场特征和解决思路。5.1 NoSuchElementException元素就是找不到报错信息会带上定位表达式。看到这个异常我的第一反应不是代码错了而是“页面状态不在预期”。按顺序排查这几项页面是否加载完成用显式等待代替直接find_element。元素是否在iframe里如果在需要先switch_to.frame。元素是否因为页面宽度不够被折叠或隐藏检查浏览器窗口尺寸。定位表达式是否复制的动态ID有些系统每次刷新都会生成新ID例如order_123456789这种就得改成相对定位或者用其他稳定属性。有一次我排查了很久最后发现页面上有两个相似按钮其中一个在视口外的折叠区find_element默认返回第一个匹配但用户实际点击的却是第二个。这种情况用XPath加过滤条件解决比如//button[contains(text(),确定)][1]或者更稳的是用可见性条件先过滤。5.2 ElementNotInteractableException元素在那里但不能操作这个异常的典型场景是元素在DOM里但被遮罩挡住了或者还在动画播放中。Selenium模拟的点击是直接派发鼠标事件的如果元素正被一个loading遮罩盖住事件就落到了遮罩层上。排查思路看元素是否存在pointer-events: none的CSS属性可以通过get_attribute(style)查看。用ActionChains移动到元素后再点击模拟真人行为。等待元素element_to_be_clickable这个条件会同时检查可见且可点击。还有一个我踩过的坑菜单展开需要鼠标悬停直接click无效。这必须用ActionChains的move_to_element先把鼠标移到菜单父级元素上等子菜单展开后再点from selenium.webdriver.common.action_chains import ActionChains menu driver.find_element(By.CSS_SELECTOR, li.menu-item) ActionChains(driver).move_to_element(menu).perform() sub_menu wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, li.sub-menu a))) sub_menu.click()5.3 StaleElementReferenceException元素引用失效这个异常翻译过来是“元素过期了”。原因是页面的DOM发生了更新你手里握着的WebElement对象还指向旧的DOM节点。最典型的是翻页之后再去操作之前拿到的元素必定报这个错。解决办法有两种。一是操作前重新查询元素不要复用旧引用二是用循环判断StaleElementReferenceException并重试。我一般优先重新查询因为代码可读性更好重试逻辑写多了反而掩盖问题。如果确实要在翻页后点击每一页的某个按钮那就每页重新用driver.find_element拿一次别把按钮对象保存在循环外面。5.4 TimeoutException等待条件没有出现显式等待超时意味着你在等待的那个条件一直没有成立。这个异常比找不到元素更有信息量因为它证明脚本至少跑了等待时间。排查方向用driver.current_url确认当前页面是否跳转到了预期地址。用driver.page_source保存一份HTML搜关键字确认元素结构是否和你预期一致。等元素出现异常时优先检查等待条件里的表达式比如把你的CSS选择器拿去浏览器开发者工具的Console里跑一遍验证是否能命中所需要的节点。我在排查超时时最常用的招数是加截图。在except TimeoutException里直接driver.save_screenshot(debug.png)保存现场回头打开图片看页面停在什么状态比盯着代码猜快十倍。5.5 调试辅助截图、日志与页面状态输出这里分享一个实际工作中很实用的函数它能把报错现场完整保留下来def capture_debug(driver, tag): timestamp time.strftime(%Y%m%d_%H%M%S) driver.save_screenshot(fdebug_{tag}_{timestamp}.png) with open(fdebug_{tag}_{timestamp}.html, w, encodingutf-8) as f: f.write(driver.page_source)截图解决“页面长得什么样”的问题HTML解决“页面上到底有什么元素”的问题。两者搭配能把绝大多数定位和状态异常定位到具体原因。日志级别也可以调低让Selenium内部通信输出到终端from selenium.webdriver.chrome.service import Service service Service(executable_path/path/to/chromedriver, log_outputsubprocess.STDOUT)不过日志输出量很大平时不用开只在问题难缠时开。6. 项目落地与长期维护经验脚本能跑一次不算完成能稳定地重复跑才对得起“自动化”三个字。这一部分讲讲我从一次性的脚本升级成可维护项目时的经验。6.1 把脚本封装成类而不是堆函数脚本超过一个文件时纯函数写法很难梳理依赖关系。我会用类来管理浏览器生命周期和公共工具方法。例如class WebAuto: def __init__(self): self.driver init_driver() self.wait WebDriverWait(self.driver, 15) def login(self, username, password): ... def collect(self, keyword): ... def close(self): if self.driver: self.driver.quit()这样做的直接好处是多个测试用例或采集任务可以复用同一个基类不用每个脚本都重写一遍等待和初始化逻辑。6.2 选择器维护策略把定位信息集中管理项目中经常出现“页面改版脚本报废”的情况核心原因是选择器散落在代码各处。我把所有定位表达式集中到一个配置文件或常量模块里例如LOCATORS { username: (By.ID, username), password: (By.ID, password), login_button: (By.CSS_SELECTOR, button[typesubmit]), search_keyword: (By.ID, keyword), result_rows: (By.CSS_SELECTOR, table.result-table tbody tr), }页面改版时只需要改动这一个字典不用翻开几百行代码找By.ID。这对大项目尤其好用。6.3 与定时任务和CI结合如果你的目标是让脚本每天定时运行那就得考虑执行环境。常见做法是把测试脚本挂在CI流水线上用cron触发。要注意几点容器里要安装完整浏览器依赖只用Chromium内核和driver还不够可能缺系统库。运行环境不能有可视化界面时无头模式是必选。脚本结束必须调用driver.quit()防止容器内存泄漏。运行结果要能通知到人可以输出JUnit XML格式的报告让CI解析。6.4 Headless环境中的本地调试技巧Headless环境下最难受的是“我看不见浏览器在做什么”。我的经验是先用非headless模式在本地把脚本完全跑通再切到headless。本地开发时可以故意把--window-size调大开一个浏览器窗口用driver.execute_script(window.scrollTo(0, document.body.scrollHeight);)滚动页面观察哪些元素是懒加载出来的。另外headless模式下下载文件也和普通模式不一样。普通模式点击下载会弹保存窗口headless下需要配置偏好设置比如prefs { download.default_directory: /tmp/downloads, download.prompt_for_download: False, download.directory_upgrade: True, } options.add_experimental_option(prefs, prefs)这个不配置好你会点半天下载按钮却找不到文件。我最初就卡在这个细节上排查时还以为是点击逻辑写错了。回到这个系列的主题我觉得Selenium这条路的成长曲线并不陡峭真正花时间的不是API而是理解浏览器运行的节奏。当你把等待机制吃透把页面上下文切换玩熟再回头看那些“脚本偶尔跑挂一次”的旧代码基本都能一眼看出病根。我自己的习惯是每写完一个自动化流程都会反问一句如果页面的响应速度比平时慢两倍这个脚本还能不能稳定跑完如果答案是否定的那就说明等待条件还不够精准。这个思考习惯帮我避开了很多线上运行时的突发现象希望你也能从中得到一点启发。
