2.3 环境搭建实战：从装环境到跑通第一条脚本

2.3 环境搭建实战：从装环境到跑通第一条脚本

本节摘要：环境搭建的本质是让三样东西持续匹配——语言绑定库、浏览器驱动、浏览器本体，前三步装齐它们，第四步用一条冒烟脚本验证全链路。本节给出一份从零到跑通的可复制清单：虚拟环境隔离、依赖安装、驱动自动管理、无头模式与窗口尺寸设置，以及流水线环境的差异点。前三节建立的是架构认知，本节把它兑换成你手里一台能跑的机器。

从零到第一条绿字：四步走

新成员入职第一天拿到一个自动化仓库，最常见的体验不是写用例难，而是环境半天起不来：依赖版本打架、驱动对不上浏览器、代理拦住了驱动下载。本节按"四步走"组织，每步的产出都可验证，走完四步你就拥有一个可以提交代码的可用环境。顺手记下这张工单的预防条款：环境问题要有清单化的解法，而不是口口相传的玄学。

第一步：隔离的运行环境

自动化脚本依赖一堆三方库，绝不要直接装进系统 Python——项目 A 要的版本和项目 B 冲突是迟早的事。用虚拟环境把每个项目圈在自己的地盘里：

python -m venv .venv
source .venv/bin/activate      # Windows 下为 .venv\Scripts\activate
python -m pip install -U pip
​

激活后命令行提示符前会出现环境名，此时安装的任何包都只属于这个项目。团队协作时，把依赖清单固化成文件并进仓库，新人一条命令还原环境：

pip install selenium pytest
pip freeze > requirements.txt
​

这里埋着第二个坑：清单里只写顶层依赖是不够的，pip freeze 会把间接依赖全部钉死版本。钉版本对复现是好事，但记得定期升级——Selenium 大版本落后太多，会与新浏览器协议脱节。

第二步与第三步：绑定库与驱动的自动管理

pip install selenium 装好的是客户端层（2.1 的第一层）。第二层的浏览器驱动，过去是环境搭建的头号劝退点：手动下载驱动、对版本、配环境变量，三步任何一步错都报"会话未创建"。从 Selenium 4.6 起内置了驱动管理能力，它会自动探测本机浏览器版本、下载匹配的驱动并缓存复用：

from selenium import webdriver

driver = webdriver.Chrome()          # 4.6+ 自动解析并获取匹配驱动
print("浏览器版本:", driver.capabilities["browserVersion"])
print("驱动版本:", driver.capabilities["chrome"]["chromedriverVersion"])
driver.quit()
​

两行打印不是摆设，它是环境自检的核心动作：把"实际生效的版本"打印出来对齐认知，能提前拦截九成的版本错配工单。某些内网环境拦住了驱动下载通道，此时需要配置镜像地址或人工放置驱动并指定路径——但这是受控的例外，不要把它当成默认做法。

第四步：冒烟脚本与无头模式

环境验证不追求覆盖业务，只追求打通全链路：启动浏览器、打开一个稳定页面、断言一个必然存在的元素、退出。下面这个冒烟脚本建议原样放进每个自动化仓库：

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait

def test_smoke():
    options = webdriver.ChromeOptions()
    options.add_argument("--headless=new")          # 无界面运行
    options.add_argument("--window-size=1920,1080") # 固定视口，避免布局差异
    options.add_argument("--disable-gpu")
    driver = webdriver.Chrome(options=options)
    try:
        driver.get("https://www.example.com")
        h1 = WebDriverWait(driver, 10).until(
            lambda d: d.find_element(By.TAG_NAME, "h1"))
        assert h1.text.strip(), "页面标题元素为空，页面可能未正常加载"
    finally:
        driver.quit()                               # 必须退出，防止进程残留
​

三个设置各有讲究。无头模式让浏览器不渲染界面，流水线机器没有显示器也能跑，速度快、资源省；固定窗口尺寸是为了消除视口差异——响应式页面在不同视口下布局不同，不固定尺寸会出现"本地过、流水线挂"的灵异工单；finally 里的退出是纪律：会话不销毁，进程就残留，流水线节点会被一点点吃光内存。至于那个 WebDriverWait，本节只需照写，它的机制是下一章 3.3 的主角。

流水线环境还有两处差异要预留：一是根目录权限，容器里以非 root 用户跑 Chrome 需要额外的启动参数；二是字体与渲染库缺失，会导致截图乱码而非功能失败。第 6 章 6.3 讲容器化时会给出完整的镜像方案，本节先记住差异点清单。

常见报错速查

这张表按 2.2 的归层直觉组织。环境类故障的排查纪律是：先打印版本对齐认知，再看报错文案归层，最后才动手改配置——顺序反了就是在用试错代替诊断。

两个高频追问

问：能不能不装浏览器驱动，直接让脚本控制浏览器？ 不能跳过驱动这一层，但可以不让"你"来管它——4.6 起的自动管理机制就是干这个的。需要人工干预只剩两种场景：内网阻断了驱动下载通道，或使用了小众浏览器内核。前者配镜像或人工放置驱动，后者查该内核的驱动文档。

问：冒烟脚本该多久跑一次？ 每次环境变更（升级浏览器、更新依赖、换机器）后必跑；日常开发里，也可以把它作为每天开工的第一条命令——三十秒确认"今天的环境是好的"，比写了一下午才发现环境坏了划算得多。

收工清单

• 环境三匹配：绑定库、驱动、浏览器本体；4.6 起驱动管理自动化，手动配驱动的时代结束了。
• 四步清单：虚拟环境、装绑定库、驱动自管、冒烟验证；每步有可验证产出。
• 冒烟三件套：无头模式、固定视口、finally 退出——分别消灭三类灵异工单。
• 版本自检动作：打印实际生效的版本号，比"我装过了"可靠得多。
• 流水线差异：容器权限与字体渲染是两大预留项，完整方案见第 6 章。

环境跑通，机器在手。下一章进入自动化测试真正的心脏地带：元素定位与等待——那是工单簿里最厚的一沓。