我们已经有一个持续的一体化进程看我们构建，运行单元测试，做静态代码分析和生成文档。 然而，我们想扩展为包括自动性能测试。 在这种情况下，我们正在研究一个.NET Web应用程序。
我们已经做了用JMeter一些性能测试（测试CI过程之外），但我不知道这是不是在CI过程，包括最好的工具？ 硒是一种选择？ WAPT Pro的？
在该水平应我们测试性能？ 我们应该有一组“性能单元测试”？ 我们应该在生产环境中运行JMeter的（或类似的东西），如果任何请求采取>1秒失败？ 会不会像这样有太高的差异？
所以，你们怎么还包括自动性能测试作为您的CI的一部分？ 你怎么测试，并且你使用哪些工具？ 什么你的经验了什么样的？
首先，JMeter是包含在CI一个不错的选择，因为它可以在命令行中运行，您可以在变量传递，当你做到这一点。 我会推荐它完成这个任务。
虽然在一般，整合逆足。 测试导入CI是困难的。 你已经列出许多原因，这是因为你了解限制你已经走了一半。 这就是擦：这是可能有逆足。 测试在CI但仅在有限的程度。
我认为一个好的做法是遵循一些原则：
您不能运行满负荷（或浸泡或容量）的CI测试，这是不实际的。 结果是主观的，需要人的解释，需要时间来运行测试。 但是你可以运行简单，减少一套衡量请求响应时间测试，然后就可以评估这些响应时间之一：
您还可以运行自动负载/ PERF。 测试-在最大音量-构建过程之外。 '半CI'。 因此，也许你可以自动化测试在夜间运行，然后检查在上午的结果？
重复。 刚开始做这件事，并取得成果，并微调测试以及如何解释它们随着时间的推移。 保持简单，并侧重于表面上是有用的区域。 不要用大张旗鼓推出，保持安静，直到你与进程的信心，然后启动失败构建和讲述它的人 - 首先，你可能会得到大量的假阴性。
仪器的结果执行此操作。 很多。 CI是所有关于早期的失败，所以如果你把它看作你最终的目标则最好的方式来实现它是早期经常运行测试，但这个问题是，你就有可能得到埋在数据。 因此，一个有效的方法来紧缩的数据，并提出相关的信息帮助很大。
你不能自动完成整个流程下来到红旗绿旗 - 但你应该尝试尽可能沿着这条道路成为可能。
最后，还有一个很好的谈话由铅逆足给出。 测试仪在谷歌是讲述了这个问题。 现在是有点老，但原则仍然站立。 此外，在几个星期我要去参加一个聚会 ，其中通道4，英国媒体公司，将谈论他们是如何接近这一点-也许你可以问一些幻灯片。
>您不能运行满负荷（或浸泡或容量）的CI测试，这是不实际的。
后TISQA会议本周在美国这里，我更倾向于说，我们应该理直气壮地与自动化自动化CI完整，复杂的负载测试的越来越多。
你甚至可以考虑有一个单独的CI实例在更大的负载测试实验室的运行，具有更逼真的基础设施配置为支持有意义的测试结果。 负载测试过程本身是没有什么不同的独立软件开发过程（设计，构建，部署，执行，分析，重复）。 几乎每个性能工具现在支持更多的优雅和强大的集成，以CI解决方案，包括SOASTA下，LoadRunner / PC，JMeter的，Neotys，Blazemeter，Flood.io。
但这里有三件事情需要提防的 - 类似奥利弗的评论： - 有很多更细微差别表现效果......不仅明确合格或不合格的 - 不要忘记维护脚本保持同步与应用程序的变化 - 同步/缩放你与生产负荷测试实验室也可能自动化
如果你想-回顾一些幻灯片从我自己TISQA呈现在这里 。 这可能是对如何在整个生命周期使用CI +性能开始。 比如，为什么不能有，只是“腕表配置”，因为它在PROD得到改变，并同步这些更改回你的负载测试环境的CI实例？
无论是JMeter的也不硒是CI工具。 JMeter是性能测试工具，硒是自动化的功能测试工具。 因此，已进行性能测试集成到构建过程中，你可以使用JMeter的任何CI服务器：詹金斯，Bamdoo等。
据我所知，在使用JMeter的詹金斯与时下的两种常见的解决方案：
使用詹金斯/哈德森JMeter的插件吧，这允许在完成构建过程后，启动性能测试任务。 在这种情况下，你需要有JMeter的负载生成器上配置的适当数量。
另一种方法-使用JMeter的测试云 。 该服务提供詹金斯的插件 ，它允许创建应用程序后启动远程测试。 在这种情况下，你不需要关心配置测试服务器。
PS虽然我工作Blazemeter，我想提供客观的信息。 希望，这是有帮助的。
在你的问题你问 - 硒是一种选择？
如果您是从CI利用计算机的一个内部网或公共云中运行，那么你应该使用硒的webdriver与无头浏览器驱动器考虑性能测试。
在小亚马逊VM（AMI）我得到使用这种方法模拟周围25个虚拟用户。 所以，如果你的需求是在500 VU的顺序，那么我会调查这为优势包括： -
没有更多的“相关”的URL重写等作为无头浏览器会自动处理此。
你的功能测试改变用途的性能测试，这样一个工具，成为专家，并没有返工只需重新目的。
你是不是在看与持续集成集成性能测试的唯一的人。 在一般情况下，非泛函测试中使用被忽略或离开受了不少ogranisations的软件交付过程的尽头。 我可以看到的态度和积极的变化，在CI / CD非功能性需求自动验证更多的利益。 这包括性能，可访问性和安全性，以不同的程度。 您已经使用Selenium进行性能测试提及。 我知道有些人（尝试）这样做，甚至看到了如何不成功的就是这样的尝试之一。 我完全理解为什么人们认为这样做，但我建议你远离这个了。 除非你有一个很好的理由做相反。 在一般情况下，这是很难实现比人们可能会想到。 硒是一种伟大的工具，在CI的GUI测试的目的包括，但其在性能测试结合是有点麻烦。
现在有一个新的工具，它可以帮助您与您所选择的CI服务器整合JMeter的，有一些专门的功能为TeamCity的詹金斯：
https://github.com/automatictester/lightning
功能要求的欢迎。
