浏览器操作演示 · 元素交互

与元素交互

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

本页说明 —— 元素交互

演示 Selenium 与页面元素交互的 核心 7 个方法，覆盖点击、输入、查询三大场景。

操作前必须先定位：用 find_element(By.ID/XPATH/CSS, ...) 获取 WebElement 对象。

元素交互

元素交互

click / send_keys / clear / get_attribute / is_displayed / is_enabled
为什么要学习元素交互？
定位到元素后，真正干活的就是这几个交互方法——输入、点击、清空、读属性。它们是自动化脚本的"手脚"。
常见用途： 登录注册（输入账号密码） 点击按钮/链接 表单填写提交 获取元素属性做断言
⚠️ 常见坑： ElementNotInteractableException 元素存在但不可交互（被遮挡/没滚动到） | click() 点不到时试试 driver.execute_script("arguments[0].click()", el) 用 JS 强制点击（el 就是你用 find_element() 定位到的那个元素对象，execute_script 会把它作为参数传给 JS 里的 arguments[0]，相当于绕过 Selenium 的可交互性检查直接触发 DOM 事件）
对应 API：
element.click() 点击元素
element.send_keys("text") 输入文本（配合 Keys.ENTER 可模拟回车）
element.clear() 清空输入框
element.submit() 表单提交（等同于在输入框按回车）
element.text 获取元素可见文本
element.get_attribute("href") 获取 HTML 属性
element.get_property("value") 获取 DOM property（比 get_attribute 更可靠，比如读输入框当前值）
element.tag_name 获取标签名（如 "input" / "button"）
element.size 获取尺寸 {'height': N, 'width': N}
element.location 获取页面坐标 {'x': N, 'y': N}
element.rect 获取完整的位置+尺寸对象
element.is_displayed() 元素是否可见
element.is_enabled() 元素是否可操作
element.is_selected() 复选框/单选框是否选中
模拟操作目标（点击下方按钮操作这些元素）
代码开关（开=右侧显示对应代码）
send_keys("admin")
输入用户名
send_keys("123456")
输入密码
clear()
清空用户名输入框
clear()
清空密码输入框
click()
点击按钮
submit()
回车提交
.text
获取文本
get_attribute()
HTML 属性
get_property()
DOM 属性
tag_name
标签名
size
元素尺寸
location
页面坐标
rect
完整矩形
is_selected()
是否选中
is_displayed()
是否可见
is_enabled()
是否可点
对应 Python Selenium 代码
点击下方开关，这里将生成对应的 Selenium 代码...
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/element_interact_tech.html")

# ② 定位输入框与复选框（id 与本演示页真实元素一致）
username = driver.find_element(By.ID, "mockUsername")
password = driver.find_element(By.ID, "mockPassword")
remember = driver.find_element(By.ID, "mockRemember")

# ③ 输入文本、清空后重新输入
username.send_keys("admin")
username.clear()
username.send_keys("admin")
password.send_keys("123456")

# ④ 点击复选框；submit() 模拟回车提交表单
remember.click()
password.submit()

# ⑤ 读取元素属性与状态（自动化断言常用）
print("placeholder：", username.get_attribute("placeholder"))
print("标签名：", username.tag_name)
print("尺寸/坐标/矩形：", username.size, username.location, username.rect)
print("选中/可见/可用：", remember.is_selected(), username.is_displayed(), username.is_enabled())

driver.quit()
操作效果展示区域
点击模拟登录按钮或切换开关，这里会显示元素操作的执行结果和关键数据

关于我们

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