SAP物料分类账差异分摊原理与月结避坑指南
2026/10/15 9:48:24
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，冷启动更贵。同用例、同知识库连续两轮：
| 轮次 | Cache | Token | 耗时 | 结果 |
|---|---|---|---|---|
| 冷跑第 1 轮（Run25） | miss | 约 29.7 万 | 约 208 秒 | 通过 |
| 热跑第 2 轮（Run26） | hit | 约 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 维护还是测开维护？改版后多久更新一轮？