每当我遇到错误时，我的第一件工作就是编写一个失败的测试来表明错误存在。当添加到我的自动化测试套件中时，此测试用于确保错误不再出现。
但是，由于性能错误，我无法做到这一点。任何关于性能的断言都只会在我自己的机器上是正确的，并且不适合签入自动化测试套件。这需要我常用的防止回归的工具。
您如何防止自己代码中的性能回归？
一个理想的答案：
- 与语言无关。
- 自动防止回归。
- 提供通常的开发周期：签出、补丁、回归测试、签入。
- 适用于开发人员不一定知道“通常”性能的开源项目。
问问题
217 次
2 回答
1
我对这类问题使用了两种不同的方法。
正如@Fresh 建议的那样，在现实的、可能是实时的环境中监控性能是一个不错的选择。这避免了您可能在开发环境中看到的误报和误报结果。这可能必须在提交后发生，但它也是我能想到的唯一工具来尝试捕获系统组件之间的交互，这些交互可能永远不会在本地或与不同的数据集显示为性能问题。
来自开发环境的一些可以预先检查运行的指标仍然提供有关可能的性能问题的有用提示。特别是我喜欢让我的测试套件报告每个单元/集成/验收类别中最慢的 N 个测试。虽然这些结果中的新出现或测试运行时间的增加远非一个确定的指标，但这很好地暗示了性能问题。这也有助于降低测试套件的运行时间，这也很有价值。
于 2013-11-04T22:18:20.387 回答
1
好问题，棘手的问题。
正如您在问题中指出的那样，问题的症结在于环境的差异，即您的开发箱和测试/QA 环境之间的差异。
为了减轻性能下降，您可以设置持续部署环境，例如自动部署到测试环境，您还应该部署到操作参数尽可能与最终生产环境相似的 QA 环境（例如类似的硬件，类似大小的数据集等）。这通常称为“一次构建，多次部署”
有了这个持续部署系统，您还应该包括验收测试以检查性能限制，例如系统应该在 x 毫秒/秒内响应请求，这是一种常见的非功能性要求 (NFR)。当您的代码被签入时，它会自动针对这些环境进行测试，以便您可以快速查看何时出现性能问题。
为了帮助调试这些性能问题，您最好在运行测试时记录性能指标。然后，这些测试可能会为您提供一个很好的指标，说明问题可能出现在哪里，例如，您将能够看到特定方法花费了大部分时间来完成。
这种设置在实践中很难建立，但它肯定会让您“快速失败”并快速检测性能问题。
于 2013-10-31T22:02:55.640 回答