持续集成中的性能测试？

Question

我们已经有一个持续的集成过程，可以构建，运行单元测试，进行静态代码分析并生成文档。但是，我们希望将其扩展到包括自动性能测试。在这种情况下，我们正在开发.NET
Web应用程序。

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

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

那么，你们是否将自动性能测试作为CI的一部分包含在内？您要测试什么，并使用哪些工具？您的经历如何？

Answer 1

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

总的来说，集成Perf。对CI进行测试非常困难。您已经列出了这样做的许多原因，因此您已经了解了其中的局限性，因此已经处于中间位置。就是这样：可能有Perf。在CI中进行测试，但仅在一定程度上进行。

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

您不能在CI中运行满负荷（或保持或容量）测试，这是不切实际的。
结果是主观的，需要人为解释，并且运行测试需要时间。但是您可以运行一个更简单的简化测试集来衡量请求的响应时间，然后可以评估以下响应时间：

• 在NFR或预期范围内-即。应该少于1秒。
• 反对以前的结果-即。偏差不应超过上一个版本的10％。

您还可以运行自动加载/性能。 在构建过程之外进行全面测试。“半CI”。 因此，也许您可​​以自动化测试以进行整夜运行，然后在早上检查结果？

重复。
只需开始进行操作并获取结果，然后对测试以及您对它们的解释方式进行微调即可。保持简单，并专注于似乎有用的领域。不要大张旗鼓地发声，保持安静直到您对过程有信心，然后开始使构建失败并告诉人们有关信息–最初，您可能会得到很多错误的负面评价。

检验结果
执行此操作。很多。CI就是要尽早失败，因此，如果您将其作为最终目标，那么实现此目标的最佳方法就是尽早且经常进行测试，但是这样做的问题是您有被数据埋藏的风险。因此，一种有效的数据整理方法和呈现相关信息的方法将大有帮助。

您无法将整个过程自动化到“红旗绿旗”，但您应该尝试尽可能走远。

最后，领军人物Perf发表了很好的演讲。Google的测试人员，涵盖了这个主题。现在有点老了，但原则仍然存在。另外，在接下来的几周内，我将参加一次聚会，英国媒体公司Channel4将讨论他们如何实现这一目标-
也许您可以要求一些幻灯片。