TestStar AI 测试实战系列· 第 4 篇 · 上一篇AI UI 测试火不代表你也该上——先答这 4 题番外篇帮你答「该不该上」本篇进入实战——「跑得起怎么办」。同一套TestStar平台、同一条 19 步真实用例冷启动约48 万 token热缓存约5.4 万——差的不只是钱是「实验室 demo」和「每天跑两千次 CI」之间能不能站住。这系列还会有几篇后续接着更。一、先算一笔账单次几块钱规模化就是每月几万AI UI 测试的宣传往往停在「用自然语言描述AI 自动点页面」——很少人帮你把规模化成本摊开。我们在TestStar里用一条真实业务用例做过完整测算登录 → 进 SQL 控制台 → 输入 SQL → 执行 → 断言19 个步骤。场景成功率单次耗时单次 tokenAI 调用次数冷启动cache miss通过约 367 秒~6 分钟约 48 万约 99 次热缓存cache hit通过约 114 秒~2 分钟约 5.4 万大幅减少连续跑稳后通过约 65 秒与热缓存同级—按 2026 年主流视觉模型的公开价粗算48 万 token 一次大约几块钱。听起来不贵。但生产不是跑一次500 条用例 × 每天 2 轮 每天 1000 次若每次都按冷启动算每天大几百元一个月成本算下来也不少了没有测试负责人会批这种预算。所以我们很早就定了一条硬规矩没有 cache 治理的 AI UI 测试不允许上生产 schedule。这不是优化项是准入条件——跟自愈、日志、失败分类同一级别。二、48 万 token 烧在哪——不是「用例太长」是「每步都要「看」一遍」很多人第一反应19 步用例是不是写太啰嗦了不是。AI UI 测试的 token 大头不在 YAML 行数而在执行引擎的工作方式截图 视觉理解每一步都要「看」当前屏幕多模态模型按像素/token 计费多轮规划一个aiAct背后往往是「理解 → 规划 → 操作 → 再确认」一步拆成多次调用上下文累积越往后历史截图、思考文字、页面状态越堆越多断言也要「看」aiAssert/aiQuery同样走视觉链路不是免费午餐所以 19 步跑出约 99 次 AI 调用、48 万 token在视觉驱动自动化里是正常量级不是实现 bug。这也解释了为什么传统 Playwright 脚本「几乎不花 inference 钱」——它读 DOM不读像素。AI 测试换的是维护成本不是算力成本。算力必须单独治理否则 demo 永远比生产好看。三、Cache 到底缓什么——不是缓「测试结果」是缓「AI 已经想明白的那一步」底层执行引擎我们用的是 Midscene 一类视觉驱动方案自带cache 机制。用大白话讲AI 在某一步「看过屏幕、想好了怎么点、点成功了」下次在足够相似的屏幕 足够相似的指令下可以直接复用上次的规划结果少打模型、少传截图token 和耗时一起下来TestStar 在 Harness 层要做的事是让 cache 在平台尺度上可控、可观测、可算账而不是每人都手工清缓存。三个必须搞清楚的决策1. Cache 粒度按用例隔离别串台多条用例共用一份 cacheA 用例的登录步骤可能污染 B 用例。每条用例或每个 cache id独立是底线。我们给长生命周期业务用例配稳定 cache id一次性探索跑可以用临时 id跑完即弃。2. 读写策略生产默认「只读复用」常见两种模式只读read-only命中就用不往 cache 里写新东西——适合 CI 定时回归防止一次跑飞把脏规划写进 cache读写read-write边跑边更新——适合用例调试期、页面改版后的前几轮我们踩过的坑调试期用 read-write忘了切回 read-only一次 prompt 微调 页面小改把错误规划写进 cache后面连续「稳定失败」——看起来像 flaky其实是脏 cache。3. 什么时候该整包作废——比「相似度阈值」更先问下列情况我们宁可整用例 cache 清空重跑也不抠相似度用例 YAML 改了步骤顺序或关键aiAct文案被测页面大改版导航结构、登录流程换了自愈自动改写过用例并固化新版本知识库注入内容变更见下文Cache 是加速器不是真相来源。真相永远是当前这次跑的结果。四、相似度阈值不是玄学是「省钱 vs 点错按钮」的交换「相似度阈值」决定当前屏幕和 cache 里那一帧有多像才允许复用。阈值太高几乎不命中token 下不来回到 48 万阈值太低界面其实变了还硬复用点错位置用例飘红且难排查我们没有对外宣称「一个万能阈值」。工程上的做法是先用默认策略跑一条基准用例看冷/热两次 token 差48 万 vs 5 万就是合格信号热缓存仍失败先查是不是页面真改了再考虑降阈值不是先降阈值碰运气CI 定时跑偏保守只读 略高阈值人工调试偏激进读写 允许更宽匹配记住阈值调太低省下的 token可能一次误点造成的排查人力更贵。五、48 万 → 5.4 万我们一条用例上的真实曲线同一条 19 步用例Tier 1 稳定性验证里连续跑了 8 次token 不是线性下降而是前几轮猛降、后面走平阶段大致 token大致耗时说明第 1 次冷~48 万~367 秒几乎步步都打模型第 2–3 次快速下降明显下降高频步骤开始命中第 4 次起热~5.4 万~114 秒稳定 band再往后~5.4 万~65 秒token 不降了耗时还能挤几个反直觉的点1. Token 降九成不等于「只花原来的十分之一钱」还有启动浏览器、拉服务、写库、出报告的平台成本。但对AI inference 账单九成节省是真实发生的。2. 生产第一次失败token 也是 5 万级我们有一次生产 headless 首跑子进程其实跑完了但平台 worker 被同步写库卡死DB 没写上API 判失败。token 跟热缓存同级问题在平台不在模型。所以看账单时要分「推理钱」和「平台能不能撑住」——第 2 篇、第 3 篇讲过的坑在 token 账上也会骗你。3. 极短用例5 步不适合指望 cache启动开销占大头cache 省下的 inference 抵不回固定成本。这类用例更适合传统脚本或合并进更长流程。六、哪些该缓存哪些宁可每次重算适合缓存慎用或别缓存稳定中后台登录 → 列表 → 表单 → 提交强风控验证码、滑块、行为检测步骤固定、页面布局变动慢Canvas / WebGL / 游戏画面CI 定时回归同一套用例强动态 SPA每次刷新 DOM 全变已调试定稿的aiAct文案用例还在改 prompt 的调试期先 read-write定稿再只读知识库锚点稳定后的热跑知识库刚改完、cache 还没重建还有一类故意不追求 cache 命中探索性测试、首次录新业务流程——这时本来就要多烧 token 换覆盖率别心疼。七、知识库注入冷启动更贵热跑更稳——第二篇 hidden cost第 5 篇会专讲知识库这里只写跟 token 相关的取舍。给aiAct注入页面元素的位置提示「登录按钮在表单底部」这类之后我们对比过冷/热两次冷缓存热缓存token约 30 万仍贵但稳定性换回来约 5.7 万与不注入的热跑同级耗时~200 秒级~100 秒级稳定性—明显提升曾出现的密码框误识别消失结论注入 加长 prompt→ 冷启动仍贵甚至某次实验比纯视觉还贵一旦热 cache 建立成本回到正常 band稳定性白赚所以知识库是长线投资接受前几轮贵一点换后面 CI 少红几次若你团队刚上知识库别用前两轮的 token 账单否定方案——看第五轮以后。八、Prompt 一改Cache 可能全废——这是 AI 测试独有的「回归成本」传统脚本改一个选择器影响局部。AI 测试改一句aiAct可能改变模型规划路径可能让旧 cache全部失效可能「今天能命中、明天模型升级就不命中」所以我们维护用例时的纪律Prompt 能不改就不改——用知识库补稳定性而不是每天重写 aiAct大改用例版本号 清 cache写进 SOP别靠人记模型版本变更单独做一轮回归别假设 cache 还能用这也是我说「AI 测试的回归测试本身是个难题」的原因之一——你不只回归产品还要回归 prompt × 模型 × cache 三者的组合。九、平台侧还要算什么——Token 看板为什么必要TestStar 在仪表盘里按用例 / 套件 / 时间拆 token不是为了好看是为了回答四个问题哪条用例是「吞金兽」冷启动 never 热起来哪次发布之后 token 突然飙高页面改版cache 污染套件层面能不能批算「这一版发布回归要烧多少钱」自愈救回一次多烧多少 token——救回值不值没有账单视角团队会在「全量每天跑」和「干脆不跑」之间摇摆。可观测的 token才是能讨论的 token。十、还没做好的实话跨用例复用登录步骤每条用例各烧一遍我们还没做「公共子流程 cache 共享」模型换版后的 cache 自动失效现在靠人工清理想是版本号绑定自愈改写用例后的 cache 自动迁移改了 YAML 有时要人手清 cache精确到「哪一步」最耗 token有总量步骤级归因还在做Token 治理是持续运维不是上线前配一次参数就结束。几句能记住的48 万 vs 5 万不是营销数字是同一用例冷/热两次的真实差——决定能不能上 scheduleCache 缓的是AI 规划结果不是测试结果脏 cache 比没 cache 更坑相似度阈值是省钱和误点的交换CI 偏保守调试偏激进知识库注入冷启动贵、热跑稳——用第五轮后的账单评价别用第一轮Prompt / 模型 / 页面任一变了先想 cache 要不要作废再调阈值