假设我的代码库具有尽可能高的单元测试覆盖率。(超过某个点,增加覆盖率并没有很好的投资回报率。)
接下来我要测试性能。对代码进行基准测试以确保新提交不会不必要地减慢速度。我对 Safari对提交减速的零容忍政策非常感兴趣。我不确定这种对速度的承诺水平对于大多数项目是否具有良好的投资回报率,但我至少希望收到速度倒退发生的警报,并能够对此做出判断。
环境是 Linux 上的 Python,对 BASH 脚本也适用的建议会让我非常高兴。(但 Python 是主要焦点。)
假设我的代码库具有尽可能高的单元测试覆盖率。(超过某个点,增加覆盖率并没有很好的投资回报率。)
接下来我要测试性能。对代码进行基准测试以确保新提交不会不必要地减慢速度。我对 Safari对提交减速的零容忍政策非常感兴趣。我不确定这种对速度的承诺水平对于大多数项目是否具有良好的投资回报率,但我至少希望收到速度倒退发生的警报,并能够对此做出判断。
环境是 Linux 上的 Python,对 BASH 脚本也适用的建议会让我非常高兴。(但 Python 是主要焦点。)
如果可能,您将希望在系统级别进行性能测试 - 在上下文中测试整个应用程序,使用尽可能接近生产使用的数据和行为。
这并不容易,而且更难实现自动化并获得一致的结果。
此外,您不能使用虚拟机进行性能测试(除非您的生产环境在虚拟机中运行,即使这样,您也需要在没有其他任何东西的主机上运行虚拟机)。
当您说进行性能单元测试时,这可能很有价值,但前提是它用于诊断确实存在于系统级别(不仅仅是开发人员头脑中)的问题。
此外,单元测试中的单元性能有时无法反映它们在上下文中的性能,因此它可能根本没有用。
虽然我同意在系统级别测试性能最终更相关,但如果您想为 Python 进行 UnitTest 样式的负载测试,FunkLoad http://funkload.nuxeo.org/正是这样做的。
当您尝试加快代码库中的特定操作时,微基准测试就占有一席之地。完成后续性能单元测试是一种有用的方法,可以确保您刚刚优化的此操作不会在未来提交时无意中降低性能。
MarkR 是对的……进行真实世界的性能测试是关键,并且在单元测试中可能有些躲闪。话虽如此,看看cProfile
标准库中的模块。它至少有助于让您从提交到提交的过程中相对了解事情的运行速度,并且您可以在单元测试中运行它,当然您会在包括开销在内的细节中获得结果单元测试框架本身。
但是,总而言之,如果您的目标是零容忍,那么您将需要比这更强大的东西......单元测试中的 cProfile 根本不会削减它,并且可能会产生误导。
当我进行性能测试时,我通常有一套数据输入的测试套件,并测量程序处理每个数据需要多长时间。
您可以每天或每周记录性能,但我发现在实现所有功能之前担心性能并不是特别有用。
如果性能太差,那么我打破cProfile,使用相同的数据输入运行它,并尝试查看瓶颈在哪里。