用 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 接口查询对应的链路信息。 让大模型评估这次对话是否符合预期，

感谢认可，测试领域的智能探索免不了都要涉及用例生成。这个方向确实也是最好出结果的。简单搭个工作流，针对某个需求特调几天，演示时放个 prd 进去就能出一个像模像样的用例。但非特调的效果只有一线真正背质量风险的 QA 才知道了。

我这边演示也是特调的，但是和老板公开了从生成的狗屁不通到像模像样的特调过程，除了要在提示词加一堆限定，还需要不断调整知识库的分片和需求文档的细节，比把用例直接写给智能体还费劲

时隔几年冒个泡，也是希望大家谨慎入坑用例生成方向。在模型和 rag 有质量的飞跃前，出结果容易出效果难

大佬谈不上哦，个人比较建议后端 qa 做用例执行和验证方向。
只要用例明确，从接口维度是可以走通场景执行 + 验证流程的，且通用性较高，不太受业务复杂度影响。
别的不敢说太多，怕被敲门查水表

你说得对，全新功能的需求只有第一次好用，再迭代就跟迭代中的需求一样难受了

个人觉得知识库中背景知识这部分靠人是堆不好的。它不像操作手册数据构造这类基本不变化可以沉淀为 skills/prompt，也不像天气时间这类可以通过 mcp 实时获取阅后即焚。业务背景知识是不断随着系统迭代变化的。某个场景今天需要这样支持，明天需要改成那样，甚至再过几天下线也是常有的。甚至还有灰度这种同业务不同处理模式的情况，只有建立和人脑类似的结构才能很好的处理归纳这类知识。

真突破了的那天直接给 cursor 或则 Claudecode 一份 prd + 知识库就可以了，开发先一步下岗了哇，

向量库库模式我们试过的，先不说知识库的维护难度。真正复杂的业务，需要知识库的内容是海量的，包括业务场景的介绍，操作步骤，数据构造方式，核心关注点这些。一旦某一条召回的不够准确，就会跟下毒一样产生蝴蝶效应。
目前没找到能自动根据业务重点返回刚刚好 “合适” 分片的知识召回模式。 目前也没发现有大模型能在海量业务上下文中还能完全遵循提示语圈定的范围进行用例生成。

之前把某个新业务花了好几天终于调好了，用例生成的也基本能看到了，等业务一迭代就完蛋了。知识库要更新，提示词也要改，调试成本超级高。给老板演示完就搁置了，打算等哪天模型能力够强了再捡起来吧。

另外光知识库也不够，还需要配合源码级别改动点的输入，光把 code diff 传进去也是不够的，需要系统性的分析改动方法的调用关系，从入口方法传到改动点的方法源码，不然模型无法通过改动对应到场景，用例的可执行性超级差。 这又给本就不富裕的上下文雪上加霜。

总的来说就是，上下文给少了生成效果不知所云。 上下文给多了注意力涣散胡言乱语

做了一年多 AI 提效相关的活，有上头派下来的，也有内部孵化的。目前我这这边团队内共识的是测试分析和测试用例生成目前不适合 ai。看起来是能快速出结果，但结果可用性不高，主要问题在于输入的语料太多导致分不清重点是什么，导致实际可能的实际业务场景无法列全，对新项目稍微好一点，对于迭代中的业务基本没有价值。

这个问题在上下文受限的当下是无解的，除非人把 prd 和技术方案进行二次处理梳理好重点业务场景和细节。可这样和让 qa 写用例区别不大了。 这样的成本不如人写完用例让 ai 做 review 呢

智能体做的比较好的是测试执行和验证这类根据用例可以明确步骤的事情，qa 生成指令 (用例) 之后让智能体执行，等执行结果 review 就好了。目前通过不断调优正在做的更好

长期的行业发展鄙人目光短浅看不到，中期来看 AI 时代是对 qa 的要求更高了，需要产出能让智能体执行的用例，另外需要能通过调整用例和优化测试智能体，提升测试执行和结果检查的质效。

测试执行比较明确，对错也好判断，现阶段无非就是贵和耗时 (除了模型本身速度，还需要考虑错了重试的消耗)。
用例生成这种看起来简单的，生成出来的效果反倒是最差的。
特别是迭代到中后期的业务还要涉及到之前的相关文档，压缩也无法明确哪些和本次有关系，会不会被压没了

什么？界面可信度为啥要找 70 位测试去打分？这不是产品经理和 UI 要做的事情么

测最大可以承受多少并发很麻烦的。
不如用最大 tps&当前的并发&响应时间估算

感觉你的视角有问题，要测路口，关注的只是这个条路每秒能过几辆车。 每辆用时多久。
并发数只是用来保证这条路是饱和的，每个口子都有车在过。四个口子的话只要保持 4 的并发即可。
就算加到一万辆车一起过，除了在过口子的车，其他车都是无效的压力。因为对于四个口子的路口来说他们当前也只承受了 4 个并发而已，后面的车他们感知不到的。

只有这条路有 1W 个口子可以并排开过 1W 辆车的时候，并发才算是 1W

TPS 怎么算出来的是 4？

并发是 TPS* 平均响应时间，2*1.5 =3 啊。
并发 3 是意味着一直保持有三辆车在过闸口。

要是你说一共只有 8 量车，那并发量其实是根据时间在递减的。
你想啊，过了 1 秒后，还剩 4 量车，这时候并发还是 8 么？

TPS=并发数/平均响应时间是对的
TPS=总请求数/总请求耗时。
总请求数=并发量 * 总请求耗时/平均响应时间。

没办法，实在琢磨不出来，为啥我的反问句会被理解成疑问句

那线程在等什么呢？ 等迟钝了的服务器的返回对不对？ 压力没增加那为什么服务器迟钝了？

高线程等不等于高压力？44 楼的回帖你真的看懂了么？
增加线程没有增加压力的话，那服务器响应的延时会增加是因为什么呢？

1.不需要知道什么是 BIO，看过官方文档的就会认为更高的线程能造成更高的压力 （Number of Threads：Number of users to simulate.）
2.我根本没说线程==并发，这是你的误解。只是线程数和并发量一般都成正比，同样可以量化压力，方便你更好理解我才写括号里的。

再抬杠下次我可要收学费了哦。