单元测试的另一个比较重要的特点是能并行进行，这通常是由于构件或者模块之间的非相关性造成的。这点在测试中很重要，通常会大大缩短测试时间。

　　为了更好的进行单元测试，软件需要设计的高内聚，也是设计之初要采用好的设计模式。这点毫无疑问。

　　集成测试：

　　以前，我一直想这样一个问题：如果每个模块都是正确的，为什么要担心将它们集成在一起后的结果呢?后来在多次参与团队合作项目之后，终于意识到集成检测(即使这样还是没意识到集成测试，而仅仅是集成检测)的重要性。关键还是“接口”一词。数据在模块之间流动时可能部分丢失甚至更改;在一些设计不好的软件中，或者说不可避免的在所有软件中，模块之间会有影响;全局数据结构等等。而这些问题在多个模块之间很可能会迭代扩大到无法承受的地步。

　　一个不是很恰当的例子，在TCP/IP协议中，网络层的IP协议与传输层的TCP协议都是设计良好的协议，单独工作都很好，但是集成起来以后必须增加像ICMP这样的辅助协议才能协调工作。


　　一个更加危险的倾向是，集成的错误常常是非增量式的。也是说，系统在第一次集成时会报一大堆的错误，这是因为，错误会在构件之间进行传递。而且，一旦改正了某个错误，反而会出现一系列的新的错误，以此类推。

　　由此可见，集成测试是比单元测试更重要也更复杂的测试过程。为了解决这个问题，计算机界的先辈们(PS：大多数是国外的人，哎)提出了许多富有成效的继承测试策略，比如自顶向下集成测试、自底向下集成测试、回归测试、冒烟测试等等。太麻烦了，我不浪费版面的(其实是我也讲不太清，?)。有兴趣的朋友可以google之。

 

　　确认测试：

 

　　确认测试在前面已经提到过了，是为软件满足完备的功能，行为以及性能，交互需求等提供后的保证。

　　系统测试：

　　这后的一步实际上已经超出了一半编程人员或者说是测试人员的工程范围。我们知道，软件的运行并不只是软件本身的结构，而是与硬件、数据库、操作人员、市场环境共同参与的结果。软件的系统测试必须考虑所有的这些因素，这也是为什么我们说你永远不能完成测试，这个任务只会从软件开发人员转移到客户身上的原因。

　　1.4 软件测试成功的标准

 

　　我想，这是许多关注这篇文章的人关心的问题之一：测试工作要做到什么时候?

 

　　关于这个问题我当初也是很感兴趣，我遍查了很多书籍，也在网上搜了很多牛人对这个问题的回答，可惜，一直没找到一个大众的回答。许多回答都只是经验之谈。

 

　　一个比较大众的回答是：测试工作不可能完成，多是这个工作由程序员转移到客户身上。这和峰哥经常强调的“程序没有完成的(咆哮语气)!!”观点类似。


　　另一种回答稍显无聊，但又是非常准确的：一直测试，知道你时间或是资金不能支持为止。