其实个人觉得 D 接口自己构造一些业务数据直接压就可以，对于业务来说，场景里 D 接口查询的是不是 jmeter 压的 C 接口数据应该影响不大，对于 C 接口我一般会写一个脚本去统计业务异步处理的正确性和处理时效，这个也是一个性能指标数据

不是 a 调 b，b 调 c，c 调 d
那种吗

以下纯属个人猜测，如有雷同，纯属巧合：
1.如场景以 D-Finnish 为终止点：ABC 和 D 需要相互独立验证，分别得出两者的性能，然后取其低者（肯定是 D 低~）
2.如场景以 C 为终止点，则只取 ABC 的性能即可（通常页面状态也是以 C 结束为识别点），至于 D 都考虑异步了，性能方面忽略就算了，不是太离谱就行

我理解性能测试不应该以单个业务来设计， 而是去评估每个接口分别会有多少流量，然后按比例来构造。 比如 四个接口的流量比例分别是 1:2:2:3 类似这样。
具体的比例是多少，要么是看生产的数据统计，要么是根据业务模型去评估。

感觉得看具体业务场景，D 有可能单独拎出去做性能测试，不一定要和 ABC 串联绑定在一起。

假设 D 是因为任务的量大且单个任务耗时长，背后使用队列来做异步消费，那考虑的是任务堆积的情况下 D 接口的响应会不会有什么问题。

假设 D 就是一个简单的任务状态查询接口，查一下库里任务的 status，那可以单独测 D 能扛多少读压力，能否满足业务诉求。

总结来说就是按具体业务场景去考虑，要结合技术实现去看。

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

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

这个时候你需要一个可编程的压测工具，很简单的功能用 Jmeter 反而复杂了

所以你这个就是适用于第一场景，必须以 D 的结束为终点，那性能的瓶颈点大概也是以 D 的性能为主要成分，2min 也就可以算是你的性能指标了，但这种异步类场景验证流程性能的意义不大，我建议重点关注 D 接口的性能便可

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

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

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

按你现在阐述的场景，这样是不合适的
大家讨论的其实都是异步接口是否应该与常规接口放在一起评估性能，我认为是不应该的。就这个场景而言，我认为 ABC 和 D 应该相互独立测试，这样才能直观的看到场景瓶颈是在哪段，如我之前所说的。
至于具体测试场景操作设计，你可以在站内搜一下，常规性能场景就可以，没啥好说的

你上边说的是轮询获取结果来着，我理解 D 接口应该是一个频次高的业务结果查询，看起来是要把 D 接口拿出来，单独设计压测场景。

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

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

宝贝，你这样我可就没法和你聊了
并发的含义是什么？单接口测试的前置需求有哪些？实行性能测试对接口功能方面的要求是什么？

从设计角度，A+B+C 可以看作一个整体，D 是另一个主体。
两者可以通过流水的方式进行并行。

通常性能，只谈时间，有两个指标：

1. REALTIME 延时，全流程时间。
2. 并发能力 这两个某些时候就是冲突的。 如果是 2，且开发设计合理的话，性能=max(A+B+C 时间/线程数，D 时间/线程数）

PS：这是正面回答你的问题。
下面是我个人的理解：这么设计，我说服开发都存在困难，通常我默认测试能测成啥样算啥样，只要不崩，差不多就结了。性能我会 PUSH 开发测试。

abcd 是一个整体，或者说 abc 是一个整体，只是一个查询接口。D 接口可以单独测试一下，d 的访问量肯定比 abc 大多了。也可以单独测提交性能 abc 和生成性能就是 c 提交后到 d 查询成功。

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

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

D 接口只是一个查询接口，我理解接口查询性能和任务处理是两个方面。你可以单独测一下系统支持最多多少个任务同时处理，处理的时效咋样。

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

居然还在纠结这个问题，我的话一定是 abcd 一起测试，但是我会模拟客户端的请求顺序和频率，也就是完全模拟客户端的行为，构建真实场景测试结果自然接近真实数据。

你和开发确定需求了吗？这个异步接口可以一起沟通下，一般性能方面要求很低的，不然也不会考虑异步了
至于前置需求，应该是依赖 abc 结束的数据吧，查库数据参数化能否实现

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

看实际的业务量把，一般根据当前最大值然后再扩充一点，满足未来一段时间的需求。

看你描述，你的测的是业务场景耗时，那么先考虑 abc 吧，d 接口理论上没有什么业务逻辑，直接返回状态。
另外 abc 后，是会产生一个异步处理，这里是 mq 的或怎么样的，也考虑中间件的性能，别打爆了

用户发起多个 adc 的业务操作后，页面上应该对只有一个 D 的请求吧

是想测试 abc 接口发起的业务，后端处理这个任务的性能吧？如果是的话，我觉得可以忽略掉 adc，直接测试发起的任务量多少，对后端处理任务的性能影响。直接测试 D 接口 status 变化为 finish 的时间就行吧

10 分钟间隔来统计吞吐量吧

价格 if 循环不就好了