单元测试应该集成到自动测试的框架中。

　　另一个重要的措施是要把单元测试自动化，这样每个人都能很容易地运行它，并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的，这样每个单元测试的错误就能及时被发现并得到修改。

　　单元测试必须和产品代码一起保存和维护。

　　单元测试必须和代码一起进行版本维护。如果不是这样，过了一阵，代码和单元测试就会出现不一致，而且所有代码的作者要花时间来确认哪些是程序出现的错误，哪些是由于单元测试更新滞后造成的错误。这样就失去了单元测试的意义，同时又给大家增加了负担。如此折腾多次以后，大家就会觉得维护单元测试是一件很费时费力的事。

　　3、回归测试

　　在单元测试的基础上， 我们就能够建立关于这一模块的回归测试  （Regression Test）.

　　Regress 的英语定义是： return to a worse or less developed state。是倒退、退化、退步的意思。

　　在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。

　　在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准 （Baseline） ， 一个模块的所有单元测试就是这个模块最初的Baseline。

　　假如，在3.1.5版本，模块A的测试用例125是通过的，但是测试人员发现在新的版本3.1.6，这个测试用例却失败了，这就是一个“倒退”。在新版本上运行所有已通过的测试用例以验证有没有“退化”情况发生，这个过程就是一个“Regression Test”。如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因）引起的，那么测试用例的基准就要修改，以便和新的功能保持一致。

　　针对一个Bug Fix， 我们也要作Regression Test。

　　（1）验证新的代码的确把缺陷改正了。

　　（2）同时要验证新的代码没有把模块的现有功能破坏，没有Regression。

　　所以对于“回归测试”中的“回归”，我们可以理解为“回归到以前不正常的状态”。

　　回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。单元测试是回归测试的基础.

　　在专注于模块基本功能的单元测试之外， 还有功能测试 – 从用户的角度检查功能完成得怎么样。  在微软的实践中，在一个项目的最后稳定阶段，所有人都要参加全面的测试工作，把所有以前发现并修复的bug 找出来， 一个一个验证， 以保证所有已经修复过的Bug的确得到了修复，并且没有在最后一个版本中“复发”， 这是一个大规模的、全面的“回归测试”。