langchain，做需求生成 ui 和 api 用例，ai 用例分析，bug 转 ui 用例。 现在不都没测试，全是 ai 在测

需求文档用 ai 转 ui 用例，新版本通过率也就只有 90 左右，怎么做到 95%，你们新版本不改任何旧页面吗？

不稳定，不可靠，有更好的更可行的方法，我们公司已经落地了，ai 一天写上百条用例，版本迭代通过率 90 以上，已经没人执行手工测试了

还有搞传统测试的，现在不都 ai 生成自动化用例自动定位 bug 了吗，

现在先进一点的公司不都是全链路 ai 测试
招进去点点点也没东西给你点啊

你的思路错了，ai 时代不是靠人力去驱动，开发用 ai 一天生成几千行代码，甚至上万行，测试不再是人工执行，而是进入到了开发测试一体化阶段。这个是目前的大背景，新功能不由人工测试，而是先走自动化，再分析，人工是最后一环测试，用例批量失败是必然的，ai 会排查到 bug 和维修用例，但有很多场景是 ai 没法覆盖的。
比如： 某功能依赖于第三方服务，第三方服务部署复杂，ai 目前阶段没法搞定，但因为第三方服务在用例运行过程中故障，这部分是 ai 没法搞定的。

你的想法还停留在上个世纪，自动化越来越稳定，恰恰相反，自动化面临极大挑战，大家都在无人测试，你却把自动化当后置

并不是老问题，而是以前人工执行用例，现在变成 ai 执行用例，现阶段去掉人工阶段会有很多新问题， 不是简单 +ai 就能解决的，以前项目发布一个月两个月，现在一周两周就要发布一次，给你一万个 bvt 用例怎么一天就分析完？要是按以前的流程跑分析个一两周都行，ai 分析不了就问开发。现在一天两天就要弄完，你说这话说明你公司的应用场景太小了

现在已经过了 ai 生成 ui 测试用例和接口测试用例困难的阶段了，现在有大量用例怎么管理的问题，有几万用例失败怎么高效分析异常，ui 和接口用例数量每天上百条增加，怎么做智能精准测试，智能维护现在才是问题，人力分析用例一天也就几十条，ai 又不会跟开发扯皮，只能解决部分用例分析问题

还在搞古法测试工具

ui 自动化生成的是基于文本用例实现的。
现在目前的 ai ui 自动化有几种原理， 都可以在源码中看到实现原理
1.browser use 为代表的图像派，源码是通过，可访问性树，标记图像，然后让 ai 返回坐标，在用 playwright 点击

2.stagehand 为代表的优化版可访问性树，在树上加上 dom 的 ID，找到 DOM，然后解析为 XPath

3.用户输入文本然后 rag 直接提取相近的 HTML 树，再让 ai 生成 XPath

我部门用了 browser use 做改进，实现缓存，调用接口功能，改了 browserusr 上万行代码，作为 ui 自动化的底座

然后光有底座不能把用例自动转成 ui 自动化用例，我举个例子。

比如测试搜索功能可用

步骤一 用 admin 账户使用首页的搜索框
期望结果 搜索成功，返回商品数据

生成的用例和测试写的用例都是类似这样的。ai 并不知道登录点哪里，首页有多个搜索框点哪个，写成 broswer 的用例就需要非常详细

所以引入了产品地图的概念，产品地图就是 设计文档需求文档 ai 转化而来，相当于给 ai 加了个产品说明书。

然后用这个产品说明书实现用例的细化。

步骤 1.打开网址
2.点击登录输入框
3. 输入 admin
以此类推

变成非常详细的用例步骤。

这里大概四五成用例就能直接跑了

产品地图 还起到另外一个作用，ai 自动纠正错误和告警。
当界面太复杂，详细的步骤也可能写的不对， 所以在 browser 改进版中引入了 airtest 的能力，用产品地图校验产品和修正 ui 自动化用例，实现自愈功能。

上面就是实现 ui 全自动化的简易思路