持续集成的性能测试？

Question

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

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

我们应该在哪个级别测试性能？我们应该有一套"性能单元测试"吗？我们应该在类似生产的环境中运行JMeter(或类似的东西),如果任何请求需要> 1秒,则会失败吗？这样的东西不会有太高的变化吗？

那么,你们是否将自动性能测试作为CI的一部分？你测试什么,你使用哪些工具？你的经历是什么样的？

Answer 1

首先,JMeter是包含在CI中的一个很好的选择,因为它可以从命令行运行,并且您可以在执行此操作时传入变量.我会推荐它来完成这项任务.

一般来说,整合Perf.测试CI很困难.你已经列出了许多原因,为什么你已经在那里,因为你了解其局限性.这就是问题:可能有Perf.CI中的测试但仅在有限的范围内.

我认为一个好的方法遵循其中一些原则:

您无法在CI中运行满载(或浸泡或容量)测试,这是不切实际的. 结果是主观的,需要人工解释,运行测试需要时间.但是,您可以运行一组更简单的测量来测量请求的响应时间,然后您可以评估这些响应时间:

您还可以运行自动加载/性能.测试 - 完整卷 - 在构建过程之外.'半CI'. 那么也许你可以让测试自动运行一整夜,然后在早上查看结果？

重复. 只需开始做它并获得结果并微调测试以及如何解释它们.保持简单并专注于看似有用的区域.不要大肆宣传,保持安静,直到你对这个过程有信心,然后开始失败的构建并告诉人们 - 最初,你可能会得到很多假阴性.

检测结果 执行此操作.很多.CI是关于早期失败的,所以如果你在最终目标时采用它,那么实现它的最好方法是尽早并且经常运行测试,但问题是你有被埋在数据中的风险.因此,有效的方法来处理数据并显示相关信息有很大帮助.

你不能将整个过程自动化到红旗绿旗 - 但你应该尝试尽可能远的路径.

最后,领导Perf 进行了非常好的演讲.Google的测试人员,涵盖了这个主题.它现在有点老了,但原则仍然存在.另外,几个星期后,我要去参加一个会议,英国媒体公司Channel4将谈论他们如何接近这个 - 也许你可以要求一些幻灯片.