ChromeDriver 与 lora-scripts 结合实践：自动化测试 WebUI 的完整路径
在 AI 模型快速迭代的今天，LoRA（Low-Rank Adaptation）因其轻量高效、易于部署的特性，已成为 Stable Diffusion 和大语言模型个性化训练的事实标准。然而，对于大多数非专业开发者而言，从数据准备到模型微调再到效果验证，整个流程依然充满挑战——尤其是当需要频繁验证新训练出的 LoRA 权重是否能在 WebUI 中正常工作时。
一个常见的场景是：你刚刚完成了一轮风格化 LoRA 训练，迫不及待想看看它在 Stable Diffusion WebUI 里生成的效果。于是你手动启动 WebUI，等待加载完成，找到“附加网络”插件，上传.safetensors文件，输入提示词，点击生成……这个过程看似简单，但如果每天要重复十几次，甚至要在多个环境中验证兼容性，人力成本就会迅速累积。
有没有办法让这一切自动完成？
答案是肯定的。通过ChromeDriver + Selenium实现对 WebUI 的自动化操作，并结合lora-scripts完成端到端的训练-测试闭环，已经成为许多高效团队的标准做法。这不仅适用于回归测试，还能支撑 CI/CD 流水线，真正实现“提交即验证”。
ChromeDriver：不只是浏览器控制工具
ChromeDriver 并不是一个简单的“模拟点击”工具。它是 Google 官方维护的一个独立进程，作为 Selenium 与 Chrome 浏览器之间的桥梁，基于 W3C WebDriver 协议和 Chrome DevTools Protocol（CDP）实现深度交互。
它的核心价值在于：能够以编程方式精确操控浏览器行为，同时具备强大的调试与监控能力。这意味着你可以做的远不止“点按钮”这么简单——比如拦截网络请求、获取性能指标、执行 JS 脚本、捕获页面错误等。
更重要的是，它支持无头模式（--headless），非常适合在服务器或 Docker 容器中运行，完全无需图形界面。这对于自动化流水线来说至关重要。
但这里有个关键前提：ChromeDriver 必须与本地 Chrome 浏览器主版本严格匹配。例如，如果你安装的是 Chrome 128.0.6613.119，就必须使用对应版本的 ChromeDriver，否则会抛出session not created错误。这一点常常被忽略，导致初学者卡在第一步。
目前官方下载地址为：
https://edgedl.meulab.com/chrome/chromedriver/
该镜像站同步更新 Google 官方发布的所有版本，支持 Windows、Linux、macOS 各平台，且访问稳定，推荐优先使用。
此外，也可以通过以下方式自动获取匹配版本：
from selenium import webdriver from webdriver_manager.chrome import ChromeDriverManager options = webdriver.ChromeOptions() options.add_argument("--headless") driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()), options=options)借助webdriver-manager库，可以自动检测当前 Chrome 版本并下载对应的 ChromeDriver，省去手动查找的麻烦。
自动化脚本实战：用代码“代替人”操作 WebUI
假设你的 Stable Diffusion WebUI 正在http://localhost:7860运行，你想自动测试新训练的 LoRA 是否能成功生成图像。下面这段脚本就能帮你完成全过程：
from selenium import webdriver from selenium.webdriver.chrome.service import Service from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC import time chrome_driver_path = "./drivers/chromedriver-128.0.6613.119" options = webdriver.ChromeOptions() options.add_argument("--headless") options.add_argument("--no-sandbox") options.add_argument("--disable-dev-shm-usage") options.add_argument("--disable-gpu") service = Service(executable_path=chrome_driver_path) driver = webdriver.Chrome(service=service, options=options) try: driver.get("http://localhost:7860") # 等待提示词框出现，确保页面已加载 prompt_input = WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, "txt2img_prompt")) ) prompt_input.send_keys("cyberpunk cityscape with neon lights, <lora:my_style_lora:0.8>") generate_btn = driver.find_element(By.ID, "txt2img_generate") generate_btn.click() # 等待输出图像可见（最长等待60秒） output_image = WebDriverWait(driver, 60).until( EC.visibility_of_element_located((By.CSS_SELECTOR, "#txt2img_gallery img")) ) print("图像生成成功！") driver.save_screenshot("output/generation_result.png") finally: time.sleep(2) driver.quit()这段代码的关键点在于：
- 使用WebDriverWait配合expected_conditions实现智能等待，避免因网络延迟或 GPU 渲染慢导致的元素未找到问题；
- 通过 ID 或 CSS 选择器精准定位 WebUI 组件，这些 ID 通常由 Gradio 框架生成，结构清晰可预测；
- 最终截图保留结果，可用于后续比对或人工复核。
小贴士：如果 WebUI 启用了用户名密码认证，可以在
driver.get()前加入driver.get("http://user:password@localhost:7860")实现自动登录。
lora-scripts：把训练变成“一键操作”
如果说 ChromeDriver 解决了“怎么测”，那lora-scripts就解决了“怎么训”。
这是一个专为 LoRA 微调设计的高度封装工具包，目标很明确：让非专家用户也能轻松完成从数据到模型的全流程训练。
它的工作流非常清晰：
1. 准备图片和标注文件（如metadata.csv）；
2. 编写 YAML 配置文件定义训练参数；
3. 执行一条命令启动训练；
4. 输出.safetensors权重文件。
整个过程无需编写任何 PyTorch 代码，也不用关心分布式训练细节，极大降低了入门门槛。
来看一个典型的配置文件示例：
train_data_dir: "./data/style_train" metadata_path: "./data/style_train/metadata.csv" base_model: "./models/Stable-diffusion/v1-5-pruned.safetensors" lora_rank: 8 lora_alpha: 16 lora_dropout: 0.1 batch_size: 4 epochs: 10 learning_rate: 2e-4 optimizer: "adamw_8bit" scheduler: "cosine" output_dir: "./output/my_style_lora" save_steps: 100 logging_dir: "./output/my_style_lora/logs"其中几个关键参数值得特别注意：
-lora_rank：一般设为 4~16，数值越高表达能力越强，但也更耗显存；
-lora_alpha：建议设置为2 * rank，用于控制权重缩放；
-adamw_8bit：使用 8-bit 优化器可显著降低内存占用，适合消费级 GPU；
-save_steps：定期保存检查点，防止意外中断导致前功尽弃。
训练命令也极其简洁：
python train.py --config configs/my_lora_config.yaml一旦训练完成，权重文件会自动保存到指定目录，接下来就可以进入自动化测试阶段。
构建完整闭环：从训练到验证全自动化
真正的效率提升来自于系统集成。将 lora-scripts 与 ChromeDriver 测试脚本串联起来，就能构建一个完整的“训练 → 部署 → 验证”自动化流水线。
典型流程如下：
- 用户提交新的训练数据集；
- 自动运行标注脚本生成
metadata.csv； - 调用 lora-scripts 启动训练；
- 训练完成后，自动将
.safetensors文件复制到 WebUI 插件目录； - 启动 WebUI（可通过后台服务管理）；
- 运行 Selenium 脚本进行功能测试；
- 若测试失败，发送告警通知；若成功，归档截图并记录日志。
整个过程可以在 GitHub Actions、Jenkins 或自建调度系统中运行，实现“零人工干预”。
这种架构尤其适合以下场景：
- 小团队快速迭代多种风格 LoRA；
- 教学项目中批量验证学生作业；
- 开源项目维护者进行发布前回归测试；
- 企业内部定制化 AI 模型服务平台。
实践中的经验与避坑指南
在真实部署中，有几个常见问题必须提前预防：
1. 版本冲突
Chrome、ChromeDriver、WebUI 插件三者版本不一致可能导致元素定位失败。建议锁定版本，例如：
- Chrome 浏览器：128.x
- ChromeDriver：128.0.6613.119
- sd-webui-additional-networks：v0.27+
2. 显存争抢
训练和推理都依赖 GPU，若在同一台机器上并发运行，极易 OOM。最佳做法是：
- 训练时关闭 WebUI；
- 或使用不同设备分工处理。
3. 页面加载超时
WebUI 启动较慢，特别是首次加载大模型时。应在自动化脚本中设置合理的等待时间（如 120 秒），并加入重试机制。
4. 元素 ID 变化
Gradio 生成的 DOM ID 可能随界面更新而变化。建议：
- 使用稳定的 CSS 类名辅助定位；
- 或在 WebUI 启动时启用固定 ID 模式（如有）；
- 定期检查选择器有效性。
5. 日志与证据留存
每次测试都应保存：
- 截图；
- 控制台输出；
- 网络请求日志（可通过 CDP 拦截）；
以便事后追溯问题根源。
写在最后
AI 工程化的未来，不是拼谁写代码更快，而是看谁能构建更可靠的自动化体系。
ChromeDriver 与 lora-scripts 的结合，正是这样一个典型案例：前者打通了代码与图形界面之间的最后一公里，后者则将复杂的深度学习训练简化为可复用的配置文件。两者协同，让原本需要数小时的手工验证，压缩到几分钟内全自动完成。
更重要的是，这套方案并不依赖昂贵硬件或专业团队。一台普通的带 GPU 的 PC，加上开源工具链，就能跑通整套流程。它降低了实验成本，加速了创新节奏，也让个人开发者有机会参与高质量 AI 模型的持续演进。
随着越来越多 AI 工具走向 Web 化、可视化，基于浏览器的自动化测试只会越来越重要。掌握 ChromeDriver 不仅是为了 today’s task，更是为了 tomorrow’s workflow。
