并不是用例执行 ai 做不到。而是生成的用例执行性太差了。
比如
用例描述 “在商城页面点击商品详情，加入购物车后使用优惠券结算” 人看没啥问题。直接交给智能体就很难有效执行。

需要翻译成：“在 http://xxx页点击 xxx 元素查看商品详情，等待跳转完成后点击 xxx 元素加入购物车，再点击 xxx 元素输入商品数量，再点击 xxx 选择优惠券，再…，最后验证 xxx 数据的 xxx 字段需要为 xxx 值”

这只是用例的一个细节，全量的转换难度可想而知，目前 1M 的上下文根本扛不住…

我觉得测试执行是 ai 最好做的，可控也可监测。不像用例生成，生成的好不好完全需要人再审查一遍。好的用例才是一切测试活动的开始……

目前测试执行的不好关键的问题还是用例生成的不够精确 + 没有对应数据构造能力。
用例生成不够精准体现在：“xxx 数据正确存入数据库” -------数据详情是什么？数据库是哪个库哪个表？
没有数据构造能力体现在：“生成一个 xxx 类型的订单 ，之后修改这个订单的 xxx 信息” ----------有对应的数据构造能力么？
除了用例生成不够精确外，数据构造能力是可以建设解决的。

用 openai 是没得选。知识库大把可以选的，大把可以离线部署商用的。
IMA 还要自己去重和脱敏，成本一点都不低，明显就不是面向商用的。真不如装个 Milvus，离线，同时不用人工去重和脱敏

成本最低，正反馈最快的结论是认真的吗？刚试了下，IMA 除了好安装以外，没 openapi，又要联公网，知识库内容还要上传到他司服务器，被信安发现了工作都不保。
个人用户体验一下还可以，无法想象有对于生产资料的外发限制这么宽松的公司

目前针给稍微复杂点的业务生成一份可行的用例都很难，还是别指望 ai 做深度的漏测评估了。
你问就是 “漏测” 了，保险起见你还是测一下吧，甚至还可能带出来几十个其他 “漏测” 的场景，人是测还是不测呢。

测试覆盖面的广度是用例设计中需要考虑的，如果 A 设计用例，B 完全按照 A 的用例执行用例。后面发现场景覆盖不全导致线上问题，会找设计方 A 还是找牛马 B？

在测试过程中想起来遗漏场景的情况，我理解有两种情况：

1. 用例执行失败了，排查的时候发现了一个遗漏的场景。 这种通过 ai 也会执行失败，需要人介入排查之后也是可以兜住的。
2. 通过执行用例，人对场景的理解越发深入，发现有些操作可以变化一下，变化后会导致一个未评估过的结果。这个可以在全部用例执行前和全部用例执行后各加一个反思环节，让智能体多次判断是否存在可能遗漏的场景。

单纯从权责的角度上来说，因为用例已经三方 review 过了且严格执行和验证了，指望在用例执行过程发现遗漏场景是不负责任的赌神行为

这个是业界难题了，能解决的人配享太庙

凭感觉哪成，制定好准入准出标准测几轮就知道差哪里了

真不是大佬
目前是用户写手工用例，之后让智能体生成代码用例去执行。

想做好这套依赖完善的基建。基建不完善是搞不定的，至少要支持：
1.实时维护的依赖数据生成器
2.查询接口声明
3.执行后影响的数据查询
4.用例维度的代码覆盖

如果是 langchain 生态，langfuse 必须要用啊！不用 langfuse 无法知道智能体的过程数据。而且 langfuse 本身也提供了评估模块可以提供回放能力。
测的话可以通过接口触发智能体，然后通过 langfuse api 接口查询对应的链路信息。 让大模型评估这次对话是否符合预期，