我们已经有一个持续集成过程，我们在其中构建、运行单元测试、进行静态代码分析和生成文档。但是，我们希望将其扩展为包括自动性能测试。在本例中，我们正在开发一个 .NET Web 应用程序。
我们已经使用 JMeter（在 CI 流程之外）进行了一些性能测试，但我不知道这是否是包含在 CI 流程中的最佳工具？硒是一种选择吗？WAPT 专业版？
我们应该在哪些级别上测试性能？我们应该有一套“性能单元测试”吗？我们是否应该在类似生产的环境中运行 JMeter（或类似的东西）并在任何请求花费 > 1 秒时失败？像这样的东西不会有太高的方差吗？
那么，你们是否将自动性能测试作为 CI 的一部分？你测试什么，你使用哪些工具？你的经历是怎样的？
首先，JMeter 是包含在 CI 中的一个不错的选择，因为它可以从命令行运行，并且您可以在执行此操作时传入变量。我会推荐它来完成这项任务。
但总的来说，集成 Perf。测试 CI 很困难。您已经列出了许多原因，所以您已经成功了一半，因为您了解这些限制。这就是问题所在：Perf 是可能的。CI 中的测试，但仅限于有限的范围。
我认为一个好的方法遵循以下一些原则：
您不能在 CI 中运行全负载（或浸泡或容量）测试，这是不切实际的。 结果是主观的，需要人工解释，运行测试需要时间。但是您可以运行一组更简单、精简的测试来测量请求的响应时间，然后您可以评估这些响应时间：
您还可以运行自动加载/性能。测试 - 全量 - 在构建过程之外。'半CI'。 所以也许你可以自动化一个测试，让它在一夜之间运行，然后在早上检查结果？
迭代。 只需开始这样做并获得结果并微调测试以及随着时间的推移如何解释它们。保持简单并专注于看起来有用的领域。不要大张旗鼓地启动，保持安静，直到你对过程有信心，然后开始失败构建并告诉人们 - 最初，你可能会得到很多假阴性。
检测你的结果 这样做。很多。CI 就是尽早失败，所以如果你把它作为你的最终目标，那么实现它的最好方法就是尽早并经常运行测试，但这样做的问题是你有可能被数据埋没。因此，一种处理数据并呈现相关信息的有效方法会大有帮助。
你不能将整个过程自动化到红旗绿旗——但你应该尽可能地沿着这条路走下去。
最后，领队Perf做了一个非常好的演讲。涵盖此主题的 Google 测试人员。现在有点老了，但原则仍然存在。另外，几周后我将参加一个聚会，英国媒体公司 Channel4 将讨论他们是如何处理这个问题的——也许你可以索要一些幻灯片。
> 您不能在 CI 中运行全负载（或浸泡或容量）测试，这是不切实际的。
本周在美国举行的TISQA 会议之后，我更倾向于说我们应该自信地通过 CI 自动化来自动化越来越多的完整、复杂的负载测试。
您甚至可以考虑在更大的负载测试实验室中运行一个单独的 CI 实例，配置更真实的基础架构以支持有意义的测试结果。负载测试过程本身与单独的软件开发过程（设计、构造、部署、执行、分析、重复）没有什么不同。现在，大多数性能工具都支持与 CI 解决方案更优雅、更强大的集成，包括 SOASTA、LoadRunner/PC、JMeter、Neotys、Blazemeter、Flood.io。
但这里有三件事需要注意 - 类似于 Oliver 的评论： - 性能结果还有很多细微差别......不仅仅是通过或失败 - 不要忘记脚本维护以与应用程序更改保持同步 - 同步/缩放您的生产负载测试实验室也可能是自动化的
如果您愿意，请在此处查看我自己的 TISQA 演示文稿中的一些幻灯片。这可能是如何在整个生命周期中使用 CI + Performance 的开始。例如，为什么不让 CI 实例在 PROD 中更改时“监视配置”并将这些更改同步回负载测试环境？
Neither JMeter nor Selenium are tools for CI. JMeter is performance testing tool, Selenium is tool for automated functional testing. So, to have performance testing integrated into build process, you can use JMeter with any of CI servers:Jenkins, Bamdoo, etc.
AFAIK, there are two common solution of using JMeter with Jenkins nowadays:
Use Jenkins/Hudson with JMeter plugin for it, which allow to start performance testing task after finishing build process. In this case you need to have appropriate number of load generator with JMeter configured on it.
Another way - using JMeter testing cloud. This service provides Jenkins plugin, which allows to start remote test after building application. In this case you don't need to care about configuring test servers.
P.S. While I'm working for Blazemeter, I wanted to provide objective information. Hope, it's helpful.
在您问的问题中-硒是一种选择吗？
如果您使用内部计算机网格或公共云从 CI 运行，那么您应该考虑使用 Selenium WebDriver 和 Headless 浏览器驱动程序进行性能测试。
在一个小型 Amazon VM (ami) 上，我使用这种方法模拟了大约 25 个虚拟用户。因此，如果您的需求大约为 500 VU，那么我会对此进行调查，因为其好处包括：-
由于无头浏览器会自动处理 URL 重写等，因此不再需要“关联”。
您的功能测试被重新用作性能测试，因此成为专家的一个工具，无需返工，只需重新调整用途。
您不是唯一一个将性能测试与持续集成集成的人。通常，非功能性测试过去常常被许多组织忽略或留到软件交付过程的最后阶段。我可以看到态度的积极变化以及对 CI/CD 中非功能性需求自动验证的兴趣。这在不同程度上包括性能、可访问性和安全性。您提到使用 Selenium 进行性能测试。我知道有些人（尝试）这样做，甚至看到其中一种尝试是多么不成功。我完全理解人们为什么考虑这样做，尽管我建议远离这个。除非你有充分的理由反其道而行之。一般来说，实现起来比人们想象的要难。
现在有一个新工具，可以帮助您将 JMeter 与您选择的 CI 服务器集成，并为 TeamCity 和 Jenkins 提供一些专用功能：
https://github.com/automatictester/lightning
欢迎提出功能要求。
如果性能是您的应用程序的重要组成部分，并且您从一开始就一直关心（或想要关心），我的目标是将其作为集成和部署管道的一部分 - 所以是的。
.NET 世界（及其他）中有许多工具可以帮助您提供这种体验并在您最喜欢的 CI/CD 软件中无缝设置，例如：
所以，是的 - 以上所有内容以及更多内容都可以作为您管道上的一个步骤。在我们的设置中，我们目前在 Staging 和 UAT 环境之间有一个完整的阶段，我们在其中进行审计：静态代码分析、性能测试 (FE & BE)、安全扫描和渗透测试 (OWASP ZAP) 等等。如果测试不符合我们的阈值或期望——我们显然不想引入不必要的降级——我们会在这里停下来，在到达 UAT 和生产之前返回重构并修复问题。希望它能帮助你，也许还有其他人。
我还在我最近的演讲（下面的幻灯片）中收集了一些我的发现，并将其转换为围绕该主题的系列博客，其中第一个已经发布：