TestStar AI 测试实战系列· 第 5 篇 · 上一篇Token 怎么从 48 万压到 5 万——AI UI 测试上生产的成本账全文用同一条19 步 SQL 控制台用例登录 → 选实例 → 输入 → 执行 → 断言。纯视觉跑测冷启动约48 万 token热缓存约5.4 万——贵但还能跑真正搞心态的是flaky同一步今天点对、明天误点相邻控件。本篇讲跑得稳——页面知识库。对其中15 个交互/断言步骤做静态覆盖命中12 个约 80%注入后冷跑约29.7 万 token热跑约5.7 万「密码框误点」类 flaky 未再出现。一、有一类失败很搞心态不是 bug是 AI 每次重新猜AI UI 测试上生产后常见这种失败同一条登录流今天点对「登录」明天点到密码框旁空白——产品没改、用例没改、环境没换视觉理解在抖。我们在TestStar里用真实用例踩过登录 → SQL 控制台 → 输入 → 执行 → 断言19 步后文 token 数据均出自这条线。其中一步反复「节点定位偏了」——不是断言错是 AI把相邻控件看混。传统 Playwright 绑#submit-btn改 DOM 才红。AI 测试靠看屏幕相邻元素像就容易抖。自愈能救一部分系列第 3 篇但更根本的问题是能不能少让 AI 每一步都从零猜页面长什么样页面知识库干的就是这个——不替代视觉而是给短的位置锚点先看锚点找不到再纯视觉。二、知识库记什么——「语义 位置」不是 XPath 博物馆很多人一听「知识库」就想到 Page Object几十个 selector、一改版全崩。我们每条元素只记两样记什么例子不记什么语义密码登录 tab、登录按钮、实例连接完整 XPath/CSS位置提示登录页顶部 tab 区、表单底部、列表每行右侧像素坐标、绝对 DOM 路径AI 测试的步骤是自然语言「点登录」「选实例」。知识库在跑之前补一句你这句话指的是页面哪一块让模型先看锚点再看像素。SQL 控制台这条线我们从5 个元素试起两周扩到 11 个——缺哪补哪不先画大架构登录入口密码登录 tab · 顶部 tab 区登录按钮表单底部实例连接列表每行右侧SQL 输入框、执行按钮、结果区域……一条 knowledge 长什么样可直接照着写element:登录按钮semantic:提交登录表单的主按钮location_hint:密码输入框下方表单底部居中match_keywords:[登录,提交,确认登录]page:登录页notes:勿与顶部「验证码登录」tab 混淆11 个具体元素比 1 套「通用 schema」先有用——第六节专门说为什么。三、注入在跑之前——静态匹配命中才加长 prompt知识库不是跑时让 AI 自己去翻 wiki而是启动前做一次静态匹配列出用例里所有交互步、元素级断言步用步骤关键词登录、连接、执行 SQL…匹配知识库命中→ 附加位置提示再交给视觉引擎未命中→ 原样跑不硬贴 hint乱贴比不贴更坑链路用大白话讲步骤点击登录 → 匹配「登录按钮」→ 提示「表单底部」 → 执行优先在表单底部找找不到再纯视觉和 Token 缓存是两套机制机制解决什么Cache复用上次 AI 想明白的那一步 →省钱知识库减少这一步想错地方 →省 flaky叠加后才出现「热跑 5 万级 token 稳定性上来」。四、80% 命中算不算合格——我们怎么验别急着宣称「全覆盖」。我们做过静态覆盖检查不跑浏览器只数步骤能否匹配用例15 个交互/元素断言步命中12 个 → 80%未命中 3 个都有理由未命中步骤为什么不命中关闭弹窗通用逻辑靠 AI 泛化数据类断言结果行数不涉及控件定位临时/debug 元素低频不值得固化80% 是健康线——粒度够又没为 KPI 硬塞。只有 40%库太薄或用例关键词太散声称 100%多半把不该固化的也塞进去了。100% 覆盖的知识库通常是把不该固化的步骤也固化了。验收三步挑1 条真实核心业务用例别 demo 页数交互 元素断言步算命中率每个 MISS 写一句「为什么不命中」——写不出理由的才补五、冷跑 vs 热跑token 与稳定性知识库会加长 prompt冷启动更贵。同用例、同知识库连续两轮轮次CacheToken耗时结果冷跑第 1 轮Run25miss约 29.7 万约 208 秒通过热跑第 2 轮Run26hit约 5.7 万约 99 秒通过冷跑 / 热跑 token 对比对比未注入知识的纯视觉冷/热约 48 万 / 约 5.4 万冷跑注入后 prompt 更长第一轮账单不能否定方案热跑回到5 万级与「纯视觉热缓存约 5.4 万」同一量级稳定性两轮连续通过「密码框/节点偏了」注入位置提示后未再出现定位接受前几轮贵一点、建库花一点人工换 CI 少红、少误点、少人工盯。用第五轮以后的账单和 flaky 率评价别用 Run1 的 token 砍项目。六、为什么不做「通用页面 schema」有人提议抽通用 UI schema登录按钮、表格、分页器统一字段全产品复用。我们否了先沉淀一条用例的真实知识跑两周看哪些字段真有用再决定要不要抽象。路线典型结果先画通用 schema什么都能描述什么都没描述清先深耕单用例11 个具体元素2 周验 80% 覆盖抽象门槛三条缺一继续堆具体元素至少 2 条不同用例复用同一套字段且字段被读过、改过维护成本低于各用例各写一份产品改版时schema不会比具体知识更难改七、建库实操两周从 0 到 11 个元素第 1 周跟跑一条用例跑挂时区分真 bugvs点错地方点错处补一条「语义 位置」目标登录 进控制台 核心操作先覆盖 5 个高频元素第 2 周对照覆盖表补洞做第四节80% 静态检查该补的补执行按钮、结果区不该补的写理由弹窗、纯数据断言持续改版 知识半衰期按钮搬家、文案改了旧 hint 可能反噬错锚点比没锚点更坑目前靠改版后一轮回归 人工改库理想态是失败率突增时提示「某条 knowledge 可能失效」和自愈、记忆的分工能力解决什么页面知识库少猜、少误点失败记忆同类失败下次别重蹈自愈已失败后能否改步骤救回知识库在前自愈在后——能少失败比失败了再救便宜。八、还没做好的跨用例复用登录流各用例各一份公共子流程库在做自动失效检测旧 knowledge 还在注入靠人闻味道运行时采纳率静态 80% 有了「hint 被采纳还是回退视觉」未逐步统计多端Web 最深移动端「语义 位置」是否够用系列第 6 篇会写知识库不是配一次就结束是跟产品版本一起养的。几句能记住的记语义 位置不是 XPath 博物馆——给锚点不替 AI 看屏跑前静态注入命中才加长 prompt未命中别硬贴80% 静态覆盖是健康线MISS 要有理由冷跑贵、热跑稳第五轮后再评价通用 schema 晚点做——11 个具体元素往往比万能描述先见效下一篇多端 UI 测试同一业务流 Web / Android / iOS / 鸿蒙要不要各写一套——步骤三分法与 4 端 POC 维护账本。关注我系列持续更新。你们页面知识是 PO 维护还是测开维护改版后多久更新一轮