题记：去年12月在淘宝和奥莱利公司举办的Velocity会议上，结交了很多好朋友。当时有好多想分享的主意，回来后写了个“开源软件的参与及社区互动的一些体会和建议”系列。之后就酝酿着要写一个测试系列，因为我坚信好的测试是生产高质量软件的必要条件。后来因为有家人从各地来，再加上时间安排不当（主要是懒和自律性差）和其它方面的原因，现在才动手写这个系列。这是开头篇。 通过自己的实战经验和阅读别人经验体会，我感觉我们可以总结出在生产高质量和高可靠的软硬件产品过程中，大都会走如下流程： 尽快制出原型产品（prototype）； 尽快把原型产品拿到生产环境中做检测和获得反馈； 尽快把在生产中得到的反馈数据和教训融入到下一步的故障修复和性能提升； 把改进后的产品再次尽快拿到生产环境中做检测和反馈； 循环以上步骤。 在这样的流程里，有以下几个方面特别值得注意： 1. 尽快做出原型产品并拿到实战中（或近可能类似于生产环境中）检验。 和用户互动，了解实战应用场景，检索、阅读、和了解业界同仁的文章和经验积累，搜索、阅读、分析网上网下的关于各种语言、解决方案的文档等都是很重要的过程。但把想法和了解到的信息付之与实践之前，那些理论、分析、和研究到头来只是纸上谈兵。把东西付诸与实践后，你会加深和巩固自己对已有知识的理解，碰到和解决自己和别人没有想象或碰到的问题，把学到的理论和步骤加以调整后运用到自己的环境中去。这是Kent Beck在极限编程/eXtreme Programming/XP中的一大重要、也是在实战中极端有效的一个原则。这一点和陆游在1199年写的《冬夜读书示子聿》里说得是同一个道理： 古人学问无遗力，少壮工夫老始成。 纸上得来终觉浅，绝知此事要躬行。 2. 快速的检测和反馈需要可靠、方便、和尽可能自动化的测试机制。 原型产品出来后肯定会有这样或那样的问题：有的地方需要改进和提高，有的地方需要添加新功能等等。我们在做改进和提高的同时还要做到已有功能不退化（regression bugs）。要能够实现这一目标，唯一有效的办法是建立起有效、系统、和自动化的测试脚手架。有了这种测试机制，并配有有效的源代码管理系统，我们就敢于去做代码改进和重构，就有足够的信心来保证代码的质量和可靠性。 前一段时间读Kent Beck的TDD（Test-Driven Development）书，他举了这样一个例子，我觉得挺贴切的。我们都知道用轱辘打水比从井里直接往上提省力，是打水的有效方法。假设水提到一半后你累啦或有别的情况而hold不住，你的努力就会前功尽弃。但如果你在轱辘上安装个齿轮机制来咬住你的进程而不至于让提上来的绳子后退，那你就会轻松、自信地打很多水。有效、自动化的测试机制就是你用轱辘打水的那个齿轮，它给你信心和回旋余地，让你大胆、放心地去修复、改进、重构、和添加新功能，让你有信心和实效来生产和提高产品，在保留既有功效的前提下扩大战果，打一场干脆利索、无后顾之忧（或担忧最小化）、不拖泥带水的漂亮仗！ 在编程中，如果我们把每一个类/class、每一个函数/function都当作一个产品的话，根据上述“尽快做出原型产品并拿到实战中检验”的法则，我们就可以很容易地理解TDD的原理： a.我们对某类或某函数的界面有初步打算，即脑中已经设计出原型； b.在实施该类或函数之前，我们写出一个单元测试案例来在实战中应用该函数/类的原型； c.我们运行该单元测试，那么这第一个测试应当失败； d.好，接下来我们用代码来实施该函数或类的原型，直到该单元测试通过； e.我们接着写更多的测试来强化该函数/类的代码，直至新的单元测试通过； f.循环以上步骤，来搭建其它函数/类。 按照这种方式来写代码，这些单元测试就构建成咬定既有成果的齿轮和脚手架。它们给我们提供质量保证和信心，给整个产品的稳定、可靠、和高质量打下了坚实的基础。 先写到这儿，该系列的下一篇，我写一下单元测试。 后记：这些生产原型产品、实战测试和反馈、之后提高的良性循环经验过程，不仅仅可以应用到软件开发方面，个人以为在硬件、工业制造、能源和环保产品的设计和研发等很多方面也能派上用场。比方说关于节能型汽车的研发、改进和提高，关于高铁、大飞机各部件的研发和应用，关于能源产品如藻类/海藻产生能源和风能、地热能、太阳能方面的可行性研究和应用，关于很多产业向创新、高附加值型转型等等，这些对于中国和很多后发国家都有很现实的指导意义。有的东西你可以在网上、书里、和各种会议上学，有的东西别人会藏着、掖着不想让你学到，但你若不自己去应用和尝试，那永远都不会成为你自己的东西。不要自高自大，也不要妄自菲薄，一步步建立起完善的研发、测试、反馈、和提高机制，有勇气和实际行动去大胆尝试，踏踏实实地走稳每一步，那么最后领先的会是你。