日常测试——坚持每日构建

    传统的软件工程中，测试发生在连调之后。这么做的理论依据是，测试依赖于一份一致的、至少能够正常编译并启动的代码。而这个条件在连调之前是无法满足的。

    然而在有了版本控制系统(如， cvs)之后，连调变成了开发中的日常行为。代码几乎在每一时刻都处于高度的一致状态，甚至在许多时候，代码会处于可用状态，从而为测试创造非常有利的条件。

    许多大型开发团队会使用一台甚至多台被称作TinderBox的机器来完成每日构建和测试。简单的每日构建流程如下：

    测试工程师，或代码复审员从代码库中提取一份代码的快照

    相关人员在TinderBox上进行编译

    编译的任何错误被追踪，测试工程师或代码复审员将回退代码到上一次能够成功编译的点，并与此后进行代码提交的其他开发者进行联系，解决问题

    测试工程师对于代码进行测试

    其中，第一、二步是可以通过脚本定时、自动完成的，不需要人工干预。第三步中的编译错误在软件开发中偶尔会发生(这可能来自于冲突合并时引发的问题，但由于开发人员的本地测试，这种文体不会是经常性的)，习惯上，这些错误会由代码复审员去追踪和处理，并交给相关的开发人员解决。

    测试工程师可以将编译好的版本交付给一个测试组，甚至用户去进行测试。测试工程师可能随时发布软件的“快照”版本。

    实际上在许多大公司中，每日构建是非常“家常便饭”的事情。我们看到的Internet Explorer版本，如6.0.2600或者类似6.0 Build 2600中的2600的意思就是这份代码之前已经经历了2600次每日构建操作(当然，中间肯定进行过不少修改，而且，也不排除这个2600是故意凑整得到的，但总之，他们进行了相当多的日常构建工作)。

    在软件开发的后期，由于发布的迫在眉睫，每日构建很可能会演化为持续构建，即，每次commit触发一次构建操作。所有问题立即得到反馈。

    为了支持每日构建或持续构建，比较理想的方法是采用Makefile完成构建操作。对于Unix系统，make工具通常是pmake(BSD Make)或gmake(GNU Make)；对于Visual C++，则是nmake。大的开发团体通常使用一组脚本来完成所有的make操作，而对于中小型项目，手工地使用类似VC++这样的IDE本身的构建功能也是可以接受的。

    基本的每日构建规范如下：

    基本的每日构建和测试注意事项

    避免在存在开发人员大规模地进行commit时提取快照。此时提取的中间结果很可能有问题，并导致每日构建从头做起。通常，测试工程师和代码复审员在多数开发人员下班的时候开始每日构建，因此，每日构建有时也被称作每晚构建(Nightly Build)。

    标记(tag)每日构建中能够正确编译的版本。这将减少第二天每日构建中的麻烦。

    及时通知造成问题的开发人员，即，所涉及代码的提交者。某些公司甚至要求员工开着手机和寻呼机，以保证工期。

    作为commit mail的有效补充，许多项目开发组会建立邮件列表来传递一些相关的信息。测试日报通常会发给整个开发团队的参加人员，此外，保留一个出现过的问题记录，对于测试环节也会有相当大的好处——这些问题在随后被反复测试，以保证最终的RELEASE不出现这些问题。

    每日构建并不是可有可无的工作，作为日常测试的重要手段，每日构建能够有效地帮助管理者了解工程进度，帮助开发者尽早发现问题，同时，也会促进开发组中的交流。

    有效的版本控制——版本标记、代码分支

    三个文件的“最新版本”分别是1.5, 1.3, 1.4，但最新版本不一定是我们需要的。在这种情况下，版本控制系统提供了一个非常重要的机制——版本标记。例如，我们目前已经确认三个文件的1.4, 1.3, 1.4组合在一起能够正常运行，于是我们在三个文件的这些版本上标注标记TAG_1，如下图：  

    需要说明的是，标记是可以被移动的。这意味着一旦发现标记打错了，可以把标记移动到别的位置。但在实践中，标记往往同另一个非常重要的版本控制机制——代码分支一起使用。在详细讨论标记(tag)的重要意义之前，我们先来看看代码分支时什么：

    图5. 比较复杂的情形，一个正在开发的项目中的某个文件，已经完成了2.0和2.1的发布; 其中，BP是指划分分支的切分点(Branchpoint)