浏览器操作演示 · 窗口控制

控制窗口大小与位置

首页浏览器操作导航

本页说明 —— 窗口控制

演示浏览器窗口的 位置、尺寸、显示状态 全维度控制。Selenium 4 新增的 set_window_rect() 将 size + position 两步操作合并为一个原子方法，是窗口控制的首选 API。

核心 API 对比：

maximize_window() → 拉满屏幕（含地址栏标签栏），不是全屏
minimize_window() → 缩到任务栏，Chrome 才支持
fullscreen_window() → F11 全屏，地址栏标签栏都隐藏
set_window_size(w,h) / set_window_position(x,y) → Selenium 3 风格，两次调用会有闪烁
set_window_rect(x,y,w,h) → Selenium 4 原子操作，一次调用改位置+尺寸，无闪烁

💡 进阶技巧：可以先用 get_window_rect() 存快照，跑测试，结束后用 set_window_rect(**saved) 一键恢复（Python dict 解包）。

窗口控制

maximize_window / minimize_window / set_window_size / set_window_position / set_window_rect

窗口的大小与位置
Selenium 可以精确控制浏览器窗口在屏幕上的尺寸和坐标，满足不同测试场景需求：从"全屏铺满"到"自定义 800×600 放在屏幕中央"，甚至拖到指定位置。

应用场景： 最大化：消除浏览器边框干扰自定义尺寸：测试不同分辨率 UI 多窗口排列：并行测试对比

⚠️ 常见坑： maximize 和 fullscreen 不一样：前者保留任务栏，后者 F11 沉浸式 | set_window_rect 是 Selenium 4 新增，一次搞定尺寸+位置

对应 API：
driver.maximize_window() 最大化窗口
driver.minimize_window() 最小化窗口
driver.fullscreen_window() 全屏（F11）
driver.set_window_size(w, h) 设置尺寸
driver.set_window_position(x, y) 设置位置
driver.set_window_rect(x, y, width, height) 同时设置尺寸和位置
driver.get_window_size() 获取尺寸，返回 {'width':w, 'height':h}
driver.get_window_position() 获取左上角坐标

窗口宽度

窗口高度

（浏览器内部视口大小，练习 Selenium 中 window_size API）

按 ESC 或点击退出全屏

chrome://newtab

欢迎来到 AutoTest

Selenium 自动化测试练习平台

🎯

🖱️

🧪

📊

⊞

AutoTest Chrome

--:--

1024 × 768

自定义窗口尺寸 / 位置

宽度 (w) 高度 (h) 左上角 X 左上角 Y

Python Selenium · 窗口控制完整示例

# ① 启动浏览器并打开窗口控制演示页
from selenium import webdriver

driver = webdriver.Chrome()
driver.get("https://autotest-505.pages.dev/browser_op_tech_sections/window_control_tech.html")

# ② 设置 / 获取窗口尺寸（单位：像素）
driver.set_window_size(1024, 768)
print(driver.get_window_size())        # {'width': 1024, 'height': 768}

# ③ 设置 / 获取窗口位置（相对屏幕左上角）
driver.set_window_position(100, 50)
print(driver.get_window_position())    # {'x': 100, 'y': 50}

# ④ 一次设置 x / y / width / height
driver.set_window_rect(x=0, y=0, width=1280, height=800)

# ⑤ 最大化 / 最小化 / 全屏（等同 F11）
driver.maximize_window()
driver.minimize_window()
driver.fullscreen_window()

# ⑥ 结束会话
driver.quit()

操作效果展示区域

点击上方按钮，这里会显示 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 秒+	爆炸	❌ 绝对避免

本页说明 —— 窗口控制

窗口控制

欢迎来到 AutoTest

关于我们

联系方式

免责声明