浏览器操作演示 · Cookie操作

管理Cookie参数

首页浏览器操作导航

本页说明 —— Cookie 增删改查

演示 Selenium 的 Cookie 增删改查四个核心操作，这是自动化测试和爬虫中"登录状态保持""记住我"的实现基础。

HTTP 协议本身是无状态的——服务器不知道"刚才请求的是谁"。Cookie 就是服务器塞给浏览器的一张"身份证"（sessionid / token），下次请求自动带上，服务器一看就知道你是谁。

🎯 实战场景：

测试用例加速：20 个测试用例不用每个都走一遍登录流程（填表单 → 点按钮 → 等跳转），首次登录后 get_cookies() 存下来，后续用例 add_cookie() 还原，直接跳过登录页
爬虫登录保持：第一次正常登录拿到 Cookie 存 JSON 文件，脚本重启时先还原 Cookie 再访问目标页面，服务器以为你还是那个已登录的用户
多账号切换：不同账号的 Cookie 存在不同文件，测试时动态切换 delete_all_cookies() → 载入另一套 → 刷新

⚠️ 前提：必须先 driver.get(域名) 才能操作该域名 Cookie！Selenium 不允许跨域操作 Cookie。

7 个 Cookie 字段：

name / value → 必填，Cookie 的 key-value
path → 默认 /，限定哪些路径下浏览器会自动带这个 Cookie
domain → 一般不用写，Selenium 自动设为当前域名
expiry → Unix 时间戳（秒），到期自动删除
secure → True 则只有 HTTPS 请求才会带
httpOnly → True 则 JS document.cookie 读不到，防 XSS

💡 实战套路：第一次正常登录 → get_cookies() 存 JSON → 下次新浏览器 → 读 JSON → 先 get 域名 → add_cookie() 逐条还原 → 刷新页面，直接跳过登录！

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 秒+	爆炸	❌ 绝对避免

本页说明 —— Cookie 增删改查

Cookie 增删改查

关于我们

联系方式

免责声明