最近团队的交付质量下降，客户有所抱怨，紧急情况出现不少，开发人员应付紧急情况压力和很大，也有抱怨，这样就构成恶性循环。后来开会进行反省总结，发现一些原因：

　　1. 没时间测试，客户需求变更催的急，交付日期紧迫，导致开发人员减少了单元测试，而我们的测试人员只负责后期的集成测试和用户use case测试，覆盖率是有限的。

　　2. 开发人员单元测试意识薄弱，小函数认为逻辑很简单，根本没必要测；大函数认为太复杂，根本没时间写那么多测试代码覆盖；依赖数据库、socket和其他服务接口的函数则抱怨没法测，单元测试难度太大。

　　3. 混淆单元测试和集成测试的概念，习惯做集成测试，从用户use case的角度来测试，而不是针对函数进行测试。

　　4. 团队没有专门的单元测试人员，没有单元测试自动化测试集成服务器和环境，开发工具和制度建设没有跟上。

　　5. 公司层面不重视，或者提到了要做单元测试，却没有监督检查机制。

　　大家都知道，交付质量是公司生存之根本，而怎样的质量管理能把软件的bug消除到最低程度？这是一个很大的问题。涉及到一线开发人员的质量，效率，开发习惯，测试队伍建设，开发流程的建设和改进，工具的合理高效实用等很多方面。其中测试环节是最重要的，是质量保证的关键一环。而单元测试是和开发人员最密切相关的测试类型。通常由开发人员编写和执行。由于单元测试通常发生在错误产生之后不久，因此通过单元测试发现错误然后进行修正的代价通常比较小。我们都知道，bug越早发现越好；发现产品中存在的问题越早，开发费用就越低，产品质量就越高，软件发布后维护费用就越低。一个bug被隐藏的时间的越长，修复这个bug的代价就越大。最后才修改一个bug的代价可能是在bug产生时修改它的代价的10倍！因此，单元测试是如此重要，以至于一些极限编程爱好者主张任何未经测试的代码都应该被自动删除。所以加强开发人员的单元测试意识是首要步骤，除此以外，我们制定如下措施：

　　1. 在公司层面重视单元测试 - 很多开发人员不做单元测试，是因为公司层面就不重视单元测试，没有监督/review/审查机制，所以我们要在公司层面重视单元测试，有资深程序员对年轻程序员定期进行单元测试Review走查，同时在单元测试技术上进行指导，提交代码到代码库的同时必须同时提交测试代码。

　　2. 加强开发人员的单元测试意识 -  一个bug被隐藏的时间的越长，修复这个bug的代价就越大。最后才修改一个bug的代价可能是在bug产生时修改它的代价的10倍！而单元测试通常发生在错误产生之后不久，因此通过单元测试发现错误然后进行修正的代价通常比较小。单元测试是如此重要，以至于一些极限编程爱好者主张任何未经测试的代码都应该被自动删除。单元测试还能发现代码结构设计的问题，很难测试的代码，往往也是设计糟糕的代码，例如，一个函数引用大量全局变量，依赖大量外部东西，流程混乱，出口众多，这就是很难测试的代码，往往也意外着设计非常糟糕的代码。因此单元测试还能发现代码结构设计的问题。

　　3. 增强开发人员通过单元测试对自己代码的信心 - 没写一个函数就对它进行单元测试，不仅在最早就消灭了bug，而且使得开发人员对自己的代码很有信心。与之相反的是，前期没写一个函数都不测试，最后整合起来一跑，问题一大堆，而且到时候也想不起来怎么解决；事实上后期往往发现这种系统测试耗费的时间比预想的多得多，有的甚至超出项目预期耗费的测试时间的一倍以上，究其原因，很多“小零件”前期并没有好好严密的进行测试就来到了总装厂进行总装，这样消耗的时间能不多吗？各个“小零件”中边界条件，异常情况，逻辑分支都存在这样那样的缺陷，导致系统千疮百孔，然后各自开始扯皮推脱责任，这样的系统测试的确难度太大。因此必须从源头上消除这种恶性循环。

　　4. 加强开发人员单元测试的培训 - 如何在vs2008中进行单元测试（步骤真是简单的不能再简单了，大家可以搜索一下<vs2008 单元测试>），也没有以前的private函数测试麻烦的问题；如何用Mock（具体使用开源的MoQ）来模拟数据库操作、Socket操作、文件操作、其他服务的依赖等等（具体使用大家可以搜索一下<MoQ>，http://code.google.com/p/moq/很简单）。如果程序员A需要调用程序员B开发的一个服务接口，而程序员B还在开发这个接口的实现，程序员A使用Mock就对自己的代码进行测试了。