持续性能测试：DevOps势在必行

David Buch于2018年4月03日发布 人们越来越认识到，性能测试必须是DevOps的组成部分。

有道理。 在发布周期结束前保持性能可让您回到瀑布式方法的时代。 随着更多更改的发生，隔离根本原因变得更加困难，任何修复都可能触发其他QA周期的连锁反应。 如果此时性能无法达到最高速度，则很可能会拖延整个发布计划。

考虑到这一点，使性能测试成为DevOps的一部分是什么？ 这里有一些提示，可以帮助您入门。

循序渐进

与任何测试一样，您的性能测试将在整个开发周期中随着时间的推移而发展。 在项目开始时，性能测试可能只限于您的API。 随着其他服务的开发和流程的正常运行，您可以将它们添加到测试范围中。

以连续方式对所有API或流进行负载测试可能是不切实际的目标，因为这些测试可能会花费很长时间并且会延迟您的管道。 经常使用的API和流程（例如登录）以及属于关键用户流程（例如完成购买）的API和流程应在每次签入时进行测试，而其他API和流程则应以较低的频率进行测试。

重新定义成功标准

没有单一的通过/失败规则，因为每个测试都有自己的成功标准。 随着项目的进展，应该调整性能成功目标，以反映应用程序的发展。 例如，添加到流程中的新活动可能需要更多的处理时间，而对其他功能的改进可能会加快处理速度-这些更改需要重新评估您的成功标准。

以成功的测试为基准

测试成功后，将结果另存为将来测试的基准。 您可以使用这些结果来重新定义您的成功标准，或者只是将它们添加为其他比较指标。

拿两种同类的东西作比较

不断更改测试环境可能会导致性能变化。 不考虑这种变化可能导致错误的结论。 例如，在安装新服务器后，以前的基准结果可能不再有用（这意味着该创建新的基准了）。

不要将负载生成与性能评估相混淆

运行负载测试时，您正在模拟数百或数千访问系统的用户的负载。 但是，您无法根据这些用户来衡量应用程序的响应时间。

为了正确测量结果，您需要两台机器：

同时测试，但要小心

并行运行多个测试可以节省时间并帮助您加快发布周期。 但是，并发运行的测试可能会相互影响，因此会使结果产生偏差。 在运行并发测试时，请确保您的测试没有依赖性-不仅使用单独的计算机和负载生成器，而且还要确保它们没有调用相同的API。

总结思想

将性能测试作为事后考虑可能会对DevOps的成功有害。 最终会减慢发布周期，甚至更糟-您最终可能会有一个低于标准的用户体验，不符合市场预期和业务要求。 如果您像对待连续开发过程的任何部分一样将负载测试集成到DevOps中，则不会很困难-经常进行测试，快速失败并反复进行，直到获得期望的结果。