持续集成中的性能测试？

Question

我们已经有了一个持续集成流程，我们在其中构建、运行单元测试、进行静态代码分析和生成文档。但是，我们希望将其扩展为包括自动性能测试。在本例中，我们正在开发一个 .NET Web 应用程序。

我们已经用 JMeter 进行了一些性能测试（在 CI 流程之外），但我不知道这是否是包含在 CI 流程中的最佳工具？硒是一种选择吗？ WAPT 专业版？

我们应该在哪些级别上测试性能？我们应该有一套“性能单元测试”吗？我们是否应该在类似生产的环境中运行 JMeter（或类似的东西）并在任何请求花费 > 1 秒时失败？这样的事情不会有太大的差异吗？

那么，你们是否将自动性能测试作为 CI 的一部分？你测试什么，你使用哪些工具？你的经历是怎样的？

Answer 1

首先，JMeter 是包含在 CI 中的一个不错的选择，因为它可以从命令行运行，并且您可以在执行此操作时传入变量。我会推荐它来完成这项任务。

但总的来说，集成 Perf。测试 CI 很困难。您已经列出了许多原因，所以您已经成功了一半，因为您了解这些限制。这就是问题所在：Perf 是可能的。在 CI 中进行测试，但范围有限。

我认为一个好的方法遵循以下一些原则：

您不能在 CI 中运行全负载（或浸泡或容量）测试，这是不切实际的。 结果是主观的，需要人工解释，运行测试需要时间。但是您可以运行一组更简单、更精简的测试来测量请求的响应时间，然后您可以评估这些响应时间：

• 针对 NFR 或预期范围 - 即。应少于 1 秒。
• 与之前的结果相反 - 即。与上次构建的偏差不应超过 10%。

您还可以运行自动加载/性能。测试 - 全量 - 在构建过程之外。 '半 CI'。 所以也许你可以自动化一个测试，让它在一夜之间运行，然后在早上检查结果？

迭代。 只需开始这样做并获得结果并微调测试以及随着时间的推移如何解释它们。保持简单并专注于看起来有用的领域。不要大张旗鼓地启动，保持安静，直到你对过程有信心，然后开始失败构建并告诉人们 - 最初，你可能会得到很多误报。

检测您的结果 做这个。很多。 CI 就是尽早失败，所以如果你把它作为你的最终目标，那么实现它的最好方法就是尽早并经常运行测试，但这样做的问题是你有被数据淹没的风险。因此，一种处理数据并呈现相关信息的有效方法会大有帮助。

您无法将整个过程自动化到红旗绿旗 - 但您应该尽量走这条路。

最后，主角 Perf 给出了a very good talk。涵盖此主题的 Google 测试人员。现在有点老了，但原则仍然存在。另外，几周后我会去meetup，英国媒体公司 Channel4 将在那里谈论他们是如何处理这个问题的——也许你可以索要一些幻灯片。

Answer 2

> 你不能在 CI 中运行满载（或浸泡或容量）测试，这是不切实际的。

在本周美国的TISQA conference 之后，我更倾向于说我们应该自信地通过 CI 自动化实现越来越多的完整、复杂的负载测试。

您甚至可以考虑在更大的负载测试实验室中运行一个单独的 CI 实例，并配置更真实的基础架构以支持有意义的测试结果。负载测试过程本身与单独的软件开发过程（设计、构造、部署、执行、分析、重复）没有什么不同。现在，大多数性能工具都支持与 CI 解决方案更优雅、更强大的集成，包括 SOASTA、LoadRunner/PC、JMeter、Neotys、Blazemeter、Flood.io。

但需要注意以下三点 - 类似于 Oliver 的 cmets： - 性能结果还有很多细微差别......不仅仅是明确的通过或失败 - 不要忘记脚本维护以与应用程序更改保持同步 - 将负载测试实验室与生产同步/扩展也可能是自动化的

如果您愿意，请查看我自己的 TISQA 演示文稿here 中的一些幻灯片。这可能是如何在整个生命周期中使用 CI + Performance 的开始。例如，为什么不让 CI 实例在 PROD 中更改时“监视配置”并将这些更改同步回您的负载测试环境？

Answer 3

JMeter 和 Selenium 都不是 CI 工具。 JMeter 是性能测试工具，Selenium 是自动化功能测试工具。因此，要将性能测试集成到构建过程中，您可以将 JMeter 与任何 CI 服务器一起使用：Jenkins、Bamdoo 等。

AFAIK，现在有两种使用 JMeter 和 Jenkins 的常见解决方案：

1. 使用 Jenkins/Hudson 和 JMeter 插件，它允许在完成构建过程后开始性能测试任务。在这种情况下，您需要配置适当数量的负载生成器并在其上配置 JMeter。

2. 另一种方式 - 使用 JMeter testing cloud。该服务提供Jenkins plugin，允许在构建应用程序后启动远程测试。在这种情况下，您无需关心配置测试服务器。

附：当我为 Blazemeter 工作时，我想提供客观的信息。希望对您有所帮助。

Answer 4

在您提出的问题中 - 硒是一种选择吗？

如果您使用内部计算机网格或公共云从 CI 运行，那么您应该考虑使用 Selenium WebDriver 和 Headless 浏览器驱动程序进行性能测试。

在小型 Amazon VM (ami) 上，我使用这种方法模拟了大约 25 个虚拟用户。因此，如果您的需求大约为 500 个 VU，那么我会对此进行调查，因为这样做的好处包括：-

由于无头浏览器会自动处理 URL 重写等，因此不再需要“关联”。

您的功能测试被重新用作性能测试，因此成为专家的一种工具，无需返工，只需重新调整用途。

Answer 5

您并不是唯一一个将性能测试与持续集成相结合的人。通常，非功能性测试过去常常被许多组织忽略或留到软件交付过程的最后阶段。我可以看到态度的积极变化以及对 CI/CD 中非功能性需求自动验证的兴趣。这在不同程度上包括性能、可访问性和安全性。您提到使用 Selenium 进行性能测试。我知道有些人（试图）这样做，甚至看到这样的尝试之一是多么不成功。我完全理解人们为什么考虑这样做，尽管我建议远离这个。除非你有充分的理由反其道而行之。一般来说，实现起来比人们想象的要难。 Selenium 是一个很好的工具，可以包含在 CI 中用于 GUI 测试，但它在性能测试中的结合有些麻烦。

现在有一个新工具可以帮助您将 JMeter 与您选择的 CI 服务器集成，并为 TeamCity 和 Jenkins 提供一些专用功能：

https://github.com/automatictester/lightning

欢迎提出功能请求。

Answer 6

如果性能是您的应用程序的重要组成部分，并且您从一开始就一直关心（或想要关心），我的目标是将其作为集成和部署管道的一部分 - 所以是的。

.NET 世界（及其他）中有许多工具可帮助您提供这种体验并在您最喜欢的 CI/CD 软件中无缝设置，例如：

• k6.io（https://k6.io/ - 以前称为 LoadImpact） - 允许您在环境之外执行性能检查，并将结果报告回管道。易于配置和集成，非常适合压力测试、负载测试等更“聪明”的测试场景。
• sitespeed.io (https://www.sitespeed.io/) - 我的第二个最爱，非常有趣且易于配置的工具，用于跟踪 FE 性能和测试（例如使用 Selenium 完成）
• Locust (https://locust.io/) - 用于在您自己的环境中进行负载测试。使用 ARM 模板在 Azure 上创建您自己的服务器“场”的绝佳存储库：https://github.com/ORBA/azure-locust
• dynatrace (https://www.dynatrace.com/) - 完全合格的 APM = 具有大量功能和可能性的应用程序性能监控/管理工具
• Roslyn Analyser (FxCopAnalyzers)、StyleCopAnalyzers、EditorConfig 和其他方法可以在代码被推送到构建和部署管道之前检测代码中的常见（也与性能相关！）问题
• 灯塔报告 - 也可以作为最常见问题的“指针”执行，并包含在 PR cmets 中，例如或过程中的通知（有很多 Github Actions 或 DevOps 包在做这件事）

所以，是的 - 以上所有内容以及更多内容都可以作为一个步骤放置在您的管道上。在我们的设置中，我们目前在 Staging 和 UAT 环境之间有一个完整的阶段，我们在其中进行审计：静态代码分析、性能测试 (FE & BE)、安全扫描和渗透测试 (OWASP ZAP) 等等。如果测试不符合我们的阈值或期望——我们显然不想引入不必要的降级——我们会在这里停下来，在到达 UAT 和生产之前返回重构并修复问题。希望它能帮助你，也许还有其他人。

---

我还在我最近的演讲（下面的幻灯片）中收集了我的一些发现，并将其转化为围绕该主题的系列博客，其中第一个已经发布：

1. 我关于“现代 Web 性能测试”演讲的幻灯片：https://slides.com/zajkowskimarcin/modern-web-performance-testing/
2. 该系列的第一篇关于同一主题的博客：https://wearecogworks.com/blog/the-importance-of-modern-web-performance-testing-part-1