简介EdgeDriver 92.0.902.67的win64版本是面向64位Windows系统上Microsoft Edge浏览器的自动化测试驱动组件主要服务于使用Selenium WebDriver进行Web应用功能与回归测试的开发者和测试工程师。它作为Selenium命令与Edge浏览器之间的桥梁支持通过Java、Python、C#等语言编写脚本操控浏览器完成页面跳转、元素点击、表单提交等操作是搭建Edge自动化测试环境的关键基础。压缩包总大小约6.99MB内含3个文件分别为可执行的驱动主程序、开源许可声明和HTML格式的驱动说明文档覆盖从驱动部署到版本兼容性检查的完整信息下载后按说明配置环境变量即可衔接Selenium框架使用。文档中关于版本匹配和路径配置的注意事项能帮助避免常见错误、减少调试成本。目前已有828人下载学习适合正在搭建Edge浏览器自动化测试环境、希望快速获取匹配版本驱动并了解配置细节的开发者参考使用。1. 为什么满世界找 EdgeDriver 92.0.902.67 的 win64 下载找 EdgeDriver 92.0.902.67 的 win64 下载最气的不是找不到而是下回来一跑就报版本不匹配。我在这上面翻过车问题多数不在下载动作本身而在版本匹配。别听“随便下个新版就行”的说法浏览器锁定在 92驱动就得跟着锁 92.0.902.67。这个版本一般出现在两类场景里一类是公司内部统一给测试机装了 Edge 92明令不许更新另一类是老的自动化回归脚本一直跑在 92 这条线上升级浏览器会影响业务功能兼容性验证。于是「下载一个 win64 的 EdgeDriver 92.0.902.67」就成了每天开工前绕不过去的一步。这篇笔记会把这件事一次说透版本怎么对上、win64 怎么选、下载解压后怎么验证、怎么接进自动化脚本以及我踩过的五个高频坑。新手照着做能跑通熟手可以直接跳到第 5 章看排查顺序。2. 先把 92 的匹配规则讲透Edge 版本、win64 与驱动选型2.1 版本号对齐为什么 92 只能配 92EdgeDriver 是 Edge 浏览器官方提供的 WebDriver 实现自动化框架通过它与浏览器按 WebDriver 协议通信。驱动被启动后第一件事就是和浏览器握手、读取浏览器版本号。主版本对不上握手直接失败界面上就是红字session not created后面跟一行类似This version of MSEdgeDriver only supports MSEdge version 93的说明。这句话是大多数人第一次接触「版本匹配」概念的地方。驱动本身不知道自己该服务哪个浏览器它只知道自己在编译时针对哪个主版本做过兼容。你给它一个 92 的浏览器它却按 93 的逻辑去握手协议对不上自然拒绝工作。版本对应关系可以用一句话记Edge 92.x 配 EdgeDriver 92.0.902.67Edge 93.x 配 93 系驱动主版本一旦错开连接必失败。小版本方面Edge 92.0.902.62 的浏览器配 92.0.902.67 驱动通常能正常工作官方建议尽量保持同 build但不必逐字完全一样。真正分生死的是第一位数字。用表总结一下方便你对照Edge 浏览器主版本EdgeDriver 应选主版本能否创建会话9292如 92.0.902.67正常9293 / 最新版不能报版本不匹配9392不能报支持版本不匹配确认浏览器版本的方式很简单打开 Edge 地址栏输入edge://version第一行就是完整版本号也可以在命令行跑安装路径下的msedge.exe --version。注意 Edge 的安装路径比较特殊默认经常落在 Program Files (x86) 目录下这跟浏览器位数没有直接关系2.2 我会细说。2.2 win64 与 win32先看浏览器位数别看系统位数大多数人以为操作系统是 64 位就选 win64这是选错的第一步。真正决定下载包位数的是 Edge 浏览器本身的位数不是系统位数也不是「看起来像 64 位」的直觉。判断方法三步走第一打开 Edge地址栏进edge://version第二打开任务管理器切到「进程」页找到 msedge.exe第三看进程名右侧有没有*32标记。带*32说明 Edge 是 32 位不带则是 64 位。经验上看64 位系统上装 32 位 Edge 的情况在办公环境里并不少见因为部分企业软件只适配了 32 位浏览器。反过来64 位 Edge 默认安装路径也可能是C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe所以看到 x86 路径千万别急着断言浏览器是 32 位任务管理器里的*32标记才是唯一可靠依据。选型原则用一张表说清楚判定依据结论应下载的包msedge.exe 进程带 *32Edge 是 32 位win32x86包msedge.exe 进程不带 *32Edge 是 64 位win64 包系统 64 位但 Edge 是 32 位仍是 32 位需求不要下载 win64混用不是完全跑不起来但很不稳定。32 位 Edge 配 win64 驱动偶尔能起却会在会话创建阶段随机报找不到浏览器64 位 Edge 配 win32 驱动则更容易出现启动即崩。既然标题明确要 win64说明大概率是 64 位 Edge但下载前花 30 秒看一眼任务管理器能省掉后面一整天的排查。2.3 下载前 1 分钟查清的三项运行时前提下载动作本身不复杂复杂的是环境里已经埋好的雷。我习惯在下载任何版本的 EdgeDriver 之前先花一分钟核对下面三件事。第一浏览器版本是不是真锁在 92。很多测试机名义上「装了 Edge 92」实际已经被后台更新到 93 或更高。用msedge.exe --version看实际输出如果是 93这个 92 驱动今天装了也白装得先把浏览器切回 92 或考虑直接升级整套自动化环境。第二自动更新是否还在跑。开着自动更新的机器昨晚可能就被静默改成了 93。这也是「今天能跑、明天不能跑」最常见的元凶。要长期固定 92需要把更新服务与相关任务计划停掉或者直接装不带自动更新的企业通道版本这部分属于环境治理后面第 5 章会再展开。第三WebDriver 是否被组策略或管理策略允许。公司域控机器上常见策略一旦禁止 WebDriverEdgeDriver 进程能正常启动但 session 永远创建不出来报错还不一定指向策略本身。这种情况换任何版本的驱动都无效先检查策略设置再谈下载。提示这三项前提不核对下载再多次也解决不了问题。版本匹配是「环境问题」不是「文件问题」。3. 下载 解压 验证三步拿到可用的 msedgedriver.exe3.1 官方历史版本入口不是只有「最新版」一个选项EdgeDriver 官方下载页默认展示的是最新稳定版这恰恰是找旧版本时最容易踩的坑——你看到的那个大按钮跟你要的 92.0.902.67 没关系。页面上通常还有「历史版本」或「其他版本」入口进入后按大版本折叠点开 92 这一行展开能看到 92 系列下的小版本列表包括 92.0.902.67 和它附近的几个 build。找到目标版本后再点 win64 对应的链接才会进入真正的下载直链。这个页面结构不复杂但有几个细节容易翻车。第一直链经常带查询参数和跳转复制时不要只复制中间一段要右键「复制链接地址」整段拿走。第二官方压缩包是 zip解压后里面只有一个msedgedriver.exe如果解压出一堆 dll、配置文件或者附带说明文档说明你拿到的不是官方原包。第三历史链接不一定永久有效万一 404 了先找同一个大版本下另一个小版本比如 92.0.902.62 的 win64再让浏览器小版本向它对齐这是兜底方案里最实用的一个。第三方「驱动整合包」「一键下载工具」我一般不建议碰。压缩包被重新打包后常见问题是签名丢失、文件被安全软件当成可疑程序处理真出了问题排查成本远大于省下的那几分钟。宁可多花两分钟走官方路径。3.2 Windows 下用 PowerShell 下载并解压拿到直链后的下载动作我推荐直接写在 PowerShell 里而不是用浏览器点。这样能重复执行也能把「下载哪个版本」沉淀成脚本的一部分。下面这段按步骤拆开写# 1. 从官方历史版本页复制 92.0.902.67 / win64 的直链 # 实际链接以下载页复制结果为准粘贴到下面变量里 $url 官方下载页复制的 win64 直链 # 2. 保存到临时目录避免污染当前工作目录 $outZip $env:TEMP\edgedriver_win64.zip # 3. 解压到固定目录目录名带上版本号方便以后多版本共存 $destDir C:\dev\drivers\edgedriver-92.0.902.67 # 4. 下载压缩包-L 跟随重定向-o 指定输出文件 curl.exe -L -o $outZip $url # 5. 解压-Force 覆盖已存在的旧文件 Expand-Archive -Path $outZip -DestinationPath $destDir -Force # 6. 列出解压结果确认只有一个 exe Get-ChildItem $destDir这里用curl.exe而不是 PowerShell 的Invoke-WebRequest是因为 Windows 10 自带的 curl.exe 在处理重定向、下载速度和出错信息上更直接Invoke-WebRequest在 PowerShell 5.1 下对大文件下载容易卡在内存缓冲里偶尔还会因为目标站点的 TLS 配置报错。如果你的机器连curl.exe都没有再退回Invoke-WebRequest也不迟。-Force参数很重要重复执行脚本时不会因为目标目录里已有文件而报错。解压目录C:\dev\drivers\edgedriver-92.0.902.67是我刻意选的路径里没有空格、没有中文目录名自带版本号后续多个版本的驱动可以并排放在一起不会互相覆盖。3.3 解压后三连验证版本、位数、签名解压完别急着接脚本先做三件事。第一确认版本号C:\dev\drivers\edgedriver-92.0.902.67\msedgedriver.exe --version正常情况下输出类似MSEdgeDriver 92.0.902.67 (win64)。如果输出的是 92 但末尾没有(win64)说明下载成了 win32 包如果输出 93 或更高说明直链拿错了。这一步能挡下 80% 的配置问题。第二确认文件签名。官方发布的驱动带有效签名第三方搬运包经常丢签名。执行Get-AuthenticodeSignature C:\dev\drivers\edgedriver-92.0.902.67\msedgedriver.exe输出里Status字段为Valid才算正常。这一步对后续接入安全软件管控严格的公司环境特别有用也是排查「驱动被隔离」的起点。第三如果下载页公布了哈希值顺手核对一下文件哈希Get-FileHash C:\dev\drivers\edgedriver-92.0.902.67\msedgedriver.exe -Algorithm SHA256把计算结果和官方页面上的哈希逐位比对。这不是玄学是确认「下回来的文件没有被传输过程破坏、没有被中间环节替换」的最快办法。比对通过后驱动文件本身才算真正拿到手下一步才是接到自动化脚本里。4. 接进自动化脚本固定路径、Selenium 配置与启动前版本断言4.1 固定路径管理为什么不要裸依赖 PATH驱动文件有了接下来常见做法是把解压目录加到系统 PATH 里然后让自动化框架自己去找。这个做法在单版本、单项目的机器上没问题但稍微复杂一点的环境就会埋雷一台机器上可能同时存在 92、93、最新版三套驱动PATH 里只能放一个优先顺序还不可控。项目 A 要 92项目 B 要 93PATH 里放 93 时项目 A 就崩放 92 时项目 B 就崩。我一般用固定目录管理结构长这样C:\dev\drivers └── edgedriver-92.0.902.67 └── msedgedriver.exe不同版本各占一个目录版本号写进目录名。脚本里按项目需要显式指定绝对路径不依赖 PATH 的全局状态。这样做的代价是每次配置要写一行路径但换来的是脚本可重复执行、多人协作不互相踩。对于固定版本跑回归的场景这个取舍非常值得。4.2 Python Selenium 最小可运行配置接进 Selenium 时很多人会省略驱动路径让框架自动去找。这个行为在最新版 Selenium 里尤其危险——它会自动下载「当前最新版驱动」直接把你固定 92 的计划打乱。正确的做法是显式声明驱动路径和浏览器路径from selenium import webdriver from selenium.webdriver.edge.service import Service from selenium.webdriver.edge.options import Options # 驱动固定 92.0.902.67不让框架自动替换成最新版 driver_path rC:\dev\drivers\edgedriver-92.0.902.67\msedgedriver.exe # Edge 默认安装路径通常在这个 x86 目录下64 位 Edge 也可能在这里 edge_path rC:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe service Service(driver_path) options Options() options.binary_location edge_path # 显式指定浏览器可执行文件 driver webdriver.Edge(serviceservice, optionsoptions) driver.get(about:blank) print(driver.title) driver.quit()Service(driver_path)的核心作用是锁死驱动文件位置框架启动时直接拉起这个 92 的驱动不会走自动管理逻辑。options.binary_location则是告诉驱动「浏览器在哪」避免它在注册表或默认路径里找错。尤其当机器上同时装了稳定版和 Beta 版 Edge 时这一行往往决定成败。有一个反直觉的点值得提醒Edge 64 位版本也可能装在那个 x86 路径下所以代码注释里写了「以实际路径为准」。不要因为看到 x86 就以为浏览器是 32 位判断依据还是任务管理器里的*32标记路径本身不能作为唯一依据。4.3 启动前版本断言把坑挡在脚本外面接好了能跑但还不够稳。环境是动态的今天驱动是 92明天可能被同事重新解压覆盖成 93又或者 Edge 自动更新把浏览器推到了 94。与其等第一条用例红了再去排查不如在初始化阶段就强制校验版本。import re import subprocess import sys DRIVER_PATH rC:\dev\drivers\edgedriver-92.0.902.67\msedgedriver.exe EXPECT_VERSION 92.0.902.67 out subprocess.check_output([DRIVER_PATH, --version], textTrue) print(out.strip()) version re.search(r[0-9]\.[0-9]\.[0-9]\.[0-9], out).group() if version ! EXPECT_VERSION: sys.exit(f驱动版本不匹配期望 {EXPECT_VERSION}实际 {version})这段代码可以放在测试套件的公共初始化里或者作为单独的检查脚本在跑用例前执行一次。它的逻辑很简单拿驱动的--version输出用正则取出完整版本号和期望值比对不一致就直接退出不让用例继续往下跑。这样驱动被换、下错包这类问题会在第一秒暴露而不是在跑了半小时后突然失败。5. EdgeDriver 92 下载配置避坑5 个高频翻车现场与排查顺序这一章列出的五个问题基本覆盖了我见过的求助帖里一大半场景。很多人遇到时当成玄学处理系统重装、驱动反复换其实按「驱动文件本身 → 浏览器版本 → 策略设置 → 安全软件」的顺序排查基本十分钟内能定位。5.1 现象报session not created且提示支持版本是 93这是最经典的一条。脚本初始化时直接红字提示This version of MSEdgeDriver only supports MSEdge version 93但项目明明用的是 Edge 92。原因几乎都是驱动版本拿错了要么直接下了最新版要么之前有人在机器上手动换过驱动把 92 的驱动覆盖成了 93。驱动文件被换这个事很容易被忽略因为它不影响文件是否存在只影响内容。解决方法是把Service里驱动的绝对路径重新指到C:\dev\drivers\edgedriver-92.0.902.67\msedgedriver.exe并先跑一次msedgedriver.exe --version确认输出确实是MSEdgeDriver 92.0.902.67。确认完再跑脚本。如果输出不是 92重新下载解压不要只改代码里的路径名。5.2 现象报msedgedriver.exe executable needs to be in PATH脚本初始化时找不到驱动提示信息里明确点了msedgedriver.exe这个名字。原因有两类一是代码里根本没有传Service框架走默认查找逻辑而 PATH 里没有这个 92 驱动二是自动驱动管理工具介入下载了它认为「合适」的版本但那个版本可能在临时目录里没进 PATH或者版本本身不对。解决方法是回到第 4 章的写法用Service显式指定绝对路径。PATH 方式只适合单版本单项目的极简环境固定版本的项目我建议直接放弃 PATH。另外检查一下代码里webdriver.Edge(...)是否传了executable_path这类旧参数新版 Selenium 里它已经废弃要用Service。5.3 现象Edge 窗口一闪而过或启动后白屏驱动能启动Edge 进程也起来了但窗口闪一下就消失或者页面一直白屏。原因排查三处。第一binary_location指向的浏览器路径可能不对典型错误是有人把msedge.exe的路径写成了chrome.exe然后复制过来第二驱动位数与浏览器位数不匹配比如 64 位 Edge 配了 win32 驱动偶发启动异常第三后台有正在运行的 Edge 进程占用了浏览器文件导致新实例起不来。解决方法是先确认路径真实存在且能弹出浏览器首页再确认驱动--version输出的平台标记和任务管理器里的*32标记对应最后关掉所有 msedge.exe 进程再重试。这个坑最迷惑人的地方在于报错不一定出现只是窗口消失得很干净。5.4 现象驱动前一天正常第二天被安全软件隔离了文件还在目录里但脚本一跑就报「找不到可执行文件」或权限异常打开安全软件隔离区一看msedgedriver.exe躺在里面。原因多为驱动来自第三方下载站重新打包原始签名丢失安全软件规则把它判定为不可信程序少数情况是安全软件对「浏览器自动控制类程序」的默认策略本身就比较敏感。解决方法是走官方渠道重新下载解压后立刻执行Get-AuthenticodeSignature看签名状态是否为Valid然后把C:\dev\drivers加入安全软件的白名单目录。注意白名单别加整个 C 盘那样反而会带来更大的安全隐患。这一步做完基本不会再复发。5.5 现象昨天还能跑今天全部用例超时没有版本报错没有启动失败就是用例在等待页面加载时全部超时。看 Edge 进程还在但页面始终打不开。原因大概率是 Edge 在夜里完成了自动更新浏览器主版本从 92 跳到了 93 或 94。驱动还是 92握手时没被明确拒绝但协议行为已经出现偏差表现就是超时与各种诡异等待。解决方法是把测试机的自动更新停掉或者接受升级然后把驱动一起升到对应版本两条路只能二选一最忌讳只升级一边。停了更新之后把 Edge 版本手动降回 92再配合 4.3 的版本断言脚本这类问题就能在启动阶段直接暴露而不是等到超时才被发现。6. 用一键校验脚本守住版本匹配PowerShell 自检技巧版本匹配这个事靠人记靠不住靠环境不变更不现实。我最后的建议是把它固化成一个本地命令每次跑用例前先执行一遍。下面这个 PowerShell 脚本可以直接用# 一键核对 Edge 与 EdgeDriver 的主版本是否一致 $edgePath C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe $driverPath C:\dev\drivers\edgedriver-92.0.902.67\msedgedriver.exe if (-not (Test-Path $edgePath)) { Write-Host 未找到 Edge请检查安装路径 -ForegroundColor Red exit 1 } if (-not (Test-Path $driverPath)) { Write-Host 未找到 EdgeDriver请检查驱动路径 -ForegroundColor Red exit 1 } $edgeVer $edgePath --version $driverVer $driverPath --version $pattern [0-9]\.[0-9]\.[0-9]\.[0-9] $edgeMajor ([regex]::Match($edgeVer, $pattern).Value).Split(.)[0] $driverMajor ([regex]::Match($driverVer, $pattern).Value).Split(.)[0] if ($edgeMajor -eq $driverMajor) { Write-Host 版本一致Edge $edgeVer / Driver $driverVer -ForegroundColor Green } else { Write-Host 版本不一致Edge $edgeVer / Driver $driverVer -ForegroundColor Red }脚本逻辑不复杂分别调mse dge.exe --version和msedgedriver.exe --version用正则提取出四位版本号再比较主版本。主版本一致就放行不一致直接标红。这里比较主版本而不是完整版本号是因为小版本差异通常不影响会话创建真正会导致翻车的是主版本跨线。把它存成check-driver.ps1后我一般放在项目根目录或者工具的公共脚本目录里让每个新人都能直接运行。它挡不住所有问题但能挡住最常见的 80% 启动失败。我现在的习惯是任何一次「莫名其妙跑不起来」都先跑它再谈别的——这个习惯帮我省掉了大量重复排查时间。希望帮到你。本文还有配套的精品资源点击获取
