大功能流的JMeter可持续解决方案

Question

我有一个使用API来测试的巨大流程。有3个端点。一个进程(db迁移)可以持续2-3天，一个进程返回当前正在运行的进程的状态(正在运行，成功，失败)，最后一个进程返回所有失败的进程(作为列表)。

整个流程应该是：

1. 启动第一个进程
2. 调用第二个端点，直到第一个进程结束(应该失败或成功)
3. 如果进程失败，再次调用第一个端点，如果没有调用，则转到下一个进程。 问题是，一个过程可以持续2-3天，我们有大约20k的进程要检查。(这需要很长时间)。我确实有一个专门的VM只用于这个。

我的问题是:是否值得尝试使用JMeter实现这一解决方案？

Answer 1

它不值得在JMeter中实现，除非您希望使用该工具作为一个工作负载自动化引擎，以取代UC4 AppWorkr或Control提供的功能。根据您的描述，它似乎不是一个负载测试，除了第二部分，它不断地查询服务的成功/失败。我不知道这个实现背后的架构。因此，我无法量化，即使这将是一个负载测试或不。