业务流程包含 4 个接口：
同步接口：A、B、C
异步接口：D
业务大概是这样，用户依次访问 A 接口-》B 接口-》C 接口，C 接口会返回一些信息，然后前端根据这些信息去 D 接口里面去轮询结果，D 接口的响应有个状态字段 status，如果 status 是 finish 的话前端就停止轮询，如果 status 是 executing 的话就会继续轮询 D 接口，直到 status 是 finish，那我的业务肯定是要轮询 D 接口直到 finish 状态才算完成
现在要根据这个业务场景设计压测场景，如果说不要 D 接口，那很简单，直接依次访问 A，B，C 接口就可以了，可是轮询 D 接口这个动作怎么设计到场景里面去呢？？
如果说设计压测场景是访问 A-》B-》C-》D，直到轮询出结果，耗时总共 2 分钟，那我的 TPS 是多少？零点零几吗？哈哈，好像没看过有这么说的。。。
TPS 都是一秒完成多少事务吧，那我这耗时 2 分钟才完成一个事务，感觉算起来好奇怪。还有，jmeter 里面怎么去添加一个轮询的接口？是把 A、B、C、D 接口都放到一个事务控制器下面就可以了吗？
有没有大佬赐教一下
其实个人觉得 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 接口的性能便可
今晚打老虎
回复
虎哥，是不是就按 A-B-C-D 顺序调接口，然后把整个流程用事务控制器包裹起来，D 出结果才算完成一个 tps。
然后 jemeter 不断上线程，重点关注后端能同事处理多少个人的任务，有没有报错等等，就不用什么 tps 哪些做性能指标了，就统计能支持多少用户，然后他们的渲染时间分别是多少。。。
卡丁车卡丁丁
回复
按你现在阐述的场景，这样是不合适的
大家讨论的其实都是异步接口是否应该与常规接口放在一起评估性能，我认为是不应该的。就这个场景而言，我认为 ABC 和 D 应该相互独立测试，这样才能直观的看到场景瓶颈是在哪段，如我之前所说的。
至于具体测试场景操作设计，你可以在站内搜一下，常规性能场景就可以，没啥好说的
杨腾
回复
我感觉 D 不能单独压的，因为 D 得需要用户调了 A、B、C 才能有结果，而且一个用户只能提交一个任务，在这个任务没结束前不能再提交别的
今晚打老虎
回复
虎哥，我觉得你说得不中啊，D 能不能轮询到结果，取决于用户有没有调 A、B、C 接口去提交任务，而且一个用户一次只能提交一个结果，如果有运行中得任务，用户是不能一直提交任务得
从设计角度，A+B+C 可以看作一个整体，D 是另一个主体。
两者可以通过流水的方式进行并行。
通常性能，只谈时间，有两个指标：
- REALTIME 延时，全流程时间。
- 并发能力 这两个某些时候就是冲突的。 如果是 2，且开发设计合理的话，性能=max(A+B+C 时间/线程数，D 时间/线程数）
PS：这是正面回答你的问题。
下面是我个人的理解：这么设计，我说服开发都存在困难，通常我默认测试能测成啥样算啥样，只要不崩，差不多就结了。性能我会 PUSH 开发测试。
abcd 是一个整体，或者说 abc 是一个整体，只是一个查询接口。D 接口可以单独测试一下，d 的访问量肯定比 abc 大多了。也可以单独测提交性能 abc 和生成性能就是 c 提交后到 d 查询成功。
藕片
回复
a b c 比较好测，按照流程疯狂提交任务就行，但是 D 接口，我在想要怎么单独来压测呢？
感觉好像没办法准备前置任务，因为 a b c 一提交就自动开始了，不会等待的。。。
居然还在纠结这个问题，我的话一定是 abcd 一起测试，但是我会模拟客户端的请求顺序和频率，也就是完全模拟客户端的行为，构建真实场景测试结果自然接近真实数据。
卡丁车卡丁丁
回复
你和开发确定需求了吗？这个异步接口可以一起沟通下，一般性能方面要求很低的，不然也不会考虑异步了
至于前置需求，应该是依赖 abc 结束的数据吧，查库数据参数化能否实现
看你描述，你的测的是业务场景耗时，那么先考虑 abc 吧，d 接口理论上没有什么业务逻辑，直接返回状态。
另外 abc 后，是会产生一个异步处理，这里是 mq 的或怎么样的，也考虑中间件的性能，别打爆了
用户发起多个 adc 的业务操作后，页面上应该对只有一个 D 的请求吧
是想测试 abc 接口发起的业务，后端处理这个任务的性能吧？如果是的话，我觉得可以忽略掉 adc，直接测试发起的任务量多少，对后端处理任务的性能影响。直接测试 D 接口 status 变化为 finish 的时间就行吧
10 分钟间隔来统计吞吐量吧
价格 if 循环不就好了
单用户基准：业务流 A-B-C-x*D（到 finish 可能会有多次 D）
分片性能摸底：（并发模式）A-B-C、D;（x 倍并发模式）D
业务全流程性能：（RPS 模式）A-B-C-D（D 异步回调，需要模拟前端间隔），其实支持异步的压测工具（如 K6）就可以直接测试业务流，不过这种压测结束后，正常还需要关注一下压测结束后 D 未 finish 的堆积量（脚本做一些记录输出就可以了）。业务全流程资源开销一般大于分片，所以 RPS 模式压测可以考虑梯度模型，分梯度摸底