冒烟测试是一个简短的测试集合，其目标是被频繁修改的代码区。冒烟测试不必设法运行整个产品。一套好的冒烟测试应该是可以轮换运行的……它们不 是永久不变的。当你开始致力于不同的产品领域时，退出原来的冒烟测试，把新的测试添加进来。你可以从完整的测试套件中选择恰当的测试，使其在冒烟测试套件 运行。我通常都是把它们添加到一个Ant target（我把它命名为smoke-test）中，然后运行选定的测试。

　　我们仍然需要一个干净的构建和周期性运行的完整测试。这就是我们如何验证是否有人忘记提交一个被修改的文件或者用一种非预期的方式来破坏产品。冒烟测试经常遗漏这几类破坏，为了保持产品处于最佳状态，我们需要相当频繁地运行整个测试套件。

　　不 要要求每个开发者从头构建整个系统，也不要每天运行五遍每个可用的测试。相反，那些需要花费一些时间来执行的任务，我们都该让计算机来替我们完成。因为我 们可以给计算机分配任务来执行自动构建和自动运行测试，所以我们没有理由每周不运行超过一遍。事实上，每个代码改动后也没有理由不运行一遍。

　　建立这类自动化的最佳方式是什么？最快捷、最容易的方法就是使用一个持续集成（CI）产品。CI产品可以监视你的代码，在每次修改后构建，运行测试，然后通知所有相关人员。

　　持续集成图

　　CI系统会创建一个快速反馈循环。当你修改代码时，如果代码遭到破坏，你就会在忘记为什么修改它之前发现它。（关于CI系统的更多信息，请访问我的CI页面 .net/ci.html">http://www.jaredrichardson.net/ci.html）。

　　所有这些讨论都是关于开发速度和持续不断的进度的。对于保持团队的进度，回顾上周或者上个月所编辑的代码是一条末路，而在数小时内抓住并且解决问题才是真正的解决之道。

　　这里描述了系统是如何进行工作的：你在电脑上编写代码，直到你确信已经完成了某个功能或者修补了某个缺陷，然后你将所作的修改提交到源代码管理系统中 （SCM）。持续集成系统一直监视着SCM，注意到该段代码发生了改变。接着，它就会从SCM中检出代码，构建它，并且运行整个测试。你也将会及时地收到 一封邮件，通知修改和测试是否已经通过或者失败。

　　这个概念相当简单，但是它在实践中力量非凡。

　　测试

　　BAT最后一部分就是指自动测试。现在CI系统正在构建产品，运行你的自动测试，我们需要确信我们的测试充分地覆盖了整个产品。毕竟，从客户的观点来看，如果一个测试不能检验客户所使用的功能，那它就是没用的。

　　首先，设法理解产品是如何使用的……对于一个遗留产品，这常常是出于自身的要求。或许，你甚至要为客户创建一套使用场景。例如，恐怕你要有一组场景，生成日常的报表，完成日常的数据导入，或者增加新的客户。

　　或许，你也想区分用户类别，它被称为“用户角色”。你恐怕要有“Joe——超级用户”、“Mary——系统管理员”或者“Fred——新用户”等用户角色。每个角色使用了该产品中不同的功能，正如一个超级用户与一个新手使用该产品是大相径庭的。

　　下一步就是使用模拟客户测试来重现大多数的普通客户使用场景。

　　模拟客户测试

　　模拟客户测试（Mock Client Test）并不是一套特定的测试框架。它的目的是用来确保预期的功能不会被破坏。你要改变系统中的一部分，却不知道这个修改影响了产品的其他区域，这在遗 留产品中经常出现。曾经我编写一个产品时，修改了通讯协议，却影响了GUI组件布局。CI系统中的模拟客户测试，是你预防意外修改的保障策略。对产品是否 如你所预望进行测试，就会有一个坚实的产品基线。而且测试也会包括更多有趣的情形，正如你所遇到的那样。

　　一个优秀的测试策略是缺陷驱动测 试（Defect Driven Testing）。每次你发现一个系统缺陷，就增加一个相应的测试。当你增加该个测试时，你可以尝试增加一些与该测试相近而不同的测试。随着时间的推移， 这个策略为产品最需要涵盖的范围，提供了相当可观的测试覆盖率。

　　不管你如何选择增加测试，都要设置测试优先级。如果你计划对产品进行任何修改，有一个基本的测试套件是最关键的。

　　最后一步就是将测试集成到持续集成系统。

　　当自动测试运行在持续集成环境下时，你会及时地得到关于所有问题的反馈。每次你修改一段代码，你就会“从头开始”构建和运行完整的测试。大多数开发者很快就会沉浸于此，并且很快依赖这个 “编外成员”。

　　。编写场景

　　。创建模拟客户测试

　　。使用持续集成

　　小结

　　构建、自动化和测试（BAT）对于程序员都是好的建议，但是它对于继承遗留代码者尤其好。拥有自信的重构能力非常关键。我发现如果我要不断地停 下来去查看我正在破坏什么，这种境况下变得高效则很困难。一个好的测试套件可以替我进行监视，而且能够让我集中精力设法完成性能改进。

　　记住，如果你不能测试遗留代码的话，那么就不要修改它。而且不要单纯地进行手动测试，除非没有其他选择。

　　不仅不要害怕遗留代码，还要正确地对待它。用BAT这种方法来处理它，你就会每次都能成功。

　　关于作者

　　Jared Richardson是《Ship It！ A Practical Guide to Successful Software Projects》 一书的作者之一。他是一名演说家和独立顾问，擅长使用非定制技术来解决疑难问题。Jared有着十年丰富的工作经验，曾经做过顾问，开发者，测试者和经 理，包括很多公司开发部主管。直到最近，他领导SAS软件研究所（SAS Institute，Inc.）的一个开发团队和测试团队，为三百个项目，五百万行代码和超过1800个开发者部署了一个持续集成系统。他也带领整个公司提高了测试自动化的使用。