浏览器操作演示 · 截图保存

获取页面截图

首页 浏览器操作导航
浏览器操作练习
参数配置练习 打开关闭练习 页面导航练习 窗口控制练习 页面信息练习 元素交互练习 Cookie操作练习 截图保存练习 超时等待练习
浏览器操作作业
参数配置作业 打开关闭作业 页面导航作业 窗口控制作业 页面信息作业 元素交互作业 Cookie操作作业 截图保存作业 超时等待作业

本页说明 —— 截图保存

演示 Selenium 截图的 3 类 API + 1 个 Selenium 4 新功能，自动化测试排查失败现场的必备技能。

截图方式对比：

⚠️ 关键限制：Selenium 默认只能截 视口（屏幕可见区域）。要截整页需用 CDP：
driver.execute_cdp_cmd("Page.captureScreenshot", {"captureBeyondViewport": True})

💡 实战套路：把截图写进 except 块，测试失败自动截图 + 文件名带时间戳，CI 环境里排查失败原因一眼看到。

截图操作

截图保存

save_screenshot / get_screenshot_as_file / 元素截图
为什么需要截图？
自动化测试中，截图是"留证据"的关键手段。测试执行完毕后（尤其是失败时），一张截图可以让你直观地看到当时页面长什么样，是调试和报告的核心素材。
常见用途： 测试失败自动截图 视觉回归对比 登录验证留档
5 种截图 API 对比
API 截图范围 返回值 写到文件？ 适用场景
driver.save_screenshot("a.png")视口True/False✅ 是最常用，直接存本地
driver.get_screenshot_as_file("a.png")视口True/False✅ 是同 save_screenshot，API 更冗长（遗留）
driver.get_screenshot_as_base64()视口base64 str❌ 否嵌入 Allure/pytest-html 报告
driver.get_screenshot_as_png()视口bytes 二进制❌ 否内存处理，上传 OCR/AI
element.screenshot("a.png")元素True/False✅ 是只截某个元素（Selenium 4+）
选型速查： 存本地 → save_screenshot | 嵌入 HTML → get_screenshot_as_base64 | 上传 AI → get_screenshot_as_png | 只截按钮/验证码 → element.screenshot
⚠️ 重要认知：所有 driver 级截图都是视口截图（viewport），只截取当前视口的浏览器内容可见区域，不会自动滚动去截上下方的内容！
要实现"全页截图"需额外手段：headless Chrome + --full-page-screenshot、selenium-screenshot 库、或 JS 滚动拼接。
截图演示区
新标签页
https://demo.autotest.com/index.html
🏠 自动化测试首页
欢迎来到练习平台
📦 功能模块 A
视口可见
📦 功能模块 B
需滚动才看到
📦 功能模块 C
需滚动才看到
📦 功能模块 D
需滚动才看到
📦 功能模块 E
需滚动才看到
⊞
AutoTest Chrome
280 × 190
5 种截图 API · 点击演示
前 4 种 driver 级 API 截图区域完全相同（浏览器 视口，不含标题栏/地址栏），区别只在返回值类型和是否写文件。
第 5 种 element.screenshot 只截指定元素（按钮/验证码等），Selenium 4+ 支持。
save_screenshot
视口保存到文件（最常用）
get_screenshot_as_file
视口写文件（遗留 API）
get_screenshot_as_base64
视口截图 → base64 字符串
get_screenshot_as_png
视口截图 → PNG bytes
element.screenshot
只截某个元素（Selenium 4+）
点击上方 5 种 API 卡片，这里会生成真实的 Canvas 截图缩略图
Python Selenium · 截图保存完整示例 
# ① 启动浏览器并打开截图演示页
from selenium import webdriver
from selenium.webdriver.common.by import By

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

# ② 整页（视口）截图保存为文件，成功返回 True
print(driver.save_screenshot("full.png"))
driver.get_screenshot_as_file("full2.png")          # 等价写法

# ③ 截图为 base64 字符串，适合直接嵌入 HTML 测试报告
b64 = driver.get_screenshot_as_base64()

# ④ 截图为 PNG 二进制 bytes，可在内存中处理或上传到服务器
png_data = driver.get_screenshot_as_png()
with open("from_bytes.png", "wb") as f:
    f.write(png_data)

# ⑤ 只截取单个元素（Selenium 4+，id 与本演示页按钮一致）
btn = driver.find_element(By.ID, "shotBtnElement")
btn.screenshot("element.png")

driver.quit()
操作效果展示区域
点击上方按钮，这里会显示 Selenium API 执行结果和关键数据

关于我们

Python 自动化测试学习平台是一个面向软件测试工程师、开发人员及在校学生的交互式在线学习平台，专注于 Selenium WebDriver 与 Python unittest 自动化测试技能的教学与实践。

我们以"理论 + 实战 + 可交互演示"为核心特色，将八种常规元素定位和Javascript定位、元素操作、自动化测试工具、单元测试、测试模型等知识体系拆分为模块化课程，每个模块都配有可点击、可输入、可运行的模拟练习页面。

平台致力于降低自动化测试的入门门槛，让学习者从"看懂代码"到"动手实操"，逐步掌握企业级自动化测试框架的设计与落地能力。

联系方式

📧邮箱：lq@selenium-auto-test.com

📞电话：0755-12345678

📍地址：深圳

💬微信公众号：Selenium自动化测试

🐙GitHub：github.com/selenium-auto-test

免责声明

1. 本平台所有示例代码、演示页面及教程内容均仅供学习交流使用，不构成任何商业推广或技术服务承诺。

2. 平台中的 Selenium API 描述、Python 语法说明均以官方文档为准，如有版本差异请以对应官方文档为准。

3. 学习者在实际项目中应用平台所学内容时，应结合自身项目环境进行充分测试，本平台不对因直接使用示例代码而产生的任何直接或间接损失承担责任。

4. 本平台所引用的第三方库（Selenium、ChromeDriver、unittest 等）版权归其各自作者及维护者所有。

5. 如涉及版权问题或内容建议，请及时通过联系方式与我们沟通，我们将第一时间处理。

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 规范对隐式等待仅定义了超时值的语义（见上文），对驱动内部的轮询实现细节完全未做约束。具体而言，规范未规定： 以 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： 注：以上是前端性能的普遍经验数字，不是数学公式，极端场景可能超出范围。

权衡一：为什么选 1s 而不是 0.5s？
500~1000ms 是 0.5s 和 1.0s 的兜底能力分水岭：
低于 500ms 两者都能兜；高于 1000ms 两者都兜不住（该用显式等待）；
只有在 500~1000ms 之间，1.0s 比 0.5s 多出了实际价值： 代价对比（和显式等待 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）0ms0 秒0 秒规范最严谨
1s1000ms30 秒10 秒经验+权衡默认推荐
0.5s500ms15 秒5 秒经验+权衡确认页面 <500ms
2s2000ms60 秒20 秒代价太大谨慎
≥5s≥5000ms150 秒+50 秒+爆炸❌ 绝对避免