这个感觉更多是个 demo, 只适合单需求的处理, 如果一个迭代有很多需求, 那么在需求分析阶段需要加上需求/功能拆分、 关联分析, 测试设计阶段, 需要加上测试点分析、用例生成、用例审核
测试人员从需求到用例, 也不是一步到位的, 各种需求分析、测试设计才是重点
「接口测试:AI 根据 OpenAPI 文档自动生成参数边界值用例,并智能编排执行顺序。」
如果接口参数大量依赖实际数据库/其他接口返回的数据, 这块有什么好的方案不, 总不能人工一条条给他梳理吧
赞一个
公司降薪, 心情不好
说得太对了, 比如我们公司....., 让大家搞 ai, 说是可以报销, 但是没有细则....
现在让研究研究 trae-cn
好奇这一套下来 token 消耗咋样,花了多少钱
用例的颗粒度, 取决于执行用例的人是否理解需求和熟悉系统
自己写自己执行 (深入理解需求和系统), 写测试点就好, 除非是重要 + 复杂逻辑 要深入评审则要写细点 (场景细, 但还是废话别太多)
给不清楚这块业务/没看过需求的人执行: 还是细点吧, 不知道他们能理解成啥样
让他写 AI 完成负责的工作, 然后辞退他
厚脸皮问一下,可以分享一下 agent 怎么测试的嘛
支持不同代码版本的覆盖率合并吗