ChromeDriver截图比对：自动化检验DDColor两次输出一致性
ChromeDriver截图比对：自动化检验DDColor两次输出一致性
在数字影像修复日益普及的今天，老照片上色已不再是专业图像处理人员的专属技能。借助像DDColor这样的深度学习模型，普通用户也能一键将泛黄的黑白照片还原为色彩鲜活的历史记忆。然而，当我们在不同环境、配置或时间点运行同一工作流时，是否能确保每次输出的结果完全一致？这不仅是用户体验的问题，更是自动化部署与质量保障的核心挑战。
尤其是在基于 ComfyUI 构建的图形化工作流中，虽然操作直观，但缺乏标准 API 输出接口，使得传统张量级比对难以实施。面对这一困境，我们转向了一种更贴近“人眼感知”的验证方式——通过浏览器自动化技术抓取可视化结果，并进行像素级差异分析。这种方法不仅绕开了对底层模型结构的依赖，还实现了真正意义上的黑盒测试。
ChromeDriver 作为 Selenium 生态中的核心组件，其能力远不止于网页功能测试。它能够精确控制 Chrome 浏览器的行为：打开页面、上传文件、点击按钮、执行脚本，甚至截取指定区域的图像。这些特性让它成为连接自动化逻辑与图形界面之间的理想桥梁。
设想这样一个场景：你刚刚升级了 ComfyUI 到最新版本，或者更换了 DDColor 的模型权重。如何快速确认这次变更没有引入视觉上的异常？最直接的方式就是跑一遍典型用例，看看输出图有没有变色、模糊或错位。但如果要验证几十甚至上百组图像呢？手动检查显然不现实。
于是我们构建了一个闭环流程：
启动本地 ComfyUI 服务 → 使用 ChromeDriver 模拟用户操作 → 加载固定工作流并输入图像 → 触发推理 → 截图保存结果 → 更改参数后重复执行 → 对比两次截图。
整个过程无需修改任何前端代码，也不依赖模型内部日志，完全是对外部可观测行为的捕捉和验证。这种非侵入式的设计极大提升了测试的灵活性和可维护性。
以 Python 脚本为例，通过selenium.webdriver可轻松实现全流程控制：
from selenium import webdriver from selenium.webdriver.chrome.service import Service from selenium.webdriver.common.by import By import time service = Service('/usr/local/bin/chromedriver') options = webdriver.ChromeOptions() options.add_argument('--headless=new') options.add_argument('--no-sandbox') options.add_argument('--disable-dev-shm-usage') options.add_argument('--window-size=1920,1080') # 统一分辨率避免缩放干扰 driver = webdriver.Chrome(service=service, options=options) try: driver.get("http://localhost:8188") time.sleep(5) # 等待页面初始化 # 上传预设工作流 workflow_input = driver.find_element(By.XPATH, "//input[@type='file' and contains(@class, 'workflow-upload')]") workflow_input.send_keys("/path/to/DDColor人物黑白修复.json") time.sleep(2) # 上传测试图像 image_input = driver.find_element(By.XPATH, "//input[@type='file' and @accept='image/*']") image_input.send_keys("/path/to/test_image.jpg") time.sleep(1) # 启动推理 run_button = driver.find_element(By.CSS_SELECTOR, "button[data-run]") run_button.click() # 建议使用显式等待替代 sleep，例如监测输出容器出现新图片 time.sleep(15) # 截图仅保留输出区域 result_element = driver.find_element(By.ID, "output-image-container") result_element.screenshot("run1_result.png") finally: driver.quit()这段脚本可以封装成可复用函数，传入不同的model_size参数或其他变量，分别生成两组输出图像。接下来的关键一步是——如何科学地判断它们是否“看起来一样”。
这里我们引入 OpenCV 进行图像比对：
import cv2 import numpy as np def calculate_image_difference(img1_path, img2_path): img1 = cv2.imread(img1_path) img2 = cv2.imread(img2_path) # 统一尺寸防止因分辨率差异导致误判 h, w = min(img1.shape[0], img2.shape[0]), min(img1.shape[1], img2.shape[1]) img1 = cv2.resize(img1[:h, :w], (w, h)) img2 = cv2.resize(img2[:h, :w], (w, h)) # 计算绝对差值图 diff = cv2.absdiff(img1, img2) gray_diff = cv2.cvtColor(diff, cv2.COLOR_BGR2GRAY) # 统计变化像素占比 change_ratio = np.count_nonzero(gray_diff) / gray_diff.size # 均方误差（MSE）反映整体偏差强度 mse = np.mean(diff ** 2) return mse, change_ratio, diff最终返回的两个指标非常实用：
-MSE < 1.0表示平均每个像素的误差小于1个灰度单位，基本可视作无明显偏色；
-变化像素占比低于0.5%意味着绝大多数区域保持一致，局部微小波动可能是压缩噪声或渲染抖动所致。
当然，阈值设定需结合实际业务调整。例如对于高精度档案修复任务，可能要求 MSE < 0.3；而对于预览级应用，则可放宽至 MSE < 2.0。
值得一提的是，DDColor 本身的工作机制也会影响输出稳定性。该模型采用双分支扩散架构，在 Lab 色彩空间中分离亮度（L）与色度（ab）通道进行联合建模。其中，model_size参数决定了输入图像的缩放尺度，进而影响细节还原能力：
- 人物类图像推荐 size 在 460–680px 之间：过低会导致面部肤色不均，过高则可能引发边缘振铃效应；
- 建筑类图像适合 960–1280px：大尺寸有助于捕捉墙面纹理与天空渐变，但也对显存提出更高要求。
若在同一测试中混用不同类型模型（如用人像模型处理风景照），即使参数不变，也可能出现系统性色调偏差。因此，在设计比对实验时，必须保证除目标变量外其余条件严格一致——包括模型类型、输入路径、浏览器窗口状态等。
此外，为了提升自动化流程的鲁棒性，还需注意几个工程细节：
- 避免动态元素干扰：截图应精准裁剪至仅包含输出图像的 DOM 容器，避开带有时间戳、加载动画或按钮状态的区域；
- 优化等待策略：使用
WebDriverWait配合expected_conditions监听图像加载完成事件，而非简单sleep()； - 环境隔离：每次运行前清空缓存或重启 ComfyUI 实例，防止上次推理结果被错误复用；
- 异常处理机制：捕获网络超时、元素未找到、驱动崩溃等情况，记录失败原因并自动重试。
这套方案的价值不仅限于 DDColor 的回归测试。事实上，所有基于 Web UI 的 AIGC 工具——无论是 Stable Diffusion WebUI、Fooocus，还是自研的可视化建模平台——都可以借鉴这一思路，建立统一的输出一致性监控体系。
更重要的是，它降低了 QA 团队参与 AI 质量保障的技术门槛。测试人员无需理解扩散模型原理，只需定义输入样本集和预期输出范围，即可通过脚本批量执行并生成可视化报告。当某次更新导致大量图像 MSE 超标时，系统可立即告警，阻止潜在风险上线。
展望未来，该方法还可进一步集成至 CI/CD 流程中。例如每日凌晨自动拉取最新模型权重，运行一轮全量测试，生成差异热力图并推送摘要邮件。长期积累的数据还能用于分析模型输出的漂移趋势，辅助研发团队定位性能退化根源。
技术的魅力往往体现在跨界融合之中。ChromeDriver 原本是为 Web 测试而生，却在这里成为了 AI 输出验证的“眼睛”；OpenCV 本用于计算机视觉任务，如今反向服务于模型自身的质量检测。正是这种灵活组合的能力，让开发者能在复杂系统中找到简洁高效的解决方案。
当我们在追求极致还原一张老照片的同时，也在努力确保每一次“还原”都经得起重复验证。这才是自动化真正的意义所在——不只是让机器干活，而是让结果可信、可控、可持续。