凌晨两点测试报告还是红的。我把日志翻来覆去看了好几遍最后得出结论页面元素没定位到脚本在第三步就挂了。那时候我在菏泽的一家本地公司做测试管着一堆没人爱看的自动化用例维护成本却快赶上开发。这不是技术问题这是我的问题——我做测试做了四年从手工点点点到半自动脚本始终卡在一个瓶颈上我能写的用例越来越复杂但团队越来越依赖我个人经验换个人就玩不转。后来我把AI测试这条路慢慢趟通了靠两件事一是把“用AI来测软件”和“测AI软件本身”分清楚二是从只盯UI脚本往数据、模型、接口、用户反馈这些层去补。现在我在一个国际项目里负责AI测试方案的设计与落地工具链、流程、止损机制都是自己从零搭出来的。这篇文章把我这几年的路数做个复盘。不灌鸡汤只讲我踩过的坑、验证过的方法和可以直接抄作业的配置。适合三类人看正在做功能测试想转AI测试的已经写自动化脚本但被维护成本折磨疯的以及接到了AI相关系统的测试任务、不知道从哪下手的。1. 从菏泽到国际项目我的AI测试转型背景1.1 小城市测试工程师的困局菏泽本地的软件公司不算多测试岗位更少大部分项目是本地生活服务、政企类系统业务逻辑不复杂但流程很传统。我在那四年里做过的事情基本就是用例设计、手工回归、偶尔写几个半成品的脚本。这些活不难难的是没有体系没有持续集成没有缺陷度量没有版本基线。你在这样的环境里待久了很容易产生一种错觉——测试就是个点鼠标的活谁都能干。真正让我慌的是后来参与一个外地接过来的外包项目。对面要求三天内交付一份可自动执行的回归套件我翻遍自己攒的脚本发现没有一个能直接跑。那一刻我才意识到侷限我的不是菏泽这座城而是我根本没有跳出“手工半自动”的思维方式。于是我开始逼自己接线上项目、看开源测试框架的源码慢慢从“会写脚本”往“会设计测试链路”的方向走。这段经历给我的教训就一条小城市也可以触达大项目前提是你先让自己的能力半径大于所在平台的半径。后面所有AI测试相关的转型都是在这个痛点下逼出来的。1.2 重新定义“AI测试”它到底是干什么的“AI测试”这个词这两年被用烂了。有人觉得是用ChatGPT写测试用例有人觉得是给自动化脚本加个智能等待还有人说AI测试就是测试AI应用。我一开始也糊涂直到把一个国际项目的测试方案拆完才意识到必须做一次彻底的正名。按我现在的理解AI测试分两条大路第一条用AI辅助测试。就是用机器学习和深度学习能力去解决传统测试里“人肉总结、人肉定位、人肉判断”的问题。典型场景包括智能生成测试用例、缺陷预测、UI元素视觉定位、脚本失败自动修复、日志聚类、视觉回归。这条路的核心产出是让测试过程更快、更省人。第二条测试AI系统本身。被测对象是算法模型、大模型服务、推荐系统这类东西传统黑盒用例根本覆盖不了。你需要验证模型精度、鲁棒性、性能、安全性甚至要处理“模型没有标准答案”的挑战。这时候图灵式评测、对抗样本、评测集建设这些方法就会派上用场。我把这两条路做了个对照避免自己也跑偏方向核心问题常用技术典型产物用AI辅助测试测试执行效率低、维护成本高视觉定位、OCR、LLM用例生成、日志聚类自动化套件、智能报告测试AI系统模型效果/行为是否符合预期评测集、A/B盲测、鲁棒性测试、压测模型评测报告、上线准入结论如果你刚转型我建议先走第一条因为它能很快在业务里产生看得见的价值也能帮你积累对模型能力和局限的感知。第一条路走稳了再去做第二条就不会一上来就被评测指标砸晕。1.3 我的技能栈清单很多朋友私信问我“AI测试工程师要学什么”我的答案非常务实不用一口气学完深度学习像我这种半路出家的人是按场景倒逼着学的。编程基础Python为主pytest/unittest能写脚本能读源码。这部分占了我前期60%的学习时间。自动化框架Selenium、Appium、Playwright至少精通其中一到两套尤其是移动端App自动化。图像与OCROpenCV的基本用法、模板匹配、Tesseract后来加了PaddleOCR。视觉定位的底子都在这里。大模型调用能力会写requests脚本调API会设置参数会写提示词会解析多模态模型的返回结果。工程化基础Docker、CI/CD、日志采集。没这个AI能力再强也只能在你电脑上自嗨。基础机器学习指标准确率、召回率、F1、混淆矩阵。不需要会训练模型但得看得懂评测报告。这个清单看起来多但如果你按“我在下一个项目里要解什么题”去学速度会快很多。我是先接了App自动化项目才去啃OpenCV先要测公司的对话机器人才去研究评测集。技能不是攒出来的是被问题逼出来的。2. AI如何重构APP自动化测试全流程2.1 传统自动化三大痛点我最早负责的是一个跨境电商App的回归测试iOS、Android、H5三端都覆盖。表面上自动化用例跑了三百多条实际上每天光修脚本就要花掉半天。问题高度集中在三处。第一元素定位不稳定。Android端很多控件没有resource-id开发者一高兴改个ID脚本全挂iOS端 accessibilityLabel 经常被文案更新带偏H5页面里WebView混合布局xpath又长又脆。说白了传统定位方式是把测试脚本绑死在实现细节上代价太高。第二等待策略靠猜。页面加载快慢、网络波动、动画时长都会影响执行结果。有人习惯sleep(3)慢了误报快了必挂有人写显式等待但元素“存在”不等于“可点击”可点击也不等于“渲染完成”。脚本里全是时间赌局。第三维护成本失控。一条用例平均生命周期不到两周UI一改所有相关脚本跟着改。到后来团队宁可手工回归也不想碰那堆红得发紫的用例。这几个痛点不是靠“更勤快的自动化”能解决的得换个定位思路这也是我把AI引进去的直接原因。2.2 AI视觉定位与智能等待我改进的第一步是把“靠控件ID找元素”改成“靠视觉找元素”。截图下来对目标区域做检测或模板匹配直接拿坐标去点击。对稳定页面OpenCV模板匹配就够用对动态场景用目标检测模型识别按钮、输入框、列表项拿不到坐标的时候再让OCR把屏幕上的文案读出来按文本内容定位。后来国际项目里我更激进了一点直接把截图丢给多模态大模型提示词里写清楚“请返回图中【立即购买】按钮的中心坐标按JSON格式输出”然后解析返回结果。这套方案对中英文混排、样式变来变去的界面特别抗造。请你注意这种方式带来的定位能力提升前提是模型返回格式必须可解析所以system prompt和json schema校验要做死。再说智能等待。我不再设固定时间而是做了一个“页面静止判断器”轮询截图计算截图的感知哈希差异连续N次无变化才认为页面稳定同时监听网络请求请求结束后再给视觉判断一个容错窗口。这样脚本的执行时长从平均40秒压到20秒以内再没出现过“等不到元素”的玄学。这里插一段可参照的视觉定位代码用的是我那时在项目里的思路模型服务可以换成你私有化部署的任何多模态接口import base64 import json import requests def locate_by_vision(image_path: str, target: str) - dict: with open(image_path, rb) as f: image_b64 base64.b64encode(f.read()).decode(utf-8) payload { model: your-multimodal-model, messages: [ { role: user, content: [ {type: image_url, image_url: {url: fdata:image/png;base64,{image_b64}}}, {type: text, text: f请找出图中包含‘{target}’字样的控件中心坐标 以{\x\: 0, \y\: 0}格式输出如果找不到则输出{\x\: -1, \y\: -1}。} ], } ], temperature: 0.0, max_tokens: 100, } resp requests.post(http://your-model-endpoint/v1/chat/completions, jsonpayload, timeout20) content json.loads(resp.json()[choices][0][message][content]) return content # 返回 {x: ..., y: ...}这段代码不是什么高深东西但实践价值很高它把定位从“依赖DOM结构”迁移到了“依赖视觉信息”对动态界面更稳。踩坑提醒模型返回偶尔会带多余文字我建议先做一轮JSON清洗再走schema校验解析失败就重试重试两次仍失败才判脚本错误不要一上来就判产品缺陷。2.3 视觉回归与自动修复光解决定位还不够界面回归的另一个大坑是像素级误报。我把视觉回归分成两层第一层是结构比对用目标检测框出关键控件比对控件是否存在、位置是否发生偏移第二层是语义比对让多模态模型判断截图里是否存在“内容变化但逻辑不变”的区域比如广告轮播、动态数字这些地方直接标记为mask区。自动修复方案也很直接。脚本跑挂之后系统先把失败截图、平台日志、步骤历史打包发给大模型分析让模型输出“失败原因替换建议”。如果模型认为只是定位方式失效就自动生成新定位表达式并跑一次冒烟验证验证通过就提交patch验证不通过或模型判断为真实缺陷才升级给人处理。这套机制上线后我那条跨境电商App回归链路的稳定性从92%左右提到了97.5%误报率从30%降到了12%。数值是能说明问题的但我更想强调的是判断逻辑AI自动修复不是让你的脚本“永不失败”而是把失败分成两类——环境类失败和产品类失败环境类交给AI直接处理产品类才留给测试人员深挖。边界划清楚团队对自动化套件的信任度才会起来。3. 测试AI系统大模型服务的评测与参数配置3.1 大模型API测试的参数矩阵测试对象的AI化之后测试方法也得跟着变。现在很多国际项目里被测系统是一个对话机器人、一个自动翻译引擎或一个内容审核服务它们通常以API方式对外暴露。测试这样的服务第一件事就是吃透参数矩阵。我拿一个典型的对话模型接口举例。它通常支持这些参数字段参数取值范围对结果的影响测试建议model不同规模/版本能力差异版本上线前必须全量回归temperature0~2随机性0和1.2各跑一轮验证边界top_p0~1采样范围与temperature联动选一种控制即可max_tokens1~N回答长度和耗时边界值测试要包含1和最大值streamtrue/false响应模式压测时单独评估timeout/retry秒/次数用户体验超时阈值要有监控数据支撑为什么这块对AI测试工程师特别重要因为你面对的不是传统接口那种“参数固定、输出固定”的逻辑。temperature0时输出是相对确定的适合做功能回归temperature1.5以上时同样输入可能每次都不同这时候就要做概率分布式的验证而不是靠单次断言下结论。我团队里新来的同事总喜欢用一套用例跑三遍就拍板我每次都提醒先看清楚参数设置再决定验证策略。我实测过一个典型的参数影响把temperature从0调到1.2同一份投诉工单摘要任务里格式不规范的输出从2%上升到18%。这类差异在需求评审阶段如果不约定清楚到了线上就是“时好时坏”的客服投诉。3.2 图灵式评测与评测集建设“图灵式评测”这个词在热词里出现过我实际做项目时也确实用过这个思路。它不是严格意义上的图灵测试而是借用它的盲测思想把AI系统的输出和标准答案放在一起隐藏来源让评估员逐个打分。不告诉评估员哪个是机器生成的、哪个是人工写的从而判断模型效果是否达到可用线。具体流程我是这么跑的建评测集也叫golden set。里面覆盖常规请求、边界输入、对抗样本、超长文本、多轮对话、敏感内容等。批量跑模型导出每一条输入对应的输出。用随机化工具打乱顺序交给标注员按“正确性、完整性、格式规范度”三个维度打分。汇总分数后按版本对比形成模型上线准入结论。评测集的维护比测试用例难得多。测试用例是写死的评测集需要持续补充线上真实样本还要定期剔除过时内容。我当时的做法是每周从线上抽200条真实会话记录人工标一遍过滤掉带隐私信息的字段后加入评测集。这个动作看起来笨但它决定了评测结果到底能不能反映真实用户体验。指标方面除了人工打分我也会用BLEU、ROUGE做初筛但初筛只用来跑量最终判决还是靠人工盲测。纯机器指标容易失真——两个句子在指标上很接近实际一个通顺一个难读这种事太常见了。3.3 服务性能与稳定性验证模型能力只是第一关上线前还得过性能这关。调用链路上一个模型生成几十秒用户早跑了。我验大模型服务性能的时候主要看四个指标并发数、吞吐量每分钟处理多少请求、首token延迟用户看到第一个字的等待时间、错误率。压测方案和传统接口有些差异因为模型消耗与输入输出长度强相关我会把压测数据分成短文本、中文本、长文本三类分别压分别出报告。同时要监控显存和CPU占用很多模型服务单机部署后并发一上来延迟会指数级恶化。这里必须提一个国际项目里的合规细节客户数据不能拷来拷去更不能随意发送到外部服务。我最终采用的是私有化部署开源模型、本地跑评测和压测所有样本先脱敏再入料。这个问题越早和客户确认越能避免后边整个测试方案返工。所谓“AI参数配置”除了模型参数更关键的是在约束边界内把超时、重试、熔断配好——这才是稳定性的大头。4. AI测试工具怎么选从开源到商业4.1 工具选型对比表工具选型是很多人找我聊的第一话题但我通常先把热门工具放在一起做个矩阵再谈判断标准。这里列的是我在不同项目里实际用过的组合工具擅长场景优势短板SeleniumWeb平台回归生态成熟、社区大元素定位思路传统PlaywrightWeb全流程自动化自动等待、速度快AI能力需要外部接入AppiumiOS/Android/H5跨设备、跨语言性能一般定位依赖控件Maestro移动端快速建模YAML简洁、上手快复杂断言能力有限AirtestPoco游戏/安卓UI图像识别强、UI树也可拿非游戏场景利用率低自研AI视觉层APP/游戏/动态UI最灵活、可对接OpenCV和LLM工程化成本高需要人手维护每一种工具都不是万能的。Selenium解决不了动态界面的定位问题Playwright解决不了游戏引擎渲染后的控件问题Airtest在游戏里很强但在复杂业务逻辑断言上又不够。我做国际项目的时候底层框架选了Appium上层套了一个自己写的AI视觉层既保留了生态兼容性又补上了定位能力。4.2 判断标准与取舍我建议你选任何测试工具前都想四个问题失败原因可解释吗如果工具报红了半天你都不知道是环境挂了还是产品逻辑挂了那等于没报。维护成本低吗AI能力带来多少好处能不能抵消模型接口、硬件资源带来的新增成本能不能配合数据层测试很多业务异常不在界面上在接口和数据一致性上工具只盯界面就漏了。团队学得动吗再强的工具团队用不起来就是废铁。商业工具我也试过。优点是省事仪表盘、报告、告警全都现成缺点也明显定制AI策略很困难数据隐私也是个问题。开源自研胜在可控但前提是你得有一个能扛代码的测试开发。我的建议是如果项目周期紧、团队人少先用商业平台把流程跑通别在自研上恋战如果是要长期服务一个高复杂度产品那投入自研AI测试层很值得因为它能跟随业务姿势成长而不是被平台局限住。4.3 从0到1搭建轻量AI测试平台在说怎么搭平台之前先明确一点平台不是一步到位的我花了两个迭代才让团队真正用起来。整个结构大概是五层测试仓库管理用例、测试数据、评测集。Git是基础没有这个一切白搭。执行环境用Docker封好Android和Web的执行容器统一起点、统一清理。用例管理把AI生成的用例和人工维护的核心用例分开标记AI用例允许不稳定核心用例必须稳定。AI能力层提供视觉定位、OCR、智能等待、自动修复、评测打分这些服务以工具库形式被测试脚本调用。报告与告警每次执行自动生成失败原因分类按“环境/脚本/产品缺陷”三类推送对应负责人。搭建顺序也有讲究。我当年想一口吃个胖子先搞了报告系统结果用例还不稳定报告全是噪声直接被团队打入冷宫。后来重新来先保证核心用例稳定再加AI定位最后才上报告和告警。平台的价值是逐步长出来的不是一次交付的。5. 游戏场景的AI测试落地5.1 为什么游戏自动化测试和传统Web不一样游戏是AI测试里最特殊的一块因为它跟Web和App有着本质区别界面不是DOM文档而是图形引擎实时渲染出来的。你没办法通过resource-id或xpath去定位“开始游戏”按钮因为你拿到的只是一帧一帧的像素。另外游戏界面动效密集弹窗、飘字、转场动画到处都是像素级断言基本没法用。还有机型适配问题同一条路径在低端机上可能加载多两秒一个固定等待就把脚本带坑里了。这些特点决定了游戏自动化测试必须走视觉识别这条路AI在这里不是锦上添花而是必需品。5.2 用AI让游戏自己能跑起来我落地过的一个典型场景是“活动引导流程自动化”。需求是每天跑一遍新手引导、活动入口、奖励领取这条主链路确保没有卡死的步骤。用传统脚本写的话等按钮渲染、等动画结束、再点击每一步都要单独适配效率极低还老挂。后来我用AirtestPoco做基础框架再用自研AI视觉层做兜底。Poco在接入引擎SDK后可以拿到UI元素树比如按钮名称、坐标拿不到UI树的地方就切到图像识别。两条腿走路让脚本的适应能力大幅提升。更有意思的是用强化学习训练Bot来打关卡。我试过训练一个Agent在战斗关卡里自己做决策目标是在规定时间内找到通关路径。Bot运行过程中会记录每一步的状态、行为、结果测试人员可以直接用这些数据发现“某个拐角会卡住”“某类技能释放后无法继续”等可复现问题。这一招在国际项目里帮客户压测出不少真实卡死路径效果比人工反复手点强太多了。5.3 游戏UI、数值与性能的AI校验游戏测试除了“能跑”还要验证UI内容、数值逻辑、性能表现这些地方AI也有用武之地。UI内容校验我常用OCR。活动面板里的道具名、价格、按钮文案截图后用OCR识别出来和配置表比对防止出现错字、漏字、价格对不上。这比人眼扫屏可靠也快得多。数值校验比较隐蔽。某抽卡游戏要验证“掉落概率符合配置”人工想验证很难我就写了个AI样本收集器长时间自动跑挑战记录每次掉落结果积累几百个样本后做统计分析。连续一百局不发某道具这类问题很快就能暴露出来。性能维度核心是帧率和卡顿曲线。我用脚本在游戏里自动跑图同时录帧数据再用AI聚类掉帧事件和版本变更信息做关联。哪个版本、哪个地图开始掉帧一查便知。这套组合拳下来游戏团队从“被玩家骂卡才去查”变成了“版本上线前自己就能发现”。6. 踩坑实录AI测试稳定性的5个大坑6.1 问题速查表别看我前面讲得很顺实际踩过的坑一个不少。我把最典型的几个放在下表里都是自带根因和解法的坑现象根因解法AI生成的用例高度同质化提示词没注入业务规则和边界条件把产品规则写进prompt限制用例模板类型视觉定位换机型就挂只用了单一分辨率模板做多尺度模板截图先归一化再匹配大模型输出格式偶发崩坏直接解析全文没做schema校验强制JSON格式加清洗和重试误报率居高不下AI断言阈值太低低置信度也判失败对置信度低于0.7的结果直接放行只记录不报错模型评测集越跑越失真评测集不更新模型记住了题目每周抽线上样本加人工审核替换淘汰样本这些问题背后有个共通点AI测试的稳定性从来不只是模型本身的问题而是整个测试链路的设计问题。你把AI当作一个不可控的组件来对待给它做防护、做重试、做灰度它就能稳定你要是把它当神上线就等着被雷劈。6.2 鲁棒性的关键数据与基线我最想强调的一个经验是任何AI能力上线之前先收集基线数据。所谓基线就是你在没有AI干预的情况下手工或传统脚本跑一周得到的结果集合。举个例子我想用AI视觉定位替换传统的xpath定位我不会直接上线切换。第一周AI和新旧两套定位方式并行跑每天对比结果第二周把AI定位的失败样例拉出来人工分析看是环境噪声还是模型能力不足第三周再动态调整阈值或模型精度确认无误后才全量。这套流程看起来慢但有效地避开了“AI上线第一天就翻车”的尴尬。另外还有一个原则宁可漏报不可误报。误报会把团队对自动化报告的信任消耗干净。漏报只是没发现问题误报是在制造问题。所以配置AI断言的时候我默认把置信度阈值调高一些宁可让某些真实问题逃逸到人工测试里也不能让报告变成狼来了。6.3 稳定性的工程保障最后聊工程保障。AI能力再强也得靠三个基础习惯来保护超时和重试必须有上限。很多模型接口偶发变慢不能因为一次调用超时就判整个用例失败。失败必须先分类。环境故障、脚本bug、产品缺陷要分开统计否则报告上全是红没人知道该干嘛。每日巡检加告警。我搭的平台每天凌晨跑一轮冒烟早上给团队推送结论有问题早发现早处理别等版本发布会前才炸。做AI测试这些年我最大的体会是AI测试不是让AI接管你的工作而是让人的判断力上移。以前你花两小时查一个脚本为什么挂现在AI把那层重复劳动消化了你得空出精力去判断业务逻辑本身对不对。这才是AI对测试行业真正改变的地方。7. 如果考软考AI测试论文怎么写7.1 论文结构建议“AI测试”出现在软考论文题目里已经是这两年的常客了。如果你正准备软考高项想以AI测试作为论文主题我提供一个我亲自验证过的写作框架。软考论文评分看的是几个点项目背景是否真实、问题分析是否切中要害、技术方案是否完整、实施过程是否有数据、结果是否能量化。很多人一上来就写“引入AI后效率高了”评卷老师一看没有具体数据直接扣分。我的建议结构项目背景写一个国际电商项目多端、多语言、版本迭代快回归压力大。痛点分析元素定位不稳定、脚本维护成本高、漏测频发。技术方案智能用例生成、AI视觉定位、智能断言、失败自动分类。实施过程数据集建设、模型选型、灰度验证、全量推进、持续优化。效果量化回归时长从多少降到多少稳定性从多少提到多少人力节省多少。这套模板的逻辑是“用问题推方案用数据证效果”正好踩在评卷老师的评分点上。7.2 我的经验总结再补充几个写论文时容易翻车的点。第一不要展示“祖传代码”也不需要贴完整实现论文考察的是设计能力不是代码能力。你架构图画清楚、流程讲明白、数据给到位比贴几屏代码有用得多。第二技术方案别吹太满。几年前我看到过有人说“AI让测试不用人了”这种话写进论文只会被扣分。AI测试的边界、稳定性风险、人工兜底方案你都该写进去。这才是成熟的工程师视角。第三量化数据要合理。我刚跑的项目里稳定性从92%提到97.5%、回归时长从4小时压到1.5小时这类数据拿出来就有说服力。但注意别编造太夸张的数字评卷老师见得多一眼就能看出水分。如果你在职考软考最好的策略就是把你自己正在做的AI测试实践直接整理成论文素材。项目真实数据可信方案务实比临时编造的场景强太多。结尾一些关于转型的实际体会我最后还想分享两件事。第一关于从菏泽小城到国际项目这条路的真实转折点。很多人以为是技术其实是我把“会什么”和“能解决什么问题”两件事拆开了。在本地公司那几年我一直在补工具的使用直到有一天我开始主动去问业务方“你最痛的是哪一环”然后才真正进入AI测试的实战状态。第二一个我一直用到现在的习惯引入任何新的AI能力之前先手工标注100条基线数据跑一周再谈上线。这个动作听起来简单但能拦住无数“看起来很美好、实际没法用”的方案。AI测试的本质不是炫技而是把不可控的东西一步步变成可控的东西。希望这篇复盘能给你一些能直接上手的思路也欢迎在评论区聊聊你自己在AI测试里踩过的坑。