1.3 建立自动化策略我们需要在不破坏现有功能的前提下发布产品的新功能特性。而且，需要尽快知道一个新的代码变动是否会引起回归测试的失败。手动回归测试在每两周的迭代后期才能给予我们反馈，以至于没有时间进行充分的回归测试。我们中一些人曾经在其他敏捷团队中进行过测试驱动开发（Test-Driven Development, TDD）。我们发现TDD能帮助创建出设计良好的、健壮的代码。我们现有的回归测试是手动操作的，整个团队通过使用团队Wiki上所记录的脚本进行手动测试。在每两周的迭代周期中，这就花费了整个团队的20%的时间。这些测试仅仅为程序最核心的部分提供了最小程度的覆盖。产品中报告的缺陷表明，回归测试的失败仍有可能发生。在每次迭代周期中，我们至少要花20%的时间修复这些产品缺陷，从而限制了我们能开发的新功能的数量。自动化的回归测试会带来更高、更准确的覆盖率，这需要投入大量的时间、金钱和精力，我们可能需要硬件和软件来建立构建过程、持续运行测试所需要的环境，我们也需要使测试实现自动化的架构和驱动。然而，我们可以计算出这一自动化将会节省我们40%的时间，利用这些时间可以进行更多有价值的活动，比如进行新的开发，所以，其收益远大于成本。 继续进行手动回归测试必将会失败，我们需要一个明确的决策来进行自动化。因为我们都在进行手动回归测试，每个人都感受到了没有自动化测试的痛苦。所以，我们有了解决这一问题的动力。首先，我们需要一个可测试的架构……1.3.1 一个可测试的架构TDD这条路是要走的，但是当前的代码在业务逻辑、数据库访问和UI等处相结合时，情况比较复杂，自动化单元测试也就变得很难了。往往很难隔离任何一个组件单独进行测试。这样看来，似乎找到一种把软件进行分层的新架构是非常明智的。我们开发出了这一新架构的所有新功能。【小窍门】不要尝试解决老问题，进行新的开发来开展更好的实践。如果进行自动化测试的成本比其收益高，那么进行自动化测试就没什么意义。我们研究图1-1所示的自动化测试金字塔（这一金字塔是由我们当时的经理Mike Cohn提出的）。单元级别的测试一般ROI最高。程序员可以很快写出它们并运行，而且测试可以根据需要进行更新。因此可以将单元级别的测试作为自动化回归测试的坚实基础。我们的业务逻辑相当复杂，而且新架构将这一逻辑从数据库和用户接口层中分离出来，这样就可以通过设置内存中数据并在其上运行产品代码来进行测试。这是金字塔的中间层———比底层运行的测试要少但是依然很重要。我们还需要测试UI，但是通过UI进行的自动化测试本身就非常脆弱、维护费用高且运行缓慢。因为最终想使UI测试所占的比例尽量最小，所以它就处在金字塔的最顶端。尽管如此，与其他团队一样，我们从图形用户界面（GUI）冒烟测试（smoke test）开始，来获取一些代码防护。所以，从这个角度，我们的金字塔是上下颠倒的，但是没关系———最终我们会将它翻转过来。（我们最终花了4年时间才获得为之努力的三角形形状！）
【小窍门】解决问题的最直接途径未必是最佳途径。我们现在明白了我们需要做什么，所以我们开始着手实施那个能给我们带来**最大实惠的任务。1.3.2 建立构建过程**我们只有4位程序员，但是他们会经常检查源代码控制系统中的变化。我们需要确保他们没有不小心修改别人的内容或者破坏现有的任何功能。同时，我（测试人员）有时候不得不等待好几天，部署在测试环境中的代码才能完成一次构建。一个自动化的构建过程（build process）将保证在每次检入后的几分钟内，最新代码的可部署版本就是可用的。管理层向我们强调了质量是我们的第一目标，他们乐意宽限一些时间来让我们搭建一个好的基础结构。【真知灼见】好的管理者会准许团队花时间去开发自动化的基础结构。我们停下正在做的事情，使用CruiseControl和一个新的Linux服务器建立了一个持续集成（Continuous Integration, CI）过程。因为我们还没有可以运行的任何测试实例，所以只是简单编译代码和构建可部署的二进制文件。我可以看到每次构建的检入文件并能够选择想部署到产品中的二进制文件。这很有用，但是还不够。1.3.3 获取测试的基准：GUI冒烟测试程序员正在学习如何使单元测试自动化并编写测试先行（test-first）的代码，但是要真正实施测试驱动开发需要花好几个月的时间。针对遗留代码，使用GUI冒烟测试可能是一个快速获得自动化测试覆盖的途径。但是使用什么工具最好呢？我们有购买一个付费工具的预算资金，但是团队里的程序员是Java程序员，他们万不得已是不愿意使用另一种脚本语言来进行测试的。捕获/回放并不适合我们，因为我们需要可维护的、稳定的测试脚本。我们选中了 Cannoo WebTest——一个可以让我们修改XML文件中的测试用例，并使用Ant运行它们的开源框架。而且它很容易与我们的构建过程集成。【真知灼见】昂贵的商业工具不一定是最好的选择。我让业务专家把需要用冒烟测试来保护的系统核心区域按优先等级进行划分。每个冲刺时间段里，都安排了时间让我用WebTest工具自动运行测试脚本。我们首先追求的是“快赢”，针对系统中每个用户角色的基本功能实现自动测试。首先， CI构建过程只运行了少量单元测试和一些覆盖系统高得分点的GUI冒烟测试。随着在这两个级别引入更多测试，我们将GUI测试移到单独的构建过程中并只在晚上运行，这样，我们可以更快得到的反馈信息。与此同时，我们将单元测试和每个新用户故事（user story）的GUI冒烟测试都放在迭代中完成。新的功能将会在自动化的单元测试和GUI测试中被覆盖。一旦程序员能够熟练使用TDD，我们就将进入金字塔的中间层。1.3.4 在单元级别驱动开发我们的程序员中只有一人曾经实施过TDD，但每个人都支持这种理念。我们根据别人的介绍，找到了我们能找到的最好的顾问来帮助我们学习如何实施TDD，很多时候我们都是自带午餐以便挤出时间来进行TDD试验。但是很遗憾的是：它很难学！我们团队需要时间来掌握它。我们的管理层知道这个道理：目标是写出优美的代码，优美到可以拿回家给妈妈，当做冰箱贴。我们的公司——一个刚刚成立3年的商业公司，因为网络应用问题和无能力及时发布新功能而面临倒闭。我们的商业合作伙伴也准备放弃我们了，但自从我们实施敏捷开发（Scrum）以后，他们看到了我们为提高稳定性和响应能力所做的努力。我们的执行者致力于具有长远收益的投资。【经验教训】一个迫在眉睫的灾难可能是巨大进步的推动力。我们知道这些单元级别的测试具有最好ROI。我们也理解TDD事实上是代码设计，而不是测试。考虑“代码是用来做什么的”可以帮助程序员写出正确的代码，而快速实施测试，才能及时地提供重要的反馈信息。单元级别测试的最大好处就是能够提供最快速的反馈。在研究一些好的实践之后，我们决定将代码构建过程的时间控制在10分钟内。这需要单元测试的随机重构。早些时候，单元测试需要访问数据库，之后，程序员掌握了如何构造、模拟它，以及消除它的影响，使测试快速运行又能提供正确的测试覆盖。
