理论是理论，实践是实践，汇报是汇报

哥们啥业务啊，全 AI 托管的质量保证至少要需要业务知识 + 全量代码远小于 AI 上下文限制的一半以上才敢这么干。
我这边现状是测试成本低/质量要求低的研发团队才会把以前本就可有可无的 QA 吃掉作为不裁员的理由。
稍微复杂点的业务的 QA 依旧是大爷，光跨端的数据构造就够研发喝一壶了。

并不是用例执行 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 过了且严格执行和验证了，指望在用例执行过程发现遗漏场景是不负责任的赌神行为

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

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