基于Yi-Coder-1.5B的自动化测试：Selenium脚本生成
1. 当测试工程师还在手动写脚本时，有人已经用AI自动生成了
电商网站上线前要测登录、购物车、支付流程；SaaS系统每次迭代都要验证核心功能是否正常；金融类应用对UI稳定性的要求更是严苛到毫秒级。这些场景里，测试团队每天面对的是成百上千条测试用例，而每一条都得对应一段Selenium脚本——定位元素、模拟点击、等待加载、断言结果。重复劳动多、维护成本高、新人上手慢，成了很多团队的共同痛点。
去年底，我们团队在重构一套内部管理系统的测试体系时，尝试把Yi-Coder-1.5B模型接入测试工作流。它不是那种需要GPU集群才能跑的大模型，一台普通开发机就能启动，但生成Selenium脚本的能力却出乎意料地扎实。最让我们惊喜的是，它能准确理解“点击右上角头像后选择退出登录”这样的自然语言描述，并输出结构清晰、可直接运行的Python代码，覆盖了90%以上的常规UI操作场景。
这不是概念演示，而是真实落地的工程实践。接下来，我会带你看看这套方案是怎么跑起来的，它解决了哪些实际问题，又有哪些值得借鉴的经验。
2. Yi-Coder-1.5B为什么特别适合测试脚本生成
2.1 小而精的代码专家，专为开发者设计
Yi-Coder系列模型从诞生起就有一个明确的定位：做懂代码的轻量级助手。1.5B这个版本尤其适合本地部署和快速响应——866MB的模型体积，连中端笔记本都能轻松加载；128K的上下文长度，意味着它能同时理解一份完整的测试用例文档和对应的页面HTML结构；支持52种编程语言，其中对Python、Java、JavaScript这三大测试常用语言的理解深度，在开源模型中属于第一梯队。
对比其他通用大模型，Yi-Coder-1.5B在代码生成任务上有个明显优势：它不会为了“显得聪明”而堆砌复杂逻辑。比如你让它写一个“输入用户名密码并点击登录”的脚本，它不会擅自加入异常重试、日志记录、配置中心调用等额外功能，而是专注把基础动作做准、做稳。这种克制反而让生成的代码更贴近测试工程师的真实需求。
2.2 理解测试语义，不止是语法转换
很多开发者误以为AI生成测试脚本就是“把中文翻译成Python”，其实远不止于此。真正的难点在于理解测试意图背后的业务逻辑。举个例子：
“在商品详情页，找到‘立即购买’按钮，如果按钮文字是‘缺货中’则跳过，否则点击并等待订单确认弹窗出现”
这段描述里包含了条件判断、状态检查、动态等待等多个测试关键点。Yi-Coder-1.5B能准确识别出：
- “立即购买”是待定位的元素文本
- “缺货中”是需要校验的动态文本内容
- “订单确认弹窗”是预期出现的页面元素
- 整个流程需要显式等待机制
它生成的代码会自然包含WebDriverWait、expected_conditions等Selenium核心组件，而不是简单用time.sleep()硬等。这种对测试语义的深层理解，源于它在训练数据中大量接触过开源项目的测试用例和CI/CD脚本。
2.3 开箱即用的本地化体验
我们不需要对接任何云服务或API密钥，整个流程完全在内网完成。用Ollama一键拉取模型后，通过几行Python代码就能调用：
from ollama import chat response = chat( model='yi-coder:1.5b', messages=[{ 'role': 'user', 'content': '生成Selenium脚本：在登录页面输入用户名"testuser"和密码"123456"，点击登录按钮，等待首页标题"欢迎回来"出现' }], options={'temperature': 0.3} ) print(response['message']['content'])响应速度在2-5秒之间，足够支撑日常的交互式编写。更重要的是，所有提示词（prompt）和生成结果都留在本地，符合企业对数据安全的基本要求。
3. 从测试用例到可执行脚本的完整实践
3.1 构建你的测试提示词模板
提示词设计是整个流程的关键。我们经过几十次迭代，总结出一套针对UI测试的高效模板，它包含三个核心要素：
上下文（Context）：告诉模型当前要测试的系统类型和约束条件
任务（Task）：用清晰动词描述具体操作步骤
格式（Format）：明确指定输出代码的语言、框架和结构要求
下面是一个我们团队正在使用的实际模板：
你是一名资深Selenium测试工程师，正在为一个基于Vue3的电商后台系统编写自动化测试脚本。 请严格遵循以下要求： - 使用Python 3.9+和Selenium 4.x - 所有元素定位优先使用CSS选择器，其次XPath - 必须使用WebDriverWait进行显式等待，超时时间设为10秒 - 每个操作后添加简短注释说明目的 - 不要包含driver初始化和quit()调用，只生成核心操作部分 现在请生成脚本：{{测试用例描述}}把{{测试用例描述}}替换成实际内容，比如：“在用户管理列表页，点击ID为'usr-1024'的用户所在行的‘编辑’按钮，修改姓名字段为‘张三_测试’，点击保存，验证页面提示‘更新成功’”
3.2 看看它生成的实际效果
我们拿一个真实案例来演示。这是某CRM系统的测试用例：
“在客户列表页，使用搜索框输入‘北京科技’，点击搜索按钮，验证结果表格中第一行的客户名称包含‘北京科技’，且状态列显示‘已签约’”
Yi-Coder-1.5B生成的代码如下（已做脱敏处理）：
# 在搜索框中输入关键词 search_input = WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, "input[placeholder='请输入客户名称']")) ) search_input.clear() search_input.send_keys("北京科技") # 点击搜索按钮 search_button = WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.CSS_SELECTOR, "button[type='submit']")) ) search_button.click() # 等待搜索结果加载完成 first_row = WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, "tbody tr:first-child")) ) # 验证第一行客户名称包含关键词 name_cell = first_row.find_element(By.CSS_SELECTOR, "td:nth-child(2)") assert "北京科技" in name_cell.text, f"客户名称未包含关键词，实际值：{name_cell.text}" # 验证状态列为'已签约' status_cell = first_row.find_element(By.CSS_SELECTOR, "td:nth-child(5)") assert status_cell.text == "已签约", f"状态列不匹配，实际值：{status_cell.text}"这段代码可以直接粘贴到现有测试框架中运行。它没有使用任何魔法字符串，所有CSS选择器都符合前端团队的规范；等待逻辑覆盖了可能的网络延迟；断言信息清晰，失败时能快速定位问题。
3.3 处理复杂场景的实用技巧
当然，不是所有用例都这么规整。我们遇到过几个典型挑战，也摸索出了应对方法：
动态ID问题：前端经常给元素加随机ID，比如id="btn-submit-abc123"。我们的解决方案是在提示词中强调：“避免使用ID定位，优先用CSS选择器，例如根据按钮文字‘提交’或父容器class来定位”。
异步加载弹窗：有些弹窗是AJAX加载的，DOM结构会动态变化。这时我们在提示词里补充：“对于弹窗类元素，使用presence_of_element_located而非visibility_of_element_located，确保元素已插入DOM即可”。
多步骤依赖：比如“先创建订单，再进入订单列表页找到刚创建的订单”。我们拆分成两个独立提示词，第一个生成创建脚本并返回订单号，第二个把订单号作为变量注入提示词：“在订单列表页搜索订单号{{order_id}}……”。
这些技巧不需要修改模型，纯粹靠提示词工程就能解决80%的边界情况。
4. 实际落地中的收益与注意事项
4.1 真实提升的效率指标
我们统计了过去三个月的测试脚本开发数据：
- 新增测试用例平均编写时间从42分钟降至9分钟，效率提升78%
- 脚本首次运行通过率从63%提升到89%，减少了大量调试时间
- 新人工程师上手周期从2周缩短到3天，能独立编写基础用例
- 维护成本降低约40%，因为生成的代码风格统一，定位问题更快
最直观的感受是，测试工程师终于能把精力从“怎么写代码”转移到“怎么设计用例”上。以前花半天写一个复杂流程的脚本，现在半小时就能生成初稿，剩下时间专注在业务逻辑验证和边界条件覆盖上。
4.2 那些它还做不到的事
必须坦诚地说，Yi-Coder-1.5B不是万能的。我们在实践中发现几个明确的边界：
- 不理解私有组件库：如果项目用了自研的UI组件（比如封装过的表格组件），它无法识别内部结构，需要人工补充定位策略
- 无法处理验证码：涉及图片验证码、滑块验证等安全机制的场景，仍需人工介入或集成专门的识别服务
- 复杂断言能力有限：比如“验证图表数据趋势与上月相比增长15%”，它能生成获取数据的代码，但计算逻辑需要人工补全
我们的应对策略很务实：把AI当作高级代码补全工具，而不是全自动测试机器人。它负责生成80%的样板代码，工程师专注处理那20%需要领域知识的部分。
4.3 团队协作模式的转变
最大的改变其实是工作方式。现在我们建立了新的协作流程：
- 测试分析师写出自然语言用例（不再写伪代码）
- 测试工程师用提示词模板生成初版脚本
- 前端工程师参与Code Review，重点检查元素定位是否符合当前DOM结构
- 自动化脚本纳入CI流水线，每日构建时自动运行
这个流程让各角色回归本职：分析师专注业务逻辑，工程师专注技术实现，前端保障UI稳定性。意外的是，前端同事反馈说，他们现在更愿意提前提供稳定的CSS类名，因为知道这些会直接影响自动化脚本的健壮性。
5. 让AI测试真正为你所用的建议
回看这几个月的实践，有几个经验值得分享：
先从高频场景切入：不要一上来就挑战最复杂的流程。我们最先落地的是登录、列表搜索、表单提交这类重复度高、结构稳定的场景，快速建立团队信心后再逐步扩展。
建立自己的提示词库：把验证有效的提示词按场景分类存档，比如“表单操作类”、“弹窗处理类”、“数据校验类”。新成员入职时，直接提供这份“傻瓜式模板”，比讲原理更有效。
保持对生成代码的敬畏心：我们规定所有AI生成的代码必须经过人工审查才能合入主干。不是不信任AI，而是测试代码一旦出错，影响的是整个质量门禁。这种审慎态度反而让团队对AI的能力更加认可。
关注长期维护性：在提示词里强调“生成的代码要便于后续维护”，比如要求使用有意义的变量名、添加必要注释、避免过长的链式调用。短期看多花几秒，长期看节省的是无数调试时间。
最后想说的是，技术的价值不在于它有多炫酷，而在于能否让一线工程师少写几行重复代码、少熬几个夜、少背几次锅。Yi-Coder-1.5B带给我们的，正是这样一种踏实的生产力提升——它不取代测试工程师，而是让工程师更像一个真正的工程师。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
