测分、用例这些文字工作提效还是非常明显的。但是要实现真正提效，只靠测试一个环节或者角色，远远不够。必须是端到端的组织形态的升级。

确实是，今年整个产研要求都使用 AI，但也是实践阶段，目前准备就是把用例生成这一部分能提效，选用一个合适的大模型，当前选的是 chatGpt 付费版的。生成用例当前哪个大模型覆盖的更全面一点儿？

测试生产的话，成败在知识库的构建/重构，而不在你选了那个大模型。

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

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

老师新年好 我想咨询一下
1、目前你们项目的业务场景复杂吗？如果够复杂的话整个业务知识流程怎么处理呢？
2、在大数据方面有使用吗？例如离线数仓
3、目前你们使用 AI 保障质量是着重哪一方面呢？是日常回归巡检还是开发新功能就在用？
4、目前 AI 设计出来的用例有效占比多少呢？
5、既然已经落地了，测试人员的同比投入工时是否减少？提效了多少呢？缺陷呈现的分布是怎样的？生产问题是否有实质上的改善呢？
6、是否有打算做线上巡检呢？

身边的环境正在这样变化，仅供参考：

1. 产运：AI 重塑业务
2. 研发：AI 提效编码开发、Code Review、监控报警（主要还是编码开发）
3. 测试：AI 提效测试文本/自动化用例生成、质量风险评估、用例执行，并大量人员开始转型大模型评测

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

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

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

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

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

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

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

能问下测分是什么意思吗

测试分析吧

大佬，ui 自动化用例，和场景接口自动化用例能展开说说吗

基于 llm 生成测试用例

蹭个贴简单说一下我的使用经验吧。

工作中正儿八经使用 AI 大概是从 25 年初开始的。

上半年主要是使用 cursor 协助进行测试工具开发、协议测试用例编写等工作，AI IDE 也的确算是当时最主流的形态了吧。

下半年全面转向 AI Agent ，主力使用 Codex CLI，Gemini CLI 和 opencode 作为补充。这时候使用场景就无限扩展了，几乎可以插手我的所有工作事项。

• 需求文档、测试用例等材料审核
• 全仓库代码审核（配置表 + 导表、前后端代码、协议、等等）
• 工具开发、协议用例脚本编写等等常规代码工作

目前我遇到任何具体的工作事项，都会第一时间想想 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 全自动化的简易思路

有 UI 组件比较麻烦定位的话，处理起来是多个方式重试吗？？像 playwright mcp 一样？执行 token 太长会分成 2 条用例来跑吗

请问复杂业务场景是怎么训练 AI 的，这部分的前期投入大吗？
需求文档全是孤立的，且很多功能都是在反复改来改去。没有整合过一份完整的。
之前公司搞过一个 AI 用例生成，但是把需求文档扔进去，解析出来的用例也就是复制粘贴文档里的文字。
几乎没有什么智能化的提炼。甚至文档里有前后矛盾的逻辑，错别字啥的也都一并照搬了
没有接口文档，接口用例都是自己抓包或者是用录制的办法搞的。
想要让 AI 介入感觉都是一头雾水
这种是不是要先补前面的债再逐步推广 AI 介入比较好？

应用商店场景，给包名，自动设计测试用例，自动执行测试用例，已落地