软件测试作为软件质量保证的重要手段已引起软件用户和开发人员越来越多的关注。然而在对测试认识逐渐深化的过程中，首先应该弄清几个问题。

　　非进行测试不可吗？

　　世界软件市场将有一个突飞猛进的发展，应用程序的类型越来越复杂，从传统客户/服务器应用，到基于浏览的Internet/Intranet应用，再到混合型应用等等。在这些大量的、日渐复杂的应用程序中，由于GUI的对象丰富，使得状态组合数量巨增；软、硬件来自不同厂商，程序运行环境复杂；版本不断升级以及同时使用某个厂家的不同版本，致使程序运行环境经常改变；并发用户的数量逐渐增多，对性能要求不断提高等等。可见，随着软件业的发展，测试成为必然。

　　据统计，在软件开发总成本中，用在测试上的开销要占30%到50%。如果把维护阶段考虑在内，讨论整个软件生存期时，测试的成本比例也许会有所降低，但实际上维护工作相当于二次开发，乃至多次开发，其中必定还包含有许多测试工作。因此，有人估计软件工作有50%的时间和50%以上的成本花在测试工作上。因此，测试是必需的，问题是我们应该思考“采用什么方法、如何安排测试？”

　　测试和调试可以相互替代吗？

　　为了判断应用系统是否合格，而用预先确定的一系列数据在系统中运行，并与预期的结果进行比较，这一过程称为测试。它是软件质量保证的重要手段。然而，有些人往往把测试和调试混为一谈，这是不正确的。

　　简单地说，测试是一种检验，经过测试人们会看到一些现象。这些现象也许是可疑的征兆，但往往不能直接从测试的结果中找到错误的根源。这就需要充分利用测试结果和测试提供的信息进行全面分析，以便找到错误的根源和出现错误的原因。紧接着便是纠正已发现的错误。测试以后进行的这些工作称为调试或排错。

　　我们不能把两者混为一谈。但它们毕竟有着密切的关系，常常是在测试以后紧接着要着手排错。实际上，这两种工作经常交叉进行，是不可相互替代的。

　　科学的测试应从何时开始？

　　有一种传统的观念认为：“应用系统开发完毕，再对它进行测试。”用这种思想来指导测试工作是相当危险的。

　　对于软件质量的判断决不只限于程序本身，它和编码以前所完成的需求分析及软件设计工作密切相关。很显然，表现在程序中的错误，并不一定是编码所引起的，很可能是详细设计、概要设计阶段，甚至是需求分析阶段的问题引起的。错误在初期也许只是范围很小的隐藏问题，但由于各开发阶段的连续性，使其逐步扩展。如果早期开发中出现的错误不能及时发现和解决，将带到设计、编码、测试等各阶段，影响会逐步扩大。这就要付出不必要的人力、物力来修正错误。可见，解决问题、纠正错误应追溯到前期的工作，越早着手越好。科学的测试是贯穿整个产品生命周期中的测试。

　　考虑到以上这些情况，我们将测试分成如下阶段：模块测试、集成测试、确认测试和系统测试。对程序的最小单位——模块进行测试，是为了检验每个模块能否单独工作，从而发现模块的编码问题和算法问题；集成测试是将多个模块连接起来，以检验概要设计中对模块之间接口设计的问题；确认测试则应以需求规格说明书中的规定作为检验尺度，发现需求分析的问题；最后的系统测试是将开发的软件与硬件和其他相关因素（如人员的操作、数据的获取等）综合起来进行全面检验，这样的做法涉及到软件需求以及软件与系统中其他方面的关系。

　　我们应着眼于整个软件生存期，特别是着眼于编码以前各开发阶段的测试工作，以保证软件的质量，这就要突破原来对测试的理解。据有关机构研究表明：在开发周期中，每推后一步实施错误检查，成本就会增加10%。因此，查找、修改错误的最佳开始时间是在项目设计阶段，之后还要伴随着开发过程的每一个环节，保证测试与开发的同步进行。

　　对软件能够做到彻底测试吗？

　　既然测试的目的就是查找软件中的错误，那么为了得到高质量的软件，能不能借助测试工具将所有隐藏的错误全部找出来呢？

　　我们知道，只有对应用的每一个运行环境、语句、条件分支、路径等进行穷举测试，才能确保测试的彻底性。但往往这种做法工作量过大，所用时间过长，实际是不现实的，因而也就失去了实用价值。软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试开发项目。在测试阶段既然穷举测试是不现实的，为了节省时间和资源，提高测试效率，就必须精心设计测试用例，这样采用这些测试数据能够取得最佳的测试效果。掌握测试量的度是至关重要的。一位有经验的软件开发管理人员在谈到软件测试时曾这样说过：“不充分的测试是愚蠢的，而过度的测试是一种罪孽。”测试不足意味着让用户承担隐藏错误带来的危险；过度测试则会浪费许多宝贵的资源。到测试后期，即使找到了错误，然而已经付出了过高的代价。总之，进行测试是为了使软件中蕴涵的缺陷低于某一特定阈值，使产出/投入比达到最大。