好强，是个 AI 测试大佬

这个框架是你自己写的，有在公司推广吗，公司其他人怎么反馈的

为什么要做这个？解决了业务中什么问题？相对于传统的 xpath 定位，采用 AI 准确率提升了多少？落地效果怎样？

哎，说了一堆没说做的效果怎么样，落地后数据怎么样，效果比传统的快了多少，稳定了多少，用例量级在多少。总之都在说工具没说业务和效果，让人看了都是在吹很虚

1.稳定性问题：如何解决用大模型做 UI 测试的误报问题，成功率 80%，那每次都有 20% 左右的误报需要多少人力成本去排查
2.知识库问题：如何让模型知道你的业务逻辑或者说业务术语，比如什么是发起回帖

这让我想起了之前试过的一个东西 midscene

想知道根据元素定位成功率调整缓存策略实现自适应学习机制是怎么实现，这个要缓存啥

不是它 但是效果是一样 那个是字节的开源框架 node 写的 如果要用的话还得去学 node 感觉生态不是很好

是这样的 核心思路就是把最近成功的定位结果记到 Redis，下次优先用；成功就升，失败就降，同一候选连续成功 2 次就缓存一天 失败的就缓存一小时 如果定位不到就会降级到从 mysql 里面找 找不到就会用 ai+ocr 进行兜底 ai 识别成功元素会把元素坐标位置选择器等信息存数据库 将元素的优先级提高 下次优先使用 如果都定位失败 那就需要人工来协助了

你这个是面向什么业务设计的？80% 的识别成功率影响不大吗？

如果是我，我会问这几个问题：

1. 80% 识别率是怎么统计的？样本覆盖了哪些场景？不同复杂度页面的识别率差异有多大？
2. 80% 成功率之外的 20% 失败场景，你们怎么处理？是回退手工测试，还是有其他自动化兜底方案？
3. 新框架识别率只有 80%，实际落地时，这个成功率真的能比传统方案更稳吗？有没有和旧方案做过对比测试（比如相同页面的执行稳定性、维护成本）？
4. 80% 成功率是针对所有页面，还是只覆盖了部分简单场景？如果遇到高频的复杂页面（比如表单嵌套、动态加载），识别率会不会暴跌？这种情况下怎么保障测试质量？
5. token 消耗怎么计算？每次元素识别、用例执行要花多少钱？有没有统计过
6. 20% 的不稳定性会不会让业务测试提心吊胆？，增加了监控和重跑的负担，违背了自动化提升效率的初衷？

另外你的描述，给我一种你没有 在实际业务测试中用过这个测试框架的感觉，否则 80% 的成功率你都写出来？
你想想识别成功率是 80%，不考虑其他因素，算你一条用例的成功率是 80%，若一次回归测试有 50 个用例，全部成功的概率仅为 0.8⁵⁰ ≈ 0.0001%（几乎为 0），这意味着几乎每次执行都会出现失败，这就是我上面想问的，如果每次执行都会出现识别率问题，那你们的精力是不是都分散到区分是实际 bug 还是识别问题？

这个主要是为了提高在快速迭代中的元素定位效率 尤其是前端经常迭代 页面元素经常失效 都需要重新去写 xpath css 等定位，通过 redis 缓存→数据库→AI→OCR 四层降级来命中元素，基本上缓存命中毫秒级完成 ，而且自适应学习（成功晋级、失败降级），把高质量候选沉淀到缓存与 DB，减少改版后的批量修复。目前刚搞完 只跑了几条 case 目前效果还可以 正在编写大量 case 来验证，目前对预热后的页面元素定位时间 1s 不到 输入框就可以成功输入信息

好的哥 我补一下 这个刚搞完 目前 case 不是很多 对于预热后的页面 像输入框按钮什么的 元素定位时间 1s 以内就会输入完成 像一些 img 图标什么的 就可能需要 ai 来处理了，我试验一下补一些数据

这块没有做 rag 产品文档不是很规范 写用例的话是可以用 yaml 那种声明式的 直接中文描述 哪里需要点击 需要打开那个页面 我用的大模型其实是一种兜底策略 用的是多模态的通义千问的 让大模型 +ocr 去识别页面元素 通过对置信度的判断 来确定页面元素坐标是否可用，是通过四层定位 redis mysql ai ocr 这样来提高元素定位效率 跨域 iframe 且未暴露测试钩子 这种就只能靠视觉模型处理了

没 我才做测试一年经验 大家一起学习

是我写的 目前在真实业务在跑的 case 有 20 条 还在陆续编写不断完善