我们已经有了一个持续的集成过程，可以构建，运行单元测试，进行静态代码分析并生成文档。但是，我们希望将其扩展到包括自动性能测试。在这种情况下，我们正在开发.NET Web应用程序。
我们已经使用JMeter（在CI流程之外）进行了一些性能测试，但是我不知道这是否是包含在CI流程中的最佳工具？硒是一种选择吗？ WAPT Pro？
我们应该在哪个级别上测试性能？我们应该有一套“性能单元测试”吗？我们是否应该在类似生产的环境中运行JMeter（或类似的工具），并且如果任何请求花费的时间超过1秒而失败？这样的东西差异不会太大吗？
所以，你们是否将自动性能测试作为CI的一部分？您要测试什么，并使用哪些工具？您的经历如何？
首先，JMeter是包含在CI中的好选择，因为它可以从命令行运行，并且可以在执行此操作时传入变量。我会推荐此任务。
尽管一般来说，集成Perf。对CI进行测试非常困难。您已经列出了这样做的许多原因，因此您已经了解了其中的局限性，因此已经处于中间位置。就是这样：可能有Perf。在CI中进行测试，但仅在有限的范围内进行。
我认为一种好的方法遵循其中一些原则：
您无法在CI中运行满载（或浸泡或容量）测试，这不切实际。结果是主观的，需要人为解释，并且需要时间来运行测试。但是您可以运行一个更简单的简化测试集来衡量请求的响应时间，然后可以评估这些响应时间：
您还可以运行自动加载/性能。在构建过程之外进行全面测试。 “半CI”。因此，也许您可以使测试自动化以进行整夜运行，然后在早上检查结果？
重复。只需开始进行操作并获取结果，然后微调测试以及如何随着时间的推移对其进行解释。保持简单，并专注于似乎有用的领域。不要大张旗鼓地发声，保持安静，直到您对过程充满信心，然后开始使构建失败并告诉人们-最初，您可能会得到很多错误的负面评价。
显示您的结果做这个。很多。 CI就是要尽早失败，因此，如果您将其作为最终目标，那么实现它的最佳方法就是尽早且经常进行测试，但是这样做的问题是您有被数据埋藏的风险。因此，一种有效的数据整理方法和呈现相关信息的方法将大有帮助。
您无法将整个过程自动化到红旗绿旗-但您应尝试尽可能走远。
最后，领队Perf给了a very good talk。 Google的测试人员，涵盖了该主题。现在有点老了，但原则仍然存在。另外，在几周后，我将转到meetup，英国媒体公司Channel4将在此讨论他们如何实现这一目标-也许您可以索要一些幻灯片。
>您无法在CI中运行满负荷（或浸泡或容量）测试，这不切实际。
[本周在美国TISQA conference之后，我更倾向于说我们应该自信地通过CI自动化使越来越多的完整，复杂的负载测试自动化。
您甚至可以考虑在较大的负载测试实验室中运行一个单独的CI实例，并为其配置更实际的基础架构以支持有意义的测试结果。负载测试过程本身与单独的软件开发过程（设计，构造，部署，执行，分析，重复）并无不同。现在，每个性能工具中的大多数都支持与CI解决方案更优雅，更强大的集成，包括SOASTA，LoadRunner / PC，JMeter，Neoyty，Blazemeter，Flood.io。
但是这里需要注意三件事-与奥利弗的评论类似：-性能结果还有很多细微差别...不仅是通过或失败-不要忘记脚本维护以与应用程序更改保持同步-您的负载测试实验室与生产的同步/扩展也可能是自动化的
[如果您愿意，请阅读我自己的TISQA演示文稿here中的一些幻灯片。这可能是如何在整个生命周期中使用CI + Performance的开始。例如，为什么没有一个CI实例仅在PROD中进行更改时“监视配置”并将这些更改同步回负载测试环境？
JMeter和Selenium都不是用于CI的工具。 JMeter是性能测试工具，Selenium是用于自动化功能测试的工具。因此，要将性能测试集成到构建过程中，可以将JMeter与以下任何CI服务器一起使用：Jenkins，Bamdoo等。
[AFAIK，现在有两种将JMeter与Jenkins结合使用的常见解决方案：
将Jenkins / Hudson与JMeter插件一起使用，可以在完成构建过程后开始性能测试任务。在这种情况下，需要配置适当数量的Load Generator，并在其上配置了JMeter。
另一种方法-使用JMeter testing cloud。该服务提供Jenkins plugin，可在构建应用程序后启动远程测试。在这种情况下，您无需关心配置测试服务器。
P.S。在为Blazemeter工作时，我想提供客观的信息。希望对您有所帮助。
您问的问题-硒是否可以选择？
如果从CI使用计算机的内部网格或公共云运行，则应考虑使用Selenium WebDriver和Headless浏览器驱动程序进行性能测试。
在小型Amazon VM（ami）上，使用这种方法模拟了大约25个虚拟用户。因此，如果您的需求约为500 VU，那么我将对此进行调查，因为其好处包括：-
不再需要URL重写等“关联”，因为无头浏览器会自动处理此问题。
您的功能测试被重新指定为性能测试，因此一个工具可以成为专家，并且无需重新设计就可以重新使用。
您不是唯一考虑将性能测试与持续集成相结合的人。通常，很多功能都将非功能性测试忽略或留给软件交付过程的最后阶段。我可以看到态度上的积极变化，并且对自动验证CI / CD中的非功能性需求越来越感兴趣。这在不同程度上包括性能，可访问性和安全性。您已经提到使用Selenium进行性能测试。我知道有些人（试图这样做），甚至看到这种尝试之一是多么的不成功。我完全理解为什么人们会考虑这样做，尽管我建议您不要这样做。除非您有充分的理由相反。总的来说，实现这一目标比想象的要难。 Selenium是包含在CI中以进行GUI测试的好工具，但是将其包含在性能测试中有些麻烦。
现在有一个新工具，可以帮助您将JMeter与您选择的CI服务器集成，并具有TeamCity和Jenkins的一些专用功能：
https://github.com/automatictester/lightning
欢迎提供功能要求。
如果性能是应用程序的重要组成部分，并且您从一开始就一直关心（或想要关心），那么我希望将其作为集成和部署管道的一部分-是的。
。NET世界（及以后）中有很多工具可以帮助您提供这种体验，并在您喜欢的CI / CD软件中进行无缝设置，例如：
所以，是的-以上所有内容以及更多内容都可以作为您的管道中的步骤放置。在我们的设置中，我们目前在过渡和UAT环境之间进行审核，整个阶段包括：静态代码分析，性能测试（FE＆BE），安全扫描和渗透测试（OWASP ZAP）等。如果测试与我们的阈值或期望不符-我们显然不想引入不必要的降级-我们会停在这里，然后在到达UAT和生产之前返回重构并解决问题。希望它能对您甚至其他人有所帮助。
[我还在最近的演讲中收集了一些发现（下面的幻灯片），并将其转换为围绕该主题的一系列博客，其中第一个已经发布：