AI自动化测试Agent这事不是调个大模型API就能跑通的。很多人试了一把——Agent执行到一半跑偏、断言结果飘忽不定、Excel用例生成出来没法用——然后得出AI测试不靠谱的结论。但说句实在话问题大概率不在模型在于背后的原理没搞清楚。01 Agent Loop不是调一次API是转一个圈AI测试Agent的运转方式是一个循环不是一次调用。你给它一个任务它不是直接给你结果而是看一眼当前屏幕→想想要干嘛→执行一步操作→再看结果→再想下一步……一直转到任务完成。这个循环有四个阶段少了哪个都不转感知阶段截图当前界面获取设备信息构建多模态消息。看着简单但截图时机很讲究——截早了页面没加载完Agent看到的是半成品截晚了白白浪费时间。而且截图要跟当前APP包名一起传给模型模型得知道自己在哪个App里不然判断会偏。决策阶段把截图和任务描述一起发给视觉语言模型模型输出下一步动作指令。这一步是整个循环的大脑输出质量直接决定Agent的行为。执行阶段解析模型返回的动作指令转成设备能识别的操作。点击就调点击、滑动就调滑动、输入就调输入——每一步都得映射到底层自动化框架的具体方法上。判断阶段检查这一步执行完是任务完成了还是得继续。任务完成了就退出循环没完成就把新的截图和上下文塞回去开始下一轮。当然还有保护机制——步数超限了也得退出防止死循环。这里面有个容易被忽视的设计点上下文管理。Agent的每一轮决策都依赖之前的对话历史模型要知道自己上一步干了什么、现在在哪个页面。但如果对话历史无限增长token消耗会炸。所以要么做滑动窗口裁剪只保留最近几轮要么定期归档旧上下文这个权衡得做。很多人第一次做Agent测试上来就写请帮我完成登录测试然后等模型一次性输出完整结果。不可能的。手机屏幕上的状态是动态的每一步操作都会改变界面Agent必须根据当前状态来决策下一步。你没法提前预知每一步的界面长什么样所以必须走循环——这是Agent测试和传统脚本测试最大的区别。02 前置操作AI验证两大设计思想这是我在搭框架的过程中觉得最有价值的设计思想——不是我自己发明的是在实战中逐步提炼出来的。思想一前置操作执行体 多模态大模型验证执行体结果什么意思跑测试用例之前得先进入正确的页面。比如测退出登录你得先保证当前是已登录状态。这个先进入正确页面就是前置操作。传统做法是写固定脚本做前置准备但不同设备、不同网络环境、不同账号状态下前置操作的执行结果可能不一样。你没法保证脚本一定能成功进入目标页面。我的做法是让Agent执行前置操作执行完之后调多模态大模型验证——截图当前界面问模型当前是否已经进入我的页面模型判断是否符合预期。符合就继续跑主测试不符合直接终止不浪费后续执行时间。思想二测试步骤执行体 多模态大模型分步骤验证步骤执行结果把一条测试用例拆成多个独立步骤Agent每执行一步立刻调模型验证这一步的结果。某一步失败了就立即终止不需要跑完所有步骤再告诉你失败了。比如点击设置→点击退出登录→点确认这三个步骤如果第二步就点错了传统方案会一直跑下去最后给你一个测试失败你还得手动排查哪一步出了问题。分步验证的方案在第二步就告诉你点击退出登录失败了当前页面仍在设置页排查效率完全不一样。这两个设计思想说白了就是执行的归执行验证的归验证。执行交给Agent的循环去跑验证交给多模态模型去看。两者独立运作又互相配合。理解了这两个思想后面所有的模块设计都是在为它们服务。03 坐标系统从看懂屏幕到点对位置有多远多模态模型看完截图告诉你登录按钮在坐标(540, 1200)。问题来了——这个坐标是基于什么的我用的开源手机操作执行端它的坐标空间是归一化的所有坐标都是0-999的值不管设备实际分辨率是多少。Agent输出的指令类似do(actionTap, element[450, 280])执行端再根据设备实际分辨率把0-999映射回去。这个设计的好处是Agent的输出跟设备无关换一台手机不用改指令。但前提是你得理解归一化的原理和映射方式不然出了偏差根本查不到原因。归一化坐标到真实坐标的转换大概是这样真实X 归一化X × (设备宽度 / 999) 真实Y 归一化Y × (设备高度 / 999)看着就一行代码的事但它牵出一堆麻烦截图分辨率不一定等于设备分辨率。ADB截图的时候设备可能会自动压缩截出来的图跟实际屏幕比例不一样。你得先确认截图的真实尺寸不能假设它就是设备分辨率。不同平台差异也大。Android点击是touch((x, y))iOS需要加按压时长touch((x, y), duration0.5)Android返回是keyevent(BACK)iOS是从左侧滑入返回。这些差异得在执行层统一处理不能让Agent去操心平台的事。还有个细节模型返回的坐标有时候就是不准尤其界面上元素密集的时候。同一张截图模型可能两次给出不同的坐标。这种情况下可以加一层校验——OCR识别目标文字的位置跟模型返回的坐标做交叉验证取交集区域的中心点。准确率会比单靠模型坐标高不少。坐标转换做不好Agent的操作就永远是大概在那个位置点了一下。测试需要的是精确偏几十个像素可能就点到了旁边的按钮。这个原理不搞清楚后面所有执行相关的调试都是在瞎猜。04 提示词驱动决策Agent怎么想取决于你怎么说Agent的决策质量很大程度上取决于提示词写得好不好。我在框架里把提示词体系分成了三个层次系统提示词System Prompt定义Agent的身份、能力和行为边界。这一层是宪法所有行为都不能违背它。完整的系统提示词包含三个部分——角色定义你是什么、能干什么、动作指令集你可以执行哪些操作、输出什么格式、执行规则你必须遵守什么约束。动作指令集的格式设计很关键。我用的格式是do(actionTap, element[x,y])这种结构化指令Python端用正则解析。格式不统一后面所有逻辑都建立在沙滩上。动作类型要覆盖全面但不能冗余——Launch启动App、Tap点击、Swipe滑动、Type输入、Back返回、Home回桌面、Wait等待、Finish完成任务大概就这些多了反而让模型选择困难。执行规则是最容易被忽略但最有用的部分。比如执行任何操作前先检查当前App是否是目标App如果不是先Launch“页面没加载出内容最多连续Wait三次否则执行Back重新进入”“如果进入无关页面先Back”“购物车操作时先清空已有商品”——这些规则不是靠模型自己悟出来的得在提示词里写死。测试用例提示词驱动Agent执行具体测试步骤。这层提示词的要点是——每一步只做一个动作做完立刻停止。格式是就在当前界面做一个动作点击文字[设置]看到设置页面最上方显示[设置]两个字则立刻停止。为什么要加立刻停止因为Agent特别喜欢多做事你不拦着它它点完设置还会顺手点进去看看。必须约束它的行为边界做完这一步就停别自作主张。还有一条硬规则必须写在提示词里“不要擅自处理任何类型的弹窗如果我没有告诉你处理弹窗的方式看到弹窗就立刻停止。“这条规则是血的教训换来的——我见过Agent遇到弹窗后自作主张点了确定”结果那个确认框是确认删除所有数据”。AI验证提示词用于多模态模型验证执行结果。格式是请判断实际操作与结果是否符合期望操作与结果回答格式成功 或 失败“。这里面有个细节——前置操作的验证要求基本符合就行”因为前置操作只要达到目的就行而步骤验证要求部分符合就行因为每步的结果可能不完美但整体可接受。验证标准的松紧要跟场景匹配一刀切会出问题。提示词不是一劳永逸的。模型在迭代业务在变场景在扩展提示词也得跟着调。我的做法是提示词模板单独成文件不跟代码混在一起改提示词不动代码改代码不碰提示词。05 多模态AI断言截图模型判断的套路传统断言是精确匹配——assert element.text 登录成功。要么通过要么失败没有中间地带。AI测试的断言得换个思路。多模态断言的做法是截一张图把截图转成Base64编码跟验证提示词一起发给视觉语言模型模型看了截图之后判断当前界面是否符合预期输出判断结果。整个流程是截图→Base64编码→构建多模态消息图片文字→调用模型API→解析返回结果。说起来顺畅但实操中有一个大麻烦模型返回的JSON格式不稳定。同样一个请求模型可能返回三种格式用 json 包裹的、用特殊标记包裹的、或者直接裸JSON。所以解析层做了兼容处理——先尝试提取代码块内容再尝试提取特殊标记内容最后尝试直接解析。解析失败还要用json_repair修复。这一层兼容代码看着不优雅但少了它断言功能基本没法用。在实际使用中我总结了几条断言设计的经验断言描述要具体不要模糊。“页面正常显示这种断言等于没写。改成页面顶部显示用户昵称底部Tab栏选中首页图标”——有具体可观测的视觉特征模型的判断就会稳定很多。多模态验证和文本分析要配合用。视觉模型看截图判断界面状态文本分析模型判断执行结果描述是否符合预期。两者互补视觉模型能发现截图里的异常文本模型能发现语义上的偏差。两者都通过才算真正通过漏判概率大幅下降。关键断言双重验证。P0级别的断言AI判断完之后再用传统方式二次确认。AI判pass脚本验证也pass才算真正通过。断言这块是AI测试和传统测试差异最大的地方也是最容易引起争议的地方。不要指望AI断言完全替代传统断言两种方式互补各取所长。06 智能弹窗处理测试里的灰色地带弹窗是Agent测试最头疼的问题。权限申请、登录过期、网络异常、版本更新、营销广告——弹窗种类太多传统规则匹配永远补不全。我在框架里做了一套基于OCR的弹窗处理方案分两层规则层用OCR识别屏幕文字匹配预定义的弹窗规则。每条规则是触发文字操作文字的组合——检测到打开蓝牙就点允许检测到隐私协议就点同意检测到限时优惠就点关闭。这些是最常见的系统弹窗处理逻辑是固定的不需要Agent每回都去思考规则匹配又快又稳。监控层启动一个连续监控进程每隔零点几秒扫描一次屏幕检测有没有匹配的弹窗。支持多种退出条件——检测到特定文字时停止、连续N次没检测到弹窗时停止、超时停止。还有OCR缓存机制0.5秒内不重复识别同一张截图避免性能浪费。弹窗规则的定义很有讲究。每条规则包含触发文字检测弹窗的标志、操作文字点击的按钮、OCR置信度阈值低于这个值不处理、操作后等待时间、是否模糊匹配。模糊匹配很重要——位置服务和位置权限其实是同一类弹窗模糊匹配能兜住这种差异。但OCR弹窗处理也有边界。它只能处理看文字就能判断的弹窗对于那些纯图标弹窗或者图形化弹窗OCR识别不了。这时候就得交给Agent看图判断了。弹窗处理还有个容易翻车的地方不可逆操作。涉及删除、支付、退出登录这类弹窗Agent不应该自己点必须停下来等人工确认。这条边界要在提示词里写死——“不要擅自处理任何类型的弹窗”不留灰色地带。07 结构化用例设计从Excel到自动化的桥梁很多人觉得AI Agent测试就是说一句话它自己去跑。确实可以但这种模式下Agent的行为完全不可控、不可重复、不可回归。稍微严肃一点做测试还是需要结构化用例。我的做法是用Excel模板定义用例模板有9个核心字段用例ID、测试模块、测试描述、前置操作、测试步骤、预期结果、优先级、用例状态、备注。Excel的门槛最低谁都能填不要求写代码。其中最有设计含量的是三个字段前置操作的编写公式定位目标 备选方案 判定条件“在系统桌面找到文字为天气的软件没找到就左右滑动尝试寻找找到后点击进入”——定位目标是文字为天气的软件备选方案是左右滑动寻找判定条件是找到后点击进入。三个要素缺一不可没有备选方案Agent找不到就卡死了没有判定条件Agent不知道自己进没进对页面。测试步骤的编写公式做xxx操作看到xxx“点击文字[设置]看到设置页面最上方显示[设置]两个字”——操作是点击设置预期是页面顶部显示设置。每个步骤只做一件事做完有明确的视觉验证点。步骤太长Agent理解会偏步骤太短又拆得太碎。备注里的APP主页判定标准这是最容易被忽视但最有用的字段。在备注里写清楚APP主页长什么样——比如天气APP主页包含城市名称、PM2.5与UV指数、天气状况与温度范围、未来几天天气预报。Agent验证前置操作结果时就靠这个判定标准来确认自己是否进对了页面。写好Excel用例之后Python端读取Excel、解析结构化数据、自动生成pytest测试脚本。每个用例生成一个测试函数函数里自动编排前置操作→分步执行→AI验证的流程。改用例不用改代码换执行引擎不用改用例用例和执行完全解耦。这种解耦让整个系统可维护、可迭代、可回归。没有这个标准化AI生成用例也好、人工写用例也好格式五花八门谁都接不住。08 混合架构框架管确定性Agent管灵活性纯Agent方案我试过不好用。纯脚本方案也试过遇到变化就废。后来想通了为什么非得二选一测试这件事说到底就是两种工作的混合一种是确定性操作——加载用例、按步骤执行、收集结果、生成报告这些流程是固定的不需要智能判断另一种是灵活性决策——弹窗怎么处理、定位失败了怎么办、断言结果是bug还是环境问题这些需要根据上下文现场判断。混合架构的思路就是让适合的工具干适合的活框架比如pytest负责确定性工作用例加载和解析、测试步骤的编排和执行顺序、前置条件准备和后置清理、结果收集、断言执行、报告生成。这些交给框架做又快又稳。Agent负责灵活性决策页面弹窗怎么关、元素找不到怎么换策略、断言失败是bug还是环境问题、没见过的异常怎么恢复。这些场景没有标准答案需要根据实际情况判断。判断标准很简单能不能写成if-else。能写的框架干写不出来的Agent干。边界不是固定的。一开始某个场景交给Agent处理后来发现处理逻辑稳定了就可以固化成规则交给框架。这是混合架构的迭代过程——从灵活到确定从Agent到框架。在框架里每个测试用例的执行流程都是这样的pytest加载用例→检查有没有前置操作→有的话调Agent执行前置操作→调多模态模型验证前置结果→通过则进入步骤执行→每步调Agent执行→每步调模型验证→所有步骤通过则整体验证→生成报告。整个流程由pytest编排Agent只在需要看和判断的时候出场。混合架构比纯Agent模式稳定性高出一个量级。差别就在于不该Agent干的事别让Agent干省下的推理开销和出错概率都是实打实的。09 多模型协同三种模型各管一摊搭AI测试Agent光靠一个模型是不够的。我的框架里用了三种模型各司其职Agent模型负责看屏幕、想策略、做动作。它接收截图和任务描述输出结构化的动作指令——点击哪里、输入什么、滑动到哪。这是Agent Loop里决策环节的引擎调用频次最高。多模态视觉模型负责看截图、判结果。Agent执行完一步截图发给它问当前界面是否符合预期。它不负责决策怎么操作只负责判断结果对不对。输出格式是结构化的判断结果加原因说明。文本分析模型负责看描述、判语义。它不看截图只分析文本——Agent的执行结果描述是否符合预期、步骤之间的逻辑是否自洽、失败原因的分析。它和多模态模型互补一个看图一个看文字交叉验证的准确率比单模型高很多。三种模型可以分别部署——在线调API或者本地跑Ollama都行。Agent模型因为调用频次最高建议在线API保证响应速度文本分析模型本地部署就够了省API费用。配置管理上也有讲究。不同环境开发/测试/生产的API地址、密钥、模型版本都应该分开管理不要把生产密钥写在代码里。我用环境变量或者独立配置文件的方式隔离改环境只改配置不改代码。10 这些原理不是看看就懂的得动手跑坐标转换看着简单我第一次做的时候直接拿模型返回的坐标去点击偏了几十个像素点到旁边的按钮上排查了半天才发现是归一化坐标没做映射。提示词写不好Agent跑着跑着就开始自己发挥该测登录的跑去检查设置了。弹窗处理没分层Agent遇到确认删除弹窗直接点了确定测试数据全没了。混合架构的边界怎么划、异常怎么分层也是调了很多轮才定下来的。这些经验不是看文章就能真正理解的得拿真实项目跑一遍翻一遍才能变成自己的东西。我自己把这些原理和实战经验整理成了一套系统课程——AI纯视觉自动化测试框架高级12个章节从Agent Loop的感知决策执行循环到坐标归一化映射从提示词三层体系到多模态断言的JSON兼容解析从OCR弹窗处理到Excel模板驱动的脚本自动生成每个原理都配了可跑的项目代码不是PPT讲概念是跟着做就能跑起来那种。课程覆盖的几个重点前置操作AI验证和步骤执行分步验证两大设计思想的完整实现、归一化坐标系统与多平台适配的代码实操、结构化Excel用例模板的设计方法和自动生成流程、智能弹窗处理的规则匹配连续监控方案、混合架构的落地细节和异常分层策略。适合在做移动端自动化测试、想低成本引入AI能力但不知道从哪下手的同行。欢迎私信交流