持续性能管理（Continous Performance Management）的前提是测试驱动开发和持续集成方法论。在这个部分，描述了这些方法论的概览，以使你能够更好地理解CPM。如果你已经是测试驱动开发和持续集成专家，可以跳到下一部分。

1.测试驱动开发

      测试驱动开发的创建是为了解决我们目前测试实践的限制。简单地说，测试驱动开发提倡软件开发人员在实现代码之前编写代码的测试用例。然后把所有开发者的测试用例结合成全面的测试套件。

      具体地，测试驱动开发有以下要求：

• 测试用例必须由开发者编写
• 测试用例必须的实现之前编写
• 每个代码组件必须和相应的测试套件一起交付

      要求开发者编写他们自己的测试用例，这有助于确保他们的代码的各方面都能得到适当的测试，并确保测试用例针对当前代码而编写，而不是过期的。要求他们在编写代码之前编写测试用例有助于确保到底需要什么样的代码实现，仅此而已；这有助于减少问题代码的副作用。最后，要求所有的代码随相应的测试套件一起交付有助于确保组合的测试套件的健全和精确。

      如果整个开发生命周期都认真地遵循这个过程，其结果是彻底，准确，全面的测试套件，将发现功能错误，并迅速查明错误的根源。

生命周期

      测试驱动开发并不仅限于以上所列的三个要求；它包含一个可复制的生命周期模型的过程。测试驱动开发生命周期如图2所示。

      测试驱动开发生命周期包含以下步骤：

1. 在实现基础代码之前先添加一个测试用例到已存在的测试套件
2. 执行测试套件证明现有代码对新的测试失败，以确保测试用例被编写正确
3. 实现新测试执行的功能
4. 执行测试用例，并确保通过新的测试
5. 重构代码实现一个更优雅的解决方案。如果重构破坏了现有代码，新的测试能立即发现

      注意：CPM需要你编写测试用例，但它不要求您正式接受测试驱动开发的所有方面。例如，如果你不想在编写代码之前编写测试用例，你仍然能够使用CPM

2.持续集成

      Martin Fowler在他网站上发表的一篇出色的文章里，定义了一种新的叫做"持续集成"的敏捷方法：

      http://www.martinfowler.com/articles/continuousIntegration.html

      Fowler作为一名暑期实习生时，就认识到将开发者的代码集成到一个正工作的产品中会花费大量不可预测的时间，有时甚至比应用开发阶段还要长：可能你最初将组件集成进去并工作得很好，或者这个过程可能花费两个月的调试时间。

      为了避免这种不可预期的冗长的集成过程，持续集成规定持续集成你的应用，或者至少每天集成几次。确切地说，就是当新的代码提交到中心代码库时，就应该编译，然后运行一个全面的测试套件，并作为一个整体进行测试。如果代码破坏了这次构建（或者导致测试套件失败），错误会在几个小时被获知，并立即解决。在开发迭代完成时，只需简单地给构建添加标签，并将它移交到质量保证部门再次进行业务用例测试；没有单独的集成阶段。

生命周期

      在这篇文章里，Fowler概述了持续集成环境额外标准，推荐读者阅读。图3概述了一个持续集成环境的生命周期。

      持续集成环境的中心是持续集成服务器。有各种开源版和商业版的选择，强烈推荐CruiseControl。CruiseControl是由Martin Fowler所在的ToughtWorks公司开发的一个免费，开源产品。所以开发者真正理解持续集成。此外，对于那些受到java损害的人还是接受持续集成，也有针对.NET和Ruby on Rails的Cruisecontrol的软件包。

      持续集成生命周期包含以下步骤：

1. 监视一个源代码库（比如：CVS，Subversion，Perforce，或者Visual Source Safe）
2. 如果代码已经提交到源代码库，则签出并构建整个应用
3. 两步执行全面的功能测试套件：一次快速运行的"提交构建"目的是在十分钟完成，并发现大多数问题 运行一组时间更长的"二次构建"能够在一个更深的层次测试应用，比如，使用一个在线的数据库或者多层部署中测试应用
4. 发布构建结果，返回继续监视源代码库

      通过这个过程，中断构建或测试用例的错误在进入应用时就能被发现，并且容易解决。毕竟，如果你提交代码，在十几分钟后，能知道应用中失败了的测试案例，代码在你的头脑中还保留着记忆，你可以迅速隔离和解决这个问题。

（北京铸锐数码科技有限公司 www.InnovateDigital.com）