迭代和递归性能_迭代，自动化和连续性能

迭代和递归性能

我们的行业了解到，如果我们提供中间结果并重新审视功能要求，则可以避免延迟交付错误的系统。 我们了解到，如果我们定期执行单元和功能测试，我们将交付的bug更少。 尽管我们关注应用程序的性能，但在应用程序接近完成之前，我们很少进行性能测试。 我们应用于功能测试的迭代，自动化和连续性课程也可以应用于性能吗？

今天，我们可能会争辩说，应该以每小时，每天或每周为基础完成包含单元测试的构建。 我们可能会争论100％的覆盖率与50％的覆盖率。 我们可能会争论，讨论和思考该过程的具体细节。 但是，我们大家都同意，定期执行自动测试并完成单元测试是一种最佳做法。 但是，关于性能测试的论点往往仅限于此。

过早或及时

性能测试推迟到最后有几个原因。 其中许多原因与为什么我们很少（如果有的话）使应用程序测试自动化的原因非常相似。 设置自动构建需要花费时间，精力和精力。 要向企业证明作出此承诺符合他们的最大利益，这很困难。 毕竟，我们是程序员，所以我们希望开发功能而不花时间进行测试。 测试是针对测试人员的。 编写单元测试需要花费时间，时间，而这些时间最好花在开发功能上，等等。

但是，我们能够将其潜入我们的开发过程中，因为将测试代码组织到单元测试中只会使我们已经在做的事情正式化。 因此，支持这种形式化所需的增量投资并没有那么大。 一旦企业开始看到收益，情况只会变得更好。 人们可能会认为，将其扩展到性能测试是自然而然的事情，但事实并非如此。 支持性能测试所需的投资被认为要大得多，而潜在收益却要小得多。 毕竟，我们无法在开发中的系统上进行性能测试，因为没有要测试的东西。 毕竟，性能不仅仅是更多还是更好的硬件的问题？

出于性能测试的考虑，将投资视为更大的原因有两个。 与单元测试不同，性能测试不是开发人员已经在做的事情。 这意味着要开展一项新活动，而不是对已经在做的事情进行形式化。 但是，我们今天进行的单元测试远远超过了在单元测试成为正式学科之前进行的非正式测试。 在这方面，将正式的性能测试引入开发周期所需的实际投资与实际投资之间存在差异。

还有其他反对早期性能测试的论点：过早的测试，没有什么可以测试的，无法获得任何东西，这是微性能调整，它太细微而无用，因为我们只能对整个系统进行性能测试，设置性能测试太复杂，花费太多时间，过程多变等。 这些原因并非没有实质性的。 如果您与几乎所有性能测试小组的经理进行交谈，您都会听到最大的时间消耗者只是使应用程序在测试环境中运行。 该任务可能非常艰巨，以至于实际上限制了他们可以测试的应用程序的数量。 有些人对我窃窃私语，他们只能对不到已部署的所有应用程序的50％进行性能测试。

毫无疑问，几乎总是应该使过早的优化无效。 特别是这样，因为优化过程很复杂，实施起来很费时，而且相应的回报是未知的。 例如，如果我们经常对列表进行排序，那么我们真正需要的只是一个简单的冒泡排序。 如果排序时间很关键并且数据量足够保证，我们只需要更复杂的排序即可。 如果我们不能很好地满足这两个要求，则实施更复杂的排序策略将是过早的优化。

测试组件

通过持续的性能测试，我们需要专注于系统，组件和框架的更细化方面。 就像单元测试一样，当我们单独测试这些工件时，我们只能期望发现某些类别的问题。 一个恰当的例子是滥用框架的各个组件之间的争执，导致响应时间比预期的要长； 这些是只有在完整的集成测试中才会出现的东西。 但是，了解我们需要多少CPU，内存，磁盘和网络I / O可以帮助我们预测并采取预防措施（而不是应用过早的优化）。

在费用问题上，毫无疑问； 性能测试将增加开发成本。 与功能测试不同，性能测试不是开发人员要定期检查的内容，因此没有像功能测试那样存在明确的形式化途径。 但是，考虑了两种类型的成本：直接成本和隐藏的成本，这些成本是必须解决的所有性能问题，因为它们随机出现在最终版本中。 直接的经济回报（在金钱和时间/进度方面）仅在项目开发周期结束时进行性能测试。 但这是错误的经济奖励。 据说通过较少的测试，您就需要更少的工时来开发应用程序。 然而，它并不能说明风险。 如果您没有汽车保险就开车，可能会口袋里有更多的钱，但是如果遇到交通事故，您将蒙受损失。 考虑到我们在这个行业中目睹的“汽车残骸”的数量，没有测试就像没有保险的驾驶。

表现的嘲弄

但是我们可以做些有助于降低成本的事情。 开发人员创建模拟和单元测试所需的其他内容。 尽管模拟很可能不会包含性能测试所需的内容，但在大多数情况下，可以轻松地对其进行修改。 模拟一下清单一中提供的信用卡服务。

public class MockCreditAuthorizationServiceProvider
 		implements CreditAuthorizationServiceProvider {

     private double rejectPercentage;
     private Random random;
     public MockCreditAuthorizationServiceProvider() {
         // set the rejectPercentage from a property
         random = new Random();
     }

     public void authorize(AuthorizationRequest request) {
         if ( random.nextDouble() > rejectPercentage)
             request.authorize();
         else
             request.deny();
     }
 }

清单1.模拟被拒绝的信用卡授权

该模拟程序已设置用于功能测试。 它符合功能要求，并且应根据某个可调率来验证交易。 该模拟足以测试用于处理接受和拒绝的信用卡授权的功能要求。 但是，为了测试性能，我们还需要模拟与授权服务之间的服务水平协议。 模拟不仅要授权，还必须授权。 它必须在通常需要执行和授权的时间内执行此操作。 如果系统一次只考虑5个授权请求，则还需要将其编码到模拟中。 这些要求已添加到我们的原始模拟中，如清单2所示。

public class MockCreditAuthorizationServiceProvider
                 implements CreditAuthorizationServiceProvider {

     private double rejectPercentage;
     private Random random;
     private Expondential serviceDistribution; 

     public MockCreditAuthorizationServiceProvider() {
         // set the rejectPercentage meanServideTime from a property
         random = new Random();
        this.serviceDistribution = new Expondential( meanServiceTime);
    }

     public void authorize(AuthorizationRequest request) {
         try {
             Thread.sleep( this.serviceDistribution.nextLong());
         } catch (InterruptedException e) {} 

         if ( random.nextDouble() > rejectPercentage)
             request.authorize();
         else
             request.deny();
   }

清单2.模拟了拒绝和服务时间模拟的信用卡授权

另一个不是那么微不足道的挑战就是简单地使应用程序在合适的测试环境中运行。 但这对于那些进行功能测试的人来说也是一个问题，他们已经找到了解决方案-不断进行。 对于那些想要进行性能测试的人来说，显而易见的解决方案是背负这种努力。

工装

最初，我们使用了一个精巧的小工具JUnit，可以帮助我们组织测试，执行测试并向我们展示结果。 我们使用了ANT，这是一种针对Make的复杂性而编写的工具。 从这些不起眼的开始，我们见证了支持连续构建和单元测试的工具的爆炸式增长。 但是，似乎几乎没有对连续性能测试的支持。 确实没有任何现有工具宣传对性能测试的支持，但确实存在。 正如缺乏广告可能表明的那样，这种支持是有限的。

第一个限制是所支持的测试类型。 当前，我们拥有ANT ， Maven和CruiseControl ，但是由于它们与ANT集成，它们都具有插件来支持Apache JMeter的自动化运行。 Apache JMeter不再需要对HTTP服务器和应用程序进行性能测试。 它支持其他类型的测试，但仅限于一些定义明确的组件，包括JMS，WS和JDBC。 但是Apache JMeter具有相当的可扩展性，如果我们要测试组件，这正是我们要做的：扩展Apache JMeter。 在许多情况下不是理想的解决方案。 唯一的选择是手动滚动我们自己的压力测试装置。 再一次，一个不太理想的解决方案。 虽然工具支持可能很弱，但我们希望随着时间的推移，它会不断改善，就像对连续测试的工具支持一样。

案例

缺少工具支持是否应该延迟进行连续性能测试的时间？ 答案将取决于您的组织愿意冒险的程度。 但是在完全放弃引入它的想法之前，请考虑一下。 有一些组织制定了一项持续绩效计划，尽管证据可能是反对的，但结果令人鼓舞。 在一个案例中，最终产品由6个不同的开发团队共同努力。 性能调整团队要求在开发过程中每个团队都进行性能测试。 性能最困难的组件是由一个不符合请求的团队提供的。

结论

戴夫•托马斯（Dave Thomas）写了关于窗户破损的文章 。 就像连续构建和单元测试可以修复“损坏的窗口”一样，连续性能测试也可以修复“损坏的性能窗口”。

肯特·贝克（Kent Beck）描述了使用驾驶汽车的类比对自动构建进行连续测试的方法。 当您沿着道路行驶时，您的眼睛会告诉您需要进行哪些微调整才能停留在中心或车道上。 您不会想闭着眼睛开车，只睁开它们一秒钟就能看到您在哪里，因为担心错过弯道或偏离车道。 初次学习时很难，但是随着时间的推移它会变得更容易。 他们的意思是，通过迭代，自动化和连续，您可以睁大眼睛进行开发。

翻译自: https://www.infoq.com/articles/iterative-continuous/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

迭代和递归性能