1. 项目概述当大模型遇上自动化测试最近在搞自动化测试的朋友估计都听过一个词AI辅助生成。没错现在让大语言模型LLM来写测试脚本已经不是科幻片里的情节了。我手头这个项目就是围绕“Qwen3.5-4B-Claude模型自动化测试脚本生成”展开的一次深度实践。简单说就是利用像Qwen3.5、Claude这类大模型把我们用自然语言描述的测试需求直接转换成可执行的Selenium或Appium自动化测试代码。这听起来很美好对吧但实际干起来你会发现从一句“帮我测试一下登录功能”到一段能稳定运行的driver.find_element(By.ID, “username”).send_keys(“testuser”)中间隔着十万八千里。模型的选择、提示词Prompt的工程、生成代码的可靠性、以及如何集成到现有工作流每一个环节都是坑。我花了大量时间折腾了本地部署的Qwen3.5、尝试了Claude的API、也研究了各种自动化测试框架的集成目的就是摸索出一套从需求描述到最终代码的、切实可行的自动化生成路径。这篇文章我就把这些踩过的坑、试出来的有效方法以及那些模型不会告诉你的“潜规则”一次性讲清楚。无论你是想提升测试效率的测试工程师还是对AI应用开发感兴趣的开发者相信都能从中找到可以直接“抄作业”的实操方案。2. 核心思路与方案选型为什么是Qwen3.5和Claude直接让GPT-4或者Claude-3 Opus来干这个活行不行当然行效果可能还更好。但问题在于成本和可控性。对于企业内部的持续集成CI流水线或者需要频繁生成、修改脚本的场景每次都调用昂贵的闭源API不仅费用高数据安全性和响应速度也是问题。因此本地化或可控的模型方案成为了更务实的选择。2.1 模型能力对比与选型逻辑我主要评估了Qwen2.5-7B-Instruct、Qwen2.5-14B-Instruct以及Claude 3 Haiku通过API。选择它们的原因如下代码能力与指令遵循生成测试脚本模型必须深刻理解编程语法Python/Java、测试框架pytest/unittest以及Web/移动端元素定位逻辑。Qwen2.5系列在代码生成基准如HumanEval上表现优异且对中文指令的理解很好这对于国内团队描述需求非常友好。Claude 3 Haiku虽然体积小但在代码生成和逻辑推理上非常扎实且输出格式规整。上下文长度与成本测试需求描述可能包含页面截图需转Base64、复杂的操作流程文本这需要模型有足够的上下文窗口。Qwen2.5-14B支持128K上下文能吞下非常详细的规格说明。而Haiku的API调用在速度和成本间取得了很好的平衡适合作为云端备选方案。本地部署可行性Qwen2.5-7B/14B模型可以通过Ollama、vLLM或Transformers库轻松部署在消费级显卡如RTX 4090甚至Mac M2/M3上。这意味着你可以搭建一个内网可用的代码生成服务完全掌控数据和流程。注意网上常说的“Qwen3.5-4B”可能是一个泛指或特定版本的微调模型。在官方模型库中更常见的发布是Qwen2.5系列如7B, 14B, 32B。如果追求极致的轻量化可以寻找基于Qwen2.5-1.5B或3B进行SFT监督微调的代码专用模型但生成复杂脚本的能力会打折扣。本项目讨论的核心是7B及以上的模型。最终我的方案是双引擎驱动日常高频、对延迟敏感的任务使用本地部署的Qwen2.5-7B当遇到极其复杂、需要更强推理能力的场景如从模糊的需求中推导出测试用例则通过API调用Claude 3 Haiku作为补充。这样既保证了效率和控制力又在关键时刻有“外援”。2.2 整体技术架构设计整个系统的目标不是创造一个全自动的“黑盒”而是一个“AI辅助编程”的增强环境。其核心工作流如下自然语言需求 - 结构化Prompt工程 - 大模型调用 - 生成代码 - 代码验证与修正 - 集成到测试套件为了实现这个流程我搭建了以下组件需求解析与增强模块将用户简单的描述如“测试登录失败”转化为结构化的Prompt。这包括自动补充上下文例如“我们使用Python语言pytest框架Selenium WebDriver假设Base URL是https://example.com请生成一个测试函数。”模型服务层封装了对本地Ollama运行Qwen2.5和Claude API的调用。提供统一的接口根据需求复杂度、当前负载自动选择模型。代码后处理模块模型生成的代码可能缺少必要的import语句、使用过时的API或者元素定位器不准确。这个模块会进行简单的静态检查、自动添加标准库导入、并调用一个“元素定位建议器”。验证与反馈循环生成的脚本不会直接投入生产。而是先在一个沙盒环境中运行捕获运行错误如元素未找到、超时。将这些错误信息连同原始需求再次喂给模型让它进行修正。通常经过1-2轮迭代就能得到可用的脚本。这个架构的关键在于认识到大模型不是一步到位的代码编译器而是一个需要引导和纠正的强大协作者。3. Prompt工程实战如何与模型高效“对话”让大模型生成可用的测试代码80%的功夫在Prompt设计上。一个糟糕的Prompt会得到天马行空或根本无法运行的代码。经过大量实验我总结出一个高效的Prompt模板它包含以下几个核心部分3.1 结构化Prompt模板详解你是一个资深的自动化测试开发专家精通Selenium和Appium。请根据以下需求生成完整、可直接运行的Python测试代码。 ## 项目上下文 - 测试类型[Web自动化 / Android APP自动化 / iOS APP自动化] - 编程语言Python 3.8 - 测试框架pytest - 驱动工具Selenium 4.x / Appium 2.x - 基础URL/包名[例如https://demo.testfire.net / com.example.app] - 浏览器/设备[例如Chrome / Android Emulator (Pixel 4, API 30)] ## 测试需求描述 [用清晰、无歧义的自然语言描述测试场景。例如测试用户登录功能。输入错误的密码正确用户名为‘admin’错误密码为‘wrongpass’验证页面上出现了‘Invalid username or password’的错误提示信息。] ## 输出要求 1. 生成一个完整的pytest测试函数函数名需具有描述性如test_login_with_invalid_password。 2. 代码必须包含所有必要的import语句selenium.webdriver, pytest, time等。 3. 使用显式等待WebDriverWait来定位元素避免使用time.sleep进行固定等待。 4. 元素定位优先使用ID、CSS Selector或XPath。如果需求中未指定请使用合理的定位策略并在代码注释中说明。 5. 包含必要的断言assert验证测试点。 6. 在测试结束时妥善关闭WebDriver/Driver。 7. 在代码最后以注释形式简要说明代码的逻辑步骤。这个模板为什么有效因为它模拟了人类测试开发工程师接到任务时的思考框架明确环境约束 - 理解具体任务 - 遵守编码规范。它限定了技术的选型给出了明确的输出格式指令并灌输了最佳实践如使用显式等待。3.2 高级技巧提供“示例”与“元素映射表”对于更复杂的页面模型可能无法凭空猜出元素的定位器。这时我们可以提供更多上下文。技巧一提供页面元素映射Page Element Map在需求描述后附加一个简单的字典或JSON描述关键元素的大致信息。## 页面元素参考信息 { “用户名输入框”: “可能ID为‘username’或name为‘user’” “密码输入框”: “可能ID为‘password’” “登录按钮”: “可能是一个class包含‘btn-login’的button” “错误提示区域”: “可能ID为‘error-message’或class为‘alert-error’” }模型会利用这些线索生成更可能成功的定位代码例如driver.find_element(By.ID, “username”)或driver.find_element(By.CSS_SELECTOR, “.btn-login”)。技巧二少样本学习Few-Shot Learning在Prompt中先给出一两个正确的代码示例。这对于让模型学习你团队特定的代码风格比如是否使用Page Object模式非常有效。## 代码风格示例 python # 示例一个简单的搜索测试 def test_search_functionality(driver): # driver是pytest fixture search_box WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.NAME, “q”)) ) search_box.send_keys(“Selenium” Keys.RETURN) # ... 更多断言然后再说“请按照上述风格生成一个登录测试。”经过这样调教的模型生成的代码质量会有质的飞跃风格统一且更贴近实际项目。 ## 4. 从生成到执行完整实操流程 光说不练假把式。我们以一个具体的Web登录测试为例走通从需求输入到脚本运行的全过程。假设我们使用本地Ollama部署的Qwen2.5-7B-Instruct模型。 ### 4.1 环境准备与模型部署 首先确保你的开发环境已经就绪。 1. **安装Ollama**前往Ollama官网下载并安装。对于Mac/Linux通常一行命令搞定。 2. **拉取并运行模型**在终端执行 ollama run qwen2.5:7b-instruct。首次运行会自动下载模型约4.7GB。运行后它会启动一个本地的API服务默认在11434端口。 3. **安装Python依赖** bash pip install selenium pytest requests # 安装对应的浏览器驱动如ChromeDriver并确保其在PATH中 ### 4.2 构建请求与获取生成代码 我们编写一个Python客户端脚本向Ollama API发送构造好的Prompt。 python import requests import json def generate_test_code(prompt): url “http://localhost:11434/api/generate” payload { “model”: “qwen2.5:7b-instruct”, “prompt”: prompt, “stream”: False, “options”: { “temperature”: 0.2, # 低温度让输出更确定、更少创造性 “num_predict”: 2048 # 最大生成token数 } } response requests.post(url, jsonpayload) if response.status_code 200: return response.json()[“response”] else: raise Exception(f“请求失败: {response.status_code}”) # 构建我们的Prompt test_prompt “””你是一个资深的自动化测试开发专家...此处填入上一节完整的模板和需求...””” generated_code generate_test_code(test_prompt) print(“生成的代码”) print(generated_code)执行这个脚本你会得到模型返回的一大段文本其中应该包含了完整的Python代码。将其保存为test_generated_login.py。4.3 生成代码示例与解析以下是一次实际运行中Qwen2.5-7B生成的代码经过轻微格式整理import pytest from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.keys import Keys import time pytest.fixture(scope“function”) def driver(): # 初始化WebDriver这里使用Chrome options webdriver.ChromeOptions() options.add_argument(‘--headless’) # 无头模式适合CI环境 driver webdriver.Chrome(optionsoptions) driver.maximize_window() driver.get(“https://demo.testfire.net”) yield driver driver.quit() def test_login_with_invalid_password(driver): “”“测试使用错误密码登录时是否显示正确的错误信息。”“” # 步骤1定位用户名输入框并输入 username_field WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, “uid”)) ) username_field.clear() username_field.send_keys(“admin”) # 步骤2定位密码输入框并输入错误密码 password_field WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, “passw”)) ) password_field.clear() password_field.send_keys(“wrongpass”) # 步骤3定位并点击登录按钮 login_button WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.NAME, “btnSubmit”)) ) login_button.click() # 步骤4等待并验证错误信息出现 error_message WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, “_ctl0__ctl0_Content_Main_message”)) ) actual_error_text error_message.text expected_error_text “Invalid username or password.” # 断言错误信息包含预期文本 assert expected_error_text in actual_error_text, f“错误信息不符。预期包含‘{expected_error_text}’实际为‘{actual_error_text}’” print(“测试通过成功捕获到无效登录错误信息。”) # 代码逻辑说明 # 1. 使用pytest fixture初始化并清理浏览器驱动。 # 2. 使用显式等待WebDriverWait确保元素加载完成后再操作提高稳定性。 # 3. 按照登录流程顺序操作输入用户名、密码、点击登录。 # 4. 使用显式等待定位错误信息元素并获取其文本。 # 5. 使用assert语句验证获取的文本是否包含预期的错误信息。 # 6. 测试完成后fixture会自动退出浏览器。代码质量点评优点结构完整包含了import、fixture、测试函数。使用了WebDriverWait显式等待这是最佳实践。定位器使用了ID和Name相对稳定。断言清晰并包含了有用的错误信息。潜在问题它直接使用了某个演示网站demo.testfire.net的具体元素ID如“uid”,“passw”。这说明模型从我给的示例URL中“学习”并应用了具体定位器。在实际使用中我们需要确保提供的“元素参考信息”或示例URL与真实被测系统一致或者模型具备根据通用描述生成更泛化定位策略的能力如By.XPATH, “//input[placeholder‘Username’]”。4.4 执行与集成现在你可以直接在命令行运行这个生成的测试pytest test_generated_login.py -v。如果目标网站可访问且元素ID未变测试应该能够通过。为了将其集成到现有项目你需要代码审查与微调将生成的代码放入项目的测试目录如tests/。根据项目规范调整fixture可能你们使用一个全局的conftest.py来提供driver并确保定位器与当前页面版本匹配。纳入版本控制像管理其他源代码一样管理这些AI生成的脚本。接入CI/CD在Jenkins、GitLab CI或GitHub Actions的配置中加入运行这些测试的步骤。5. 进阶应用处理复杂场景与Appium移动端测试简单的线性操作输入-点击-断言模型处理得不错。但自动化测试中真正的挑战是复杂场景文件上传、下拉选择、iframe、异步加载、移动端手势等。5.1 复杂Web交互的Prompt技巧对于复杂操作需要在Prompt中提供更精确的“操作剧本”。示例测试一个带文件上传和异步提交的表单## 测试需求描述 测试一个“用户反馈”表单。操作步骤 1. 在ID为“feedback-title”的输入框中输入“页面加载速度慢”。 2. 在ID为“feedback-desc”的文本域中输入详细描述“首页图片加载时间超过5秒”。 3. 点击文本“选择文件”会触发一个文件选择对话框。需要上传一个位于本地路径“/tmp/test_image.jpg”的图片文件。 4. 从ID为“feedback-type”的下拉框中选择选项“性能问题”。 5. 点击ID为“submit-feedback”的按钮。 6. 提交后页面会异步显示一个提示框ID为“toast-message”需要等待其出现并验证其文本包含“感谢您的反馈”。 请生成对应的测试代码注意处理文件上传和异步等待。关键点在Prompt中明确指出了“文件选择对话框”和“异步显示”这会引导模型使用send_keys直接输入文件路径而不是尝试模拟点击无法由WebDriver控制的系统对话框并对提示框使用EC.visibility_of_element_located进行等待。5.2 Appium移动端测试代码生成将上述模式迁移到Appium非常直接核心是更新“项目上下文”和提供移动端特有的能力如desired_capabilities。Appium专用Prompt上下文调整## 项目上下文 - 测试类型Android APP自动化 - 编程语言Python 3.8 - 测试框架pytest - 驱动工具Appium 2.x - 设备配置Android Emulator, Android 13, 设备名“Pixel_4_API_33” - APP信息APK路径“./app/myapp.apk”包名“com.example.myapp”主Activity“com.example.myapp.MainActivity”模型会根据这个上下文生成使用appium.webdriver以及正确desired_capabilities的代码。对于移动端特有的操作如滑动、长按需要在需求描述中明确写出。示例生成一个滑动列表的测试## 测试需求描述 在APP主页面可通过ID为“home_list”的ListView访问执行向下滑动操作直到找到文本内容包含“查看更多”的元素然后点击该元素。一个训练良好的模型会生成类似下面的代码片段from appium.webdriver.common.appiumby import AppiumBy from appium.webdriver.common.touch_action import TouchAction # ... driver初始化 ... home_list driver.find_element(AppiumBy.ID, “home_list”) # 使用Appium特有的滑动查找 driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR, ‘new UiScrollable(new UiSelector().resourceId(“home_list”)).scrollIntoView(new UiSelector().textContains(“查看更多”))’).click()6. 避坑指南与常见问题排查在实际操作中你会遇到各种各样的问题。下面是我总结的“血泪”经验。6.1 模型生成代码的典型问题与修复问题现象可能原因解决方案代码无法运行ImportError模型使用了不存在的库或错误的方法名。在后处理模块中添加规则将模型可能误写的from selenium.webdriver.common.by import By检查并修正。或者在Prompt中强制指定版本和导入语句模板。元素定位失败 (NoSuchElementException)模型生成的定位器如ID、XPath与实际页面不符。1.强化Prompt提供更精确的元素参考信息。2.使用智能定位在后处理中可以集成一个简单的启发式规则如果ID定位失败尝试CSS Selector或XPath备用方案。3.人工审核对于关键测试生成定位器后由人工通过浏览器开发者工具确认一次。等待逻辑问题 (TimeoutException)模型设置的等待时间不足或等待条件EC不对。在Prompt中强调使用显式等待并给出等待条件的示例。生成代码后可以统一将等待时间调到一个安全值如15秒。代码逻辑冗余或低效模型可能生成多个重复的find_element调用或使用了time.sleep。在后处理阶段进行简单的代码分析合并重复定位并将固定的sleep替换为针对特定条件的等待。生成的代码不符合项目规范模型不知道你们团队使用的Page Object、Fixture管理方式。使用少样本学习Few-Shot。在Prompt中提供1-2个你们项目中的真实测试文件作为示例让模型模仿其风格和结构。6.2 提升生成代码的稳定性分而治之不要试图让模型一次性生成一个包含10个复杂步骤的巨型测试用例。将其拆分成多个独立的小需求如“生成登录函数”、“生成搜索函数”然后由人工或另一个脚本将它们组合起来。这样生成的成功率更高也便于维护。引入验证循环这是最关键的一步。建立一个自动化的验证流程步骤一模型生成代码。步骤二系统自动在无头浏览器/模拟器中运行该代码。步骤三捕获运行日志和错误如异常堆栈。步骤四将错误信息连同原始需求再次发送给模型要求其“根据以下错误修复代码”。 通常经过1-2轮修正代码就能运行通过。这个过程可以完全自动化。维护一个“定位器知识库”对于你的被测系统将稳定的元素定位器如导航栏、页脚等通用组件维护成一个JSON文件或数据库。在生成Prompt时自动将这些已知的定位器信息作为上下文注入可以极大提高生成代码的准确性。6.3 关于Claude API的使用注意如果你使用Claude API如Haiku除了关注成本还要注意速率限制API有每分钟/每天的调用次数限制在CI流水线中大量使用时需要设计队列和重试机制。输出格式化Claude的API响应是结构化的JSON直接提取content字段即可。相比本地模型它的输出通常更规整代码格式错误更少。上下文管理对于多轮修正对话你需要妥善管理messages历史将之前的对话和错误信息都包含进去让模型理解上下文。7. 项目总结与未来展望折腾这一套东西最终目的不是取代测试工程师而是把他们从重复、繁琐的脚本编写中解放出来去从事更有价值的测试设计、探索性测试和质量分析工作。经过几个月的实践我发现这个“AI辅助生成”的模式在回归测试用例的快速补充、新功能上线时的冒烟测试脚本生成、以及将手工测试用例转化为自动化脚本这几个场景下效率提升尤为明显。最大的体会是成功的核心在于人机协作的流程设计。你需要像一个导师一样通过精心设计的Prompt教学大纲和验证反馈循环批改作业去引导和纠正模型这个“实习生”。一开始生成的代码可能漏洞百出但随着你不断优化Prompt、积累修复案例、完善后处理规则这个“实习生”会越来越靠谱。目前我已经将这套系统用于几个中型Web项目的测试脚本辅助生成平均能减少约40%的基础脚本编写时间。对于移动端Appium脚本由于元素定位的复杂性更高收益约在20-30%但依然显著。下一步我计划探索两个方向一是将视觉模型VLM接入实现“对着屏幕截图说需求直接生成操作代码”的可能性二是构建一个更智能的“测试流程理解器”它能理解更抽象的需求如“遍历所有商品分类”并自动分解成一系列可执行的子步骤再调用代码生成模块逐一实现。这条路还很长但起点已经足够令人兴奋。如果你也在尝试类似的事情欢迎交流那些只有踩过才知道的坑。