过去，该客户使用 LoadRunner 已被证明是成功的，但需要相对繁重的过程。这与反馈周期短的敏捷开发理念背道而驰。
SoapUI 测试工具已被证明是真正的全能工具。可以在 GUI 中对单个 HTTP 请求进行参数化和测试。测试用例和测试套件允许对这些请求进行分组，并可以使用附加构建块（例如条件、循环和 Groovy 脚本）扩展到工作流程中。每个 HTTP 请求的断言允许验证是否成功执行。还使用了 JUnit 中已知的“绿色条”。这些测试用例也可以作为负载测试来执行——无论是在 GUI 中还是通过批处理脚本。 Excel 文件可以通过 Groovy 和 Java 库轻松访问，事实证明对于测试的输入数据非常有用。这种自动化和评估水平是其他工具（例如 Postman）无法实现的。
最大的好处不在于测量性能和吞吐量，而在于发现并发问题。从两个实际例子可以清楚地看出这一点：
首先，在使用org.apache.http.impl.client.CloseableHttpClient时发现资源泄漏。在后端调用 Rest API 时，总会出现 HTTP 连接池耗尽的情况。增加池中的最大连接数可以解决测试运行的问题，但可能只会延迟 活动策划者电子邮件列表 错误的发生。使用仅十个测试用户的负载测试重现了该问题，该测试是专门针对涉及可疑后端的调用而定制的。通过 Spring Boot Actuator 端点同时监控连接池的此类测试现已成为开发的一部分。
负载测试发现的另一个案例是不完整的事务管理。在测试过程中，不断出现org.springframework.dao.OptimisticLockingFailureException类型的错误。然后，测试用例可以减少为两个测试用户，他们基本上同时调用相同的函数。使用记录的 SQL 语句，问题被追溯到缺少事务控制注释。在随后更多测试用户的测试中，该错误不再出现。
测试数据通常使用开发期间已使用的用户和数据。如果负载测试需要十个以上的测试用户，可以从测试中心订购具有所需属性的测试用户。但是，特殊情况通常必须使用 SQL 脚本手动添加。现有数据可作为模板。
展望：持续负载测试
为确保反馈周期短，还应连续进行负载测试。然而，连续并不一定意味着作为构建过程的一部分，以免延长其执行时间或导致其失败。如果不仅测试脚本而且相关的工具都在团队的控制之下，那么就没有理由以比计划的发布更改更短的间隔来执行负载测试。
目标不是将负载增加到正在测试的应用程序的容量限制。无论如何，登录进程或某些后端系统通常是吞吐量的限制因素。所需要的是基本负载以及智能监控和日志监控。智能监控是指监控HTTP、数据库、队列连接、内存、CPU等资源池的分配和释放。通过对负载生成器使用不同参数（测试用户数量和建立负载所需的时间）进行多个测试系列，还可以推断出较大负载的值。对增长是否成比例或不成比例的评估通常就足够了。