问答 有在研究利用 AI 生成测试用例的团队么？效果如何？遇到哪些瓶颈？
先抛转引玉下，我们团队从去年开始探索用例平台接入 AI 的能力，通过输入需求内容产出脑图格式的用例。
主要流程：
1.平台交互页面提供需求录入的页面
2.调用底层 AI 工作流（基于 DIFY 二次开发的，工作流包含了 RAG 和模型的调用），生成用例
3.用例处理，平台页面实时展现
效果方面：
1.整体 AI 生成用例条数占比 10% 左右，由于生成的用例都需要人工 check 和优化结构，目前实际提效基本可以忽略
2.先让 AI 对长文本需求拆分后，再逐块生成，效果会好一些
主要的障碍：
1.由于多数需求都是增量的需求，对历史知识库的依赖比较重，而目前 RAG 在基于需求这种长文本检索方面效果并不理想（召回数量最大也只有 top10）
2.历史知识库碎片化也比较严重，实体关系较难在 RAG 检索阶段被理解
3.尝试模型微调训练的方案，所需要的数据集（问答对）的梳理工程量有非常巨大，目前进展也不太理想
不知道大家在这块都有哪些好的经验？实际效果如何？
你这种方式有点本末倒置了，感觉一点都不提效
还不如直接把需求扔给 AI 提取测试点，然后看看自己的用例有什么可补充的
KPI 产物
面向领导编程的产物
吹嘘大于实用的产物
演示完就丢仓库的产物
总结：一无是处
AI 生成的用例还是需要经过二次筛选的，存在严重的幻觉问题。只能用来碰运气看它能不能想到一些隐蔽的测试点
一样的问题
我的脑子就是思维导图，我点的地方就是测试用例
这个问题也思考了很久，如果作为提效的手段，按投入产出比来平衡，可能 10 年都收不回投入。可能目前比较好的方案是辅助线的协助测试完成一些工作，加入主流程，反而会导致效率低下。
如果后面要做，把需求文档上传后生成结构化数据，针对预览结构化数据的 prd 逐条或者多条生成测试用例，最后对生成的用例进行汇总预览，选择下载。
之前做过接口文档生成用例的，嗯领导对上面汇报完装完逼就结束了。。。哈哈哈
我们这边也研究过感觉现阶段的 AI 有点不靠谱
大模型目前使用下来的感觉就是，能把 1-10 相对合理的组合起来，但是它自己无法生成 11，创造性这事儿还做不来。现在看生成用例这部分还无法替代人工，如果这都能做了，让它执行就更简单了吧。那还需要测试工程师做什么呢？
产出结果就是能拿来水，并且 AI 现在真的赚钱的点就是卖课，深入研究除非从业人员不然没意义。
个人认为要真能做到提效，得一个团队几个人投进去几个月的时间，但是老板会同意这么多时间成本吗，最多也就给多一个月
你要不要去问问 kimi、ds、千问、文心它们这几个问题：
- 测试对象有 4 个输入，取值分别为（A1, A2）、（B1, B2, B3）、（C1, C2）、（D1, D2, D3, D4），使用 BC(Basic Choice) 覆盖方法获得的测试条件有哪些？
- 有函数 f(l, m, n)，l 取值 [1500, 1800], m[2, 15], n[3, 25]，采用边界值法和基本选择法进行测试，仅考虑边界内有效值，最少有几个测试用例，分别是什么？
听听 AI 在放什么屁……再决定要不要用 AI 写 case
槽神
回复
特意去搜了一下
问题一：BC 覆盖方法的测试条件
对于输入参数 A（A1, A2）、B（B1, B2, B3）、C（C1, C2）、D（D1, D2, D3, D4），使用基本选择（BC）方法时，测试条件如下：
选择每个参数的基本值：假设选各参数的第一个值作为基本值（A1, B1, C1, D1）。
生成测试条件：对于每个参数的非基本值，生成一个测试条件，其他参数取基本值。
测试条件列表：
A2, B1, C1, D1
A1, B2, C1, D1
A1, B3, C1, D1
A1, B1, C2, D1
A1, B1, C1, D2
A1, B1, C1, D3
A1, B1, C1, D4
总数：7 个测试条件。
问题二：边界值法结合基本选择法的测试用例
参数范围：
l ∈ [1500, 1800]（整数）
m ∈ [2, 15]（整数）
n ∈ [3, 25]（整数）
策略：
边界值法：为每个参数选择最小值（min）、最大值（max）和中间值（nominal）。
l: 1500（min）, 1650（nominal）, 1800（max）
m: 2（min）, 8.5 → 9（nominal）, 15（max）
n: 3（min）, 14（nominal）, 25（max）
基本选择法：以中间值为基本值，生成用例覆盖各参数的 min 和 max。
测试用例：
基本组合：l=1650, m=9, n=14
l 的边界值：
l=1500, m=9, n=14（l 的 min）
l=1800, m=9, n=14（l 的 max）
m 的边界值：
l=1650, m=2, n=14（m 的 min）
l=1650, m=15, n=14（m 的 max）
n 的边界值：
l=1650, m=9, n=3（n 的 min）
l=1650, m=9, n=25（n 的 max）
最少用例数：7 个。
我这边也再试用 AI 生成测试用例，目的是用 AI 生成测试用例，最好是能直接用。
刚开始考虑的是直接试用 PRD 来直接生成用例，但是，这边的 PRD 写的比较渣，很粗，遂放弃。
后来是使用整理测试点，用测试点来生成用例的方式，然后发现个问题，不同的对话框，同样的描述语句生成的用例不一样，而且区别还比较大，像是不同风格的人写的，整理起来很费时间。
最后是新增了一个步骤：将写好的用例再投给 AI，让 AI 再次整一下，整个流程就变成了：整理测试点-->AI 生成用例-->手动整理-->AI 修改、补充-->手动整理。这个流程就比较消耗时间，而且在【AI 修改补充】阶段修改后的用例也是不能直接用的，还是需要再整理。
整体使用下来感觉 AI 只能补充下测试点、提供下测试思路，用例还是需要自己来写才行。而且只能用在简单、单一的功能上，如果业务比较复杂的话就不行了。
TAPD 已经有现成的功能了
我的理解是用 AI 写业务逻辑的用例，需要先整理一篇逻辑性的文档才行，否则 AI 没有上下文，没有相关的业务逻辑，也无法生成测试用例，UI 类的用例倒是可以扔给 AI 去写了
目前哪个测试用例写的好点？