1.1.2　目标

　　我们决心尽自己所能编写出最高质量的代码，但是从哪里开始呢？作为一支自组织的敏捷开发团队，让我们感到欣慰的是整个团队的紧密协作。那是在2003年，我们中有些人在别的团队中曾有过良好的自动化测试经验，他们相信总是会有办法的。我们发现，一个安全的自动化回归测试网络可以让我们更快速地工作。如果我们知道是由于某段特殊的代码而引入的非预期的操作，那么我们能够立即稳定我们的代码库。通过充分的测试覆盖来不断进行集成，使我们每天都有一个稳定的构建过程。而在迭代的后期，现在很难得到稳定的集成，所以这个想法虽然并非那么容易实现，但听起来很不错！

　　接下来，看看到底是什么帮助我们创建了一个成功的策略来实现自动化回归测试套件。

　　1.2　整个团队的承诺

　　我们是由多个程序员、一个测试人员、一个数据库管理人员、一个系统管理人员和一个敏捷教练所组成的团队。公司的业务专家可以随时协助我们。我们整个团队致力于在每次发布之前运行我们的手动回归测试脚本。因为我们每两周发布一次，这意味着两周的迭代周期中我们要花1 ~ 2天的时间进行手动测试。在最终用户使用之前，我们没有足够的时间来进行探索性测试，虽然这种测试可能会帮助我们找到严重的缺陷。

　　【真知灼见】

　　敏捷开发团队中的每个人都进行手动测试，所以他们更能体会到自动化测试的好处。

　　我们都很关心质量，并且我们都致力于保证所有的测试活动都是有计划的且在每一次迭代中执行。这是一个好的开始！

　　1.3　建立自动化策略

　　我们需要在不破坏现有功能的前提下发布产品的新功能特性。而且，需要尽快知道一个新的代码变动是否会引起回归测试的失败。手动回归测试在每两周的迭代后期才能给予我们反馈，以至于没有时间进行充分的回归测试。

　　我们中一些人曾经在其他敏捷团队中进行过测试驱动开发（Test-Driven Development， TDD）。我们发现TDD能帮助创建出设计良好的、健壮的代码。

　　我们现有的回归测试是手动操作的，整个团队通过使用团队Wiki上所记录的脚本进行手动测试。在每两周的迭代周期中，这就花费了整个团队的20%的时间。这些测试仅仅为程序最核心的部分提供了最小程度的覆盖。产品中报告的缺陷表明，回归测试的失败仍有可能发生。在每次迭代周期中，我们至少要花20%的时间修复这些产品缺陷，从而限制了我们能开发的新功能的数量。

　　自动化的回归测试会带来更高、更准确的覆盖率，这需要投入大量的时间、金钱和精力，我们可能需要硬件和软件来建立构建过程、持续运行测试所需要的环境，我们也需要使测试实现自动化的架构和驱动。然而，我们可以计算出这一自动化将会节省我们40%的时间，利用这些时间可以进行更多有价值的活动，比如进行新的开发，所以，其收益远大于成本。

　　继续进行手动回归测试必将会失败，我们需要一个明确的决策来进行自动化。因为我们都在进行手动回归测试，每个人都感受到了没有自动化测试的痛苦。所以，我们有了解决这一问题的动力。首先，我们需要一个可测试的架构……

　　1.3.1　一个可测试的架构

　　TDD这条路是要走的，但是当前的代码在业务逻辑、数据库访问和UI等处相结合时，情况比较复杂，自动化单元测试也就变得很难了。往往很难隔离任何一个组件单独进行测试。

　　这样看来，似乎找到一种把软件进行分层的新架构是非常明智的。我们开发出了这一新架构的所有新功能。

　　【小窍门】

　　不要尝试解决老问题，进行新的开发来开展更好的实践。

　　如果进行自动化测试的成本比其收益高，那么进行自动化测试就没什么意义。我们研究图1-1所示的自动化测试金字塔（这一金字塔是由我们当时的经理Mike Cohn提出的）。单元级别的测试一般ROI最高。程序员可以很快写出它们并运行，而且测试可以根据需要进行更新。因此可以将单元级别的测试作为自动化回归测试的坚实基础。