单元一这里会出现错误吗？

　　单元二这里会出现错误吗？

　　两个单元都会出现错误吗？

　　两个单元之间的地方会出现错误吗？

　　会因为测试的缺陷出现错误吗？

　　将模块直接集合在一起进行测试远比先独立测试每一个单元模块，然后再将它们集合在一起进行测试要复杂的多。

　　驱动和存根可重复使用，在开发周期中不断发生的变化可以经常进行重新测试，而无需编写大量的额外测试代码。事实上，这减少了每次编写驱动和存根的成本，并且对重复测试的成本也更好控制。

　　k、集成测试

　　集成测试是单元测试逻辑上的延伸。最简单的测试形式是，在完成了两个单元的单元测试后，将这两个单元组合成一个组件，测试两单元之间的界面。这里组件的意思是指多个单元的综合。在真实的场景中，很多单元被合并成组件，这些组件又被合并成更大的部分。这个想法是测试组合件，最终扩大测试该组模块与别组模块的过程。最终所有模块将并一起进行测试。除此之外，如果程序是多个进程组成，它们应该成对测试，而不是一次性全部一起测试。

　　集成测试是在将单元结合在一起的时候发现错误。通过使用一个测试计划，测试每一个单元，并在合并单元前确保每个单元的都是ok的。你就会知道在合并单元时发现的错误就可能和单元间的界面有关系。利用这种方法，可以将推测错误位置的可能性降低到一个简单的多的分析水平上。

　　集成测试有很多种方法，以下三种是最常见的：

　　自上而下的方法：需要测试最高级别的模块，并且先集成起来。这使得在过程中要先测试高层次的逻辑和数据流，往往最小化了驱动的需要。然而，存根的需求使测试管理复杂化。并且在软件开发生命周期中，低级别的往往在后面测试。自上而下的集成测试另外个不好的地方在于它不支持有限功能的提前释放。

　　自下而上的方法：需要测试最低级别的单元，并且先集成起来。这些单元常常被称为公用模块。通过使用这个方法，在开发过程早期测试公用模块，存根的需要就被最小化了。不过这个方法的缺点就是驱动的需求使测试管理复杂化，并且高级别的逻辑和数据流往往在后面测试。像自上而下的方法一样，自下而上的方法同样不支持有限功能的提前释放。

　　第三个方法，有时也被称为伞方法，需要沿着函数数据和控制流路径来测试。首先，函数的输入是集成在上面讨论的自下而上的模式中。然后，函数的输出是集成在自上而下的模式中。该方法最主要的优势在于它支持有限功能的提前释放。并且它将存根和驱动的需求最小化。该方法潜在的弱点是显著的，它比其他两种方法要欠缺系统性，导致需要更多的回归测试。

　　l、验收测试

　　用户验收测试常常是推出程序之前的最后一步测试。

　　通常，使用程序的最终用户会在接受程序前对应用程序进行测试。这种形式的测试使最终用户对交付到他们手上的应用程序质量更具有信心。该测试也能帮助发现程序在可用性上的缺陷。该测试有两种测试类型，分别是Alpha测试和Beta测试。

　　Alpha和Beta测试

　　Alpha测试在开发员的站点上进行，在发行给外面客户使用前，先由内部工作人员对业务系统进行测试。

　　Beta测试在客户的站点上进行，在发行给别的客户前，先由一组顾客在他们自己的站点上使用该系统对其进行测试。后者通常被称为“现场测试”。

　　m、系统测试

　　系统测试对软件整体进行测试。在一个有代表性的企业里，由程序员来做单元测试。这保证了每一个组件都正常工作。集成测试关键在于软件各个部分的成功组合（组件或单元代码）。一旦组件被组合到一块，整个系统就需要进行彻底的测试来保证它达到质量标准。

　　因此系统测试建立在单元测试和集成测试的基础上。通常一个专业的测试团队是有责任做系统测试的。系统测试在质量管理过程中是关键性的一步。

　　为什么系统测试如此重要？

　　在软件开发生命周期中，系统测试在系统作为一个整体进行测试中是第一级的。通过测试系统来检验它是否达到功能和技术上的要求。应用程序/系统是在一个很类似于生产环境的环境下进行测试的，那里应用程序最后要被释放。系统测试让我们测试、检验并确认产品无论在业务需求还是体系结构上是否都达到标准。