简介面向因网络原因在线安装频繁中断、从Python官网获取源码又慢又易失败的开发者这是一份可直接使用的selenium 3.141.0离线安装压缩包适合正在学习Web自动化测试或需要搭建Selenium环境的Python使用者。整个包共104个文件核心为86个Python模块文件另含少量js脚本、so动态库、cfg配置、许可证说明以及txt文本文档整体仅905KB解压后执行python setup.py install即可完成本地安装无需反复重试网络下载。目前已有2127人次浏览学习说明离线安装方案得到了较多同类需求者的认可。包内文件类型覆盖库源码与辅助配置既能为网络受限环境提供快捷安装途径也便于开发者查看更新日志与许可证说明了解版本特性与授权条件对于仍在使用Selenium 3系列的老项目还能直接获取对应版本完整文件避免升级带来的兼容性问题。整体结构清晰适合离线教学与自动化测试环境快速搭建。 拿 selenium-3.141.0.zip 这个文件名说事的人大概率跟我一样是从某篇老教程、某个仍在维护的旧项目或者某条网盘链接里翻出来的。这个名字听起来像个“过气版本”但它在 selenium自动化测试框架里的分量一点不轻——官方 Maven 坐标其实是org.seleniumhq.selenium:selenium-java:3.141.59文件名传着传着就变成了 3.141.0。很多企业项目至今还在用这套版本跑用例网上的提问热度也一直没断过。这篇文章我打算从 python selenium 和 java引入selenium自动化 两条最常用的引入路径讲起把文件下载自动化、点击按钮下载图片、以及自动化中碰到滑块/拼图验证码怎么处理、怎么判断下载完成后才进行下一步这几个高频问题一次性理顺。刚下载完 zip 准备跑第一个脚本的或者老项目被 Chrome 驱动版本搞得焦头烂额的都能在这篇里找到能直接抄的答案。1. Selenium 3.141.0 为什么到现在还有人用不是不能升是没到非升不可1.1 版本定位3.x 系列的收官版本兼容性反面教材最少Selenium 3 是 WebDriver 成为唯一标准的关键一代。它废弃了远古时期 Selenium RC 那套服务端注入方案让浏览器驱动ChromeDriver、geckodriver通过 HTTP 协议接收指令这个架构一直延续到今天的 Selenium 4。3.141.59 是 3.x 分支的最终稳定版本之后官方直接跳到了 4.0所以这个版本号在大量博客、教材和真实项目里被反复引用为“最后能稳定跑旧代码的版本”。很多人手里拿到的 selenium-3.141.0.zip其实指的就是这一代。这代版本的官方支持语言非常全Python、Java、C#、Ruby、JavaScript 都有对应包API 风格高度统一。拿 Python 为例webdriver.Chrome()、find_element_by_id()这类写法在 3.141.0 里是绝对主流网上搜到的 90% 案例代码都能直接跑。说它是“反面教材最少”的版本一点不过分——因为 4.0 改了部分 API比如find_element_by_*系列方法被调整很多老教程里的代码放 4.x 上会报警告甚至直接报错但 3.141.0 不会。1.2 项目不升 Selenium 4 的几个现实原因我在不同公司见过不下十个“还钉在 3.141.0”的自动化框架大家不升级的理由其实惊人一致一是存量代码太多一升就要全局重构定位方式二是浏览器驱动版本已经被锁定在旧方案里升级后连带要换 CI 机器上的浏览器三是团队对 4.0 的新特性相对定位器、CDP 协议支持根本没有硬需求。Selenium 4 确实带来了观测性更强的 DevTools 协议接入和更完善的多窗口管理但对绝大多数“点击、填表、下载文件”类任务来说3.141.0 已经完全够用。如果你当前项目的测试环境里浏览器版本并不激进继续用 3.141.0 完全不用心虚。真正该考虑的升级时机是需要 Chrome/Edge 新版本特性支持、需要并行跑大规模分布式用例、或者你受够了老版本对浏览器版本匹配的敏感程度。给个简单对照方便你对号入座对比项Selenium 3.141.0Selenium 4.x核心协议WebDriver HTTPWebDriver HTTP DevTools元素定位 APIfind_element_by_*find_element(By.X, ...)视频录制/网络拦截需第三方库原生支持较强Grid 部署配置复杂相对简单老教程兼容性高需注意 API 差异2. 本地环境引入Python 和 Java 两条路都给你捋明白2.1 Pythonpip 安装 selenium3.141.0再配一个精确匹配的浏览器驱动环境准备其实就两步。第一步装包pip install selenium3.141.0装完验证一下import selenium print(selenium.__version__)能看到 3.141.0 就说明包本身没问题。第二步下载浏览器驱动这一步是新手最容易翻车的地方。Selenium 本身不内置浏览器控制能力它只负责发指令真正干活的是 ChromeDriver 或 geckodriver。而 ChromeDriver 必须和本机 Chrome 主版本匹配否则启动时报错“This version of ChromeDriver only supports Chrome version xx”这一行英文能让无数人卡一整天。我常用的做法是在命令行敲google-chrome --version或者看 Chrome 设置里的“关于”确认浏览器主版本号然后去对应源站下载相同主版本的 ChromeDriver。比如 Chrome 114就找 chromedriver 114.x 版本。驱动下载后放到任意固定目录代码里指定路径即可from selenium import webdriver driver webdriver.Chrome(/path/to/chromedriver) driver.get(https://example.com) print(driver.title) driver.quit()如果驱动已经加进了系统 PATH也可以不传路径。这里有个细节Selenium 3.141.0 对最新浏览器版本偶尔会出现兼容性警告但绝大多数情况下只要版本号主版本一致跑基础操作没有问题。2.2 JavaMaven 依赖引入比手动扔 jar 干净得多Java 工程里引入 Selenium 3.141.0我强烈建议用 Maven 管理依赖别去手动下 jar 再往项目里塞。pom.xml 里加这一段dependency groupIdorg.seleniumhq.selenium/groupId artifactIdselenium-java/artifactId version3.141.59/version /dependencyMaven 会自动拉取 selenium-api、selenium-remote-driver、selenium-support 等一整套相关模块省去手动配路径的麻烦。如果你拿到的确实是一个selenium-3.141.0.zip包里面大概率是源码或某次第三方打包直接解压后把里面的 jar 加进 classpath 也能用但这很容易漏掉依赖的第三方库比如 commons 系列。手动引入时最稳的做法是解压后把libs目录下所有 jar 也一起引入否则运行到一半报ClassNotFoundException就得回头折腾。老 Java 项目里通常会这么写System.setProperty(webdriver.chrome.driver, driver/chromedriver.exe); WebDriver driver new ChromeDriver(); driver.get(https://example.com); System.out.println(driver.getTitle()); driver.quit();注意System.setProperty在 3.x 还是主流写法到 4.x 已经被 Selenium Manager 自动管理驱动取代了这也解释了为什么老项目的初始化代码长得跟新项目不一样。2.3 浏览器驱动版本配对最常见的一场灾难现场“驱动版本和浏览器不匹配”基本是 selenium自动化测试框架入门第一坑。症状很明显启动 Chrome 时报错、报错信息里直接给出当前驱动支持的 Chrome 版本范围而且提示非常直白。解决思路其实只有一条让两者主版本对齐。Chrome 115 之后的版本变化更快ChromeDriver 下载渠道也经历了几轮调整如果你用的是比较新的 Chrome建议直接找对应主版本号的官方驱动二进制别偷懒用“最新的驱动”。这里分享一个排查顺序先确认浏览器版本再确认 driver 版本最后跑一个空页面脚本验证环境。报错时把上下文完整贴进搜索引擎比盲改代码有效得多。很多人以为环境问题该看 Selenium 源码其实绝大多数情况看驱动日志就够了。3. 文件下载自动化的完整链路从点击按钮到确认下载完成3.1 “点击按钮就下载图片”的代码其实核心就两步很多人搜“selenium中点击按钮就下载图片的代码怎么写”想要的其实是一个非常直接的回答怎么定位那个按钮怎么让它触发下载。假设页面上有这样一个下载入口a iddownload-btn href/images/sample.jpg download下载图片/a自动化脚本里只需要from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC btn WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, download-btn)) ) btn.click()这里用WebDriverWait而不是直接find_element后立刻点击是为了避免页面还没渲染完就操作导致的空指针/元素不存在报错。对于带download属性的链接点击后浏览器会直接触发文件下载不会跳转发开新页面。如果按钮绑定了 JavaScript 动态生成 Blob 再下载那点击逻辑一样只是下载文件可能没有后端地址判断完成时会更依赖文件系统层面的检查。3.2 把下载文件固定到指定目录浏览器参数必须改Selenium 默认让浏览器把文件下载到系统默认下载目录这样既不好管理也没法可靠判断完成时间。解决办法是启动浏览器时直接指定下载目录并关闭下载弹窗。Chrome 的配置方案如下from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() prefs { download.default_directory: /Users/me/auto_downloads, download.prompt_for_download: False, download.directory_upgrade: True, safebrowsing.enabled: True } options.add_experimental_option(prefs, prefs) driver webdriver.Chrome(optionsoptions)这段配置能解决两个痛点一是把文件统一收进指定目录方便后续轮询检查二是不弹系统级下载确认框防止自动化进程被未预期的弹窗卡死。Firefox 也差不多用Options.set_preference(browser.download.dir, ...)一类的方式设置即可。3.3 判断“下载完成”的三种实用方案搜“selenium怎样使文件下载完成之后才进行下一步”的人多半是发现脚本下载完了但文件还没落盘或者文件还没写完整就急着去做下一步最终拿到一个损坏的文件。Selenium 3.141.0 不像 4.x 那样能方便地通过 DevTools 拿下载进度所以社区里普遍用文件系统轮询法。我平时最常用这三个方案方案一盯临时文件是否存在。Chrome 下载时会在目标目录生成后缀名为.crdownload的临时文件文件下载完成后临时文件消失。只要目录里没有再出现.crdownload就能认为下载结束了import os import time def wait_download_finish(download_dir, timeout60): deadline time.time() timeout while time.time() deadline: files os.listdir(download_dir) if not any(f.endswith(.crdownload) or f.endswith(.tmp) for f in files): return True time.sleep(1) raise TimeoutError(download timeout)方案二盯文件大小是否稳定。有些下载场景不产生.crdownload或者文件下载完后又由其他进程修改那就可以周期性读取目标文件的体积连续数次不变视为下载完成def wait_file_stable(filepath, interval1.0, stable_count3): last_size -1 stable_times 0 while stable_times stable_count: if not os.path.exists(filepath): return False size os.path.getsize(filepath) if size last_size: stable_times 1 else: stable_times 0 last_size size time.sleep(interval) return True方案三组合轮询。针对文件名不确定的情况先记录下载目录里文件集合下载开始后再轮询直到新文件出现且体积不再增长。这个方案最通用也是我做下载器类工具时的默认选择。很多人搜“selenium 音乐下载器”或者“下载器”相关需求本质都卡在“点击后文件的落地时机”上——掌握上面这三种判断方式任何下载器类自动化都能往这个框架里套。还有一个 headless 模式下的隐藏坑Chrome 无头模式里如果没正确配置下载参数有些版本会直接把下载行为丢弃或下载一半卡住。跑无头模式时务必带上download.default_directory和safebrowsing.enabled配置并且建议加一个长超时兜底。4. 网页滑块/拼图验证码在自动化里的处理思路先谈边界再谈实现4.1 为什么自动化会遇到验证码以及我建议的应对原则做网页自动化时测试环境或内网系统里经常会有滑块、拼图验证这类交互控件它们本意是拦截机器脚本但在自动化测试阶段反而成了“自己人拦自己人”。我对这类问题的处理原则很明确先看能不能通过测试白名单跳过再看能不能人工介入最后才考虑用自动化去模拟用户操作。下面的实现思路只建议用在你自己的测试页面、内网系统或获得授权的自动化项目里而不是去对抗任何线上平台的风控机制。4.2 滑块拖拽的 ActionChains 实现定位、位移、模拟轨迹处理滑块类验证码的技术核心是三点定位滑块元素、计算需要拖动的距离、模拟人手拖拽的轨迹。定位滑块本身不复杂通常是一个带class或id的按钮元素。拖拽动作用ActionChainsfrom selenium.webdriver.common.action_chains import ActionChains from selenium.webdriver.common.by import By slider driver.find_element(By.CLASS_NAME, slider-btn) ActionChains(driver).click_and_hold(slider).move_by_offset(260, 0).release().perform()这里move_by_offset(260, 0)里的 260 是像素位移需要根据页面实际情况调整。问题在于如果直接一次性把距离拖到位服务端很容易识别出这是机械操作。更接近真实用户的做法是让移动轨迹不均匀——先快后慢中间带点微小的停顿和回拉import random import time from selenium.webdriver.common.action_chains import ActionChains def drag_with_tracks(driver, slider, distance): tracks [] current 0 mid distance * 0.7 while current distance: if current mid: step random.randint(5, 12) else: step random.randint(2, 5) current step tracks.append(step) action ActionChains(driver) action.click_and_hold(slider) for step in tracks: action.move_by_offset(step, 0) action.pause(random.uniform(0.01, 0.03)) action.release() action.perform()这个例子里我把移动分成“前 70% 大步快走、后 30% 小步微调”比较接近真人看到缺口后先快速靠近再精细对准的过程。如果服务端检测很严格还可以在轨迹里加入少量上下浮动和随机停顿。4.3 拼图验证码的缺口坐标识别OpenCV 匹配思路拼图类验证码比普通滑块多一步得先知道缺口在图里的位置才能算出该往右拖多少像素。我见过很多人用截图后人工目测取坐标的笨办法这在单次调试时有效但要做自动化回归就不可持续。常见的自动识别思路是用 OpenCV 做模板匹配把“缺口小图”当模板在背景大图里找最相似的位置import cv2 import numpy as np def find_gap_position(bg_path, gap_path): bg cv2.imread(bg_path, 0) gap cv2.imread(gap_path, 0) result cv2.matchTemplate(bg, gap, cv2.TM_CCOEFF_NORMED) _, max_val, _, max_loc cv2.minMaxLoc(result) return max_loc[0]返回的max_loc[0]就是缺口左上角的横坐标再用它减去滑块初始横坐标得到实际拖动距离。这里有个细节页面上的验证码背景图通常被 CSS 缩放显示像素距离要根据图片实际宽度和显示宽度的比例换算。两种前端写法Canvas 绘制、CSS background-image对截图位置也有影响实操时建议先用一张已知答案的验证码校验换算关系。如果模板匹配精度不够可以先对图片做边缘检测或二值化处理把干扰元素去掉再匹配。4.4 更稳妥的测试方案白名单、环境开关和人工兜底抛开技术实现我更想提醒你的是生产环境的验证码本身就是防御机制自动化去强行破解并不是可持续方案。真正稳定的自动化框架通常采用三种替代思路。第一种是测试环境直接关闭验证码功能由后端配置一个开关或白名单让测试用例根本不会撞上这道坎第二种是把验证码环节抽成可插拔步骤代码里如果检测到验证码元素就输出提示等待人工处理处理完再继续第三种是验证码厂商支持测试专用 token比如某些服务商允许你在沙箱环境里走通流程。这三种方案比纯粹模拟拖拽要可靠得多维护成本也更低。自动拖拽这类技术在无法绕过验证码的授权测试场景里可以作为备用手段但别把它当成主力方案。5. 实操中踩过的一些硬坑和经验Selenium 3.141.0 专属的稳定性问题5.1 Chrome 升级导致驱动版本不匹配别慌先看主版本号用 3.141.0 做自动化最容易碰到的日常事故就是某天 Chrome 自动更新后跑用例时突然报错。我排查这类问题从来不看一大堆堆栈而是先看错误信息里是否带有 “only supports Chrome version” 或 “session not created” 字样。如果看到了八成就是驱动和浏览器对不上了。解决办法是下载匹配当前浏览器主版本的 ChromeDriver替换旧驱动。版本库变化无常但找到一个可用的 Chromedriver 之后我强烈建议把本地 Chrome 自动更新关掉或固定使用经测试过的浏览器版本不然每周都可能被更新打断一次。5.2 元素定位不到的隐性原因iframe、新窗口和加载时序很多人在“图片下载、滑块操作”场景里遇到NoSuchElementException第一反应是选择器写错其实更常见的原因是元素在 iframe 或新窗口里。点击按钮后如果新开了标签页Selenium 默认还停留在旧页面上得先切换窗口句柄window_handles driver.window_handles driver.switch_to.window(window_handles[-1])如果目标元素在 iframe 里就要先切进 iframedriver.switch_to.frame(driver.find_element(By.TAG_NAME, iframe))这类问题最坑的地方在于你肉眼在浏览器里能看到那个元素于是怎么都不信是定位问题。遇到这种诡异情况先检查当前页面上下文再检查元素是否被遮挡比如浮层盖住了按钮导致不可点击然后用WebDriverWait等元素变成可点状态而不是一上来就疯狂重试。5.3 长任务稳定性关好浏览器别裸用 sleep做大规模自动化用例时最让团队头疼的是脚本跑到一半停在莫名其妙的等待上。我见过大量新人用time.sleep(5)代替显式等待表面上能跑通但换台机器、网变慢以后立刻翻车。正确做法是用WebDriverWait配合expected_conditions做条件等待只在确实无法确定完成时机的场景比如第一章说的文件下载完成判断里才用轮询。另外我有个强制性习惯每个用例结束都用finally块执行driver.quit()而不是driver.close()。close()只关当前窗口如果脚本打开过多个标签页浏览器进程不会被完整回收长时间跑下来会有大量残留 Chrome 进程占内存。还有一个容易被忽略的坑——driver.quit()后没有清空临时目录下载文件越积越多磁盘被塞满后整个回归套件跟着崩。所以做下载类自动化时最好在任务开始前置一个清理动作把旧文件清掉再开始新任务。我自己的习惯是在框架入口统一封装一个下载目录清理函数每次跑用例前执行一遍。这套组合拳打下来Selenium 3.141.0 的稳定性足以扛住日常回归任务。本文还有配套的精品资源点击获取