首先，JMeter是包含在CI中的不错选择，因为它可以从命令行运行，并且可以在执行此操作时传入变量。我会推荐此任务。
总的来说，集成Perf。对CI进行测试非常困难。您已经列出了这样做的许多原因，因此您已经了解了其中的局限性，因此已经处于中间位置。就是这样：可能有Perf。在CI中进行测试，但仅在一定程度上进行。
我认为一种好的方法遵循以下一些原则：
您不能在CI中运行满负荷（或保持或容量）测试，这是不切实际的。
结果是主观的，需要人为解释，并且运行测试需要时间。但是您可以运行一个更简单的简化测试集来衡量请求的响应时间，然后可以评估以下响应时间：
- 在NFR或预期范围内-即。应该少于1秒。
- 反对以前的结果-即。偏差不应超过上一个版本的10％。
您还可以运行自动加载/性能。 在构建过程之外进行全面测试。“半CI”。 因此，也许您可以自动化测试以进行整夜运行，然后在早上检查结果？
重复。
只需开始进行操作并获取结果，然后对测试以及您对它们的解释方式进行微调即可。保持简单，并专注于似乎有用的领域。不要大张旗鼓地发声，保持安静直到您对过程有信心，然后开始使构建失败并告诉人们有关信息–最初，您可能会得到很多错误的负面评价。
检验结果
执行此操作。很多。CI就是要尽早失败，因此，如果您将其作为最终目标，那么实现此目标的最佳方法就是尽早且经常进行测试，但是这样做的问题是您有被数据埋藏的风险。因此，一种有效的数据整理方法和呈现相关信息的方法将大有帮助。
您无法将整个过程自动化到“红旗绿旗”，但您应该尝试尽可能走远。
最后，领军人物Perf发表了很好的演讲。Google的测试人员，涵盖了这个主题。现在有点老了，但原则仍然存在。另外，在接下来的几周内，我将参加一次聚会，英国媒体公司Channel4将讨论他们如何实现这一目标-
也许您可以要求一些幻灯片。
