TestStar | AIUI 数据库客户端测试Case执行实录

u010750578

294人浏览 · 2026-09-16 23:24:23

u010750578 · 2026-09-16 23:24:23 发布

摘要：33 步、7 个任务段的 OceanBase「登录 → SQL 工作台 → 创建存储过程 → 运行」用例，连跑 4 次全过。日志里能拆出两条线：执行缓存（自动复利、零成本）和知识库（手动建、提速 5-15%）。本文用真实数据 + 录屏讲清楚——AI 自己不行，要配套这两条线。

本篇是 TestStar AI 测试实战 #11。
怎么接，看实战 #8 · 功能用例接入 TestStar；
平台里有什么，看实战 #9 · 功能巡礼；
这篇回答：AI UI 测试靠不靠谱，看 4 次跑出来的真实数据。

写在前面

UI 自动化维护成本高、月失效率常超 20%——写过的人都懂。一个最磨人的问题是：改一次版本，脚本成片失效。

直观的解法是让 AI 看屏幕自己点。问题是：AI 自己行不行？

答案是：靠 AI 自己，不行。

AI 找元素要调模型，每一步都慢、都贵、都可能误判。靠 AI 自己点完一条 33 步的用例，5-8 分钟跑掉，2-3 块 token 钱花掉，还不一定稳。

那为什么这次 4 次跑全过？因为有两条配套的线在起作用：一条是自动复利的执行缓存（AI 跑完自己记路），另一条是手动建的知识库（团队提前告诉 AI 元素叫什么）。

这两条线单独哪条都不够，合起来才有 4 次跑全过的结果。

下面用真实数据把这件事讲清楚。

一、问题的两面

做 UI 自动化的人都被这两个问题折磨过：

第一个：维护债无底洞。

用例逻辑本身没错，坏的是写死的元素定位。按钮挪几像素、id 改了、XPath 断了——用例成片失效。修一条的流程是查原因、改定位、回归验证。用例一多，维护就是个无底洞。

第二个：夜里定时跑完，红一片不知道怪谁。

有服务连不上的，有登录态过期的，有测试数据没就绪的，也可能藏着真缺陷。红一片怎么分类？谁去看？看的人信不信报告？自动化 ≠ 敢用。

AI UI 测试工具冲的就是这两个问题。解法是：让 AI 看页面截图现场判断怎么点，用例里不写任何元素定位——页面怎么改版，用例一个字不用改。

二、AI UI 测试是什么

一句话：用例用中文写，AI 打开真实浏览器把它跑完，每一步截图留证，跑完告诉你哪些是真缺陷、哪些只是环境问题。

听起来像录屏回放——不是。回放是死脚本改不了，AI UI 测试是模型理解意图+现场判断+执行。

具体到这次跑用的平台 TestStar，机制是：

用例纯中文（"点击蓝色登录按钮"，不写 ‎#login-btn）
执行时多模态模型看截图，判断点哪、输什么- 每步截图，跑完全程有迹可循
失败时分类：环境问题 vs 真缺陷，不混

这是方案。现在什么状态：累计 269 次提交、约 7.5 万行代码，不是只能演示的 demo——自己每天在用，线上挂着定时回归任务。

三、真实跑测：4 次跑通 33 步用例

3.1 为什么挑这条用例

故意挑难的。目标页面：https://console-cn.oceanbase.com/

7 个任务段、33 步：

登录控制台 → 进 SQL 工作台并连接 chatbi 库 → 在对象树展开「存储过程」分类 → 打开新建存储过程对话框 → 填参数 → 点创建 → 验证建好了还能运行

难点：全是动态弹窗、富文本编辑器、参数表格这类不好惹的控件，不是登录页那种演示场景。

3.2 用例原文（节选）

点击「密码登录」标签页，切换到密码登录方式
在「手机号/邮箱」输入框输入「${OB_USERNAME}」
在「密码」输入框输入「${OB_PASSWORD}」
点击蓝色「登录」按钮
进入 SQL 工作台。可以从实例卡片 hover「连接」按钮后，在菜单中点击「SQL 控制台」；
也可以直接点击左侧导航栏的「SQL 控制台」入口。两条路径任选一条。
点击参数表第一行「名称」列的空白单元格。确保光标进入该单元格后，输入「TestStarA」。
如果第一次点击没有进入编辑状态，再次点击该单元格后输入。
点击参数表第一行「长度」单元格，清空默认值 45，输入 47

OB存储过程-115秒精华版

实际测试过程录屏

这段用例里有 4 个细节值得单独说：

‎一个选择器都没有——没有元素 id、XPath、CSS 选择器，全是「点击蓝色登录按钮」这种描述，那个按钮在屏幕的哪个位置，AI 自己看。
‎每一步都在防弹窗——7 处写着「如果页面存在弹窗、通知、升级提示、新手引导、体验之旅或其他遮挡元素的浮层，先关闭；如果不存在则跳过」。OceanBase 控制台的引导浮层不是页面初始化出现的，是在你点按钮之后动态冒出来的，防御必须铺在每一步前面。
‎允许两条路径——「进 SQL 工作台」那步写明了两种走法，AI 走哪条都算过。
‎用例开头带页面上下文——直接告诉 AI 这个系统长什么样：登录页左边是什么、右边表单有哪些输入框、进去之后是什么页面、SQL 工作台对象树能展开哪些分类。AI 不用从零开始猜。

3.3 4 次跑的真实数据

次数	耗时	缓存命中	Token 节省
第 1 次	333 秒	50 次	5.8 万
第 2 次	305 秒	55 次	6.4 万
第 3 次	476 秒	42 次	5.05 万
第 4 次	357 秒	57 次	6.6 万

4 次全部跑通，7 个任务段都过了。

三个口径先说清楚，免得被当成实测：

‎耗时剔除了「通用弹窗预处理」（平台每次开跑前先扫一遍页面关弹窗，约 14 秒），不算在用例本身里。
‎Token 节省是估算值——算法是「跳过的模型调用次数 × 单次估算消耗」，不是计费账单上的实测数字。真实花销还得看模型账单。
‎缓存命中是执行日志里直接读出来的，不是事后统计。

数据里 4 件事值得注意：

‎4 次全过——一条 33 步、7 个任务段的用例，连跑 4 次没有一次挂在中间。
‎缓存命中了 42-57 次——这条用例没做任何前置准备，没写选择器，也没提前登记过页面元素。成本能降下来，是因为有另一条自动的线在起作用（下文讲）。
‎耗时在 305-476 秒之间浮动——不是每次都一样快。AI 每步都要先看页面再决定动作，这是方案本身的代价，不绕开。
‎第 3 次反而最慢（476 秒）——网络抖动或模型偶发误判，任何一次都可能赶上，别把单次跑得慢当成系统问题

> 【插图1 · 13-four-runs-table.png】

图注：4 次跑的真实数字 · 一表带走

四、AI 自己不行，靠两条线

4.1 第一条：执行缓存——自动复利的免费加速

执行缓存是平台在每条用例执行时自动沉淀的页面规划结果 + 元素定位结果。不是团队手动维护的，是模型在找元素的时候第一次找到记下来，下次找同元素直接复用。

通俗点说：AI 第一次看到登录页，要看 5 张图才能认出「密码登录 Tab」在哪。认完记一下，下次看到直接说「就是它」。整个过程不需要团队做任何配置。

这次跑的证据——看 4 次重复跑：

指标	第 1 次	第 2 次	第 3 次	第 4 次
元素定位缓存命中	（首次沉淀）	25-39 次	25-39 次	25-39 次
页面规划缓存命中	（首次沉淀）	16-18 次	16-18 次	16-18 次

4 次跑有 42-57 次调用是缓存直接给的——拆开看是两部分：元素定位命中 25-39 次，页面规划命中 16-18 次。省掉的就是这些模型调用，换算下来是那 5 万到 6.6 万 Token。

它解决的是什么：不是「快」，是「不要更慢」。AI 步骤如果不缓存，第一次跑要 333 秒，第二次如果还按完全冷启动跑，可能 350 秒——因为没记录任何东西。执行缓存让重复跑几乎不增加成本。

适用场景：

✅ 同一条用例每天 / 每周重复跑（定时任务）
✅ 同一团队多条用例共用同一页面
⚠️ 单次跑——缓存基本没用
❌ 跨团队 / 跨项目共享——per-用例，不跨团队

饱和点：33 步用例里有大量动态 UI 步骤（弹窗检测、新手引导、对象树展开、刷新），这些步骤每次结果都不一样，缓存命中到 60-70% 就饱和。3 次跑后增速变缓就是这个原因。

4.2 第二条：知识库——手动建、提速 5-15%

页面知识库是团队主动登记的元素语义信息——「密码登录 Tab」叫什么、在哪、长什么样。AI 执行时优先读它，不用每次现场找。

和执行缓存的区别：

	执行缓存	知识库
是不是自动的	‎自动	‎手动
0 → 增长要多久	第一次跑就有	团队一周能起步
维护成本	零	‎要人建、要人更新
提速贡献	让重复跑不更慢	‎5-15%（不是几倍）