Selenium Web Form 多控件填写与提交验证

在一张真实 Web Form 中连续处理文本框、原生下拉、选择控件、日期与滑块；提交后重新读取新页面，以“Received!”完成结果验收。

Submit 只是分界线

网页表单自动化最容易制造一种错觉：字段都填了，按钮也点了，任务就结束了。真正可靠的完成标准发生在跳转之后——智能体必须放下提交前的页面状态，重新读取浏览器此刻展示的内容，再确认服务端返回了什么。

这段录制把填写和验收放在同一条任务链里。前半程考验不同控件的交互选择，后半程考验页面变化后的状态更新。最终答案不是“我已经点击 Submit”，而是最新页面上可见的 `Received!`。

一条可以直接运行的表单任务

打开 Selenium 官方示例页：https://www.selenium.dev/selenium/web/web-form.html。按页面顺序完成下面这组测试数据：Text input 填入 `Hello World`，Password 填入 `MySecret123`，Textarea 填入 `This is a test message.`；通过原生 select 将下拉选项设为 `Two`；勾选 `Default checkbox`，并把单选项切换到 `Default radio`；日期设为 `2026-07-31`，Range 滑块设为 `7`。

字段完成后点击 `Submit`。等待页面跳转，然后务必重新读取当前最新页面，不要沿用提交前的 DOM、标题或文字缓存。只有在新页面明确显示 `Received!` 时才报告成功；同时保留页面标题和结果页 URL 作为可复查证据。不要离开这张示例表单，不要点击其他链接，也不要用真实密码代替这里的演示数据。

一张表单，四种交互语义

三个文本字段适合直接填写，但下拉框不是另一个文本输入：视频里 Fan 调用原生 select，把选项准确切到 `Two`。复选框与单选框需要读取当前选中状态后再操作，避免把已选项点成未选。日期输入有自己的格式约束，而 Range 滑块也不能靠输入文字冒充完成。

录制中，普通表单填写方式不支持 Range。Fan 没有跳过它，也没有反复试错，而是先让滑块获得焦点，再发送两次 `ArrowRight`，把数值从 5 调整到 7。这里展示的不是某个固定脚本，而是根据控件反馈更换操作方式的能力。

录制现场留下了什么

页面提交前的状态可以逐项复核：文本为 `Hello World`，演示密码为 `MySecret123`，多行文字为 `This is a test message.`，下拉项为 `Two`，`Default checkbox` 已勾选，`Default radio` 已选中，日期为 `2026-07-31`，滑块值为 7。

点击 `Submit` 后，浏览器进入 `submitted-form.html`。Fan 随即重新读取当前页面，得到新的页面标题 `Web form - target page`，并在页面主体看到 `Form submitted` 和 `Received!`。录制右侧的执行摘要也把填写动作和提交结果分开呈现，用户可以直接把动作、输入和最终页面一一对照。

为什么不能相信旧页面

提交会触发导航，旧页面中的控件、文本和节点引用都可能已经失效。若智能体仍根据提交前的观察作答，即使按钮真的被点击，也无法证明新页面加载成功，更无法证明 `Received!` 已出现。

因此这项任务的停止条件非常具体：导航完成、重新获取最新页面、在新状态中匹配目标文字。它同样适用于登录回跳、保存设置、创建记录、筛选结果刷新等更广泛的网页流程——每一次关键状态变化之后，都应以新页面证据决定下一步，而不是让旧上下文替代现实。