还在搞古法测试工具

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 全自动化的简易思路

1、目前你们项目的业务场景复杂吗？如果够复杂的话整个业务知识流程怎么处理呢？
业务比较复杂，平台光角色就有几十种。
ai 容易切换正确的角色去生成自动化用例，这部分会加权重去解决这个问题。
平台知识数据，大部分是基于约定好的，需求和接口生成的，其中不太稳定的地方，比如接口关系流转，是开放给测试让测试去补充知识数据

2、在大数据方面有使用吗？例如离线数仓
业务开发有使用，但生成用例和文本用例的工具是没有用这些的

3、目前你们使用 AI 保障质量是着重哪一方面呢？是日常回归巡检还是开发新功能就在用？
新功能开发，
日常巡检的自动化用例，主要流程已经覆盖到 90% 以上，没有新增用例的空间

4、目前 AI 设计出来的用例有效占比多少呢？
应该有 60-70

5、既然已经落地了，测试人员的同比投入工时是否减少？提效了多少呢？缺陷呈现的分布是怎样的？生产问题是否有实质上的改善呢？

这个问题比较难搞清楚。 一方面测试用 ai 做自动化用例提升效率，但开发也用黑灯工厂去开发 70-80 的代码都由 ai 去开发，测试的效率提升了，但开发的效率也提升了很多，很难去判断提效的到底多少。
我属于测试开发组，缺陷分布没有去关注，我只知道月均十一二个左右的缺陷，现在降到了十个左右。

6、是否有打算做线上巡检呢？
没有

已经放弃传统测试设计，测试点，人肉执行那一套为主的，改为围绕 ai 生成用例和自动化用例做开发测试一体化。
文本用例和 ui 自动化用例，和场景接口自动化用例，在开发没编码前就完成 60-70 了，开发编码过程要过流水线新用例 bvt 才能 commit 代码。

文本用例技术主要用到知识图谱和状态机，也就是业务场景建模，把功能看成一个树状图，然后遍历子节点，得到文本用例和文本用例对功能的覆盖率，

我部门搞开发测试一体化，不是传统瀑布开发，敏捷开发。
用例生成流程比较长，用例参数的主要是知识图谱，文本用例主要是状态机技术，用状态转移方程让 ai 生成自动化用例，主要是为了用例覆盖率去设计的，生成出来的用例会知道覆盖率。

接口和 UI 用到的生成技术也不同，比较复杂。

开发测试一体化，就是在需求阶段根据需求生成好 ui 和自动化，和功能用例，开发接口还没写就有测试用例了。然后开发接口写一半就可以触发自动化测试了，ui 也一样，我部门用例生成覆盖率大概 70% 左右。

ui 也是生成的，主要用产品白皮书做成产品地图 + 文本用例，生成 ui 自动化用例，目前成功率不是很高只有 100 条文本用例生成只有 50 条左右直接可以用，剩下要人工修正