3.4 不管怎样， 集成测试将会抓住所有的Bug。
我们已经在前面的讨论中从一个侧面对这个问题进行了部分的阐述。 这个论点不成立的原因在于规模越大的代码集成意味着复杂性就越高。
如果软件的单元没有事先进行测试， 开发人员很可能会花费大量的时间仅仅是为了使软件能够运行， 而任何实际的测试方案都无法执行。
一旦软件可以运行了， 开发人员又要面对这样的问题： 在考虑软件全局复杂性的前提下对每个单元进行全面的测试。 这是一件非常困难的事情，
甚至在创造一种单元调用的测试条件的时候， 要全面的考虑单元的被调用时的各种入口参数。 在软件集成阶段， 对单元功能全面测试的复杂程度远远的超过独立进行的单元测试过程。
最后的结果是测试将无法达到它所应该有的全面性。 一些缺陷将被遗漏， 并且很多Bug将被忽略过去。
让我们类比一下， 假设我们要清洗一台已经完全装配好的食物加工机器! 无论你喷了多少水和清洁剂， 一些食物的小碎片还是会粘在机器的死角位置，只有任其腐烂并等待以后再想办法。 但我们换个角度想想， 如果这台机器是拆开的， 这些死角也许就不存在或者更容易接触到了，并且每一部分都可以毫不费力的进行清洗。
3.5 它的成本效率不高
一个特定的开发组织或软件应用系统的测试水平取决于对那些未发现的Bug的潜在后果的重视程度。
这种后果的严重程度可以从一个Bug引起的小小的不便到发生多次的死机的情况。 这种后果可能常常会被软件的开发人员所忽视(但是用户可不会这样)，这种情况会长期的损害这些向用户提交带有Bug的软件的开发组织的信誉， 并且会导致对未来的市场产生负面的影响。 相反地，一个可靠的软件系统的良好的声誉将有助于一个开发组织获取未来的市场。
很多研究成果表明， 无论什么时候作出修改都要进行完整的回归测试， 在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。
Bug发现的越晚， 修改它所需的费用就越高， 因此从经济角度来看， 应该尽可能早的查找和修改Bug。 在修改费用变的过高之前，单元测试是一个在早期抓住Bug的机会。
相比后阶段的测试， 单元测试的创建更简单， 维护更容易， 并且可以更方便的进行重复。 从全程的费用来考虑， 相比起那些复杂且旷日持久的集成测试，
或是不稳定的软件系统来说， 单元测试所需的费用是很低的。
4。 一些图表
这些图表摘自<<实用软件度量>>(Capers Jones， McGraw-Hill 1991)， 它列出了准备测试， 执行测试，
和修改缺陷所花费的时间(以一个功能点为基准)， 这些数据显示单元测试的成本效率大约是集成测试的两倍， 系统测试的三倍(参见条形图)。
文章来源于领测软件测试网 https://www.ltesting.net/