虎哥，是不是就按 A-B-C-D 顺序调接口，然后把整个流程用事务控制器包裹起来，D 出结果才算完成一个 tps。

然后 jemeter 不断上线程，重点关注后端能同事处理多少个人的任务，有没有报错等等，就不用什么 tps 哪些做性能指标了，就统计能支持多少用户，然后他们的渲染时间分别是多少。。。

我觉得不是这个问题啊，jmeter 也可以自定义请求，我疑惑的是场景应该怎么设计。。

前面 A、B、C 接口做的都是业务都是 D 接口给出的结果，就比如渲染一张图片，前面 A、B、C 接口都是设置图片的参数，然后调 D 接口渲染图片

这个不是哦，前面 A、B、C 接口做的都是业务都是 D 接口给出的结果，就比如渲染一张图片，前面 A、B、C 接口都是设置图片的参数，然后调 D 接口渲染图片

大哥，985 乱杀的

如果一直呆在那家日企，会不会更好

是不是把重试类一起贴出来

有新的立马给他们更新

大佬，websocket 压测时单线程可以一直跑，但是只有开多线程，就很容易超时，哪怕两三个线程也超时，这种可以排除脚本的问题吗？

直接整最新的不好吗

别做测试，只说一次

最烦这些逻辑复炸的业务

所有的吗？

再差也会在 AMD/INTEL 吧

膨胀了小子，你还想去哪

带专基本混子

......

在代码里面去控制例如@epic之类的注解，然后加上特定设备信息，应该可以区分出来

难搞

大佬的文章好像好多斗看不到了

考公

少走很多弯路

“基于此点，2023 年笔者对 CRM 模块开发了大量接口和 UI 的自动化用例来覆盖尽可能的业务场景，回头想来，这个兜底的动作是非常有效的。”

有没有啥数据支撑，正愁不知道咋吹，参考一下

大佬，就是收集用户访问的 api 比例，比如一天有 100 访问了网站，需要统计这 100 人分别访问了啥 api，然后他们之间的比例如何，然后做性能测试时就按照这个访问比例去发起压测

"不只适用于单个接口的测试，同样适用于多个接口组成的完整的业务逻辑的测试，这往往是接口自动化测试更应该做到的"

真没见过谁的接口自动化测试是只能做单个接口的，还有，定义了 yaml 还得在写一个 test 类型的代码，一个接口写两次。。。。

大佬牛逼