过去大半年我一直在琢磨一件事怎么让AI真正进到测试自动化的执行链路里而不是只在对话框里写个demo给人看。最开始我也试过最省事的办法——直接把需求扔给AI让它“写一个登录脚本”结果它确实写了写得还像模像样但一提交代码评审问题就全出来了没用页面对象、等待全靠sleep、定位符写绝对XPath甚至直接new了一个新的driver实例。负责review的同事看完一脸懵说这代码根本进不了我们的框架。后来我慢慢想明白一个道理AI不是不会写代码是你没把它放进你家的规矩里。这篇文章是“AI for Testing 提效实战”系列里执行自动化的第一篇不聊概念就聊怎么让AI在你的框架内产出能直接合入的脚本。1. AI生成的代码为什么总是和你的工程格格不入1.1 看起来能跑的脚本实际上是一堆技术债你在AI聊天框里要一个“登录并把用户名拼到首页上”的UI自动化用例它大概率给你类似这样的东西from selenium import webdriver import time driver webdriver.Chrome() driver.get(https://demo-app.example.com/login) driver.find_element_by_id(username).send_keys(tester) driver.find_element_by_id(password).send_keys(123456) driver.find_element_by_xpath(/html/body/div[1]/div/form/button).click() time.sleep(3) assert 欢迎tester in driver.page_source driver.quit()单看这段代码逻辑没错放到一个一次性爬虫脚本里完全能跑。但如果你所在的是一个多人协作、要长期维护的自动化测试工程它几乎是不可合入的。原因很直接工程里已经规定所有页面操作都要封装到Page Object里driver实例统一由框架初始化并管理等待必须走框架封装好的显式等待方法定位符优先使用测试专用属性。而AI生成的代码把这些全忽略了。有人可能会说这不就是让AI生成完再人肉改一改嘛也能用。但“改一改”的成本往往比从零写还高。尤其是当你一个月要生成几十上百条用例时每条都要重构一遍那AI的价值就只剩个“伪代码起草器”了。所以核心问题不在AI写得好不好而在于你让它开工之前有没有把“你们家的代码长什么样、有什么规矩”告诉它。1.2 AI并不是不聪明而是没有你头脑里的“框架心智”大模型在训练时看过海量代码它对通用编码风格非常熟悉包括公开教程里最常见的直接new driver、time.sleep、find_element_by_xpath那一套。但它不知道的是你们团队的BasePage封装了什么、用例层能做什么不能做什么、失败截图是谁负责处理的、测试数据从哪里读。这些信息不会出现在任何公开代码库里而是你所在工程多年迭代沉淀下来的隐性约定。我把这些约定称为“框架心智”。老测试开发在写用例时脑子里会下意识地调用这些约定就像老司机开车不需要思考档位和刹车。但AI默认没有这套心智你不主动喂给它它就只能按通用套路来而通用套路和团队标准之间隔着一大段代码评审的距离。所以“让AI在你的框架里写”这句话字面上就是第一步要做的把项目结构、核心接口、参考用例、运行方式、禁用项整理成一份它能直接读取的上下文。这一步做扎实了后面才有“直接合入”的可能性。2. 把“框架上下文”整理成提示词是合入的第一步2.1 上下文包的五类材料我试过很多种喂AI的方式最后收敛下来一份高质量的上下文包只需要包含五类材料。不需要把整个仓库塞给它也不需要写几百行的框架源码重点是让它知道“怎么写才像我们自己人”。第一类是目录结构节选。不需要完整列出只展示用例相关的三层核心层级就够了比如project/ ├── pages/ # Page Object页面元素与操作封装在这里 ├── cases/ # 测试用例只负责业务流程与断言 ├── utils/ # 公共工具比如数据生成、配置读取 └── runner.py # 执行入口第二类是核心基类接口。把页面对象和用例基类里常用的方法签名给出来AI才知道哪些动作是现成的不需要自己造轮子class BasePage: def click(self, locator: tuple) - None def input_text(self, locator: tuple, text: str) - None def wait_until_visible(self, locator: tuple, timeout: int 10) - WebElement def get_text(self, locator: tuple) - str class BaseCase: def login(self, username: str, password: str) - HomePage第三类是2到3条已经合入的参考用例。最好挑典型的表单填写、列表校验、按钮跳转各一条。AI很擅长模仿给它一个高质量样例它会照着风格写比给它一堆抽象规则更有用。第四类是运行方式与测试数据约定。比如命令行入口是什么、测试数据放在哪个目录、测试结束是否需要自动清理。这些不属于代码语法但决定生成出来的用例能不能直接接进执行链路。第五类是明确禁用项。这条最重要。把你们历史上踩过的典型坑直接写成“禁止”比如禁止time.sleep、禁止绝对XPath、禁止在用例层直接写locator、禁止调用未封装的外部资源。AI是概率模型它的“默认行为”来自海量训练数据只有用明确的负面清单才能压过那些默认行为。2.2 一套可以直接抄的Prompt框架材料准备好之后每次生成用例时我会用下面这个提示词框架它把刚才说的内容都压缩成一段结构化的约束你是我团队的测试开发工程师。请按照当前工程约定编写一条UI自动化测试用例。 目标场景{具体操作步骤与业务预期} 工程结构 {pages/ 与 cases/ 目录结构节选} 核心接口 {BasePage 与 BaseCase 方法签名} 参考用例 {一条已合入标准的用例代码} 运行方式 python runner.py --case {case_name} 硬性约束 1. 页面元素定位必须写在 pages/ 下对应的Page类中cases/ 里只允许调用Page对象方法 2. 禁止使用 time.sleep等待统一调用 wait_until_visible 或 wait_until_clickable 3. 禁止使用绝对XPath元素定位优先使用专属 test-id 或相对定位策略 4. 不要打印日志、不要直接截图日志与截图由框架统一处理 5. 输出必须是完整可运行的代码不要额外解释 请给出 cases/ 下用例文件路径与完整代码。这个Prompt的核心是“场景描述 框架约束 参考样式”。场景描述要具体到“进入列表页点击第一行的编辑按钮修改状态为启用保存后断言提示成功”而不是“测一下编辑功能”。约束越具体AI越不会自由发挥。2.3 上下文不需要“全量源码”给接口和约定就够了刚开始有同事会把整个项目代码打包成一个文件喂给AI觉得信息越全越准。实际效果恰恰相反。上下文太长时模型注意力会被大量无关实现稀释最后产出的代码反而偏离约束。你只需要给“支撑这一个用例的最小上下文”——它要调用的接口、要遵循的写法、要模仿的样例。这就像新员工入职不需要读全公司代码库只需要先了解自己岗位涉及的模块和相关规范干几天活自然就上手了。这个思路也直接决定了真实成本。大模型按token计费动不动喂全量源码既贵又慢。用精简上下文单次生成消耗很小而且迭代反馈时也能快速调整不会因为每次都带一大堆历史代码而拖慢速度。我们后来甚至把上下文包按模块拆成好几个版本登录测试用登录上下文订单测试用订单上下文准确率比一个“全量包”高出一截。3. 从AI输出到合入分支四道检查一个都不能少3.1 自动检查把“骨架一致性”交给脚本即使上下文包写得很完善AI偶尔还是会漏掉一两条约束。所以第一条质量闸门应该自动完成不要靠人肉review去盯“是否用了sleep”这种问题。我在团队里做了一组静态检查脚本用AST解析AI生成的用例文件重点检查是否 import 了 time、selenium 这类应该由框架统一管理的模块用例类中是否直接出现定位元组或XPath字符串是否调用了 pages/ 下已经存在的页面对象方法是否在断言前使用了框架要求的显式等待。这些检查规则不需要很复杂正则加AST就能搞定。检查不通过时直接把报错信息返回给AI让它基于报错再改一轮。我发现这一步能把“初版不经用”的比例从七成以上降到四成以下效果立竿见影。3.2 框架内试运行先证明它能在你家的环境里跑静态检查过了不代表能跑。第二个闸门是把AI生成的用例真正放进你的执行框架里跑一次。我们会把新生成的用例先放到cases/ai_pending/目录标记为冒烟用例跑一个专门的快速冒烟任务。这个任务只覆盖目标用例依赖的前置数据尽量控制在5分钟内出结果。通过后脚本会自动把用例移动到正式cases/目录失败的话就把日志和错误信息回投给AI让它自己修正。这个“生成—运行—回喂—再生成”的循环是整个执行自动化链路里最值钱的部分。因为AI模型本身不具备执行能力它无法感知“这段代码在当前环境下能不能跑”但你的框架可以。框架负责执行和反馈AI负责根据反馈修改两者配合才真正形成闭环。3.3 人工评审只看增量不给AI重写试运行通过后才算轮到人工评审。这里最容易犯的错误是reviewer忍不住亲自上手改代码把AI写的东西重写一遍。一旦这样做AI就变成只能生成“初稿”的工具效率提升非常有限。我的建议是人工评审只做语义审核给reviewer一张检查清单业务断言是否完备关键状态有没有校验测试数据是否可复用会不会污染其他用例用例名称与模块划分是否符合工程规划有没有把测试逻辑和业务逻辑混在一起只要不满足就把意见描述清楚再交给AI去改。比如“这里只校验了提交成功提示没有校验列表里新增数据的展示值”AI通常会很快补上。人工专注业务正确性语法和格式问题全部交给前面的自动检查去管评审速度会快很多。3.4 合入之后在回归集里观察两天合入分支不等于完事。执行自动化最怕的就是用例刚合入时能跑过两天就flaky。我们的做法是给新合入用例设置一个观察期在CI报告里标记为new_case连续跑5次全量回归全部通过后才转成正式用例。观察期内一旦出现偶发失败先查定位符和等待逻辑不要简单屏蔽。这个机制看着保守但能极大地减少“AI生成的用例污染回归集”的风险。对“直接合入”这个目标来说前面三道闸门是让代码满足工程规范第四道闸门是让代码满足稳定性要求。四道都过了AI产出才算真正进入资产池。4. 执行自动化落地中真正毁掉“直接合入”的两个隐藏杀手4.1 脆弱的定位符死在第一轮回归执行自动化里AI生成用例最常死在第一轮回归的就是元素定位。你可以在提示词里写一百句“请使用稳定的定位符”但如果没给出可操作的标准AI还是很容易写出/html/body/div[2]/div[3]/form/div/input或者带随机后缀的id。原因还是训练数据大量公开脚本为了快速演示直接用绝对XPath和当前页面结构。我们后来在上下文包和自动检查里同时加了硬性规定优先使用> 让AI测试自动化代码直接合入：框架上下文是关键
过去大半年我一直在琢磨一件事怎么让AI真正进到测试自动化的执行链路里而不是只在对话框里写个demo给人看。最开始我也试过最省事的办法——直接把需求扔给AI让它“写一个登录脚本”结果它确实写了写得还像模像样但一提交代码评审问题就全出来了没用页面对象、等待全靠sleep、定位符写绝对XPath甚至直接new了一个新的driver实例。负责review的同事看完一脸懵说这代码根本进不了我们的框架。后来我慢慢想明白一个道理AI不是不会写代码是你没把它放进你家的规矩里。这篇文章是“AI for Testing 提效实战”系列里执行自动化的第一篇不聊概念就聊怎么让AI在你的框架内产出能直接合入的脚本。1. AI生成的代码为什么总是和你的工程格格不入1.1 看起来能跑的脚本实际上是一堆技术债你在AI聊天框里要一个“登录并把用户名拼到首页上”的UI自动化用例它大概率给你类似这样的东西from selenium import webdriver import time driver webdriver.Chrome() driver.get(https://demo-app.example.com/login) driver.find_element_by_id(username).send_keys(tester) driver.find_element_by_id(password).send_keys(123456) driver.find_element_by_xpath(/html/body/div[1]/div/form/button).click() time.sleep(3) assert 欢迎tester in driver.page_source driver.quit()单看这段代码逻辑没错放到一个一次性爬虫脚本里完全能跑。但如果你所在的是一个多人协作、要长期维护的自动化测试工程它几乎是不可合入的。原因很直接工程里已经规定所有页面操作都要封装到Page Object里driver实例统一由框架初始化并管理等待必须走框架封装好的显式等待方法定位符优先使用测试专用属性。而AI生成的代码把这些全忽略了。有人可能会说这不就是让AI生成完再人肉改一改嘛也能用。但“改一改”的成本往往比从零写还高。尤其是当你一个月要生成几十上百条用例时每条都要重构一遍那AI的价值就只剩个“伪代码起草器”了。所以核心问题不在AI写得好不好而在于你让它开工之前有没有把“你们家的代码长什么样、有什么规矩”告诉它。1.2 AI并不是不聪明而是没有你头脑里的“框架心智”大模型在训练时看过海量代码它对通用编码风格非常熟悉包括公开教程里最常见的直接new driver、time.sleep、find_element_by_xpath那一套。但它不知道的是你们团队的BasePage封装了什么、用例层能做什么不能做什么、失败截图是谁负责处理的、测试数据从哪里读。这些信息不会出现在任何公开代码库里而是你所在工程多年迭代沉淀下来的隐性约定。我把这些约定称为“框架心智”。老测试开发在写用例时脑子里会下意识地调用这些约定就像老司机开车不需要思考档位和刹车。但AI默认没有这套心智你不主动喂给它它就只能按通用套路来而通用套路和团队标准之间隔着一大段代码评审的距离。所以“让AI在你的框架里写”这句话字面上就是第一步要做的把项目结构、核心接口、参考用例、运行方式、禁用项整理成一份它能直接读取的上下文。这一步做扎实了后面才有“直接合入”的可能性。2. 把“框架上下文”整理成提示词是合入的第一步2.1 上下文包的五类材料我试过很多种喂AI的方式最后收敛下来一份高质量的上下文包只需要包含五类材料。不需要把整个仓库塞给它也不需要写几百行的框架源码重点是让它知道“怎么写才像我们自己人”。第一类是目录结构节选。不需要完整列出只展示用例相关的三层核心层级就够了比如project/ ├── pages/ # Page Object页面元素与操作封装在这里 ├── cases/ # 测试用例只负责业务流程与断言 ├── utils/ # 公共工具比如数据生成、配置读取 └── runner.py # 执行入口第二类是核心基类接口。把页面对象和用例基类里常用的方法签名给出来AI才知道哪些动作是现成的不需要自己造轮子class BasePage: def click(self, locator: tuple) - None def input_text(self, locator: tuple, text: str) - None def wait_until_visible(self, locator: tuple, timeout: int 10) - WebElement def get_text(self, locator: tuple) - str class BaseCase: def login(self, username: str, password: str) - HomePage第三类是2到3条已经合入的参考用例。最好挑典型的表单填写、列表校验、按钮跳转各一条。AI很擅长模仿给它一个高质量样例它会照着风格写比给它一堆抽象规则更有用。第四类是运行方式与测试数据约定。比如命令行入口是什么、测试数据放在哪个目录、测试结束是否需要自动清理。这些不属于代码语法但决定生成出来的用例能不能直接接进执行链路。第五类是明确禁用项。这条最重要。把你们历史上踩过的典型坑直接写成“禁止”比如禁止time.sleep、禁止绝对XPath、禁止在用例层直接写locator、禁止调用未封装的外部资源。AI是概率模型它的“默认行为”来自海量训练数据只有用明确的负面清单才能压过那些默认行为。2.2 一套可以直接抄的Prompt框架材料准备好之后每次生成用例时我会用下面这个提示词框架它把刚才说的内容都压缩成一段结构化的约束你是我团队的测试开发工程师。请按照当前工程约定编写一条UI自动化测试用例。 目标场景{具体操作步骤与业务预期} 工程结构 {pages/ 与 cases/ 目录结构节选} 核心接口 {BasePage 与 BaseCase 方法签名} 参考用例 {一条已合入标准的用例代码} 运行方式 python runner.py --case {case_name} 硬性约束 1. 页面元素定位必须写在 pages/ 下对应的Page类中cases/ 里只允许调用Page对象方法 2. 禁止使用 time.sleep等待统一调用 wait_until_visible 或 wait_until_clickable 3. 禁止使用绝对XPath元素定位优先使用专属 test-id 或相对定位策略 4. 不要打印日志、不要直接截图日志与截图由框架统一处理 5. 输出必须是完整可运行的代码不要额外解释 请给出 cases/ 下用例文件路径与完整代码。这个Prompt的核心是“场景描述 框架约束 参考样式”。场景描述要具体到“进入列表页点击第一行的编辑按钮修改状态为启用保存后断言提示成功”而不是“测一下编辑功能”。约束越具体AI越不会自由发挥。2.3 上下文不需要“全量源码”给接口和约定就够了刚开始有同事会把整个项目代码打包成一个文件喂给AI觉得信息越全越准。实际效果恰恰相反。上下文太长时模型注意力会被大量无关实现稀释最后产出的代码反而偏离约束。你只需要给“支撑这一个用例的最小上下文”——它要调用的接口、要遵循的写法、要模仿的样例。这就像新员工入职不需要读全公司代码库只需要先了解自己岗位涉及的模块和相关规范干几天活自然就上手了。这个思路也直接决定了真实成本。大模型按token计费动不动喂全量源码既贵又慢。用精简上下文单次生成消耗很小而且迭代反馈时也能快速调整不会因为每次都带一大堆历史代码而拖慢速度。我们后来甚至把上下文包按模块拆成好几个版本登录测试用登录上下文订单测试用订单上下文准确率比一个“全量包”高出一截。3. 从AI输出到合入分支四道检查一个都不能少3.1 自动检查把“骨架一致性”交给脚本即使上下文包写得很完善AI偶尔还是会漏掉一两条约束。所以第一条质量闸门应该自动完成不要靠人肉review去盯“是否用了sleep”这种问题。我在团队里做了一组静态检查脚本用AST解析AI生成的用例文件重点检查是否 import 了 time、selenium 这类应该由框架统一管理的模块用例类中是否直接出现定位元组或XPath字符串是否调用了 pages/ 下已经存在的页面对象方法是否在断言前使用了框架要求的显式等待。这些检查规则不需要很复杂正则加AST就能搞定。检查不通过时直接把报错信息返回给AI让它基于报错再改一轮。我发现这一步能把“初版不经用”的比例从七成以上降到四成以下效果立竿见影。3.2 框架内试运行先证明它能在你家的环境里跑静态检查过了不代表能跑。第二个闸门是把AI生成的用例真正放进你的执行框架里跑一次。我们会把新生成的用例先放到cases/ai_pending/目录标记为冒烟用例跑一个专门的快速冒烟任务。这个任务只覆盖目标用例依赖的前置数据尽量控制在5分钟内出结果。通过后脚本会自动把用例移动到正式cases/目录失败的话就把日志和错误信息回投给AI让它自己修正。这个“生成—运行—回喂—再生成”的循环是整个执行自动化链路里最值钱的部分。因为AI模型本身不具备执行能力它无法感知“这段代码在当前环境下能不能跑”但你的框架可以。框架负责执行和反馈AI负责根据反馈修改两者配合才真正形成闭环。3.3 人工评审只看增量不给AI重写试运行通过后才算轮到人工评审。这里最容易犯的错误是reviewer忍不住亲自上手改代码把AI写的东西重写一遍。一旦这样做AI就变成只能生成“初稿”的工具效率提升非常有限。我的建议是人工评审只做语义审核给reviewer一张检查清单业务断言是否完备关键状态有没有校验测试数据是否可复用会不会污染其他用例用例名称与模块划分是否符合工程规划有没有把测试逻辑和业务逻辑混在一起只要不满足就把意见描述清楚再交给AI去改。比如“这里只校验了提交成功提示没有校验列表里新增数据的展示值”AI通常会很快补上。人工专注业务正确性语法和格式问题全部交给前面的自动检查去管评审速度会快很多。3.4 合入之后在回归集里观察两天合入分支不等于完事。执行自动化最怕的就是用例刚合入时能跑过两天就flaky。我们的做法是给新合入用例设置一个观察期在CI报告里标记为new_case连续跑5次全量回归全部通过后才转成正式用例。观察期内一旦出现偶发失败先查定位符和等待逻辑不要简单屏蔽。这个机制看着保守但能极大地减少“AI生成的用例污染回归集”的风险。对“直接合入”这个目标来说前面三道闸门是让代码满足工程规范第四道闸门是让代码满足稳定性要求。四道都过了AI产出才算真正进入资产池。4. 执行自动化落地中真正毁掉“直接合入”的两个隐藏杀手4.1 脆弱的定位符死在第一轮回归执行自动化里AI生成用例最常死在第一轮回归的就是元素定位。你可以在提示词里写一百句“请使用稳定的定位符”但如果没给出可操作的标准AI还是很容易写出/html/body/div[2]/div[3]/form/div/input或者带随机后缀的id。原因还是训练数据大量公开脚本为了快速演示直接用绝对XPath和当前页面结构。我们后来在上下文包和自动检查里同时加了硬性规定优先使用>