软件危机是软件界甚至整个计算机界最热门的话题。为了解决这场危机，软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况，那就是软件中有错误，正是这些错误导致了软件开发在成本、进度和质量上的失控。
软件的质量不仅是体现在程序的正确性上，它和编码以前所做的需求分析，软件设计也密切相关。这时，对错误的纠正往往不能通过可能会诱发更多错误的简单的修修补补，而必须追溯到软件开发的最初阶段。因此，为了保证软件的质量，我们应该着眼于整个软件生存期，特别是着眼于编码以前的各开发阶段的工作。于是，软件测试的概念和实施范围必须扩充，应该包括在整个开发各阶段的复查、评估和检测。由此，广义的软件测试实际是由确认、验证、测试三个方面组成。
在整个软件生存期，确认、验证、测试分别有其侧重的阶段。确认主要体现在计划阶段、需求分析阶段、也会出现在测试阶段；验证主要体现在设计阶段和编码阶段；测试主要体现在编码阶段和测试阶段。事实上，确认、验证、测试是相辅相成的。确认无疑会产生验证和测试的标准，而验证和测试通常又会帮助完成一些确认，特别是在系统测试阶段。
传统的测试计算机软件的策略是从“小型测试”开始，逐步走向“大型测试”。即我们从单元测试开始，然后逐步进入集成测试，最后是有效性和系统测试。在传统应用中，单元测试集中在最小的可编译程序单位――子程序(如，模块、子例程、进程)，一旦这些单元均被独立测试后，它被集成在程序结构中，这时要进行一系列的回归测试以发现由于模块的接口所带来的错误和新单元加入所导致的副作用，最后，系统被作为一个整体测试以保证发现在需求中的错误。
面向对象程序的结构不再是传统的功能模块结构，作为一个整体，原有集成测试所要求的逐步将开发的模块搭建在一起进行测试的方法已成为不可能。而且，面向对象软件抛弃了传统的开发模式，对每个开发阶段都有不同以往的要求和结果,已经不可能用功能细化的观点来检测面向对象分析和设计的结果。因此，传统的测试模型对面向对象软件已经不再适用。
1 面向对象测试模型
面向对象的开发模型突破了传统的瀑布模型，将开发分为面向对象分析（OOA），面向对象设计（OOD），和面向对象编程（OOP）三个阶段。针对这种开发模型，结合传统的测试步骤的划分，我们把面向对象的软件测试分为：面向对象分析的测试，面向对象设计的测试，面向对象编程的测试，面向对象单元测试，面向对象集成测试，面向对象系统测试。
2 面向对象分析的测试
传统的面向过程分析是一个功能分解的过程，是把一个系统看成可以分解的功能的集合。这种传统的功能分解分析法的着眼点在于一个系统需要什么样的信息处理方法和过程，以过程的抽象来对待系统的需要。而面向对象分析（OOA）是"把E-R图和语义网络模型，即信息造型中的概念，与面向对象程序设计语言中的重要概念结合在一起而形成的分析方法"，最后通常是得到问题空间的图表的形式描述。OOA直接映射问题空间，全面的将问题空间中实现功能的现实抽象化。将问题空间中的实例抽象为对象，用对象的结构反映问题空间的复杂实例和复杂关系，用属性和操作表示实例的特性和行为。对一个系统而言，与传统分析方法产生的结果相反，行为是相对稳定的，结构是相对不稳定的，这更充分反映了现实的特性。OOA的结果是为后面阶段类的选定和实现，类层次结构的组织和实现提供平台。因此，对OOA的测试，应从以下方面考虑：
对认定的对象的测试
对认定的结构的测试
对认定的主题的测试
对定义的属性和实例关联的测试
对定义的服务和消息关联的测试
3 面向对象设计的测试
通常的结构化的设计方法，用的"是面向作业的设计方法，它把系统分解以后，提出一组作业，这些作业是以过程实现系统的基础构造，把问题域的分析转化为求解域的设计，分析的结果是设计阶段的输入"。而面向对象设计（OOD）采用"造型的观点"，以OOA为基础归纳出类，并建立类结构或进一步构造成类库，实现分析结果对问题空间的抽象。由此可见，OOD不是在OOA上的另一思维方式的大动干戈，而是OOA的进一步细化和更高层的抽象。所以，OOD与OOA 的界限通常是难以严格区分的。OOD确定类和类结构不仅是满足当前需求分析的要求，更重要的是通过重新组合或加以适当的补充，能方便实现功能的重用和扩增，以不断适应用户的要求。因此，对OOD的测试，应从如下三方面考虑：
对认定的类的测试
对构造的类层次结构的测试
对类库的支持的测试
4 面向对象编程的测试
典型的面向对象程序具有继承、封装和多态的新特性，这使得传统的测试策略必须有所改变。封装是对数据的隐藏，外界只能通过被提供的操作来访问或修改数据，这样降低了数据被任意修改和读写的可能性，降低了传统程序中对数据非法操作的测试。继承是面向对象程序的重要特点，继承使得代码的重用率提高，同时也使错误传播的概率提高。多态使得面向对象程序对外呈现出强大的处理能力，但同时却使得程序内"同一"函数的行为复杂化，测试时不得不考虑不同类型具体执行的代码和产生的行为。
面向对象程序是把功能的实现分布在类中。能正确实现功能的类，通过消息传递来协同实现设计要求的功能。因此，在面向对象编程（OOP）阶段，忽略类功能实现的细则，将测试的目光集中在类功能的实现和相应的面向对象程序风格，主要体现为以下两个方面。
数据成员是否满足数据封装的要求
类是否实现了要求的功能
5 面向对象的单元测试
传统的单元测试的对象是软件设计的最小单位――模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。
当考虑面向对象软件时，单元的概念发生了变化。封装驱动了类和对象的定义，这意味着每个类和类的实例(对象)包装了属性(数据)和操纵这些数据的操作。而不是个体的模块。最小的可测试单位是封装的类或对象，类包含一组不同的操作，并且某特殊操作可能作为一组不同类的一部分存在，因此，单元测试的意义发生了较大变化。我们不再孤立地测试单个操作，而是将操作作为类的一部分。
6 面向对象的集成测试
传统的集成测试，有两种方式通过集成完成的功能模块进行测。（一）自顶向下集成：自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。（二）自底向上集成：自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试。
因为面向对象软件没有层次的控制结构，传统的自顶向下和自底向上集成策略就没有意义，此外，一次集成一个操作到类中(传统的增量集成方法)经常是不可能的，这是由于“构成类的成分的直接和间接的交互”。对OO软件的集成测试有两种不同策略，第一种称为基于线程的测试，集成对回应系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，应用回归测试以保证没有产生副作用。第二种称为基于使用的测试，通过测试那些几乎不使用服务器类的类(称为独立类)而开始构造系统，在独立类测试完成后，下一层的使用独立类的类，称为依赖类，被测试。这个依赖类层次的测试序列一直持续到构造完整个系统。
7 面向对象的系统测试
通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要。为此，对完成开发的软件必须经过规范的系统测试。系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全"再现"问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。
面向对象测试的整体目标――以最小的工作量发现最多的错误――和传统软件测试的目标是一致的，但是OO测试的策略和战术有很大不同。测试的视角扩大到包括复审分析和设计模型，此外，测试的焦点从过程构件(模块)移向了类。
不论是传统的测试方法还是面向对象的测试方法，我们都应该遵循下列的原则：
1.应当把“尽早和不断地测试”作为开发者的座右铭。
2.程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
3.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
8.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
