1. 先搞清楚自动化测试环境到底要装什么我见过太多人把“搭建 python 自动化测试环境”理解成一件特别简单的事下载一个 Python 安装包下一步下一步然后打开命令行敲两行代码就完事儿了。等真开始写用例的时候才一脸懵——脚本跑不起来、浏览器打不开、依赖装不上、项目一多版本互相打架光是排查环境问题就能耗掉一个下午。先说结论自动化测试环境不是一个“软件”而是一整套组合。除了 Python 解释器本身还包括依赖管理工具、单元测试框架、第三方库、浏览器驱动如果做 UI 自动化、报告生成组件以及让这一切协同工作的虚拟环境隔离方案。这中间任何一环断了你的自动化就跑不起来。所以这篇文章不打算教你“背命令”而是把环境搭建这件事从原理到实操完整拆开。下面这些内容更适合谁看正准备入门自动化测试的新人、换了新电脑不知道从哪开始配环境的初级测试工程师以及项目里多人协作时被环境问题反复折磨的测试同学。看完之后你至少能拥有一套自己的、可控的、能跑通的 Python 自动化测试环境并把所有依赖关系理得明明白白。1.1 为什么环境搭建是自动化测试的第一道门槛先说一个经常被低估的事实大多数自动化测试失败不是用例写得不对而是环境没搭好。我之前在一家公司带测试团队新来的同事入职第一天光是在自己电脑上把 pytest、requests、selenium 装通就花了整整半天。原因五花八门公司内部网络下载慢、pip 源没换、Chromedriver 跟浏览器版本对不上、Python 装了两个版本导致命令错乱。每一件事单独拎出来都不难但串在一起就成了劝退新手的第一道门槛。更深层的原因是自动化测试项目对环境的“精确性”要求很高。生产环境里你用 Python 3.11 跑一个脚本跟用 3.8 跑行为可能有细微差别同一个库的不同版本API 也可能完全不同。你写之前依赖的是webdriver_manager自动匹配驱动但同事电脑上没装这个库脚本就直接报ModuleNotFoundError。这类问题本质上不是代码问题而是“环境漂移”问题。这也是我为什么要花一整篇来讲“搭建环境”的原因自动化测试的环境搭建不是为了让你能运行一次脚本而是为了让你能在任意一台机器上用最少的步骤复现同样的运行结果。理解了这一点后面所有操作你都会知道为什么要这么做。1.2 一套最小可用环境包含哪些组件先给一张清单心里有谱后面按图索骥。组件作用常见选型Python 解释器运行 Python 代码的基础Python 3.8推荐 3.10/3.11虚拟环境隔离项目依赖避免不同项目冲突标准库 venv包管理工具下载、升级第三方库pip测试框架组织、执行、断言测试用例pytest接口测试库发送 HTTP 请求、解析响应requestsUI 自动化库驱动浏览器执行操作selenium 或 playwright浏览器驱动管理自动匹配、下载用户浏览器对应的驱动webdriver-manager报告工具生成可读、可归档的测试报告pytest-html、allure-pytest源码管理版本控制、多人协作git这套清单是“最小可用”不是“必须全套”。比如你只做接口自动化那 UI 相关的库和浏览器驱动就可以先不装你不出外网报告allure 也可以后面再上。但 Python、虚拟环境、pytest、requests 这四样我认为是标配中的标配。后面的实操我们就围绕这套标配来展开再逐步扩展。2. Python 版本选择与三平台安装2.1 版本怎么选别追新但也别太老很多人一上来就问“Python 装哪个版本”这个问题的答案其实很务实看你的自动化测试依赖库的兼容情况。一般来说选当下较新的稳定版本就行但同时要避开两个极端。第一个极端是追求最新版。比如 Python 3.13 刚发布的时候有些 C 扩展库还没编译好对应的 wheel 包你pip install的时候可能会遇到“需要从源码编译”或者干脆装不上。自动化测试领域的库更新速度不算快等你常用的库都跟上新版本往往要等半年以上。第二个极端是坚持用老版本比如 3.6 甚至 3.5虽然能跑但很多新工具链已经不提供支持了遇到问题连报错都看不懂。我的建议是如果你在 Windows 上做自动化测试直接选 Python 3.10 或 3.11这两个版本是目前第三方库兼容性最好的区间。公司如果已经有历史项目优先跟随公司项目指定的版本因为不同解释器版本对字符串处理、字典排序、异常堆栈的打印方式都有差异。提示我踩过一个真实的坑——项目里用requests发起请求测试响应断言时依赖字典的插入顺序Python 3.6 和 3.7 行为不同导致同一个用例在同事电脑上通过、在我电脑上失败。这种问题很隐蔽解决了半天才发现是解释器版本不一致。所以团队协作时把 Python 版本写进 README 是基本素养。2.2 Windows/macOS/Linux 三平台安装实操Windows 是最常见的测试开发环境安装时最容易踩的坑就是没有勾选“Add Python to PATH”。去 Python 官网下载对应版本的安装包双击运行后第一屏最下面有一个“Add python.exe to PATH”复选框必须勾上。然后选“Install Now”不要选“Customize installation”除非你明确知道自己要改什么。macOS 上我比较推荐直接去 python.org 下载 pkg 安装包而不是用系统自带的 Python。macOS 自带的 Python 版本老旧而且牵扯系统内部依赖你贸然升级可能会影响系统脚本。用官方安装包装出来的 Python 是独立的跟系统自带的不冲突安装完成后在终端执行python3 --version验证。Linux 的坑主要在发行版。Ubuntu/Debian 上系统自带的 Python 不能乱动因为 apt 包管理器可能依赖它。推荐用 pyenv 来安装多版本 Python它会在用户目录下独立编译安装不影响系统环境。日常做自动化测试用 pyenv 管理版本是最省心的方案pyenv install 3.11.8然后在项目目录指定pyenv local 3.11.8就行。2.3 验证安装和 pip 准备别急着开跑安装完成后不要急着装依赖先做三件事。第一打开命令行执行python --version确认能输出版本号第二执行pip --version确认 pip 存在且指向你刚装的那个 Python。这里有个常见状况Windows 上同时存在 Python 2 和 Python 3 的历史残留导致python命令指向的是旧版本。出现这种现象可以用where pythonWindows或which -a python3macOS/Linux查看实际命中的路径。第三件事也是我强烈建议做的把 pip 源换成国内镜像。新装完的 pip 默认从官方源下载包在国内网络环境下经常慢到怀疑人生。我一般在用户目录下新建一个pip.iniWindows或pip.confmacOS/Linux写上清华或阿里云的镜像地址。这里的原理是pip 会优先读取用户级配置文件你不需要修改任何系统文件也不影响团队其他人是最安全的加速方式。换完源之后装依赖的速度能提升一个数量级。3. 虚拟环境项目隔离的必修课3.1 为什么要用虚拟环境不直接用全局 Python如果你是一个项目用到头那全局环境也不是不能用。但现实中一个测试工程师手头往往同时维护几个项目一个是用 selenium 做 Web 自动化依赖 selenium 3.14另一个是接口测试平台依赖 requests 2.31还有一个项目可能要用 playwright而 playwright 和 selenium 安装在同一全局环境里偶尔会互相干扰。更麻烦的是有些依赖会间接拉取公共依赖版本升级之后某个项目莫名其妙的TypeError就出现了。虚拟环境本质上做的事情很简单为每个项目创建一个独立的目录把 Python 解释器和所有第三方库都装到这个目录里。你可以把它想象成每个 App 都有自己的沙箱A 应用升级了一个公共库B 应用不会受影响。在 Python 里官方内置的venv模块就是干这个的不需要额外安装任何东西。3.2 venv 创建、激活、退出一条龙在项目根目录打开终端执行python -m venv venv这句话的意思是用python这个解释器调用内置的venv模块在当前目录下创建一个名为venv的虚拟环境目录。目录里面会生成Scripts/Windows或bin/macOS/Linux目录所有后续安装的第三方库都会乖乖待在里面。激活方式分平台。Windows 的 CMD 里用venv\Scripts\activate.batWindows 的 PowerShell 里用venv\Scripts\Activate.ps1macOS 和 Linux 终端里用source venv/bin/activate激活之后命令行前面会出现(venv)标识这时你运行python或pip用的都是虚拟环境里的那一套跟全局环境彻底隔离。退出环境执行deactivate注意在 Windows 的 PowerShell 里首次运行 Activate.ps1 可能会遇到“禁止运行脚本”的报错。这不是你的问题是 PowerShell 默认执行策略比较保守。解决方案是在管理员模式下执行一次Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser把当前用户的执行策略放开到“本地脚本允许运行、远程脚本需要签名”然后重新打开 PowerShell 就好了。3.3 用 requirements.txt 固化依赖避免“我明明装过”项目开发到一定程度一定要把依赖清单导出来否则你换个电脑、或者同事 clone 仓库根本不知道要装哪些包。这一步非常简单pip freeze requirements.txtpip freeze会列出当前虚拟环境里所有已安装的第三方库及精确版本号重定向到requirements.txt文件里。这个文件建议提交到 git 仓库作为项目的一部分。别人拿到项目后只需要创建虚拟环境然后执行pip install -r requirements.txt就能把环境原样恢复出来。千万不要跳过这个步骤我看到过太多人换了电脑之后对着一个空空如也的环境发呆然后开始手动安装一个又一个包装到一半发现某个版本报错直接心态崩溃。4. 测试框架与依赖安装pytest 为核心的配置4.1 按测试类型拆分依赖别一把梭很多新手喜欢把能想到的库一次性全装上我没有反对但也不推荐这样做。依赖越少环境越干净问题排查越容易。你完全可以只给当前项目装需要的库等以后真的需要其他库时再补装。接口自动化核心requests处理 HTTP 请求pytest组织和断言用例。Web UI 自动化核心selenium或playwrightwebdriver-manager自动管理浏览器驱动。数据校验或数据库操作pymysql、sqlalchemy按需添加。测试报告增强pytest-html生成简单 HTML 报告allure-pytest配合 Allure 生成更丰富、带步骤和截图的报告。并发执行和稳定性pytest-xdist多进程并行跑用例pytest-rerunfailures失败用例自动重试。我的个人习惯是一个最小接口自动化项目只装pytest和requests。等用例量上去了再加pytest-html和pytest-xdist。UI 项目再单独引入 selenium 相关。这样做的逻辑是每个依赖都可能有传递依赖装得越多不同库之间的版本冲突概率越大。4.2 pytest 安装与 pytest.ini 配置安装 pytest 很简单在激活的虚拟环境里执行pip install pytest pytest-html pytest-rerunfailures安装完成后不要直接开写用例我建议先建一个pytest.ini配置文件把项目级公共选项放进去。比如[pytest] testpaths tests addopts -vs --htmlreport/report.html --self-contained-html markers smoke: 冒烟用例 interface: 接口用例 uiauto: UI自动化用例这段配置里testpaths指定 pytest 去tests目录下收集用例addopts是每次执行时默认追加的命令行参数-vs表示详细输出并把 print 内容显示出来--html指定生成 HTML 报告路径。markers注册了三个标记后面写用例时用pytest.mark.smoke就能给用例打标签执行时也可以用-m smoke只跑某一类用例。提示pytest.ini这个名字不能随便改它是 pytest 的默认配置文件。如果你的项目里还有setup.cfg或pyproject.toml也能配置 pytest但混用会带来混乱。新手阶段老老实实用一个pytest.ini就足够了。4.3 浏览器驱动与 WebDriver 版本匹配问题做 Web UI 自动化时Selenium 本身只是一个 API 库它需要通过 WebDriver 去控制浏览器。WebDriver 是一个可执行文件比如 Chrome 对应chromedriver.exe而且它对浏览器版本极其敏感Chrome 118 不能配 Chrome 119 的 driver会因为协议不匹配报session not created。手动下载匹配的 driver 是个无底洞因为 Chrome 动不动就自动升级今天匹配好的明天又失效。所以我强烈建议直接引入webdriver-manager库pip install webdriver-manager然后在代码里这样调用from selenium import webdriver from webdriver_manager.chrome import ChromeDriverManager from selenium.webdriver.chrome.service import Service service Service(ChromeDriverManager().install()) driver webdriver.Chrome(serviceservice)这段代码会在第一次运行时自动检测你本机 Chrome 的版本去官方源下载对应版本的 chromedriver并缓存到用户目录之后就不再重复下载。原理其实不复杂就是动态拼接出一个匹配当前浏览器版本的 driver 下载 URL帮你省掉人工核对版本的手动过程。很多人在这上面卡了一天用这个库 5 分钟解决。5. 从零跑通第一个自动化用例5.1 推荐的项目目录结构别把用例堆在根目录环境搭好之后就轮到项目结构了。我不喜欢教条式地规定“必须这样写”但有一个结构我用了很多年足够简单也够用project/ ├── venv/ # 虚拟环境目录不提交git ├── tests/ # 测试用例目录 │ ├── __init__.py │ ├── test_demo_api.py # 接口用例 │ └── test_demo_ui.py # UI用例 ├── report/ # 测试报告输出目录 ├── pytest.ini # pytest配置 └── requirements.txt # 依赖清单创建虚拟环境之后在项目根目录建上面的目录和文件。tests目录加一个__init__.py是为了让 pytest 正确识别模块路径避免导入时出现奇怪的 ModuleNotFoundError。report目录可以先空着pytest 插件会自动创建。5.2 接口用例示例requests pytest 快速跑通接口测试是自动化测试里上手最快、收益最明显的部分。写一个最简单的用例验证一个公开接口的返回码和关键字段import requests def test_demo_api(): url https://httpbin.org/json resp requests.get(url, timeout10) assert resp.status_code 200 assert resp.json()[slideshow][title] Sample Slide Show保存到tests/test_demo_api.py然后在项目根目录执行pytest tests/test_demo_api.py如果你看到1 passed说明 pytest、requests、虚拟环境、配置文件全部跑通了。这个用例虽然简单但它已经覆盖了一条自动化测试的基本链路发送请求、接收响应、断言结果、输出报告。5.3 UI 冒烟用例示例Selenium 打开一个页面再给一个 UI 自动化冒烟用例验证一个页面能否正常打开import pytest from selenium import webdriver from webdriver_manager.chrome import ChromeDriverManager from selenium.webdriver.chrome.service import Service pytest.mark.smoke def test_open_page(): service Service(ChromeDriverManager().install()) driver webdriver.Chrome(serviceservice) driver.get(https://www.baidu.com) assert driver.title driver.quit()执行方式同上pytest tests/test_demo_ui.py -m smoke如果配置了-vs你会看到浏览器真的被打开了然后断言页面 title 不为空。这个用例虽然只有几行但已经把“驱动自动管理、浏览器打开、页面访问、断言、资源释放”这几个 UI 自动化的核心环节走通了。5.4 执行、看报告、管理用例收集范围跑完用例之后你会在report/目录下看到一个 HTML 报告。用浏览器打开它能看到通过率、耗时、失败详情。如果你把多个用例都放进tests目录直接执行pytestpytest 会根据pytest.ini里的testpaths自动收集所有test_*.py文件执行完统一生成报告。这一步做完你的自动化测试环境已经具备“可以交付”的雏形了。后面无论是扩展用例还是接入 CI都是在这个基础上做加法。6. 常见环境问题与排查实录6.1 pip 安装失败的几类高发原因先给一个排查优先级网络问题 权限问题 版本冲突问题。新手遇到pip install报错八成是网络导致下载超时症状是“卡在 Downloading 很久后报Read timed out”或者 “Could not install packages due to an OSError”。解决方案很明确换镜像源。在用户目录配置 pip 镜像后下载速度会明显提升。第二类权限问题在 macOS/Linux 上表现为PermissionError原因是你可能用系统 Python 直接装库。解决办法是用虚拟环境或者加--user参数但我还是推荐前者。第三类版本冲突比较多见的是pip check报依赖不兼容一般发生在直接往全局环境塞各种库的场景虚拟环境能帮你规避掉大部分。注意不要为了一个问题反复暴力重装。如果某个包怎么都装不上先执行pip show 包名看这个包是不是已经存在再执行pip install 包名 --upgrade --force-reinstall强制重装。有时候只是安装中断导致文件不完整重装一遍就好了。6.2 命令找不到或版本错乱python命令找不到几乎都是 PATH 没配好。Windows 上安装时没勾“Add Python to PATH”最省事的补救方法是重新运行安装包选择 Modify勾上 Add Python to environment PATH。macOS/Linux 上如果python找不到但python3存在说明系统里只有 Python3你可以用python3命令也可以自行安装一个链接但我建议直接用python3。还有一种情况是明明装了新版本执行python --version却显示旧版本。用where python看一下大概率发现多个 Python 路径命令行优先命中了旧的。解决方案是在 PATH 环境变量里把新版本的目录放到前面或者直接把旧的卸载干净。6.3 WebDriver 启动失败UI 自动化里最常见的报错就是Message: session not created: This version of ChromeDriver only supports Chrome version xxx这句话已经非常直白了driver 和浏览器版本不匹配。如果你用的是webdriver-manager还出现这个问题大概率是浏览器自动升级到了 driver 缓存不支持的版本。解决办法是先清除~/.wdm缓存目录再重跑用例让它重新下载匹配的 driver。另一个常见问题是WebDriverException: Unable to find binary ...说明 selenium 找不到浏览器可执行文件。这种情况要指定浏览器路径。用 Chrome 时可以在代码里加上from selenium.webdriver.chrome.options import Options options Options() options.binary_location rC:\Program Files\Google\Chrome\Application\chrome.exe6.4 高频问题速查表问题现象直接原因处理办法python命令不存在PATH 未配置重装勾选 Add to PATH 或手动加环境变量pip指向另一个 Python多个 Python 并存用python -m pip代替pip安装库超时访问官方源慢配置国内镜像源PowerShell无法激活 venv执行策略限制设置 CurrentUser 执行策略为 RemoteSigned驱动版本报错Chrome 自动升级清理webdriver-manager缓存或手动匹配用例跑完没有 HTML 报告未装 pytest-html 或 addopts 未配安装 pytest-html 并配置--html...中文乱码终端编码不一致Windows 执行chcp 65001或代码头部加# -*- coding: utf-8 -*-7. 环境管理的长期建议7.1 从 requirements.txt 到 pyproject.toml前面我用pip freeze导出requirements.txt这对个人项目和小组协作完全够用。但如果你在一个更规范的项目里待过可能会遇到团队使用 Poetry 或 PDM 这类工具。它们会在pyproject.toml里同时管理“直接依赖”和“传递依赖”并且构建一个lock文件保证每个成员安装的版本精确一致。我的建议是不要急着上复杂度。先用好requirements.txt理解“锁定版本”这件事的意义。等哪天真觉得依赖管理限制了你的工作流比如你需要在多个环境中快速切换、要发布测试工具包再主动迁移到 Poetry。学习工具永远比理解原理容易先理解原理更重要。7.2 首次搭建后做一次环境自检环境搭好之后我建议你花一分钟做一次“自检”确认各个环节都真的可用。在虚拟环境里依次执行python --version pip --version pytest --version python -c import requests; print(requests.__version__) python -c import selenium; print(selenium.__version__)每一条都应该正常输出版本号而不是报错。把这段命令存成check_env.sh或check_env.bat以后换机器、换环境跑一遍就能判断环境是否健康。这个习惯能帮你省掉大量定位“到底是环境问题还是代码问题”的时间。7.3 接上持续集成环境搭建才算闭环本地环境跑通只是第一步。真正让自动化测试价值最大化的是把它接入持续集成CI比如在 GitHub Actions、GitLab CI 或 Jenkins 上每次代码提交后自动创建虚拟环境、安装依赖、执行用例、生成报告并归档。CI 环境是全新机器它没有你的手动配置没有 IDE 的隐藏依赖所以只要能在一台干净机器上完整跑通你的环境搭建方案才是真正可靠、可复用的。这一步的收益很大本地因为各种历史残留导致的环境差异会被抹平团队所有人共享同一套测试结果回归效率明显提升。如果你刚起步可以从 GitHub Actions 的ubuntu-latest开始一个很小的.yml文件就能完成。环境的重复搭建能力才是自动化测试工程化的底气。我个人在实际操作中最大的感受是很多人遇到环境问题第一反应是“重新装一下”这其实是在赌运气。真正有效的方法是把环境搭建的每一个环节都变成显式的、可复现的配置Python 版本写清楚、依赖清单固定、虚拟环境隔离、驱动自动管理、配置文件入库。做到这几点之后自动化测试环境就不再是玄学而是一个随时可以从零重建的工程资产。希望这篇里的实操路径和踩坑记录能帮你少走一点弯路。