浏览器操作演示 · 打开关闭

打开与关闭页面

首页浏览器操作导航

本页说明 —— 打开 / 关闭页面

演示浏览器生命周期管理的 三个核心动作：启动 → 打开页面 → 关闭/退出。看似简单，但多标签、异常中断等场景下有诸多细节。

三个 API 的区别：

🚀 driver.get(url)：会阻塞，直到浏览器 load 事件触发才返回——此时 HTML 解析完成

🔀 浏览器渲染流水线

从网络请求到 window.load 的 6 步关键节点

1

网络请求

服务器返回 HTML 文件的字节流

2

HTML 解析（parser 逐字节读）

<html> <head> <title> <body> <h1> 逐个读入

3

构建 DOM 树

<h1>标题</h1> → DOM 里多了一个 h1 节点
<img src="a.jpg"> → DOM 里多了一个 img 节点

4

触发 DOMContentLoaded ← 这就是"HTML 解析完成"

浏览器读完了整个 HTML 文件，DOM 树构建完毕

5

继续下载外部资源（img / iframe / CSS）

图片还在路上，iframe 子页面还没下载完

6

触发 window.load ← driver.get() 等的就是这个

所有声明式资源也下载完了

💡 driver.get() 在第 6 步才返回，不会等 fetch/AJAX、框架渲染、懒加载资源

（浏览器读完整个 HTML 文件、DOM 树构建好，对应 DOMContentLoaded 事件）+ 所有声明式资源（指 HTML 源码中静态声明的外部资源——浏览器解析 HTML 时自动发现标签里的 src/href 并发起请求，包括：<img src="..."> 图片、<iframe src="..."> 子页面、<link href="..."> CSS、<script src="..."> 同步 JS、<video src="...">/<audio src="..."> 媒体文件）加载完毕。注意它等的是 window.load 而非 DOMContentLoaded。⚠️ 关键盲区：driver.get() 不等异步加载！
```
时间线：
  0ms    HTML 开始解析
  500ms  DOMContentLoaded 触发（HTML 解析完，图片还在下）
  1500ms window.load 触发 ← driver.get() 在这里返回
  1600ms JS 发 fetch('/api/list')     ← 异步请求，get() 没等
  2000ms fetch 返回，React 渲染列表   ← 动态 DOM，get() 没等
  2500ms 列表渲染完成                  ← 需用 WebDriverWait 等待！
```
load 事件不包含：fetch/AJAX 异步请求、React/Vue/Angular 框架渲染、懒加载（loading="lazy"）、SPA 客户端路由跳转、setTimeout 定时器逻辑。driver.get() 返回后页面上的元素可能还没出现，必须用显式等待补位。
❌ driver.close()：只关当前标签，其他标签继续，driver 仍可用
💀 driver.quit()：关掉所有标签 + 杀掉 chromedriver 进程，driver 不可再用

⚠️ 重要提醒：脚本里忘了写 driver.quit()，任务管理器会残留 chromedriver 进程，长期积累会吃光内存。建议用 try/finally 保证无论成功失败都执行 quit()。

页面访问

打开 / 关闭页面

get / close / quit / 页面生命周期

页面的打开与关闭
浏览器自动化的第一步就是"打开目标页面"，最后一步是"关闭浏览器"。Selenium 提供了 get、close、quit 三个 API 覆盖完整生命周期。

核心区别： get() 打开页面（导航） close() 关当前页签 quit() 退整个浏览器

⚠️ 常见坑： close() 不关浏览器进程，多标签场景下别用它收尾 | quit() 测试结束务必调用，否则残留进程会吃内存

对应 API：
driver.get("https://xxx") 打开指定网址（https://autotest-505.pages.dev/，点击网址在同一浏览器窗口打开新标签页）
driver.close() 关闭当前页签
driver.quit() 退出整个浏览器（所有页签）

AutoTest - 首页

Home Setup Locator Action

欢迎来到自动化测试练习平台

这是一个模拟的首页内容，用于演示 driver.get() 打开页面的效果。实际项目中这里会显示完整的首页。

🎯 元素定位

9 种定位方式从入门到精通

🖱️ 元素操作

点击/输入/等待/拖拽全场景

🧪 测试框架

unittest / pytest 实战演练

当前页签已被 driver.close() 关闭

Python Selenium · 打开与关闭浏览器完整示例

# ① 启动 Chrome 浏览器
from selenium import webdriver
from selenium.webdriver.common.by import By
import psutil, time   # 进程对比用，需先 pip install psutil

# 采集 chrome / chromedriver 进程 PID 集合的辅助函数
def procs():
    return {p.pid for p in psutil.process_iter(["name"])
            if p.info["name"] in ("chrome.exe", "chromedriver.exe")}

_pids = procs()   # 启动前基线，排除你自己开着的 Chrome
driver = webdriver.Chrome()

# ② 打开演示页面（此时只有这一个标签页）
driver.get("https://autotest-505.pages.dev/browser_op_tech_sections/open_close_tech.html")
print("启动后新增进程：", procs() - _pids)   # chromedriver.exe + 若干 chrome.exe

# ③ 点击“对应 API”区域中的 https://autotest-505.pages.dev/ 链接
#    该链接 target="_blank"，点击后会在【同一浏览器窗口】里新开一个标签页
#    注意：点击后 driver 的焦点仍停留在原标签页，这里不做标签页切换
driver.find_element(By.CSS_SELECTOR,
                    'a[href="https://autotest-505.pages.dev/"]').click()
time.sleep(1)   # 等新标签页进程稳定
print("点击后新增进程：", procs() - _pids)   # 新标签页触发 Chrome 多进程架构创建渲染进程（也可能复用）

# ④ close()：只关闭 driver 当前所在标签页，另一个不受影响；用 3 个信号对比（和 quit 后三行完全镜像）
driver.close()
print("close 后残留进程：", procs() - _pids)                     # 非空集合：chrome/chromedriver 都还活着
print("chromedriver 进程状态：", driver.service.process.poll())  # None：进程仍在运行（未退出）
print("驱动还能连接吗：", driver.service.is_connectable())     # True：会话仍存活

# ⑤ quit()：关闭所有剩余标签页并退出浏览器进程（无需先切换标签）；用 3 个确定性信号佐证
driver.quit()
time.sleep(1)   # 等系统回收进程
print("quit 后残留进程：", procs() - _pids)                    # set()：chrome/chromedriver 全部退出
print("chromedriver 退出码：", driver.service.process.poll())  # 0：驱动进程已正常结束
print("驱动还能连接吗：", driver.service.is_connectable())     # False：driver 已释放
# 注意：Selenium 4 的 quit() 不会把 driver.session_id 置空，不要用它判断会话是否结束

操作效果展示区域

点击上方按钮，这里会显示 Selenium API 执行结果和关键数据

CI/CD：自动化测试的真实运行环境

CI/CD 是什么？

● CI = Continuous Integration（持续集成）
代码推送到 Git 仓库后，自动拉代码 → 装依赖 → 跑测试，每次 push 都帮你检查有没有问题。

● CD = Continuous Delivery（持续交付）
CI 通过后自动打包 → 发到服务器 → 重启，不用手动部署。
（另一种 Continuous Deployment 是全自动部署到生产，不用人审批）

CI/CD 完整流水线

你写了一行代码 → git push origin main
↓
GitHub（或 GitLab / Jenkins / Gitee）收到推送
↓
自动触发一条 Pipeline（流水线）

        ① Checkout（拉代码）

        把你刚推的代码拉到一台全新的云服务器上
        
↓

        ② Install（装依赖）

        pip install -r requirements.txt

        装 Chrome、装 ChromeDriver
        
↓

        ③ Build（构建）

        打包成可部署的产物（.tar.gz / Docker 镜像 / ...）
        
↓

        ④ Test（跑测试）

        pytest unit_tests/　　# 单元测试

        pytest selenium_tests/　# ⬅️ Selenium 在这里上场！

        代码覆盖率检查 · 代码风格检查
        
↓

        全部通过？

        ╱　　　　╲

        是　　　　否

        ↓　　　　↓
        
        ⑤ Deploy

        自动发到服务器

        生产环境立刻更新
        
        ❌ 失败

        发邮件/钉钉通知你

        修复 → 重新 push

Selenium 在 CI/CD 里扮演什么角色？
Selenium 测试脚本是流水线 第 ④ 阶段（Test） 的核心。CI 服务器会：
1. 在全新的云服务器上装 Python + Chrome + ChromeDriver
2. 以 headless（无头）模式启动 Chrome（没有 GUI，更快但渲染行为和本地略有差异）
3. 运行你的 pytest + Selenium 脚本，模拟真实用户操作（登录、搜索、下单...）
4. 全部通过才允许部署到生产；任何一步失败 → 发邮件通知 → 生产不会被污染

核心好处：每次代码合进来都有 Selenium 帮你模拟真实用户过一遍关键路径，而不是等到用户反馈"登录不了了"。

为什么 CI/CD 上 sleep 特别容易崩？
CI 环境每次都是全新的云服务器，和本地有几个关键差异：

因素	本地	CI/CD 云服务器
网络	专线稳定	数据中心共享，偶发抖动
CPU	独占	多租户，可能被抢占
浏览器缓存	有	没有（每次全新启动）
页面加载速度	有缓存，秒出	全量下载，慢 2~5 倍
并发任务	只跑你这一份	可能几十上百个同时抢资源

同样的 sleep(3)：
本地：按钮 2s 出来 → sleep 3s → 白等 1s 但能过 ✅
CI 上：按钮 6s 出来 → sleep 3s 已经过了 → find_element 找不着 → 💥

这就是为什么说 CI/CD 上尤其不稳定 —— CI 是一台你控制不了但天天要给你打分的云电脑，每次环境都不一样。
而 WebDriverWait 是"等条件满足就行，最多等 10s 上限" —— 对 CI 环境的波动天然免疫。

为什么推荐 ≤1s

📌 隐式等待超时值的语义（W3C 规范定义）
隐式等待的"兜底窗口"即 implicitly_wait(N) 所设置的 N 值本身，此结论直接来自 W3C WebDriver 规范：

"A session has an associated session implicit wait timeout that specifies a time to wait for the implicit element location strategy"
→ 驱动在一次 findElement / findElements 调用中，最多愿意等待的总时间即为该值，不得超时。

implicit=0.5s → 驱动最多等待 500ms 后必须放弃
implicit=1.0s → 驱动最多等待 1000ms 后必须放弃
implicit=0 → 驱动立即执行一次查询，不进行重试（默认值）

以上定义为 W3C 规范层面的硬约束，与驱动实现无关，是选择 implicit 值、计算叠加成本、规划白等上限的直接依据。

🔍 驱动内部轮询机制——规范未作规定
W3C 规范对隐式等待仅定义了超时值的语义（见上文），对驱动内部的轮询实现细节完全未做约束。具体而言，规范未规定：

两次查询之间的时间间隔
查询失败后采用阻塞等待（sleep）还是事件驱动（DOM mutation observer）
查询的最大次数（仅约束总耗时不得超过超时值）

以 ChromeDriver 为例，可通过让元素延迟插入 DOM、记录 find_element 实际耗时的方法进行观测：在常规负载下元素出现后约 50~70ms 内即可被查到；若同一驱动连续处理多次请求，该值可能飘至 200ms 以上。换驱动版本或换机器，结果也可能不同。

🔧 实测代码（可自行跑一遍验证你的驱动）

原理：让元素在指定延迟后才插入 DOM，调用 find_element 记录实际耗时。耗时减去延迟得到"元素出现后驱动最晚多久查到"。
延迟点密集覆盖 10~1500ms，跑一轮后取差值区间的上界，即为该驱动在当前负载下的轮询间隔量级。
同一驱动连续处理多次查找请求，若差值区间明显漂移，说明驱动的轮询节奏已不稳定。

from selenium import webdriver
from selenium.webdriver.common.by import By
import time

def test_polling(d, delay):
    d.implicitly_wait(2)
    d.get('about:blank')
    d.execute_script(f"setTimeout(()=>{{document.body.innerHTML='t'}},{delay})")
    t0 = time.perf_counter()
    try:
        cost = (time.perf_counter() - t0) * 1000
        print(f"delay={delay:4d}  耗时={cost:6.0f}  差值={cost-delay:+5.0f}")
    except: print(f"delay={delay}  超时")

driver = webdriver.Chrome()
for delay in range(10, 1550, 50):   # 50ms 步进，覆盖 10~1500ms
    test_polling(driver, delay)
driver.quit()

⚖️ 那 ≤1s 怎么选出来的？—— 经验 + 权衡
经验观察
竞态（race condition，脚本发起 find_element 的时刻与元素实际出现于 DOM 的时刻之间的竞态）通常差 200~500ms：

JS 框架 mount + 首屏 DOM 渲染 ≈ 200~800ms
浏览器微任务调度延迟 ≈ 几毫秒 → 主线程阻塞时可达几百毫秒
CSS transition 触发后元素从 hidden → visible ≈ 0~300ms
页面跳转后 DOM 重建的时间差 ≈ 50~300ms

注：以上是前端性能的普遍经验数字，不是数学公式，极端场景可能超出范围。

权衡一：为什么选 1s 而不是 0.5s？
500~1000ms 是 0.5s 和 1.0s 的兜底能力分水岭：
低于 500ms 两者都能兜；高于 1000ms 两者都兜不住（该用显式等待）；
只有在 500~1000ms 之间，1.0s 比 0.5s 多出了实际价值：

设 0.5s：竞态时间差 700ms → 兜底窗口只有 500ms，已经超时 → 抛异常 ❌
设 1.0s：竞态时间差 700ms → 兜底窗口 1000ms，还没超时 → 兜底成功 ✅

代价对比（和显式等待 explicit=15s 混用时）：
0.5s 叠加成本 = 0.5 × 30 = 15 秒　
1.0s 叠加成本 = 1.0 × 30 = 30 秒（多 15 秒）

→ 多花 15 秒叠加成本，换 500~1000ms 档竞态（race condition）的兜底覆盖。这是一个合理的折中，不是数学必然。

权衡二：为什么不设 2s？
2s 的兜底窗口确实更大，但代价全部翻倍，而兜底提升边际效益递减：

① 叠加变长成本：和显式等待混用时的最坏耗时公式：
最坏 = implicit × (explicit超时 / pollFreq)
注：这里的 pollFreq 是 显式等待 WebDriverWait 的 poll_frequency（Selenium Python 客户端默认 500ms，硬编码在 wait.py 里），不是隐式等待的轮询间隔。这个值是确定的。

假设 explicit=15s、pollFreq=0.5s：
implicit=1s → 1 × 30 = 30 秒　✅ 可接受
implicit=2s → 2 × 30 = 60 秒　⚠️ 翻倍（多 30 秒，兜底窗口只多 1000ms）
implicit=5s → 5 × 30 = 150 秒　💀 爆炸

② "确认元素不存在"的白等：你写了 10 个 try: find_element ... except NoSuchElementException：
implicit=1s → 白等 10 秒
implicit=2s → 白等 20 秒（翻倍）
implicit=5s → 白等 50 秒（爆炸）

竞态（race condition）通常差 200~500ms，1s 的兜底窗口完全兜得住绝大多数。
从 1s 升到 2s，兜底窗口只多了 1000ms，但叠加成本和白等全部翻倍——边际效益递减太明显。

✅ 最终结论

值	兜底窗口 (规范定义)	叠加成本 explicit=15s	白等 10次不存在	依据类型	推荐
不设（=0）	0ms	0 秒	0 秒	规范	最严谨
1s	1000ms	30 秒	10 秒	经验+权衡	默认推荐
0.5s	500ms	15 秒	5 秒	经验+权衡	确认页面 <500ms
2s	2000ms	60 秒	20 秒	代价太大	谨慎
≥5s	≥5000ms	150 秒+	50 秒+	爆炸	❌ 绝对避免

本页说明 —— 打开 / 关闭页面

打开 / 关闭页面

欢迎来到自动化测试练习平台

关于我们

联系方式

免责声明