第2章 架构与环境搭建

第2章 · 架构与环境搭建

本章要回答的三个问题：你的脚本发出"点击"这个指令后，它是经过哪些环节才落到页面上的？驱动、浏览器、会话这三个词到底各自指什么，版本不匹配为什么会炸？新机器上怎么把环境一次搭对、把第一条脚本跑通？回答完这三问，Selenium 对你来说就不再是"一个 import 进来的库"，而是一条看得见每个环节的指令流水线。

为什么会有这一章

用过一次 Selenium 的人都会写 driver.get 与 find_element，但大多数翻车工单的根因恰恰藏在"大多数人没看过"的那段路里。脚本报"无法解析远程主机"时，你该查网络还是查驱动？报"会话未创建"时，你该升级驱动还是降级浏览器？不本地启动会话与会话复用在资源上差多少？这些问题没有一个能靠背 API 回答，全都要靠架构认知。

还有一类更隐蔽的账：很多团队以为自动化环境是"装一次就完事"的东西，结果每换一台流水线节点都要踩一遍坑。环境的本质是三样东西的持续匹配——语言绑定库、浏览器驱动、浏览器本体。这三者的关系在上一章的演化史里已经埋了伏笔，本章把它们彻底讲透，然后一次性解决环境问题。

读完能解决什么

读完本章，你应当能拿着报错信息对号入座：分辨故障出在客户端层、协议层还是浏览器端层；说清楚一次会话从创建到销毁的完整生命周期，以及窗口句柄、元素引用这些"对象"活在哪一层；独立完成一套可复制到流水线的环境搭建——包括用驱动管理工具自动匹配版本、用无头模式压低资源占用、用第一个脚本验证全链路。这三样能力分别对应本章三节，也是后续六章每一次动手前的隐含前提。

各节怎么分工

三节是一条从抽象到具体的斜坡：2.1 立架构框架，2.2 让框架动起来（跟踪一次真实点击的全程），2.3 把认知兑换成一台能跑的机器。建议按顺序读，因为 2.2 的时序分析完全建立在 2.1 的分层词汇上。

这张会话生命周期图值得贴在工位上：第 7 章讲失败取证时，所有异常处理策略本质上都是在回答"异常之后，会话该回就绪还是直接销毁"。现在先记住主线——创建、就绪、执行、销毁，异常只是执行态的岔路。

常见疑问

问：环境搭建这节能不能跳过，直接用团队现成的环境？ 可以先用现成环境学第 3 章，但独立搭一遍的价值在于：环境是自动化工程师的"地基作业"，第 6 章的容器化与流水线环境都会回到这里的概念——没亲手搭过的人，排查环境类工单时缺少那层体感。

问：三层架构会不会讲得太深，写用例用不上？ 恰恰相反——本册后续每一章都在用这套词汇：3.2 的排错按层分流，6.3 的容器按层钉版本，7.2 的取证按层采集。架构认知不是炫技，是排错与沟通的通用语言。

问：为什么示例选 Python，换 Java 思路一样吗？ 一样。协议层完全一致，差异只在绑定库的写法习惯——夹具机制、断言风格在 JUnit 或 TestNG 里有对应物。本书选择 Python 是为了把篇幅留给机制而不是语法。

常见疑问

问：为什么把"跑通第一个脚本"放进架构章而不是开篇第 1 章？ 因为不理解链路就动手，遇到第一个报错就会卡死；先有 2.1 与 2.2 的地图，2.3 的每一步配置都变成"知道自己在改什么"。顺序即是这本工单簿的态度：先懂再修，不靠蒙。

先决条件

本章需要你手里有一台能装软件的开发机（Windows、macOS 或 Linux 均可），装有一个主流浏览器，并对命令行有最基础的使用经验。2.3 节会用到 Python 环境管理的基础操作：创建虚拟环境、用包管理器安装依赖。如果你常年用 Java 技术栈，概念完全同构，示例换成对应语言的绑定即可。

往下走到哪

环境跑通的那一刻，你会很想立刻写一堆用例——先忍住。没有定位与等待的认知打底，写出来的用例只会变成第 3 章开头那张工单的批量生产机。下一章我们直奔自动化测试的心脏：元素怎么找、什么时候算就绪、交互怎么做。