自动防止性能回归

时间:2013-10-31 17:44:55

标签: performance testing tdd performance-testing

每当我遇到错误时,我的第一项工作就是写一个失败的测试,证明错误存在。当添加到我的自动测试套件中时,此测试用于确保错误不再出现。

但是,由于性能错误,我无法做到这一点。任何性能断言只能在我自己的机器上正确,并且不适合签入自动化测试套件。这需要我通常的工具来防止退出我的包。

如何在自己的代码中阻止性能下降?

一个理想的答案:

  • 语言不可知。
  • 防止回归自动发送。
  • 提供通常的开发周期:checkout,patch,regression-test,checkin。
  • 适用于开源项目,开发人员不一定知道“通常”的表现。

2 个答案:

答案 0 :(得分:1)

好问题,难题。

正如您在问题中指出的那样,问题的关键在于环境的差异,即开发框与测试/ QA环境之间的差异。

为了降低性能回归,您可以设置一个持续的部署环境,例如:除了自动部署到测试环境之外,您还应该部署到QA环境,该环境具有与最终生产环境类似的操作参数(例如,类似的硬件,类似大小的数据集等)。这通常称为"Build once, Deploy many"

enter image description here

使用这个持续部署系统,您还应该包括验收测试以检查性能限制,例如:系统应在x毫秒/秒内响应请求,这是一种常见的非功能性要求(NFR)。当您的代码随后签入时,它会自动针对这些环境进行测试,以便您可以快速查看性能问题何时出现。

为了帮助调试这些性能问题,理想情况下还要在运行测试时记录性能指标。然后,这些测试可能会为您提供一个很好的指示,指出问题可能表现在哪里,例如:你将能够看到一种特定的方法花费了大部分时间来完成。

这种设置很难在实践中建立,但它肯定会让你“快速失败”并快速发现性能问题。

答案 1 :(得分:1)

我对这类问题采用了两种不同的方法。

  1. 由于@Fresh建议在现实的,可能是现场的环境中监控性能是一个不错的选择。这可以避免您在开发环境中看到的误报和误报结果。这可能必须在提交后发生,但它也是我能想到的唯一工具,试图捕获系统组件之间的交互,这些交互可能永远不会在本地或不同的数据集中显示为性能问题。

  2. 可以在签入前运行的开发环境中的某些指标仍然提供有关可能的性能问题的有用提示。特别是我喜欢让我的测试套件报告每个单元/集成/接受类别中最慢的N个测试。虽然远远没有确定的指标,但这些结果中的新外观或测试运行时间的增加是性能问题的良好暗示。这有助于保持测试套件的运行时间,这也是有价值的。