做了这么多年性能测试，这7个高效工作的技巧你还不知道？

lsekfe

　摘要
　　通过严格的实践来增强系统的性能和可恢复性，并对这些方面进行持续的测试，是预先找到问题的好方法。与测试的其他方面一样，性能实践的质量要比数量重要得多，这里有七个简单的技巧可以帮助你在测试系统的性能和可恢复性时更高效。
　　软件的性能和可恢复性是用户体验的关键组成部分，但是随着软件行业对开发运维一体化（DevOps）模式的接纳，它开始在性能和可恢复性方面表现出不足。
　　在软件完全失败之前，性能问题常常被忽略。
　　然而，我们都知道，性能不会突然下降。由于软件是通过迭代发布的，每次添加更多代码时都要付出性能成本，添加的逻辑循环也可能导致故障，从而影响到整个系统的稳定性。
　　严重的性能或软件可用性问题几乎不可能是单个代码的更改造成的。相反，它通常是问题一点点积累而导致的。
　　通过严格的实践来增强性能和可恢复性，并对这些方面进行持续测试，都是预先找到问题的好方法。与测试的其他方面一样，性能实践的质量比正在执行的测试数量要重要得多。
　　下面有七个简单的技巧可以帮助你在测试系统的性能和可恢复性时更高效。

　　使用基准每次只更改一个变量
　　在性能和可恢复性工程中，基准是为了把问题标准化，作为定量或对比的基础测试。我们定义了这样的测试，以便可以将它们相互比较。
　　为了进行比较，我们更改了一个元素，并根据另一个测试度量该更改的影响。
　　在我们持续集成过程中，对新版本的软件进行基准测试，以衡量代码变化如何影响软件的性能和可恢复性。
　　在其他一些基准测试中，我们希望测试软件在不同规格的硬件上的性能。由于我们还支持多种架构、平台、操作系统、数据库和文件系统，我们希望不仅能够定义如何获得最佳性能和可靠性，还希望能够将它们相互比较。
　　这些都是有效的基准实践，因为我们更改了一个元素并度量了该更改的影响。
　　然而，如果我们同时改变测试中的软件版本和测试的硬件，然后尝试比较结果，我们就无法确定变化是由于其中一种变化引起的，还是两者的结合导致的，通常情况下，这些组合元素的更改会产生与单独更改一个元素不同的效果。
　　在性能工程中，尽量进行同向比较，使用基准测试，并在要比较的测试的多个版本中一次只更改一个变量。

　　监控内存、cpu、磁盘和网络的使用情况
　　由于性能和可恢复性是一项科学工作，只有设法客观地解释我们所观察到的事件是可重现的，才能做到这一点。这意味着我们需要测量。
　　对于性能工程，我们不仅必须评估我们正在测试的软件，还必须评估我们正在测试的硬件。监控内存、CPU、磁盘和网络使用情况是我们分析的关键。我们还必须了解这些资源是如何分配的，因为它和我们的处理需求相关。
　　在信息科技发展的今天，我们总是需要点对点的传输数据，并对其进行转换。
　　在此过程中，我们添加了冗余；其中一些冗余是浪费或开销，而有些则是必要的，因为它允许我们确保数据的完整性和安全性。
　　性能工程的全部内容是消除开销和增加数据完整性。

　　每次测试至少运行三次
　　在比较测试结果之前，我们需要确保要比较的数字是可信的。
　　每次我们运行一个测试时，我们都希望，如果我们在相同的条件下，在不同的时间运行相同的测试，我们应该得到相同的结果和度量。
　　但是，当我们第一次运行测试时，在新的条件下，我们没有这种测试的历史来决定我们所得到的结果是否可重复。
　　请记住，在某个组件不同的以前的测试中，不能考虑结果的可重复性，只有多次执行相同的测试才能使我们对结果获得信心。
　　可以信任的结果是一个关键因素，所以我建议您不要考虑测试的结果来进行性能比较，除非您至少执行了该测试3次、5次甚至更多，对于向客户发布的版本或通用的可用性版本，还需要更多次的执行。

　　实现3%以下的结果差异
　　关于结果这个话题，我们必须证明，同样的测试是可重复的，在不同的时间执行也应该产生相同的结果。
　　这方面的一个关键指标是主度量的方差(也称为可变性)，方差是一种度量，它表示同一测试的最佳执行和最差执行的百分比差异。
　　让我们考虑一个[url=]性能测试[/url]，其中主要的度量是事务中的吞吐量度量。如果测试的执行吞吐量最差为每秒一百个事务，最佳执行吞吐量为每秒一百一十个事务，则我们的方差为10%：
　　(较大值-较低值)/较低值
　　(110 – 100) / 100 = 0.1
　　同样，对于可恢复性测试，主要的度量是以秒为单位的恢复时间，如果我们有一个最坏的恢复时间为5分钟，最好的恢复时间为4分钟，我们的方差将为25%。
　　方差是衡量我们的结果是否可信的关键指标。方差小于3%意味着我们的结果是可靠的。
　　3%到5%之间的差异意味着结果是可接受的和可重复的，但在测试中的测试、环境或软件的稳定性方面仍有改进的余地。
　　6%到10%之间的差异意味着我们不能重复我们的结果，应该积极研究为什么我们有如此高的差异，任何方差大于10%的测试根本都不能用它来衡量性能。

　　至少运行半个小时的负载测试
　　负载测试的目的往往是衡量一个系统的特定资源的能力。目标是得到系统在短时间内没有失败情况的最大负载力。为了使这些测试的度量是基于实际的，在我看来，所测量的性能必须至少持续30分钟。
　　考虑一下，您通过15分钟的负载测试所证明的唯一一件事是，系统可以处理15分钟的负载。此外，运行时间越短，受人为方差的影响就越大。
　　在性能工程中，我们还需要热身期，因为第一次执行，在第一次调用时总是比较慢。即使在热身系统中，测试的前几个事务也可能比较慢，并且在多次运行之间不一定相同--因此产生了人为的差异，在30分钟或更长时间的测试中，这些测试将不会显示，也不太可能导致差异。
　　如果负载测试持续时间小于30分钟，从性能工程的角度来看，其结果将没有多大意义，不包括任何热身期，测试应执行至少半小时。

　　证明你的负载结果至少可以持续两个小时
　　再次，我建议至少半个小时。正如在前一点中所解释的，您通过30分钟的负载测试所证明的唯一一件事是，系统可以承受30分钟的负载。
　　虽然30分钟足够检测大多数新的性能变化，但为了使这些测试是合理的，还必须能够证明它们可以在同一负载下至少运行两个小时。
　　由于空间不足，高峰负荷应该是可持续的，证明负载可以运行两个小时是一个很好的第一步。我建议把6小时、12小时和24小时作为里程碑，并在可能的情况下，证明你可以连续5天运行这些负载。
　　请注意，这些耐久负荷测试是为了证明负荷结果的可持续性。它们不需要针对每一个代码更改运行，而只是为了证明负载数的可持续性。
　　首先要证明两个小时是可持续的。任何少于两小时的性能测试和性能值都不应用于性能发布，也不应用于容量方面的参考。

　　确保你有良好的自动化能力
　　如果没有良好的自动化，您就不可能拥有成功的性能工程。您是否花了更多的时间来分析您的测试结果(良好的自动化)，还是执行测试并对现有的自动化(糟糕的自动化)进行更改？
　　如果您认为可以改进自动化实践，请从以下七个原则开始：
　　1.知道你为什么要自动化
　　2.了解自动化的步骤
　　3.不要只考虑容易实现或不容易实现
　　4.构建可以堆叠在一起的块
　　5.及早做自动化计划
　　6.将您的自动化场景化
　　7.从自动化中收集度量标准

　　设计你的测试以获得有意义的结果
　　解决软件性能和可恢复性的最有效方法是通过有效的测试。但是，重新考虑和组织测试并不十分复杂，遵循这七个简单的技巧会在早期发现很多性能问题——在它们成为真正的问题之前。