1. 项目概述从“代码定位”到“语言描述”的测试范式革新在软件测试特别是Web UI自动化测试领域XPath和CSS Selector这类定位器就像是测试工程师的“坐标尺”。我们花费大量时间在开发者工具里精确定位一个按钮、一个输入框小心翼翼地编写和维护这些脆弱的选择器表达式。一旦前端代码结构稍有变动比如一个div嵌套层级改变或者一个class名被重构我们的测试脚本就可能大面积失效随之而来的是繁琐的调试和修复工作。这几乎是每个自动化测试工程师的日常痛点。最近我深度体验了一个将大语言模型LLM与视觉理解能力结合并封装为Web UI工具的项目——Qwen3-VL-WEBUI。它的核心价值在于允许测试人员用最自然的语言描述来驱动测试执行比如直接说“点击那个蓝色的登录按钮”或者“在搜索框里输入‘手机’然后按回车”。这听起来像是测试自动化的终极梦想而它正在成为现实。这个项目并非空中楼阁它基于阿里通义千问团队开源的Qwen3-VL多模态大模型通过一个直观的Web界面将模型的视觉理解和指令执行能力直接应用到浏览器操作上。简单来说它试图解决的核心问题是降低UI自动化测试的脚本编写和维护门槛让测试逻辑的表达更贴近人类的自然思维从而提升测试脚本的健壮性和开发效率。对于测试开发工程师、质量保障QA人员甚至是希望快速验证页面功能的产品经理这都提供了一个极具潜力的新工具。接下来我将从设计思路、核心实现、实操细节到避坑经验完整拆解如何利用Qwen3-VL-WEBUI构建自然语言驱动的智能测试流程。2. 核心思路与架构设计为什么是“视觉语言”传统的UI自动化测试无论是Selenium、Playwright还是Cypress其核心逻辑都是“代码定位代码操作”。我们需要将视觉界面上的元素翻译成机器可读的定位符Locator再编写操作指令。这个过程存在几个固有缺陷脆弱性定位符与页面DOM结构强耦合前端微调即可能导致定位失败。高门槛编写稳定的XPath或CSS选择器需要一定的前端知识和经验。不直观测试用例的逻辑被埋没在大量的定位代码中可读性差。Qwen3-VL-WEBUI的方案则另辟蹊径采用了“视觉理解自然语言驱动”的范式。其核心思路可以概括为让AI“看”到屏幕并“听懂”你的指令去执行操作。2.1 技术架构拆解整个系统的运行依赖于几个关键组件的高效协同视觉感知层这是系统的“眼睛”。通常通过浏览器自动化工具如Playwright、Selenium的API实时捕获当前网页的屏幕截图。这张截图包含了所有视觉元素的信息是模型理解的原始输入。多模态大模型Qwen3-VL这是系统的“大脑”。Qwen3-VL是一个能够同时理解图像和文本的模型。我们将上一步获取的屏幕截图连同用户用自然语言描述的指令例如“在顶部的搜索框输入‘通义千问’并点击搜索图标”一并输入给模型。指令解析与坐标映射模型的“思考”结果不是直接的操作代码而是对指令的理解。一个设计良好的系统模型需要输出结构化的信息例如动作类型click点击、type输入、hover悬停、scroll滚动等。目标元素描述在图像中定位到的目标区域通常以坐标或边界框Bounding Box的形式表示例如(x: 450, y: 300, width: 120, height: 40)。附加参数对于输入动作需要包含要输入的文本内容。动作执行层这是系统的“手”。系统接收到解析后的结构化指令后需要将图像中的坐标通过计算映射回浏览器页面中的实际DOM元素或者更直接地通过模拟鼠标在特定坐标点击、键盘输入等方式执行最终的操作。这一步通常再次借助浏览器自动化工具的API来完成。WebUI交互层这是给用户使用的“控制台”。一个友好的Web界面允许用户输入自然语言指令、查看屏幕截图、观察模型的理解过程可解释性、管理测试用例和执行流水线。注意这里存在一个关键的技术选型分歧——坐标驱动 vs. 元素驱动。纯坐标驱动直接模拟鼠标在(x,y)点点击简单直接但可能受屏幕分辨率、窗口位置影响。更健壮的方式是利用模型输出的坐标信息结合浏览器的elementFromPoint等API反向查找出对应的DOM元素再对元素执行标准操作。后者适应性更强是更推荐的生产环境方案。2.2 与XPath方案的对比优势为了更清晰地展示其价值我们可以将两种范式进行对比特性维度传统XPath/CSS Selector 方案Qwen3-VL-WEBUI 自然语言方案脚本编写需前端知识编写定位表达式。用自然语言描述操作意图。维护成本高。页面结构变动需更新定位器。相对较低。只要视觉布局和元素语义不变描述仍有效。可读性差。逻辑淹没在技术代码中。极好。用例本身就是需求描述。健壮性脆弱。依赖DOM结构。较强。依赖视觉特征和语义。适用场景稳定、结构化的Web应用。快速原型验证、视觉化为主的应用、RPA流程。执行精度精确到具体元素。依赖模型识别精度可能存在歧义。技术门槛中。需要编程和前端基础。低。描述需求即可但调试需理解原理。可以看出新范式并非要完全取代旧范式而是提供了一种互补和升级的选择。它特别适用于页面结构频繁变动但视觉设计相对稳定的项目或者需要快速创建自动化脚本而无暇深入前端代码的场景。3. 环境搭建与核心工具链部署理论很美好但要跑通整个流程需要搭建一个包含模型服务、Web界面和浏览器控制的环境。下面是我在本地部署的一套可用的方案基于Docker和Python生态力求清晰明了。3.1 基础环境准备首先确保你的开发环境满足以下条件操作系统Linux (Ubuntu 20.04 推荐) 或 macOS。Windows可通过WSL2获得最佳体验。Docker Docker Compose用于容器化部署模型服务避免复杂的本地环境配置。Python 3.10主流的AI框架和工具链支持版本。Node.js 16部分WebUI前端可能依赖。GPU强烈推荐Qwen3-VL模型推理对算力要求较高拥有NVIDIA GPU显存建议8GB以上将极大提升体验。纯CPU模式速度会非常慢仅适合尝鲜。3.2 部署Qwen3-VL模型服务模型服务是核心。我们使用官方推荐的OpenAI兼容的API服务部署方式。步骤一获取模型文件从ModelScope或Hugging Face下载Qwen3-VL系列的模型权重文件例如Qwen3-VL-7B-Instruct。假设下载后存放路径为/path/to/your/qwen3-vl-7b-instruct。步骤二使用vLLM部署推理服务vLLM 是一个高效的大模型推理和服务框架兼容OpenAI API协议。# 安装vLLM pip install vllm # 启动API服务 (假设使用单卡GPU 0) python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/qwen3-vl-7b-instruct \ --served-model-name qwen3-vl-7b \ --max-model-len 8192 \ --api-key token-abc123 \ --host 0.0.0.0 \ --port 8000关键参数解释--model: 指定你下载的模型目录路径。--served-model-name: 客户端调用时使用的模型名称。--max-model-len: 模型支持的最大上下文长度根据模型能力设置。--api-key: 设置一个简单的API密钥用于基础验证。--host和--port: 服务监听的地址和端口。服务启动后会提供一个类似于http://localhost:8000/v1的端点支持/v1/chat/completions等OpenAI标准接口。实操心得在资源有限的机器上可以考虑使用量化版本如GPTQ、AWQ的模型能显著降低显存占用。例如使用AutoGPTQ加载4位量化的模型。命令可能变为python -m vllm.entrypoints.openai.api_server \ --model /path/to/qwen3-vl-7b-instruct-gptq-4bit \ --quantization gptq \ ... # 其他参数具体量化方法需参考模型发布页的说明。3.3 构建Qwen3-VL-WEBUI应用这里的“WEBUI”可能指两个部分一是模型本身自带的或社区提供的对话式Web界面用于测试模型的多轮对话和视觉问答能力二是我们自己需要构建的、集成浏览器自动化能力的智能测试控制台。我们重点讨论后者。我们可以基于成熟的Web框架如Gradio、Streamlit快速搭建一个原型或者自己用前端框架如React/Vue配合后端如FastAPI构建。这里给出一个使用Gradio的极简示例因为它能快速集成图像、文本和交互组件。# app.py import gradio as gr import requests import base64 import json from playwright.sync_api import sync_playwright import io from PIL import Image # 配置 VLLM_API_URL http://localhost:8000/v1/chat/completions API_KEY token-abc123 def capture_page_screenshot(url): 使用Playwright打开网页并截图 with sync_playwright() as p: browser p.chromium.launch(headlessTrue) # 无头模式 page browser.new_page() page.goto(url) # 可以设置视口大小确保截图一致性 page.set_viewport_size({width: 1280, height: 720}) screenshot_bytes page.screenshot(full_pageFalse) # 截取当前视口 browser.close() return screenshot_bytes def encode_image_to_base64(image_bytes): 将图片字节编码为Base64字符串 return base64.b64encode(image_bytes).decode(utf-8) def ask_qwen3_vl(image_base64, user_prompt): 调用vLLM服务的Qwen3-VL模型 headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } # 构建符合OpenAI Vision API格式的请求 messages [ { role: user, content: [ {type: text, text: user_prompt}, { type: image_url, image_url: { url: fdata:image/jpeg;base64,{image_base64} } } ] } ] payload { model: qwen3-vl-7b, messages: messages, max_tokens: 500 } try: response requests.post(VLLM_API_URL, headersheaders, jsonpayload, timeout60) response.raise_for_status() result response.json() return result[choices][0][message][content] except Exception as e: return f调用模型API失败: {str(e)} def execute_test(url, instruction): 主执行函数截图 - 调用模型 - 返回结果 # 1. 截图 print(f正在访问并截图: {url}) screenshot capture_page_screenshot(url) # 2. 编码 img_base64 encode_image_to_base64(screenshot) # 3. 调用模型获取动作解析结果 # 这里需要精心设计Prompt让模型输出结构化指令 structured_prompt f 你是一个网页自动化助手。请分析用户指令和当前网页截图。 用户指令{instruction} 请仅输出一个JSON对象描述要执行的动作格式如下 {{ action: click | type | scroll | hover | none, target_description: 对目标元素的简短描述, coordinates: {{x: int, y: int, width: int, height: int}} // 目标区域的中心点或边界框 text: 需要输入的文本仅当action为type时存在 }} 如果无法确定或无需操作action设为none。 model_response ask_qwen3_vl(img_base64, structured_prompt) # 4. 解析模型返回的JSON (这里简化实际需健壮解析) try: action_info json.loads(model_response.strip()) except: action_info {action: parse_error, response: model_response} # 5. 将截图和结果返回给前端显示 return Image.open(io.BytesIO(screenshot)), json.dumps(action_info, indent2, ensure_asciiFalse) # 构建Gradio界面 with gr.Blocks(title智能网页测试助手) as demo: gr.Markdown(# 基于Qwen3-VL的自然语言网页测试助手) with gr.Row(): url_input gr.Textbox(label目标网页URL, valuehttps://www.example.com) instruction_input gr.Textbox(label自然语言指令, placeholder例如点击登录按钮然后在用户名框输入‘test’) submit_btn gr.Button(执行指令, variantprimary) with gr.Row(): screenshot_output gr.Image(label网页截图, typepil) result_output gr.JSON(label模型解析的动作指令) # 绑定事件 submit_btn.click(fnexecute_test, inputs[url_input, instruction_input], outputs[screenshot_output, result_output]) if __name__ __main__: demo.launch(server_name0.0.0.0, server_port7860)这个示例提供了一个最基础的框架。它完成了从打开网页、截图、调用多模态模型到返回解析结果的全流程。然而它缺少最关键的一步将解析出的动作指令如坐标真正执行到浏览器上。这需要更复杂的集成我们将在下一章详细展开。4. 核心实现从指令解析到动作执行的闭环要让智能测试真正“动”起来我们必须打通“模型输出”到“浏览器执行”的最后一公里。这涉及到指令解析、坐标映射、动作执行和状态反馈等多个环节。4.1 设计高效的Prompt工程模型的输出质量直接取决于输入的Prompt。对于自动化测试场景我们需要引导模型输出结构化、可执行的指令而不是一段自由文本。一个改进版的Prompt模板如下你是一个专业的网页自动化测试助手。请严格遵循以下步骤和格式要求。 **当前网页目标**完成用户指令。 **用户指令**{user_instruction} **你的任务** 1. **理解指令**分析用户想做什么点击、输入、滚动等。 2. **定位元素**在提供的网页截图中找到与指令最匹配的可交互元素。 3. **输出JSON**仅输出一个合法的JSON对象格式如下 { thought: 简要说明你对指令的理解和定位逻辑, action: click | type | scroll_up | scroll_down | hover | navigate | none, target_bbox: { x: 元素区域左上角x坐标, y: 左上角y坐标, width: 区域宽度, height: 区域高度 }, type_text: 当action为‘type’时需要输入的文本, confidence: 你对此次定位和操作的确信度0.0到1.0 } **规则** - 坐标(x, y)的原点(0,0)在截图左上角。 - 只选择最可能的一个目标元素。 - 如果指令是“输入XXX到YYY框”action为typetype_text为“XXX”。 - 如果指令是“向下/上滚动”action为scroll_down/scroll_uptarget_bbox可省略或设为视口中心。 - 如果无法确定action设为noneconfidence设低。这个Prompt明确了角色、任务、输出格式和规则能显著提高模型输出结构的稳定性。4.2 坐标映射与动作执行模型返回的target_bbox是基于截图图像的像素坐标。我们需要将其映射回真实的浏览器页面坐标系然后执行操作。方案一坐标模拟直接但可能不稳定使用Playwright或PyAutoGUI直接在屏幕坐标(x width/2, y height/2)即中心点模拟点击。这种方法简单但受浏览器窗口位置、缩放比例影响大。from playwright.sync_api import sync_playwright def execute_action_by_coords(page, action_info): 根据坐标信息执行动作基础版 action action_info.get(action) bbox action_info.get(target_bbox) if not bbox or action none: return center_x bbox[x] bbox[width] // 2 center_y bbox[y] bbox[height] // 2 if action click: page.mouse.click(center_x, center_y) elif action type: page.mouse.click(center_x, center_y) # 先点击聚焦 page.keyboard.type(action_info.get(type_text, )) elif action scroll_down: page.mouse.wheel(0, 300) # 向下滚动 # ... 其他动作方案二元素反向查找推荐更健壮利用浏览器的document.elementFromPoint(x, y)API根据坐标找到对应的DOM元素然后对该元素执行标准操作。这能利用浏览器引擎的精准元素定位避免坐标偏移问题。def execute_action_by_element(page, action_info): 通过坐标查找元素再执行动作推荐 action action_info.get(action) bbox action_info.get(target_bbox) if not bbox or action none: return center_x bbox[x] bbox[width] // 2 center_y bbox[y] bbox[height] // 2 # 在页面上下文中执行JavaScript通过坐标获取元素 element_handle page.evaluate_handle(f() {{ const el document.elementFromPoint({center_x}, {center_y}); // 可能需要向上查找可交互的父元素 let interactiveEl el; while (interactiveEl !interactiveEl.click) {{ interactiveEl interactiveEl.parentElement; }} return interactiveEl; }}) if element_handle: if action click: element_handle.click() elif action type: element_handle.fill(action_info.get(type_text, )) # ... 其他针对元素的操作 else: # 降级为坐标模拟 execute_action_by_coords(page, action_info)4.3 构建完整的自动化测试流单个指令的执行只是开始。一个完整的测试用例通常包含一系列步骤并且需要验证结果。我们需要设计一个状态机或工作流引擎。初始化会话启动浏览器打开初始URL。循环执行 a.捕获状态对当前页面截图。 b.指令输入获取当前测试步骤的自然语言指令可从用例文件读取。 c.模型推理截图指令发送给Qwen3-VL获取结构化动作。 d.动作执行在浏览器中执行解析出的动作。 e.等待与验证等待页面稳定如网络请求完成可选地进行结果验证可通过模型分析新截图判断“是否出现‘登录成功’的提示”。 f.步骤记录记录成功或失败。生成报告汇总所有步骤的执行情况。这个流程可以封装成一个简单的测试运行器。验证环节同样可以借助Qwen3-VL通过Prompt让其判断页面状态是否符合预期实现“视觉断言”。5. 实战演练一个完整的登录自动化测试案例让我们用一个具体的例子将上述所有环节串联起来。假设我们要测试一个虚构的电商网站https://demo-shop.com的登录功能。测试用例描述自然语言打开网站首页。点击页面右上角的“登录”链接。在用户名输入框中输入“test_user”。在密码输入框中输入“password123”。点击“登录”按钮。验证是否跳转到用户中心页面通过检查页面是否包含“我的账户”字样。步骤一准备测试脚本我们将上述用例保存为一个JSON或YAML文件。// test_case_login.json [ { step: 1, instruction: 打开网站首页, action: navigate, url: https://demo-shop.com }, { step: 2, instruction: 点击页面右上角的登录链接, action: infer // 需要模型推断 }, { step: 3, instruction: 在用户名输入框中输入 test_user, action: infer }, { step: 4, instruction: 在密码输入框中输入 password123, action: infer }, { step: 5, instruction: 点击登录按钮, action: infer }, { step: 6, instruction: 检查当前页面是否包含‘我的账户’这几个字, action: verify, expected: 我的账户 } ]步骤二编写测试运行器核心逻辑import json import time from playwright.sync_api import sync_playwright # ... 导入之前定义的 capture_page_screenshot, ask_qwen3_vl, execute_action_by_element 等函数 class NaturalLanguageTester: def __init__(self, model_api_url, api_key): self.model_api_url model_api_url self.api_key api_key self.playwright sync_playwright().start() self.browser self.playwright.chromium.launch(headlessFalse) # 非无头方便观察 self.context self.browser.new_context(viewport{width: 1280, height: 720}) self.page self.context.new_page() self.test_report [] def run_step(self, step_info): 执行单个测试步骤 step_num step_info[step] instruction step_info[instruction] print(f\n 执行步骤 {step_num}: {instruction}) if step_info.get(action) navigate: self.page.goto(step_info[url]) time.sleep(2) # 简单等待生产环境应用更智能的等待 self.test_report.append({step: step_num, status: passed, detail: f导航至 {step_info[url]}}) return True elif step_info.get(action) infer: # 1. 截图 screenshot_bytes self.page.screenshot() img_base64 encode_image_to_base64(screenshot_bytes) # 2. 调用模型推断动作 structured_prompt f【指令】{instruction}。请输出JSON。 # 使用之前设计好的完整Prompt model_response ask_qwen3_vl(img_base64, structured_prompt) try: action_cmd json.loads(model_response) except json.JSONDecodeError: self.test_report.append({step: step_num, status: failed, detail: f模型返回非JSON: {model_response[:100]}}) return False # 3. 执行动作 if action_cmd.get(action) ! none: execute_action_by_element(self.page, action_cmd) time.sleep(1) # 等待操作生效 self.test_report.append({step: step_num, status: passed, detail: f执行动作: {action_cmd}}) return True else: self.test_report.append({step: step_num, status: failed, detail: f模型未识别到可执行动作}) return False elif step_info.get(action) verify: # 视觉验证截图后让模型判断 screenshot_bytes self.page.screenshot() img_base64 encode_image_to_base64(screenshot_bytes) verify_prompt f当前网页截图是否包含文字‘{step_info[expected]}’请只回答‘是’或‘否’。 answer ask_qwen3_vl(img_base64, verify_prompt).strip().lower() if 是 in answer or yes in answer: self.test_report.append({step: step_num, status: passed, detail: f验证成功页面包含‘{step_info[expected]}’}) return True else: self.test_report.append({step: step_num, status: failed, detail: f验证失败页面不包含‘{step_info[expected]}’}) return False def run_test_case(self, case_path): 运行整个测试用例 with open(case_path, r) as f: test_steps json.load(f) all_passed True for step in test_steps: success self.run_step(step) if not success: all_passed False # 可以选择是否继续执行后续步骤 # break # 生成报告 print(\n *50) print(测试报告) for record in self.test_report: print(f步骤{record[step]}: {record[status]} - {record[detail]}) print(f总体结果: {通过 if all_passed else 失败}) return all_passed def close(self): self.context.close() self.browser.close() self.playwright.stop() # 使用示例 if __name__ __main__: tester NaturalLanguageTester(http://localhost:8000/v1, token-abc123) try: tester.run_test_case(test_case_login.json) finally: tester.close()运行这个脚本你将看到浏览器自动打开并尝试根据你的自然语言指令一步步完成登录操作最后给出验证结果。虽然这只是一个原型但它清晰地展示了从“语言描述”到“自动化执行”的完整闭环。6. 避坑指南与效能优化在实际应用中你会遇到各种挑战。以下是我在实践过程中总结的关键问题和优化建议。6.1 模型识别精度与稳定性问题问题模型可能认错元素如把“注册”按钮当成“登录”或者返回的坐标框不准确。对策Prompt优化在Prompt中强调“选择最可能的一个”、“优先选择按钮(button)、链接(a)、输入框(input)”等。可以加入少量示例Few-shot Learning。多模态模型微调如果有足够的标注数据截图标注元素位置指令可以对Qwen3-VL进行LoRA等方式的微调让其更擅长UI元素定位任务。融合传统定位器在关键、稳定的元素上可以混合使用。例如对于永远在顶部的导航栏可以备用一个CSS选择器。当模型识别置信度低于阈值时回退到传统定位方式。后处理校验模型返回坐标后可以截取该坐标区域的小图再用一个轻量级的分类模型或OCR验证一下小图内容是否与指令匹配。6.2 执行效率与速度瓶颈问题模型推理尤其是大模型耗时较长导致测试执行速度慢。对策使用量化模型如前所述GPTQ、AWQ量化能在几乎不损失精度的情况下大幅降低显存和加速推理。缓存与预热对于不变的页面或组件可以缓存模型的识别结果避免重复推理。并行化如果测试用例间无依赖可以使用多个浏览器实例并行执行。小模型专用化考虑使用专门针对UI元素检测训练的小模型如基于YOLO或DETR架构进行粗定位再用大模型进行精细理解和决策形成级联 pipeline。6.3 复杂交互与状态管理问题如何处理下拉菜单、拖拽、文件上传等复杂交互如何管理页面跳转、弹窗出现后的状态对策扩展动作集在Prompt和动作执行层定义更丰富的动作类型如select_dropdown、drag_and_drop、upload_file。状态感知在执行每个步骤后不仅截图还可以获取页面的URL、标题等元信息作为上下文传递给模型帮助它理解当前处于哪个页面或状态。超时与重试机制网络加载或元素出现可能需要时间。执行动作后需要设计智能等待如等待特定元素出现或网络空闲而非固定sleep。失败后应有重试逻辑。6.4 测试用例的设计与管理问题自然语言描述可能存在二义性不同的人写法不同不利于维护。对策制定描述规范建立团队内部的指令描述规范例如“点击[元素描述]”、“在[元素描述]中输入[文本]”、“验证页面包含[文本]”。用例可视化录制可以开发一个录制工具用户手动操作一遍系统自动录制截图和对应的自然语言描述可由用户补充或AI生成形成可回放的测试用例。与BDD框架结合可以考虑将自然语言指令集成到类似Cucumber的BDD行为驱动开发框架中用Given-When-Then的格式组织用例使结构更清晰。7. 未来展望与应用场景延伸基于视觉和自然语言的智能测试其潜力远不止于替代XPath。它正在开启一种新的测试范式。跨平台与跨端测试同一套自然语言测试用例理论上可以适配Web、移动端Android/iOS、甚至桌面应用因为核心是“看图操作”。只需要更换底层的截图和动作执行引擎如Appium for Mobile, Pywinauto for Desktop。探索性测试与异常发现我们可以指令AI进行探索如“浏览这个电商网站找到所有价格超过1000元的商品并点击查看详情”。或者让AI在测试过程中主动观察和报告视觉异常如“页面布局错乱”、“图片加载失败”。无障碍测试A11y通过自然语言询问“视力障碍用户如何找到搜索框”并结合屏幕阅读器的语义信息可以自动化验证应用的无障碍兼容性。RPA机器人流程自动化将这套技术应用于办公自动化处理那些没有API、只有GUI界面的老旧系统实现“描述即自动化”。当然这项技术目前仍处于早期阶段。模型的准确率、推理成本、复杂场景的处理能力都是需要持续优化的挑战。但它代表了一个明确的方向让测试变得更智能、更贴近人的直觉、更专注于业务逻辑而非技术细节。从我个人的实践来看将Qwen3-VL这类多模态大模型引入测试工作流最大的价值不是立刻取代所有现有脚本而是作为一种强大的补充和生产力放大器。它特别适合快速生成原型测试、覆盖那些因UI频繁变动而难以维护的测试点、以及执行一些基于视觉验证的特定场景。对于测试工程师而言学习并运用这项技术更像是掌握了一种新的“编程语言”——一种更高级、更抽象的自然语言来与测试系统进行对话。