最近团队里有个年轻测试工程师往工作群里发了一张截图CI服务器上三百多条Selenium用例跑了一整夜最后通过的不到六成剩下的失败里有一半连失败原因都看不明白。他配了一句挺丧的话“每天早上醒来第一件事不是看需求文档而是看成堆的失败报告我不是在找Bug是在猜测试机器人为什么又把用例跑挂了。”这话干过自动化测试的人都懂。我们花大量精力搭建测试机器人初衷是把人从重复劳动里解放出来可现实往往是它反而成了新的劳动来源而且这个劳动比手工点鼠标更让人心累。借用一下《资本论》这个有点反差的书名当个引子我声明在先咱们不聊政治经济学纯粹借“劳动”与“资本”两个词说事自动化测试里我们到底在积累什么机器到底在替人做什么人和机器之间的边界是不是正在走向一个畸形循环这篇文章想认真聊一聊的就是自动化测试中的人机协作危机以及它可能的进化方向。1. 测试资产是怎么堆成山的自动化测试里的“原始积累”1.1 从几十条脚本到上万条用例资产在膨胀任何一条测试线几乎都逃不过这样的发展轨迹刚开始只是想把手头最重复的回归用例自动化跑起来用了Pytest加上Selenium几条脚本跑通团队很开心。接着领导觉得这条路走得通下了指标——“覆盖率要上去”于是脚本数量从几十涨到几百再涨到上千再遇到平台化建设用例数直接破万。我们通常把这件事叫“积累测试资产”听起来确实很正面只是很少有人在积累的过程中停下来盘点这些资产里有多少是真正能生钱的生产资料有多少是躺在仓库里的库存又有多少其实是负资产以我见过的一个真实项目为例一个中大型Web应用自动化用例两千多条每天定时在CI上全量跑一遍耗时三小时左右。表面上看资源占用不小更扎心的是失败率长期徘徊在四成。失败里有环境连不上、测试数据被脏掉、元素选择器失配、接口返回结构变了真正发现产品缺陷的失败平均一周不超过十条。两千多条用例每天真正产生决策价值的可能只有那十条其余全是在制造噪音。这就是典型的“资产膨胀期”数量上去了质量下来了价值密度稀释得厉害。测试机器人看起来很忙但忙并不等于有效。1.2 用例资产的三种类型与真实的“资产负债”我在多个团队做过一次简单的资产盘点把自动化用例按可维护性和实际产出来分类大致是这三类资产类型特点维护态度可复用资产稳定、有明确业务断言、失败时能直接定位真Bug值得投入持续维护一次性资产为了某个版本临时写的回归用例版本过了就没价值定期归档或清理负资产常年失败、无人修复、报告里没人敢删的用例必须尽快处理否则拖垮整体信任负资产是最可怕的。大家可能都有这种经验某个用例连续一个月天天失败一开始还有人去看后来所有人默认跳过它更糟的是报告里那一堆红叉已经没人当回事了。红叉不再代表产品有问题而是代表“机器人又在闹脾气”。当自动化测试的结果失去信号意义时整个测试线和测试机器人就失去了存在的价值。所以如果真要套“原始积累”的说法我想说的是自动化测试的资产积累不是脚本数量的堆叠而是可复用用例、稳定的执行环境、可解释的失败报告这三者形成的正向循环。缺了任何一环资产就会变成库存甚至负资产。2. 危机真正的名字不是工具不行是人机边界错了2.1 脆弱脚本最常见的六个导火索自动化测试跑不稳团队第一反应往往是换框架Selenium不行换PlaywrightAppium慢换新工具接口测试不好写换平台。但框架解决不了所有问题因为大部分失败根本不是框架本身的锅。根据我多年排查的经验脆弱脚本的原因基本集中在下面这六类页面结构变化前端改版某个按钮的class从btn-primary改成了btn-confirm元素定位直接失效。异步时序不稳定页面还没渲染完脚本就开始找元素于是要靠各种sleep和显式等待“蒙”时序。测试数据互相污染用例依赖的账号、订单、商品数据被另一条用例改了串数据导致断言失败。环境差异本地能过、CI上挂开发环境能过、预发环境挂浏览器版本和驱动版本不匹配。接口契约漂移后端字段名变了类型从string改成long接口自动化测试没跟上。框架和依赖升级一个无关依赖的升版导致整个执行链路崩掉。你仔细看这一串会发现一个共同特征测试机器学习的是“剧本”但业务系统每天都在“即兴演出”。测试机器人不认业务只认选择器和响应结构任何超出剧本的变化对它来说都是灾难。人必须不停地修改剧本去适配业务的变化这不是人机协作而是人在给机器当保姆。2.2 失败分类把“机器出错”和“产品出错”切开解决危机第一步是先让失败报告说人话。我强烈建议所有做自动化测试的团队从第一天就建立失败原因标签体系每条失败的用例必须打上原因分类而且分类要落到能直接定位问题的粒度。这里给出我常用的失败分类表失败类型典型表现责任归属响应动作环境类失败依赖服务重启、容器资源不足、网络超时测试基础设施团队自动重试或环境巡检数据类失败断言值不对、数据被篡改、脏数据残留测试数据团队数据工厂重建或用例隔离框架类失败选择器失效、等待超时、驱动版本不匹配自动化开发团队框架修复或登录态维护真实产品缺陷页面报错、接口返回错误、业务流程中断产品研发团队提交缺陷单阻塞发版没有这个分类体系失败报告就是一个大杂烩每个人看到红叉都要从头开始查人力消耗巨大。有了分类体系之后很多失败可以用规则和脚本自动归因人的精力能集中到真正需要判断力的“真实产品缺陷”上。这一步表面上是数据治理本质上是在给人和机器画清晰的分工边界。2.3 信任崩塌的恶性循环自动化测试还有一个特别隐蔽的危机叫作“信任崩塌”。它的循环路径大概是这样的用例失败太多工程师看不过来于是开始选择性忽略。失败的用例没人修失败率继续升高。重要版本发布前自动化测试报告因为噪音太大无法作为质量门禁的参考依据。管理层发现自动化投入了大量资源却没挡住线上事故开始质疑价值。测试团队为了自证价值又加更多用例进一步加剧噪音。这个循环走到第三步就已经很危险了。我在不少团队见过自动化测试报告沦为“演示工具”周报里截一张覆盖率图但真正发版决策根本不敢依赖它。这不是机器人的错是人机协作的闭环断了——机器不会自我判断失败是否重要人又没有持续反馈校准最后当然是一起摆烂。所以我说自动化测试危机的根源不是工具不够先进而是我们从来没认真设计“人教机器、机器反馈人”的闭环。要建立这个闭环先得有资产治理紧接着得有让机器理解业务意图的新方式这就是下面要聊的进化方向。3. 让测试机器人学会“读需求”AI Agent生成测试脚本的落地路径3.1 人工写脚本的成本上限决定了必须换一种交互方式很多人力写脚本维护脚本的团队最终都会撞到一堵墙自动化用例的编写速度根本赶不上业务迭代的速度。一个复杂流程的UI自动化用例从分析、写脚本到调试通过至少需要半天。而业务一天可能改三处脚本维护的债务越滚越大。解决这个问题的方向不是写更快的脚本而是让机器直接理解人的意图。我用“读需求”三个字来概括对应的技术路线就是最近很热门的“LLM LangChain 自动化测试框架”组合。可以把它理解成一个能读懂自然语言测试用例、自动生成UI自动化脚本的Agent。这个思路的热搜词就是“基于LangChain开发一个能读取测试用例自动生成UI自动化测试脚本的Agent”我觉得它不是噱头是目前最值得投入产出比最高的一条路。3.2 Agent的核心架构动作原语库是关键很多人在做Agent生成测试脚本时犯的第一个错误是直接让大模型生成完整的Selenium代码。后果可想而知大模型很容易把类名、方法名、元素定位写错生成的脚本能不能跑通全看运气。我实践下来的正确做法是先用人的经验把业务操作抽象成动作原语再让大模型去组合这些原语而不是从零写代码。动作原语库的样子大致如下# 领域动作原语示例业务操作的最小可执行单位 def open_url(driver, url: str) - bool: driver.get(url) return True def input_text(driver, selector: str, text: str) - bool: element wait_until_visible(driver, selector) element.clear() element.send_keys(text) return True def click_button(driver, selector: str) - bool: element wait_until_clickable(driver, selector) element.click() return True def assert_text(driver, selector: str, expected: str) - bool: element wait_until_visible(driver, selector) assert element.text.strip() expected, f期望文本: {expected}, 实际文本: {element.text} return True有了这套原语Agent的工作就从“写代码”降级为“做映射”。它只需要把自然语言描述一步步映射到这些原语上再用LLM做参数补全和边界判断。比如“用户登录后点击订单详情的确认按钮断言成功文案为‘操作成功’”这一句Agent会把它拆解成四步open_url → 登录页地址input_text → 用户名输入框读测试数据里的账号input_text → 密码输入框click_button → 登录按钮open_url → 订单页地址click_button → 订单详情里确认按钮assert_text → 断言“操作成功”文案代码生成这一环反而变得没那么重要了。重要的是拆意图、定参数以及当某一步失败时怎么从失败堆栈里判断是原语写错了还是业务真的变了。3.3 一个可跑的示例LangChain Playwright的翻译链路我这里给一个简化版本用LangChain的create_react_agent做步骤分解再用Playwright执行动作原语。这个示例不是生产级代码但能帮大家直观理解Agent的“翻译链路”是怎么走的。from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import Tool # 将动作原语封装成LangChain Tool tools [ Tool(nameopen_url, funcopen_url, description打开指定URL), Tool(nameinput_text, funcinput_text, description在selector指定位置输入文本), Tool(nameclick_button, funcclick_button, description点击selector指定的按钮), Tool(nameassert_text, funcassert_text, description断言selector位置的文本等于expected), ] with open(test_case.txt, r, encodingutf-8) as f: test_case_content f.read() # 读取自然语言测试用例 prompt f请阅读以下测试用例逐步翻译为可执行的测试动作序列 {test_case_content} 注意 1. 每一步必须且只能调用一个工具 2. 参数必须使用测试数据里的真实值 3. 如果用例描述模糊输出ACTION_NEEDED并说明缺失信息 llm ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_react_agent(llmllm, toolstools, promptprompt) # 这里省略了Prompts模板细节 agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) result agent_executor.invoke({input: prompt}) print(result[output])这个链路跑通以后我最大的体会是**大模型在语义理解上已经完全够用了卡点全在工程侧。**比如登录态怎么维护、测试数据从哪里注入、失败截图怎么回传给模型、重试策略怎么设计。这些不比写脚本简单但它们是一次性投入边际成本会越来越低。3.4 Agent落地的三个关键纪律先做“用例转脚本”不要一上来做“需求生成用例”。从已有测试用例转脚本容错率高得多因为用例里已经有人类的判断了直接让Agent从需求文档生成用例很容易生成一堆看起来像那么回事、却根本测不到点上的废用例。测试数据必须是结构化注入的。不要让LLM自己编一个用户名密码而是通过数据工厂获取真实环境里可用的测试数据否则断言永远过不了。失败信息必须闭环回传。脚本失败后把异常堆栈、页面截图、当前DOM关键信息一起回传给模型让模型判断是环境问题、数据问题还是脚本问题或者直接尝试自愈。否则Agent生成脚本只是把“人修脚本”变成了“模型修脚本”效率提升有限。这些都是我在实际项目里踩过的坑。尤其是第三点我第一次做Agent时没有做失败回传生成的脚本成功率只有五成每次都要人去分析失败原因后来加了失败分类与回传机制成功率才真正上去了。4. 从单兵脚本到平台治理自动化测试平台必须具备的五个能力4.1 平台化之前先回答三个问题很多团队一说建设自动化测试平台第一反应是买工具、搭系统、把脚本集中管理起来。但真正的平台化要回答的是三个更底层的问题测试资产是否可以被统一管理而不是散落在各人电脑上变成“个人资产”执行结果是否具备可追溯性和可解释性而不是靠截图去群里喊人机器是否能在某种程度上“理解”测试意图而不只是一个执行棋子这三个问题如果没想清楚平台建设出来也只是把原来的脚本堆到了一个网页后面没有解决人机协作的实质危机。4.2 平台的核心能力地图结合多个团队的实践经验我认为一个及格的自动化测试平台至少要具备这五项能力能力模块核心价值落地的关键点用例资产中心统一管理用例、脚本、页面对象、测试数据版本化、标签化、支持用例评审环境与数据工厂按需申请环境、一键造数、隔离账号与CI/CD联动环境状态可观测智能执行引擎任务编排、并发分配、自动重试、失败分类失败归因分析非简单重跑结果观测与分析趋势报表、失败聚类、缺陷关联以“是否值得发版”为目标输出结论智能辅助层自然语言转脚本、失败自愈、代码评审辅助基于LLM服务模型可替换我特别想强调“智能辅助层”这一层。它是进化的方向也是平台区别于传统工具的关键平台不应该只是测试脚本的“保管箱”它应该能辅助人做更多的判断和生成工作降低人机协作的摩擦。4.3 最小闭环怎么搭以及一个反面教材平台建设最大的坑是“大而全的空转”。我见过一个团队花三个月时间架构了一个包含几十个模块的测试平台功能菜单密密麻麻但连最核心的“失败原因标签”都没有打通用例跑挂了依然要在群里喊人排查。这就是典型的形式主义中台。更稳妥的路径是走最小闭环先选一个高频业务域把“用例管理→执行编排→结果聚合→失败分类→反馈模型”这条线全部跑端到端周期控制在三到四周。这条线跑顺了再逐步加环境工厂和数据工厂这些能力。换句话说平台的建设应该从“治疗负资产”开始而不是从“扩大门面”开始。我自己的做法是先用一个轻量级的开源工具比如Allure Pytest Jenkins把结果聚合和分类做起来验证团队是否能真正依赖报告做决策。等确认报告里的红叉有含金量了再考虑要不要上更重的平台。5. 测试工程师的进化从脚本工人到人机协作导演5.1 危机倒逼下人的能力结构在变自动化测试平台越来越智能测试工程师的传统技能正在快速贬值。当年吃饭的手艺——写Selenium脚本、调Appium环境、搭建接口自动化框架这些正在变成AI的普通能力。真正贵的能力已经迁移到了另一个层面。我整理了一张能力迁移的对照表很直观传统测试工程师能力AI时代测试工程师能力具体表现手写脚本写Prompt和动作原语给Agent下达清晰、可拆解的测试意图修脚本处理脆弱性审查AI生成脚本的边界判断生成脚本是否覆盖了异常场景人肉点点点的探索性测试设计测试机器人读业务的策略把业务风险点拆成机器可执行的可验证断言看报告判断通过与否评审失败归因的智能判断区分真缺陷、假失败和噪声搭建框架与CI流水线治理测试资产与搭建智能反馈闭环让失败报告从“噪音”变成“信号”我反复讲一个观点将来最值钱的测试工程师不是写代码最厉害的人而是最能表达测试意图的人。你需要对你负责的业务足够敏感知道哪个环节最容易出错然后把这个判断翻译成机器能执行的验证逻辑不管是脚本还是Prompt。5.2 以接口自动化测试为例人机分工怎么做接口自动化测试是相对容易先跑通AI辅助的领域因为接口的输入输出比较结构化LLM生成用例的容错率比UI自动化高得多。我们目前的协作方式是人负责定义接口契约、核心场景、Schema约束和关键断言AI负责补齐边界值、异常参数组合、状态码覆盖然后人做最终评审决定哪些AI生成的用例进入资产库。比如这样一个场景人工定义POST /api/order/create 成功时返回订单号失败时返回错误码 Agent补充空订单项、金额为0、商品ID不存在、并发创建同一商品、Token过期 人工评审剔除掉不合理的组合补充真实环境里才会出现的幂等场景这套流程跑下来接口自动化的用例覆盖率明显提升而人的时间没有按比例增加因为AI分担了“从方法论生成用例”的机械化工作。这才是人机协作该有的样子——人管方向和判断机器管生成和执行最终由人拍板。5.3 我在项目管理中坚持的几条协作纪律不能让机器人背锅自动化用例失败了第一反应不是“这个脚本谁写的”而是先归因确认是环境、数据、脚本还是产品问题。责任边界清楚了协作才不内耗。给机器学习的耐心和时间AI生成脚本不是一次到位需要反复用失败数据去微调Prompt和原语库。我见过太多团队试了一周觉得效果不好就放弃这就像让新人刚入职就要求产出——不现实的。保持对业务的判断力无论工具多智能最终的质量门禁必须由人来把关。AI可以帮你发现异常但“这个异常要不要阻塞发版”这个决策不能完全交给机器人。这也是我标题想说的“进化”测试机器人读不读好书不重要重要的是使用机器人的人开始用更高级的思维方式去定义劳动和协作边界。测试机器人读《资本论》是个玩笑但人如果真的开始思考“哪些重复劳动应该交给机器、哪些核心判断必须留在人手里”自动化测试的危机才真正有解。
自动化测试人机协作危机：AI Agent如何重塑脚本生成与维护
最近团队里有个年轻测试工程师往工作群里发了一张截图CI服务器上三百多条Selenium用例跑了一整夜最后通过的不到六成剩下的失败里有一半连失败原因都看不明白。他配了一句挺丧的话“每天早上醒来第一件事不是看需求文档而是看成堆的失败报告我不是在找Bug是在猜测试机器人为什么又把用例跑挂了。”这话干过自动化测试的人都懂。我们花大量精力搭建测试机器人初衷是把人从重复劳动里解放出来可现实往往是它反而成了新的劳动来源而且这个劳动比手工点鼠标更让人心累。借用一下《资本论》这个有点反差的书名当个引子我声明在先咱们不聊政治经济学纯粹借“劳动”与“资本”两个词说事自动化测试里我们到底在积累什么机器到底在替人做什么人和机器之间的边界是不是正在走向一个畸形循环这篇文章想认真聊一聊的就是自动化测试中的人机协作危机以及它可能的进化方向。1. 测试资产是怎么堆成山的自动化测试里的“原始积累”1.1 从几十条脚本到上万条用例资产在膨胀任何一条测试线几乎都逃不过这样的发展轨迹刚开始只是想把手头最重复的回归用例自动化跑起来用了Pytest加上Selenium几条脚本跑通团队很开心。接着领导觉得这条路走得通下了指标——“覆盖率要上去”于是脚本数量从几十涨到几百再涨到上千再遇到平台化建设用例数直接破万。我们通常把这件事叫“积累测试资产”听起来确实很正面只是很少有人在积累的过程中停下来盘点这些资产里有多少是真正能生钱的生产资料有多少是躺在仓库里的库存又有多少其实是负资产以我见过的一个真实项目为例一个中大型Web应用自动化用例两千多条每天定时在CI上全量跑一遍耗时三小时左右。表面上看资源占用不小更扎心的是失败率长期徘徊在四成。失败里有环境连不上、测试数据被脏掉、元素选择器失配、接口返回结构变了真正发现产品缺陷的失败平均一周不超过十条。两千多条用例每天真正产生决策价值的可能只有那十条其余全是在制造噪音。这就是典型的“资产膨胀期”数量上去了质量下来了价值密度稀释得厉害。测试机器人看起来很忙但忙并不等于有效。1.2 用例资产的三种类型与真实的“资产负债”我在多个团队做过一次简单的资产盘点把自动化用例按可维护性和实际产出来分类大致是这三类资产类型特点维护态度可复用资产稳定、有明确业务断言、失败时能直接定位真Bug值得投入持续维护一次性资产为了某个版本临时写的回归用例版本过了就没价值定期归档或清理负资产常年失败、无人修复、报告里没人敢删的用例必须尽快处理否则拖垮整体信任负资产是最可怕的。大家可能都有这种经验某个用例连续一个月天天失败一开始还有人去看后来所有人默认跳过它更糟的是报告里那一堆红叉已经没人当回事了。红叉不再代表产品有问题而是代表“机器人又在闹脾气”。当自动化测试的结果失去信号意义时整个测试线和测试机器人就失去了存在的价值。所以如果真要套“原始积累”的说法我想说的是自动化测试的资产积累不是脚本数量的堆叠而是可复用用例、稳定的执行环境、可解释的失败报告这三者形成的正向循环。缺了任何一环资产就会变成库存甚至负资产。2. 危机真正的名字不是工具不行是人机边界错了2.1 脆弱脚本最常见的六个导火索自动化测试跑不稳团队第一反应往往是换框架Selenium不行换PlaywrightAppium慢换新工具接口测试不好写换平台。但框架解决不了所有问题因为大部分失败根本不是框架本身的锅。根据我多年排查的经验脆弱脚本的原因基本集中在下面这六类页面结构变化前端改版某个按钮的class从btn-primary改成了btn-confirm元素定位直接失效。异步时序不稳定页面还没渲染完脚本就开始找元素于是要靠各种sleep和显式等待“蒙”时序。测试数据互相污染用例依赖的账号、订单、商品数据被另一条用例改了串数据导致断言失败。环境差异本地能过、CI上挂开发环境能过、预发环境挂浏览器版本和驱动版本不匹配。接口契约漂移后端字段名变了类型从string改成long接口自动化测试没跟上。框架和依赖升级一个无关依赖的升版导致整个执行链路崩掉。你仔细看这一串会发现一个共同特征测试机器学习的是“剧本”但业务系统每天都在“即兴演出”。测试机器人不认业务只认选择器和响应结构任何超出剧本的变化对它来说都是灾难。人必须不停地修改剧本去适配业务的变化这不是人机协作而是人在给机器当保姆。2.2 失败分类把“机器出错”和“产品出错”切开解决危机第一步是先让失败报告说人话。我强烈建议所有做自动化测试的团队从第一天就建立失败原因标签体系每条失败的用例必须打上原因分类而且分类要落到能直接定位问题的粒度。这里给出我常用的失败分类表失败类型典型表现责任归属响应动作环境类失败依赖服务重启、容器资源不足、网络超时测试基础设施团队自动重试或环境巡检数据类失败断言值不对、数据被篡改、脏数据残留测试数据团队数据工厂重建或用例隔离框架类失败选择器失效、等待超时、驱动版本不匹配自动化开发团队框架修复或登录态维护真实产品缺陷页面报错、接口返回错误、业务流程中断产品研发团队提交缺陷单阻塞发版没有这个分类体系失败报告就是一个大杂烩每个人看到红叉都要从头开始查人力消耗巨大。有了分类体系之后很多失败可以用规则和脚本自动归因人的精力能集中到真正需要判断力的“真实产品缺陷”上。这一步表面上是数据治理本质上是在给人和机器画清晰的分工边界。2.3 信任崩塌的恶性循环自动化测试还有一个特别隐蔽的危机叫作“信任崩塌”。它的循环路径大概是这样的用例失败太多工程师看不过来于是开始选择性忽略。失败的用例没人修失败率继续升高。重要版本发布前自动化测试报告因为噪音太大无法作为质量门禁的参考依据。管理层发现自动化投入了大量资源却没挡住线上事故开始质疑价值。测试团队为了自证价值又加更多用例进一步加剧噪音。这个循环走到第三步就已经很危险了。我在不少团队见过自动化测试报告沦为“演示工具”周报里截一张覆盖率图但真正发版决策根本不敢依赖它。这不是机器人的错是人机协作的闭环断了——机器不会自我判断失败是否重要人又没有持续反馈校准最后当然是一起摆烂。所以我说自动化测试危机的根源不是工具不够先进而是我们从来没认真设计“人教机器、机器反馈人”的闭环。要建立这个闭环先得有资产治理紧接着得有让机器理解业务意图的新方式这就是下面要聊的进化方向。3. 让测试机器人学会“读需求”AI Agent生成测试脚本的落地路径3.1 人工写脚本的成本上限决定了必须换一种交互方式很多人力写脚本维护脚本的团队最终都会撞到一堵墙自动化用例的编写速度根本赶不上业务迭代的速度。一个复杂流程的UI自动化用例从分析、写脚本到调试通过至少需要半天。而业务一天可能改三处脚本维护的债务越滚越大。解决这个问题的方向不是写更快的脚本而是让机器直接理解人的意图。我用“读需求”三个字来概括对应的技术路线就是最近很热门的“LLM LangChain 自动化测试框架”组合。可以把它理解成一个能读懂自然语言测试用例、自动生成UI自动化脚本的Agent。这个思路的热搜词就是“基于LangChain开发一个能读取测试用例自动生成UI自动化测试脚本的Agent”我觉得它不是噱头是目前最值得投入产出比最高的一条路。3.2 Agent的核心架构动作原语库是关键很多人在做Agent生成测试脚本时犯的第一个错误是直接让大模型生成完整的Selenium代码。后果可想而知大模型很容易把类名、方法名、元素定位写错生成的脚本能不能跑通全看运气。我实践下来的正确做法是先用人的经验把业务操作抽象成动作原语再让大模型去组合这些原语而不是从零写代码。动作原语库的样子大致如下# 领域动作原语示例业务操作的最小可执行单位 def open_url(driver, url: str) - bool: driver.get(url) return True def input_text(driver, selector: str, text: str) - bool: element wait_until_visible(driver, selector) element.clear() element.send_keys(text) return True def click_button(driver, selector: str) - bool: element wait_until_clickable(driver, selector) element.click() return True def assert_text(driver, selector: str, expected: str) - bool: element wait_until_visible(driver, selector) assert element.text.strip() expected, f期望文本: {expected}, 实际文本: {element.text} return True有了这套原语Agent的工作就从“写代码”降级为“做映射”。它只需要把自然语言描述一步步映射到这些原语上再用LLM做参数补全和边界判断。比如“用户登录后点击订单详情的确认按钮断言成功文案为‘操作成功’”这一句Agent会把它拆解成四步open_url → 登录页地址input_text → 用户名输入框读测试数据里的账号input_text → 密码输入框click_button → 登录按钮open_url → 订单页地址click_button → 订单详情里确认按钮assert_text → 断言“操作成功”文案代码生成这一环反而变得没那么重要了。重要的是拆意图、定参数以及当某一步失败时怎么从失败堆栈里判断是原语写错了还是业务真的变了。3.3 一个可跑的示例LangChain Playwright的翻译链路我这里给一个简化版本用LangChain的create_react_agent做步骤分解再用Playwright执行动作原语。这个示例不是生产级代码但能帮大家直观理解Agent的“翻译链路”是怎么走的。from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import Tool # 将动作原语封装成LangChain Tool tools [ Tool(nameopen_url, funcopen_url, description打开指定URL), Tool(nameinput_text, funcinput_text, description在selector指定位置输入文本), Tool(nameclick_button, funcclick_button, description点击selector指定的按钮), Tool(nameassert_text, funcassert_text, description断言selector位置的文本等于expected), ] with open(test_case.txt, r, encodingutf-8) as f: test_case_content f.read() # 读取自然语言测试用例 prompt f请阅读以下测试用例逐步翻译为可执行的测试动作序列 {test_case_content} 注意 1. 每一步必须且只能调用一个工具 2. 参数必须使用测试数据里的真实值 3. 如果用例描述模糊输出ACTION_NEEDED并说明缺失信息 llm ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_react_agent(llmllm, toolstools, promptprompt) # 这里省略了Prompts模板细节 agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) result agent_executor.invoke({input: prompt}) print(result[output])这个链路跑通以后我最大的体会是**大模型在语义理解上已经完全够用了卡点全在工程侧。**比如登录态怎么维护、测试数据从哪里注入、失败截图怎么回传给模型、重试策略怎么设计。这些不比写脚本简单但它们是一次性投入边际成本会越来越低。3.4 Agent落地的三个关键纪律先做“用例转脚本”不要一上来做“需求生成用例”。从已有测试用例转脚本容错率高得多因为用例里已经有人类的判断了直接让Agent从需求文档生成用例很容易生成一堆看起来像那么回事、却根本测不到点上的废用例。测试数据必须是结构化注入的。不要让LLM自己编一个用户名密码而是通过数据工厂获取真实环境里可用的测试数据否则断言永远过不了。失败信息必须闭环回传。脚本失败后把异常堆栈、页面截图、当前DOM关键信息一起回传给模型让模型判断是环境问题、数据问题还是脚本问题或者直接尝试自愈。否则Agent生成脚本只是把“人修脚本”变成了“模型修脚本”效率提升有限。这些都是我在实际项目里踩过的坑。尤其是第三点我第一次做Agent时没有做失败回传生成的脚本成功率只有五成每次都要人去分析失败原因后来加了失败分类与回传机制成功率才真正上去了。4. 从单兵脚本到平台治理自动化测试平台必须具备的五个能力4.1 平台化之前先回答三个问题很多团队一说建设自动化测试平台第一反应是买工具、搭系统、把脚本集中管理起来。但真正的平台化要回答的是三个更底层的问题测试资产是否可以被统一管理而不是散落在各人电脑上变成“个人资产”执行结果是否具备可追溯性和可解释性而不是靠截图去群里喊人机器是否能在某种程度上“理解”测试意图而不只是一个执行棋子这三个问题如果没想清楚平台建设出来也只是把原来的脚本堆到了一个网页后面没有解决人机协作的实质危机。4.2 平台的核心能力地图结合多个团队的实践经验我认为一个及格的自动化测试平台至少要具备这五项能力能力模块核心价值落地的关键点用例资产中心统一管理用例、脚本、页面对象、测试数据版本化、标签化、支持用例评审环境与数据工厂按需申请环境、一键造数、隔离账号与CI/CD联动环境状态可观测智能执行引擎任务编排、并发分配、自动重试、失败分类失败归因分析非简单重跑结果观测与分析趋势报表、失败聚类、缺陷关联以“是否值得发版”为目标输出结论智能辅助层自然语言转脚本、失败自愈、代码评审辅助基于LLM服务模型可替换我特别想强调“智能辅助层”这一层。它是进化的方向也是平台区别于传统工具的关键平台不应该只是测试脚本的“保管箱”它应该能辅助人做更多的判断和生成工作降低人机协作的摩擦。4.3 最小闭环怎么搭以及一个反面教材平台建设最大的坑是“大而全的空转”。我见过一个团队花三个月时间架构了一个包含几十个模块的测试平台功能菜单密密麻麻但连最核心的“失败原因标签”都没有打通用例跑挂了依然要在群里喊人排查。这就是典型的形式主义中台。更稳妥的路径是走最小闭环先选一个高频业务域把“用例管理→执行编排→结果聚合→失败分类→反馈模型”这条线全部跑端到端周期控制在三到四周。这条线跑顺了再逐步加环境工厂和数据工厂这些能力。换句话说平台的建设应该从“治疗负资产”开始而不是从“扩大门面”开始。我自己的做法是先用一个轻量级的开源工具比如Allure Pytest Jenkins把结果聚合和分类做起来验证团队是否能真正依赖报告做决策。等确认报告里的红叉有含金量了再考虑要不要上更重的平台。5. 测试工程师的进化从脚本工人到人机协作导演5.1 危机倒逼下人的能力结构在变自动化测试平台越来越智能测试工程师的传统技能正在快速贬值。当年吃饭的手艺——写Selenium脚本、调Appium环境、搭建接口自动化框架这些正在变成AI的普通能力。真正贵的能力已经迁移到了另一个层面。我整理了一张能力迁移的对照表很直观传统测试工程师能力AI时代测试工程师能力具体表现手写脚本写Prompt和动作原语给Agent下达清晰、可拆解的测试意图修脚本处理脆弱性审查AI生成脚本的边界判断生成脚本是否覆盖了异常场景人肉点点点的探索性测试设计测试机器人读业务的策略把业务风险点拆成机器可执行的可验证断言看报告判断通过与否评审失败归因的智能判断区分真缺陷、假失败和噪声搭建框架与CI流水线治理测试资产与搭建智能反馈闭环让失败报告从“噪音”变成“信号”我反复讲一个观点将来最值钱的测试工程师不是写代码最厉害的人而是最能表达测试意图的人。你需要对你负责的业务足够敏感知道哪个环节最容易出错然后把这个判断翻译成机器能执行的验证逻辑不管是脚本还是Prompt。5.2 以接口自动化测试为例人机分工怎么做接口自动化测试是相对容易先跑通AI辅助的领域因为接口的输入输出比较结构化LLM生成用例的容错率比UI自动化高得多。我们目前的协作方式是人负责定义接口契约、核心场景、Schema约束和关键断言AI负责补齐边界值、异常参数组合、状态码覆盖然后人做最终评审决定哪些AI生成的用例进入资产库。比如这样一个场景人工定义POST /api/order/create 成功时返回订单号失败时返回错误码 Agent补充空订单项、金额为0、商品ID不存在、并发创建同一商品、Token过期 人工评审剔除掉不合理的组合补充真实环境里才会出现的幂等场景这套流程跑下来接口自动化的用例覆盖率明显提升而人的时间没有按比例增加因为AI分担了“从方法论生成用例”的机械化工作。这才是人机协作该有的样子——人管方向和判断机器管生成和执行最终由人拍板。5.3 我在项目管理中坚持的几条协作纪律不能让机器人背锅自动化用例失败了第一反应不是“这个脚本谁写的”而是先归因确认是环境、数据、脚本还是产品问题。责任边界清楚了协作才不内耗。给机器学习的耐心和时间AI生成脚本不是一次到位需要反复用失败数据去微调Prompt和原语库。我见过太多团队试了一周觉得效果不好就放弃这就像让新人刚入职就要求产出——不现实的。保持对业务的判断力无论工具多智能最终的质量门禁必须由人来把关。AI可以帮你发现异常但“这个异常要不要阻塞发版”这个决策不能完全交给机器人。这也是我标题想说的“进化”测试机器人读不读好书不重要重要的是使用机器人的人开始用更高级的思维方式去定义劳动和协作边界。测试机器人读《资本论》是个玩笑但人如果真的开始思考“哪些重复劳动应该交给机器、哪些核心判断必须留在人手里”自动化测试的危机才真正有解。
