前言：关于测试，的确太过重要，尤其是把新做成的功能加入到原来已经正常运行的系统中，先随我一起进入到Brooks的世界中看一看。
剔除bug的设计
产品的概念完整性在使他易于使用的同时，也使开发更容易进行，而且bug不容易产生。
在我所经历的项目中，我只参与了其中一部分，或者负责了较大部分，在与别人负责的代码打交道的过程中，如果我稍不留神，就会滋生很多bug在其中。除去我对整体业务掌握的不够全面以外，大部分的原因是因为我们彼此之间的差异太大。
自上而下的设计。我所经历的项目的确都是自上而下的设计，都是先搭建整体模型，再不断细化。但是很多时候，做的不好，是因为模块之间的耦合度太高，导致不够灵活。
构件单元测试
Brooks提到了本机测试和交互性测试，也许我理解的不够深刻，我认为的本机测试就是我们在个人的电脑中配置软件运行所属环境，进而对代码进行整体性测试，等本地测试通过后，我们在部署到服务器当中。这个时候，因为代码以及服务器的一些固性原因，我们需要手动去改变服务的某些状态，我们在这个时候，就会对代码多加上一些人为操作手段，进而控制程序进行交互性测试。
系统集成调试
系统集成调试的概念，对于每个学习编程的开发人员来说，并不陌生，甚至我们经常挂在嘴边，我们都倾向于只做集成测试，而不太重视做集成测试之前先要做构件测试，也就是说保证集成到整体系统的每一部分都顺利通过。
小型团队没有代码review，也缺乏同级的代码评审，更缺少自我的代码测试，我们经常性的只要完成了代码，就认为可以放到服务器上供用户使用了，然而这个时候，我们经常吃很大亏，一些不负责任的程序员经常为我们埋雷。
我个人最近也深有体会，写完代码之后，我自己会反复检查几次， 然后对重要的部分进行单元测试，然而，等放到服务器上运行时，就出现了不应该出现的错误。
在集成测试之前，一定保证每个部分已经被测试通过了，至少确保你在集成测试时候发现问题时，能尽快的定位到为题发生的所在之地。
搭建充分的测试平台。这个非常的必要，我们项目部有两个小组，有一个小组虽然有测试服务器，但是很多时候，代码在正式环境上线后，依然出现很低级的错误，这其中一个很主要的原因就是没有保持好两者之间的同步。
伪构件、伪文件。我想很多时候，我们都经历过，并且取得了很多的成效。当我们无法真实产生所需的xml时，我们会手动构造一个；当我们的某个功能尚未完善时，我们会假装它已经完成。这些在测试的时候，都会给我们很大的帮助，让我们的整体测试顺利的进行下去，而不是阻塞，当然这是因为伪构件和伪文件足以让我们发现应该找到的bug。
控制变更。由于我们的小组成员人数只有我和另外一个人，再加上两人可以随时语言沟通，所以我们没有进行变更控制。但是如果项目人数有5人以上时，遵守Brooks的观点是应该的：
一个是供构件测试使用的最终锁定版本；一个是测试版本的拷贝，用来进行缺陷的修复；以及一个开发库，供其他人员进行各自的程序开发。虽然我知道svn有分支，但是我还是不太确定如何在SVN上执行这些操作。
一次添加一个构件。在很重要，交易平台的项目目前主要由我整体把控，所以我经常性的优化代码结构，但是有的时候会事与愿违，优化后的代码不足够保证程序正常运行，这很大一个原因就是我改动的太多，所以出现问题后，如果我反复很多很多次后，依然无法找出问题所在的原因时，我就会还原版本，再改动。再次改动的时候，我就会缩小范围，保证每一次修改都不会影响到原有的程序。这很重要。
