先抛转引玉下,我们团队从去年开始探索用例平台接入 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、千问、文心它们这几个问题:
听听 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 去写了