人工智能测试开发这六个字放在两年前还没多少测试工程师当回事。当时大家聊的更多是接口自动化、UI自动化、CI/CD流水线谁要是说“让AI帮我写测试用例”多半会被当成不靠谱的段子。但这两年风向变得非常快被测产品开始带AI能力测试对象本身变成了模型测试方法也跟着被倒逼升级。我在霍格沃兹测试开发学社的人工智能测试开发训练营2期完整跟完了一轮想把这套训练营里让我真正开窍的内容、踩过的坑、以及最后结业项目的完整思路整理出来。这篇更适合两类人看一类是还在犹豫要不要转AI测试方向的测试开发工程师另一类是已经报名训练营但对课程节奏和项目实战没有底的同学。1. 训练营的定位不是教算法是教测试开发怎么和AI配合1.1 先想清楚一个问题测试开发为什么要学AI很多人一听说“人工智能测试开发训练营”第一反应是“我要去学机器学习算法了”。这个理解其实跑偏了。训练营的定位非常明确不是把你培养成算法工程师而是让你成为“懂AI、能测AI、会用AI做测试”的测试开发工程师。原因从业务端看就很清楚。以前我们测的是确定性的功能比如“输入用户名密码点登录”预期结果早就写死在需求文档里断言就是等页面出现某个元素。但现在很多产品核心能力已经变成智能推荐、智能客服、图像识别、风控模型输入的是特征和上下文输出的是概率和排序没有一个固定的“正确结果”可以做硬断言。这种时候传统测试方法会直接失效你需要知道模型评估怎么做、准确率和召回率怎么取舍、线上数据分布变化怎么引起模型漂移。另一面AI也在改变测试自身的生产方式。用例设计、脚本编写、断言生成、失败日志分类、自动化脚本自愈这些重复劳动开始能被大模型替代。训练营把这两条线拧在了一起AI辅助测试加上AI系统测试。学完你不会去从头训练一个神经网络但你清楚模型怎么训练、怎么评估、怎么被测、怎么接进现有测试框架。1.2 课程模块是怎么安排的整个训练营2期的结构给我感觉是故意设计成了“楼梯型”不是一次爬坡而是先垫基础再上强度。第一段是预修内容主要补Python和自动化测试的地基。很多人觉得这段可跳过实际上后面写提示词工程、调LLM API、做断言解析全靠这点Python功底。如果连装饰器、异常处理、requests调用都不熟后面作业会写得很痛苦。第二段进入AI通识讲机器学习基础概念、常见模型类型、训练集验证集测试集的划分、过拟合和欠拟合、模型评估指标。这部分听起来像理论课但老师会把概念落到测试场景里比如怎么判断一个缺陷样本被漏掉了。课程还专门讲了数据偏差、模型偏见问题和后面AI系统测试是呼应的。第三段开始上大模型相关的实战技能包括提示词工程、上下文管理、LLM API调用、结构化输出、用模型生成测试用例和测试脚本。这一段是整个训练营最“显性”的收获因为上完课你立刻能在工作里用起来。第四段是AI测试工程化包括AI模型评测集的搭建、模型鲁棒性测试、智能断言、自动化脚本失败自愈以及一些图像类测试的方案对比。4周时间每周一个主题最后结业项目要求每个人独立完成一个“AI辅助测试”的作品。1.3 和普通测试开发课程的区别在哪我最开始以为这只是一个挂AI名头的自动化测试课实际学下来发现有三点很不一样。第一它不教你死记硬背框架API而是反复强调策略设计。比如“用大模型生成用例”和“用大模型稳定地生成高质量用例”是两码事后者要考虑输出格式、异常兜底、上下文长度、模型温度参数这些不是调一个SDK就能解决的。第二它讲了很多“模型不可靠”时的兜底方案。传统测试追求可重复、可确定到了AI这里模型输出天然带随机性今天的回答和明天可能不一样。课程会告诉你哪些环节要接受不可靠哪些环节必须做规则校验这种“规则和模型混合”的思路对落地非常关键。第三结业项目不是做玩具而是要求真连外部的LLM服务真的用Selenium抓页面真的生成一个能跑起来的pytest脚本。工程完整度比单点demo重要得多。2. 人工智能测试开发的核心技能拆解2.1 机器学习基础不调参也要能看懂模型评估指标训练营在AI通识阶段没有让我去手写神经网络的backpropagation但有些基础知识绕不过去因为它们直接出现在AI测试的工作里。比如你要测一个AI模型判断“这副图像里有没有缺陷”模型会输出一个0到1的概率分。你把阈值定在0.5超过就算有缺陷。可这个阈值不是拍脑袋定的它取决于你更怕漏报还是更怕误报。这时精确率、召回率、F1值就派上用场了。指标含义在AI测试里的理解方式准确率Accuracy所有预测里猜对的比例样本均衡时才有参考价值样本不均衡时会骗人精确率Precision预测为缺陷的样本里真正是缺陷的比例精确率低说明模型“狼来了”叫得太多误报多召回率Recall真实缺陷样本里被模型找出来的比例召回率低说明缺陷漏掉了容易漏测F1值精确率和召回率的调和平均两个指标冲突时用它做综合评估这里有一个特别典型的测试思维转变以前测功能用例执行结果只有通过和不通过是确定性的现在测模型评估结果是“召回率下降到86%了这个版本能不能发”。没有绝对的对错只有基于业务风险的权衡。训练营用了大量这类case来磨判断力。课程里还讲了过拟合。这个概念对测试开发不是用来调参的而是用来设计测试场景的。如果一个模型在训练集上效果极好一到新数据就崩说明它把训练数据背下来了而不是真正学到了规律。你在设计AI系统测试时一定要准备一份“模型没见过的数据”去做验证这就是测试领域的“验证集思维”。2.2 大模型在测试里的三种典型用法训练营花了最多时间讲大模型的应用这部分我按照自己的理解重新梳理了一遍发现实际落地基本就是三种套路。第一种是“需求到用例”的生成。输入一段需求描述让模型输出结构化的测试点。这里不是说让模型一次性给你全部用例而是先让它拆业务规则再根据规则生成正向、反向、边界用例。实际经验是模型对“边界值”和“异常场景”的敏感度不如资深测试但它的广度帮大忙短时间内能铺出一堆你容易漏掉的组合场景。第二种是“用例到脚本”的转换。你写好自然语言的测试步骤模型帮你转成pytest或者Selenium代码。这个用法看起来很爽但稳定性是最大的坑。模型生成的代码经常有小毛病不是漏了等待条件就是选择器写错。训练营的做法是让模型输出“关键步骤代码片段”再由工具层做封装和校验而不是让模型直接生成一整个完整工程。第三种是“结果到断言”的智能断言。传统自动化里断言非常死只能判断元素在不在、文本等不等于。但实际业务有一堆模糊判断比如“页面提示语是否符合友好性”、“推荐结果是否和用户偏好相关”。这时候让模型去读页面内容并给出语义层面的判断会比写死规则灵活很多。另外还有一类是AI视觉测试用目标检测模型帮你去识别页面元素位置解决传统自动化里元素坐标变动就失效的问题。训练营里介绍了YOLO这类检测模型的思路但没要求我们自己训练重点是让我理解“视觉定位”和“DOM定位”在测试工程里怎么搭配使用。2.3 提示词工程不是聊天技巧是稳定的接口设计以前我以为提示词工程就是“把话说清楚”学完之后发现不对它其实是一门接口设计。测试场景里所有提示词最终都要接进自动化流程所以输出格式必须完全可控。你不可能让模型今天返回一段散文、明天返回一个JSON、后天又多了一层嵌套字段。训练营给了我们一套结构化的提示词模板我现在一直在用角色你是资深测试开发工程师。 任务根据下面的需求描述生成测试用例。 输出格式严格输出JSON数组每个元素包含case_id、title、precondition、steps、expected等字段。 约束不要输出解释不要输出markdown代码块不要遗漏边界条件。 需求描述{{这里放入经过裁剪的需求文本}}这套模板的核心不是“角色扮演”而是用“输出格式”和“约束”把模型的自由发挥空间尽量锁死。和写接口时定义入参出参是一个逻辑。温度参数也要注意用例生成场景中我经验是把temperature调低到0.2以下让它尽量稳定但如果要做发散性的探索测试反而可以调高让模型产生更多“不常见但有可能”的用例。我们训练营里还自己动手做了个评测集来选模型比如准备100条需求文本用多个模型分别生成用例再人工打标统计生成用例的有效率和格式合规率。这个过程本质上就是在做AI模型测试比嘴上说“我觉得这个模型好用”靠谱一百倍。3. 实操项目复盘做一个AI辅助Web自动化用例生成器3.1 项目要解决的问题训练营的结业项目要求自选方向我选了一个特别贴近日常工作的场景输入一个网页URL系统自动抓取可操作元素再配合用户填写的业务需求描述让大模型生成一版可执行的pytest用例脚本。这个想法一开始被不少人质疑说“AI生成的脚本你敢直接跑吗”。我的目标也不是全自动无人值守而是把从0到60分的重复劳动交给AI让测试工程师只做最后20%的修改确认。只要框架设计合理效率提升非常明显。3.2 整体架构与分层思路我把系统设计成了四层避免模型把一切都掺和在一起。第一层是元素采集层用Selenium访问页面抓取所有可见、可交互的元素记录元素的标签、文本、class、id、name等属性并给每个元素分配一个稳定标识。第二层是上下文构建层把元素列表和用户输入的需求描述拼装成一个结构化的提示词上下文。第三层是模型生成层调用大模型接口让模型输出JSON格式的用例数据不做代码生成只做“用例逻辑”的生成。第四层是转换执行层把JSON用例映射成pytest方法自动生成测试文件并执行。关键的设计决策是模型不直接生成Python代码而是先输出JSON。原因有两个第一JSON格式校验容易代码格式校验难第二JSON只是一个中间表示我可以在转换层做安全检查过滤掉模型生成的危险操作或者无效选择器。3.3 关键代码实现和踩坑点元素采集层的核心逻辑其实就是一个带过滤条件的Selenium遍历from selenium import webdriver from selenium.webdriver.common.by import By def collect_page_elements(url): driver webdriver.Chrome() driver.get(url) elements [] for el in driver.find_elements(By.XPATH, //*[id] | //button | //input | //a): tag el.tag_name text (el.text or ).strip()[:50] el_id el.get_attribute(id) el_class el.get_attribute(class) # 过滤掉不可见元素和纯装饰元素 if not el.is_displayed(): continue if tag in (script, style, meta, link): continue elements.append({ tag: tag, text: text, id: el_id, class: el_class, name: el.get_attribute(name), }) driver.quit() return elements这里遇到的最大坑是“可交互元素”的判断。第一次我只采集了button、input、a结果漏掉了一些用div模拟的按钮。后来把规则改成“有onclick事件、有role属性、或者带cursor样式”的div也纳进来虽然有点脏但覆盖面明显提升。这个经验告诉我AI项目里的数据采集层直接决定上游生成质量与其调提示词不如先把元素采集做干净。模型的提示词部分我要求它针对每个元素生成操作步骤并且明确告诉它“如果一个元素没有任何业务含义就不要生成用例”。最初没写这句话时模型会把“footer里的友情链接”也当成核心链路来测生成的用例一大堆有效信息密度极低。JSON解析层用了一段相对保守的代码import json from typing import List, Dict def parse_cases(model_output: str) - List[Dict]: # 模型可能输出前后多余文本先尝试截取JSON数组部分 start model_output.find([) end model_output.rfind(]) 1 raw model_output[start:end] data json.loads(raw) required {case_id, title, steps, expected} filtered [] for item in data: if required.issubset(item.keys()): filtered.append(item) else: # 记录不合规的项用于后续评测模型效果 self.logger.warning(f跳过不合规用例: {item}) return filtered这段代码只做两件事截取JSON、按必填字段过滤。没有用复杂的异常处理因为问题不在“JSON解析报错”而在“模型返回了合法JSON但内容瞎编”。我后来加了一个字段叫“data_required”表示这条用例是否真的依赖页面实际数据如果模型不确定就写false转换层会自动跳过这一步避免生成一堆永远跑不过的断言。最后转换层把JSON mapping到pytest测试函数。这里我没有用动态代码生成的方式而是用exec在隔离命名空间里创建测试函数。安全上很敏感但这是内部工具且输入源是受控的模型输出所以风险可控。如果你在公司里做类似工具建议加一道“人审”按钮AI生成完先给你预览点确认再创建脚本避免不可见的风险。3.4 项目跑到什么程度算合格训练营对结业项目的验收标准不是“代码能跑”而是有三层要求第一演示路径完整确实能从URL开始生成脚本第二有一定的鲁棒性处理比如模型输出错误格式时有兜底第三给出一份评估数据说明AI生成用例的覆盖率和人工修改率。我最后在内部一个电商demo站上做了验证AI生成10条用例人工不改直接能跑通的有6条另外4条是元素定位或预期值需要微调。如果纯人工写这10条用例大概要40分钟AI从开始到生成脚本只要3分钟加上人工修改十分钟左右搞定。这个效率提升对日常回归来说非常可观。4. 常见问题与排查技巧实录4.1 模型“一本正经地胡说八道”怎么防做AI测试相关工具最常遇到的就是模型输出看起来很像一回事实际跑起来全是问题。比如让它根据需求生成登录用例它编了一个“验证码校验”的步骤但项目里根本没有验证码或者断言文本写得和页面实际不一致。我的排查思路是把它们分成两类一类是“格式性幻觉”模型没按你要求的JSON格式输出这种靠解析层的严格校验就能拦住另一类是“业务性幻觉”格式完全正确但内容不对这种只能靠上下文约束和人工抽检。上下文约束的做法是在提示词里把页面元素列表原样给模型同时明确告诉它“你只能基于我提供的元素来生成步骤不能假设页面存在这些元素之外的控件”。这能显著减少编造成分但没法完全消除。所以项目里的人工确认环节不能省。4.2 环境不一致导致AI生成脚本跑不起来有一个问题不是模型造成的而是执行环境太乱。Selenium版本、浏览器驱动版本、pytest插件版本只要有一个对不上AI生成的脚本就跑不动。而且模型并不知道你本地的Chrome是哪个版本它默认生成的代码大概率用的是最新API版本不兼容是必然的。解决方式是用固定环境。我给自己项目写了一个requirements文件并且建议所有同学都这样做selenium4.15.0 pytest7.4.3 requests2.31.0这里不推荐写“”这种模糊版本。AI辅助测试工具首先要保证“生成代码的环境”和“执行代码的环境”完全一致否则没法稳定复用。4.3 测试数据脏AI效果直线下降AI对输入数据的敏感度比传统程序高很多。一开始我直接把整个页面的HTML塞进提示词希望模型自己找重点结果生成的用例全是噪音。后来改成提取关键元素属性再按可交互性过滤一遍效果立刻好了很多。这个经验可以推广到所有AI测试场景。你要给模型的不是“原始垃圾”而是“你已经初步加工过的半成品”。数据清洗不是训练模型阶段才要做的事AI辅助测试工具同样要做。4.4 常见问题速查表问题现象可能原因排查与对策模型返回的不是合法JSON提示词没锁输出格式或模型版本差异检查提示词中的“严格输出JSON”指令解析前兜底处理markdown代码块生成的用例总是重复上下文元素列表太重模型注意力被分散精简元素数量去掉不可见元素和装饰性元素断言文本和页面始终不一致页面文本是动态渲染AI拿到的和实际执行时不同改用更稳定的定位属性执行前动态抓取当前文本做断言脚本运行极不稳定时好时坏Selenium隐式等待不够或元素加载有延迟加入显式等待让AI生成脚本时统一封装wait_click等公共方法本地能跑到CI上就失败浏览器驱动和系统路径不一致把浏览器驱动放在项目目录或使用容器化环境5. 从训练营反推出来的学习路线与面试准备建议5.1 4-6个月的AI测试开发学习路线训练营时间毕竟有限大量的消化和扩展还得靠自己。我根据自己的学习过程整理了一条更通用的路线适合已经有一定自动化测试基础的人。第一个月先补Python和自动化测试的短板。这一阶段不用碰AI如果你能熟练用pytest写接口自动化用Selenium写UI自动化就已经具备基本盘了。第二个月接触机器学习基础重点看模型评估指标和数据集设计。不需要做算法练习但要搞明白准确率、精确率、召回率、F1这些指标在业务里的取舍。第三个月开始学大模型应用重点就两个关键词提示词工程、结构化输出。建议自己写一个小工具让模型帮你从需求文档里提取测试点要求它输出JSON格式。第四到第六个月做AI测试方向的项目建议选一个和工作强相关的方向。如果你公司有搜索推荐系统就去做它的离线评测如果公司有智能客服就去做意图识别准确率测试如果什么都没有就自己开发一个AI辅助测试工具用来给内部项目生成回归用例。5.2 测试开发面试里AI题到底怎么答最近讨论“测试开发八股”、面试题的社区热度很高我看下来AI相关的高频面试题其实很集中。第一类是“AI会取代测试开发吗”。这类题不要回答“会”或“不会”而是应该讲清楚你的判断依据AI能替代的是重复劳动不能替代的是测试策略设计、质量风险评估、对业务的理解。测试开发的岗位价值正在从“写脚本的人”变成“设计测试系统的人”。第二类是“怎么测试一个AI模型”。基本答法是从数据、模型、系统三个层面展开数据层面看分布和偏差模型层面看精确率召回率等指标系统层面看和外部交互时的鲁棒性和性能。第三类是“大模型生成测试用例不稳定怎么办”。这道题其实就是考工程化思维稳定模板、输出校验、人工兜底、评测集选模型这几个点答出来基本能让面试官满意。还有一个大家问得很多的事要不要去考“人工智能训练师”之类的证书。我的看法是证书对刚转行的人可以作为学习打卡的证明但面试官更看重你能不能讲清楚项目里模型评测指标怎么算、AI工具落地的瓶颈在哪。与其花大量时间备考不如把一个AI辅助测试项目打磨完整把中间踩坑、调优的过程排成一页纸面试价值高得多。5.3 给后来者一个最实在的建议如果我现在重新上一遍这个训练营我会把更多时间花在“评测集”上。很多人学完之后会做各种AI测试工具但很少有人认真建一个属于自己的测试样本库用来测评“哪个模型更稳定”、“哪个提示词版本更好”。没有评测集你所有的优化都靠感觉有了评测集你的每一步改进都能用数据说话。这也是AI测试和传统测试最一致的地方先定义度量标准再谈优化路径。训练营2期给我的启发不是某个具体API而是让我把“测试者”的角色从“执行用例的人”变成“建立质量度量体系的人”。这个思路比任何工具都值得花时间去体会。