先学好一门编程语言吧

那会有很多个日志文件吧。。。

是否有单独需要测试广告的 sdk 的

这个可以自己写 demo 去测试吧？

大哥牛逼啊，熟练使用各种 java 工具

交叉个锤，平时都点不过来了

让你们开发自己测啊

如果只是数据的大小，国产系统就能很好做到，如果要看消息体，那就抓包

测试这个东西，除了一线城市，都不怎么样。

因为其他城市基本都是小公司了，开发自己点点就完事了，还想要专人负责给你点？？小公司开发就是神，兼顾开发、运维、测试、设计于一体的

可以，你把 docker 镜像里的 jar 包复制出来，再手动启动就行

查库不太信，他是直接提交一些任务参数去进行任务计算的，一提交任务就自动计算的

那单独压测 D 接口时，后台要同时提交多少个任务才好呢？

a b c 比较好测，按照流程疯狂提交任务就行，但是 D 接口，我在想要怎么单独来压测呢？

感觉好像没办法准备前置任务，因为 a b c 一提交就自动开始了，不会等待的。。。

我也想要

junit4 就不说了，junit5 是分了好几部分开发的，我之前看的时候多线程还没开发好，现在不知道好了没

哈哈，楼主只是反驳一下之前的帖子而已吧

不是一直很流行吗？junit 一直都是半残的状态，也不知道为啥那么多人用

sonic？

游戏大佬

虎哥，我觉得你说得不中啊，D 能不能轮询到结果，取决于用户有没有调 A、B、C 接口去提交任务，而且一个用户一次只能提交一个结果，如果有运行中得任务，用户是不能一直提交任务得

我感觉 D 不能单独压的，因为 D 得需要用户调了 A、B、C 才能有结果，而且一个用户只能提交一个任务，在这个任务没结束前不能再提交别的

虎哥，是不是就按 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 乱杀的