何时在jenkins CI中使用jmeter进行性能测试？

Question

我正在使用Jenkins为微服务创建CI管道。现在，我对性能测试感到困惑，我的意思是，在将微服务部署到服务器或在本地运行微服务后，应该在哪里添加性能测试阶段，然后进行性能测试？

Answer 1

简短的简短答案是，这取决于您要通过性能测试实现的目标。

我之所以这么说是因为有the spectrum of testing：

这是一种尝试建立测试分类法的尝试，有助于理解各种测试的类别。但是，尽管尝试将分类设为二进制，但现实并非如所描绘的那样清晰可辨。那是因为它取决于测试目标。

您可以在以下位置找到有关它的更多信息并进行测试：

• Microservice Testing: A New Dawn

• Testing Microservices, the sane way

然而，测试范围的重点是建立了两个分类：

• 生产前测试
• 生产中的测试-分为三个阶段：部署，发布，发布后

在您的情况下，如果希望使用性能测试来以自动可重复的方式防止新版本的回归，则应将其作为管道中的deploy阶段测试添加。甚至将其推送到受监视支持的release或release-release阶段。

但是您必须牢记在自动化管道中进行此类测试的成本。

如果您想按需运行性能测试，则放弃某种方式，那么您就不必在意自动化。然后，可以将性能测试作为在本地（或暂存）环境中按需运行的生产前测试而排除在外。

所以这确实取决于。

Answer 2

这取决于您要执行的性能测试的子类型。

通常，我不建议将被测系统（在您的情况下为微服务）和负载生成器（在您的情况下为JMeter）在同一台计算机上运行，​​因为您可能会遇到微服务和JMeter都在为系统资源，因此您的结果将不可靠，因为：]

• 涉及高负载时，JMeter可能非常资源密集型
• 同样适用于被测试的应用程序>

因此，当两个应用程序都缺少系统资源时，微服务将无法足够快地响应，而JMeter无法足够快地发送请求，因此您将得到“假阴性”结果。

理论上，您可以将本地环境用于regression testing目的，以防万一，当您已经发现所有bottlenecks并发现了所有问题，并且只是想确保新功能和/或错误修复不会导致性能下降而导致确保监视系统资源以排除JMeter和微服务的相互干扰，可以使用JMeter PerfMon Plugin

否则，您应该针对生产或类似生产的环境。有some forms of performance tests you can conduct on a scaled-down environment，但是如果您在没有生产机器硬件规格的本地系统上获得结果，将无法完全依靠结果。