大模型驱动的UI自动化测试：KuiTest智能遍历框架设计实战

做UI自动化测试的这些年脚本写得越顺心里就越觉得别扭。页面改个文案、换块布局你的xpath、id定位就全面崩盘真正复杂的业务链路又往往被“功能正常但流程未覆盖”放走。传统交互遍历工具按固定规则去点多数情况只是在给按钮“挠痒痒”对业务语义、异常路径、用户真实意图一头雾水。直到我把大模型放进遍历器里当“决策大脑”整个局面才彻底扭转——这也是KuiTest最初动手的原因让测试遍历从“无脑乱点”进化成“带着业务通识去探索”。这篇文章我会把KuiTest的完整设计思路、提示词工程、动作编排和落地踩坑都拆开讲适合正在搞AI测试开发、UI自动化瓶颈期、或想给自家产品引入大模型测试能力的同学直接抄作业。1. 从“录制回放”到“有脑子的遍历”KuiTest 解决的问题1.1 传统 UI 遍历测试的三大软肋第一根软肋是脚本脆弱。写死 xpath 的用例遇上前端框架升级或者样式微调前一天绿油油后一天红成一片。第二根软肋是路径固化。录制回放记录的永远是那一条既定的手指路径永远发现不了用户实际上更常走的“歪路”。第三根软肋是断言浅薄。大多数自动化用例只会看“元素是否存在”“toast是否弹出”根本感知不到页面状态是否合理、业务闭环是否真的顺畅。这三根软肋叠加导致行业里真实的 UI 自动化覆盖率远没有PPT上好看。很多团队的核心链路都靠手工回归自动化只跑冒烟。KuiTest 的思路不是去修这三个缺点而是用大模型通识直接把“遍历”这件事的语义拔高一层遍历不是为了证明“每个按钮都能点”而是为了回答“一个懂业务的人在这个界面上能完成哪些合理操作哪些操作会造成异常”1.2 KuiTest 与传统遍历的本质差别对比维度传统遍历Monkey/RandomKuiTest 遍历决策来源随机数、预置规则大模型通识页面语义上下文覆盖采样控件可达性业务路径异常路径用户高频习惯断言方式程序崩溃/控件状态页面语义合理性业务闭环状态路径发现无记忆乱走有状态记忆的探索游走脚本维护高定位符暴露低落差在意图层维护KuiTest 的本质变化在于把“测试意图”与“控件定位”解耦。测试人员不需要关心这个按钮叫submit_btn还是#app div.btn-submit你只需要描述“我想尝试提交一份不完整的表单”大模型结合页面元素结构和上下文自己决定去点哪个控件、输入什么内容、校验什么结果。这其实是很多“大模型UI 操作模型”产品的理想形态。KuiTest 不追求替代人工测试设计而是把设计好的业务通识通过提示词注入给模型再让模型在一个受控的沙箱环境里放开手脚去跑。这套做法的收益非常直接每次遍历都会产生新的路径数据这些数据会反过来补充你的测试资产库而不是像传统脚本那样跑完就扔。2. 整体框架大模型在测试链路中的落点2.1 核心链路拆解感知-规划-执行-校验KuiTest 的运行时链路可以拆成四个环节每一步都不神秘但每一步都决定最终效果。感知环节负责把当前 UI 状态变成大模型能读懂的结构化文本。这里不是扔一张截图让模型猜而是通过底层框架Web 端走 CDP安卓端走UiAutomatoriOS 走XCUITest把页面控件树抽出来裁掉噪音节点保留关键信息控件类型、可见文本、位置、可交互状态、部分常用属性。这个环节最讲究信息密度——所有控件都塞进上下文模型大概率晕掉信息太少模型又变成盲人摸象。规划环节是 KuiTest 的核心。把上一步产出的页面结构化描述连同用户配置的“测试通识”一起塞给大模型请它输出一个动作意图比如“点击搜索框”“在用户名输入框输入超长文本”“切换到第三Tab”。模型不输出具体的坐标也不输出 xpath它输出意图附带它自己的理由和风险预测——这一步非常关键理由和风险预测就是你能用来审计模型决策的日志。执行环节根据大模型的意图去控件树中匹配实际的控件节点再调用对应的底层 API 做点击、输入、滑动、长按这些操作。执行完之后重新完成页面快照回到感知环节形成闭环。如果控件匹配失败或操作无响应执行层会返回一个错误大模型读到错误后自行调整策略这种“可纠错”的能力是脚本无法具备的。校验环节不是简单断言页面是否崩掉而是让大模型扮演一个“测试评审员”它拿到执行前后的页面快照差回答几个固定问题——页面状态是否符合业务预期是否有弹窗遮挡是否存在重复提交是否有未捕获的异常提示然后生成结构化报告标记这条路径是否值得沉淀为回归用例。2.2 为什么“通识提示词”能当测试评审员用大模型做测试最大的怀疑点是“它又不了解我的业务凭什么判断对错”。KuiTest 的做法是不需要判断业务对错只需要判断业务通识的一致性。比如一个登录页面业务通识是“密码错误要给出明确提示且不应停留在加载态”。这句话并不属于某个行业的金科玉律而是所有软件产品共同的用户体验常识。大模型预训练阶段见过海量这类交互范式它完全有能力在你填了错误密码后把“点击登录→出现错误提示→按钮恢复可点”判定为合理路径把你填了密码但页面一直转圈判定为异常路径。这就是“通识”的威力。所以在设计提示词时我不会把内部业务的复杂状态机塞给模型而是给它一套经过提炼的、通用且稳定的通识约定。比如能点击的控件必须给出明确反馈表单提交前应有完整校验危险操作必须有二次确认页面跳转不应该出现白屏任何操作都不应让页面陷入无响应状态。这些通识看着简单但传统遍历器根本不会判断这些随机点击只能靠运气碰上问题。2.3 模型选型的关键考量模型选型决定了KuiTest的上限和成本。我实测下来三个指标最重要。第一是意图理解能力模型得能从“页面结构中文指令”中准确产出可执行动作。这个不能只看榜单分数得拿自己产品的页面快照去跑才见真章。第二是长上下文处理能力因为页面控件树动辄几百行 JSON再加上历史行动记录上下文窗口不足就会出现“失忆”模型开始重复点击。第三是结构化输出稳定性KuiTest 要求模型每次输出一段固定结构的 JSON有些模型强在对话但命令交给JSON 时格式总崩这在自动化链路里非常致命。多模态大模型也可以接入——当你需要感知截图、按钮图标、视觉回归时再接一层视觉输入。但如果只是交互遍历纯文本控件树完全够用还省token。3. 从零到一落地 KuiTest提示词与交互设计实战3.1 自研“遍历人格”提示词模板提示词不是越复杂越好而是要清晰、可控、可审计。我最终沉淀出来的遍历提示词模板长这样核心是角色定义 通识列表 输出约束三段式{ role: 你是KuiTest智能遍历器一个严谨的QA工程师。你会收到当前页面的控件树和历史操作记录你的任务是决定下一步操作以探索潜在缺陷。, common_knowledge: [ 1. 优先完成核心业务链路再探索异常路径。, 2. 对输入框执行边界值输入、特殊字符输入。, 3. 破坏性操作删除、提交、支付前必须观察是否有确认机制。, 4. 如果页面出现重复弹窗、无限加载、白屏视为严重缺陷并停止探索。, 5. 避免连续点击同一个控件除非页面状态已发生变化。, 6. 当无法确认下一步操作时优先回退到上一级页面路径。 ], output_format: { intent_desc: 一句话描述你的动作意图, target_element: { control_type: 输入框, visible_text: 用户名, index_hint: 1 }, action_type: input, action_value: 测试文本#$%, reason: 用边界值探测用户名输入框的校验逻辑, risk: 低 } }如果希望上下文感知更强一点可以附加一个“历史轨迹”字段只保留最近五步操作和各自的执行结果。多了模型会迷失在长上下文里少了它没法感知自己已经做了哪些事。3.2 UI 状态编码与元素定位的接口约定要模型输出意图你得先把页面控件树变成模型看得懂的文本。这一步我建议做成紧凑JSON并进行三层裁剪。第一层裁剪掉无交互能力的纯展示节点比如纯文本标签除非它紧邻一个输入框需要作为 label 提示。第二层按“可见文本控件类型”优先隐藏节点直接丢掉不能让模型去点一个看不见的按钮。第三层把坐标信息简化成相对位置描述比如“顶部导航”、“页面中央偏下”模型不需要精确坐标它只需要定位到某个语义控件。等模型输出意图 Target 后真正的执行层去控件树里做模糊匹配。匹配优先级是精确匹配 visible_text → 包含匹配 → 借助 label 描述匹配 → 同级控件 index_hint 兜底。这套策略大幅降低了对模型输出精确度的要求模型说“点击搜索按钮”执行层自己去找叫“搜索”的那个东西模型不需要知道 CSS path 和 resource-id。3.3 动作执行引擎的设计安全与防抖执行引擎是整个KuiTest最工程化的部分也是最容易出事故的地方必须考虑三个机制防抖机制、边界保护、操作间隔。防抖机制解决“模型疯掉”的问题。比如模型同一个意图连续输出了三次但页面并没有变化这要么是模型陷入循环要么是操作无效。我设了一个计数器同一意图命中同一控件超过三次且页面无变化引擎强制跳出当前循环回退到上一级并记录“疑似探索死路”。边界保护解决“操作失控”的问题。像退出登录、注销账号、清空缓存这类低风险操作可以做但涉及到真实下单、删除数据、发送消息的操作默认必须在配置里加dangerous_action_confirm: true才允许执行。这是用大模型做自动化测试的一个底线绝不能让探索逻辑影响到真实生产数据。操作间隔是另一个容易忽略的细节。大模型决策本身有延迟一轮“感知-规划-执行-校验”大概2到5秒很多页面还会出现异步请求和动画过渡。如果执行间隔太短页面还没稳定就点下一个操作会产生大量假阳性。我的经验是每次动作执行后强制等待500-800ms当检测到页面有loading或动画时自动延长到等待完全结束。3.4 用 pytest 把探索式遍历变成标准用例KuiTest 再强也得接进团队现有的测试体系不然运维成本会非常高。我在工程上的做法是用 pytest 写一个 fixture把遍历器包装成参数化用例让日常 CI 可以直接跑。# test_kuiswarm_explore.py import pytest pytest.fixture def app_session(): from kuitest import KuiSession session KuiSession( app_urlhttps://staging.example.com, driver_backendplaywright, model_config{model: qwen-plus, temperature: 0.2} ) yield session session.cleanup() pytest.mark.explore pytest.mark.parametrize(scenario, [normal, boundary, chaos]) def test_dynamic_exploration(app_session, scenario): report app_session.run_explore( start_urlhttps://staging.example.com/login, max_steps30, prompt_profile标准电商通识, scenario_guidescenario ) assert report.no_critical_defects, f发现严重异常路径: {report.critical_events} app_session.export_assets() # 将本次探索沉淀的路径导出为回归用例这样设计的好处是探索遍历在 CI 里是一个带超时、可失败、有证据产出的普通 pytest 用例但又不像传统用例一样锁定具体操作序列。你维护的是“遍历场景配置”而不是几百行操作脚本。4. 落地实录KuiTest 的坑与排查技巧4.1 常见问题速查表现象根因解决方案模型反复点击同一区域上下文窗口截断模型丢失历史限制历史轨迹为最近5步定期压缩页面控件树JSON 输出格式频繁崩坏模型不支持严格指令跟随改用带 format token 的模型加入 JSON Schema 校验轮控件描述不够准确点击误伤裁剪逻辑误删了关键 label对可输入控件引入“邻近文本合并”策略探索跑得飞快但覆盖极低模型只挑“好操作”点在提示词里压一条通识必须涵盖异常输入、反向链路误判业务合理性只给了页面树没给业务状态上下文在上下文里注入关键的状态标识如“用户已登录”模型生成长篇大论导致超时输出裁剪不足限定action_type枚举值禁止自由文本风暴4.2 避坑实录上下文管理是最难的一关我早期做KuiTest踩过最大的坑是模型在长流程里“阶段性失忆”。跑了20步之后它开始频繁点击已经操作过的位置或者反复回到初始页面。查了半天才发现上下文窗口被页面控件树撑爆之前的行动记录被自动丢弃了。后来我把上下文策略改成“根因记忆最近快照”。根因记忆是一段压缩后的探索小结让模型知道“我已经试过正常登录流程发现密码错误时提示精准现在在探索忘记密码流程”。最近快照则永远保留最新的页面结构和最近五次操作。这两块信息始终在上下文窗口里其他细节能省就省。改动之后探索路径的“连贯性”提升非常明显。4.3 断言注入的边界与审计日志用大模型做断言天然有“误判风险”。我的经验是让模型当探索者让规则当裁判模型只是提名者。KuiTest 中模型负责提交“可疑行为”但真正判为缺陷前会经过三层校验第一层是执行引擎的硬性检测比如崩溃、白屏、ANR、死循环第二层是预先写入的断言规则比如“步骤提交成功应该出现成功页面而不是回到登录页”第三层才是大模型的语义评估且语义评估只会在前两层都没有结论时启动。这套设计显著降低了误报率。同时我发现KuiTest 跑完必须留一份完整的“决策日志”——包含模型的输入快照、动作输出、执行结果和评分理由。一方面是方便复现问题另一方面是这些日志本身非常适合做数据蒸馏用于后续微调一个专属测试决策模型让探索策略越用越灵。4.4 从遍历到回归资产避免探索结果“白跑”KuiTest 最有价值的附加产出是可以把探索跑出来的有效路径一键转成回归用例。这一步如果做不好遍历完就散场长期价值大打折扣。我实现了一个“路径转换器”遍历过程中把每次“模型决策执行动作页面状态差”追平为标准步骤序列然后自动生成一个 pytest 用例函数里面的操作调用统一的Page Object方法。这样跑一轮KuiTest不但发现了问题还自动补了一批回归用例。这批用例不是瞎点点出来的而是大模型带着业务通识探索后复现的“高价值路径”。团队实际跑下来探索一轮30步大概能沉淀出8到12条有价值的回归路径这个比例比人工设计用例要高得多。5. 模型能力之外KuiTest 对测试团队意味着什么5.1 测试开发角色的重心转移从写定位符到写通识KuiTest 上线后团队里最明显的变化是测试开发不再把大量时间花在编写和修复定位符上。以前加一个新功能页面光 UI 脚本就要开发一周现在只需要在通识库里补几条页面特有的状态判断再跑一轮探索遍历基础路径就覆盖得差不多。这背后有一个理念变化测试资产从“脚本”变成“知识”。脚本是固化的知识是易迁移的。你换一套前端框架脚本全废但通识库还在你新增一个业务模块不用从零开始写用例探索遍历器直接基于修订后的通识去摸新界面。对测试团队来讲这是在降低长期维护成本也在提升测试设计的下限。5.2 大模型测试的置信边界哪些断言必须靠人工用大模型做 UI 测试要清楚它的能力边界。KuiTest 可以非常可靠地发现“交互诡异”、“路径断裂”、“页面无响应”这类通识层面的问题。但它判断不了业务规则级的问题比如“这个价格字段该不该有折扣”“这笔订单的积分计算对不对”这类断言必须由测试工程师通过规则注入或后续人工复核完成。所以 KuiTest 设计上不会吞掉传统自动化更像是给传统自动化加了一层“智能探索前置”。每次迭代探索先跑把异常路径和新页面死角找出来再人工确认并把稳定前置路径转成传统用例。这个组合拳恰好把机器靠谱的重复劳动、模型通识的泛化能力、人工的专业判断放在各自最合适的位置上。5.3 把 KuiTest 接进多端与多模态场景的扩展我目前的主力场景是 Web 和安卓 App纯文本控件树已经满足 90% 的需求。但如果你的产品是 iOS 或者有大量图标按钮、Canvas、游戏 UI纯文本控件树会漏掉很多视觉信息。这个场景下KuiTest 可以接入多模态大模型每次动作后额外截一张屏幕图让模型同时读“控件树截图”再决策。缺点是 token 消耗会明显上升延迟也会增加所以我只会对视觉敏感页面开启多模态模式普通页面还是走纯文本省钱且高效。写在最后的几个小提醒如果你们团队准备自己整一个类似的框架去接入 UI 测试我建议先从一条最核心链路跑通比如“登录到某个完整业务闭环”不要一上来就想覆盖整个 App。通识提示词和页面裁剪这些细节必须结合自己产品反复调别人的模板只能起点方向作用。大模型偶尔会有些“反直觉”的探索思路不要急着禁掉先看是不是暴露了测试盲区。另外探索遍历无论跑得多好永远不要让它直接操作生产环境或用生产账号访问真实数据这应该成为团队的默认红线。我自己跑KuiTest这段时间最大的体感是“UI自动化测试终于开始思考了”而不是像个只会念脚本的复读机。无论你是想解决脚本维护危机还是想探索 AI 测试开发的落地路径都可以从这个方向切入试试。