面向对象技术所独有的多态、继承、封装等新特点，使OO程序设计比传统语言程序设计产生错误的可能性增大，使得传统软件测试中的重点不再显得那么突出，也使原来测试经验和实践证明的次要方面成为了主要问题。
用户使用低质量的软件，在运行过程中会产生各种各样的问题，可能带来不同程度的严重后果，轻者影响系统的正常工作，重者造成事故和财产损失。软件测试是保证软件质量的最重要的手段，它使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求，弄清预期结果与实际结果之间的差别。
面向对象技术是一种全新的软件开发技术，正逐渐代替被广泛使用的面向过程的开发方法，被看成是解决软件危机的新兴技术。尽管面向对象技术的基本思想保证了软件应该有更高的质量，但实际情况却并非如此，因为无论采用什么样的编程技术，编程人员的错误都是不可避免的，而且由于面向对象技术开发的软件代码重用率高，更需要严格测试，以避免错误的繁衍。
一、评审
因为OOA、OOD阶段所建立的OOA和OOD模型不能执行，所以在每次迭代之后，一定要进行评审。
1．正确性
OO开发模式为演化（重复迭代）性质，即系统的初期为非形式化表示，以后发展为类的细节模型、类的连接和关联，系统设计和配置，以及对类的设计（通过消息组成对象连接模型）。每一阶段都要进行评审。
正确性主要在分析和设计模型表示所使用的符号语法是否正确，语义是否正确（即模型与真实世界领域是否一致），以及类的关联（实例间的联系）是否正确地反映了真实世界对象间的关联。
2．一致性
由于演化性质，OOA和OOD模型（包括分析、设计和编码层次，即类、属性、操作、消息）不仅要正确，而且要一致。一致性可以用模型内各实体间的关联性来判断。
二、测试
1．单元测试
OOP完成以后，就可以进行单元测试了。与传统的单元（模块）不同，OO中的单元是类。每个类都封装了属性（数据）和管理这些数据的操作（也被称做方法或服务）。一个类可以包含许多不同的操作，一个特殊的操作可以出现在许多不同的类中。
传统的单元测试只能测试一个操作（功能）。而在OO单元测试中，一个操作功能只能作为一个类的一部分，类中有多个操作（功能），就要进行多个操作的测试。
另外，父类中定义的某个操作被许多子类继承。但在实际应用中，不同子类中某个操作在使用时又有细微的不同，所以还必须对每个子类中某个操作进行测试。
类的测试可以使用多种方法，如基于故障的测试、随机测试和分割测试等。每一种方法都要检查封装在类中的操作，即设计的测试序列（用例），要保证相关的操作被检查。因为类的属性值表示类的状态，由此来确定被检查的错误是否存在。
2．组装测试
传统软件的层次模块间存在着控制关系，而OO软件没有层次控制结构。所以传统的自顶向下和自底向上的组装策略在OO软件组装测试中就没有意义了。
另外，一个类每次组装一个操作（传统软件的增量法）在OO软件组装中是不够的，因为组成类的各个成分之间存在着直接或间接的交互作用。OO软件的组装测试有两种不同的策略：
（1）基于线程测试(thread-based-testing) 基于线程的测试就是把合作对应一个输入或事件的类集合组装起来，也就是用响应系统的一个输入或一个事件的请求来组装类的集合。对每个线程都要分别进行组装和测试。
（2）基于使用测试(use-based-testing) 基于使用的测试就是按分层来组装系统，可以先进行独立类的测试。在独立类测试之后，下一个类的层次叫从属类。从属类用独立类进行测试。这种从属类层的顺序测试直到整个系统被构造完成。传统软件使用驱动程序和连接程序作为置换操作，而OO软件一般不用。
OO系统组装时还必须进行类间合作（强调上下级关系）的测试。类的合作测试与单个类测试相似，可用随机应用和分割测试来完成。另外，还可以用基于脚本测试和行为模型导出的测试进行。
3．确认测试
确认测试是在系统层进行测试，因此类间的联系细节出现了。与传统软件一样，OO软件确认测试也主要集中在用户可见活动和用户可识别的系统输出上，所以OO软件也使用传统软件的黑盒子测试方法。确认测试大多使用基于脚本（scenarios）的测试，因而使用用例成为确认测试的主要驱动器。
三、测试用例设计
这种设计目前正处于形成阶段。
传统软件测试用例设计是从软件的各个模块的算法细节得出的，而OO软件测试用例则着眼于适当的操作序列，以实现对类的说明。
黑盒子测试不仅适用于传统软件，也适用OO软件测试。白盒子测试也用于OO软件类的操作定义。但OO软件中许多类的操作结构简明，所以有人认为在类层上测试可能要比传统软件中的白盒子测试方便。
OO测试用例设计包含OO概念，在OO度量中所讲的五个特性:局域性、封装性、信息隐藏、继承性和对象的抽象，肯定会对用例设计带来额外的麻烦和困难。
Berard提出了一些测试用例的设计方法，主要原则包括:
（1）每个测试用例应当给予特殊的标识，并且还应当与测试的类有明确的联系。
（2）测试目的应当明确。
（3）应当为每个测试用例开发一个测试步骤列表。这个列表应包含以下一些内容：
列出所要测试对象的专门说明。
列出将要作为测试结果运行的消息和操作。
列出测试对象可能发生的例外情况。
列出外部条件（即为了正确对软件进行测试所必须有的外部环境的变化）。
列出为了帮助理解和实现测试所需要的附加信息。
1．基于故障的测试
在OO软件中，基于故障的测试具有较高的发现可能故障的能力。由于系统必须满足用户的需求，因此，基于故障的测试要从分析模型开始，考察可能发生的故障。为了确定这些故障是否存在，可设计用例去执行设计或代码。
基于故障测试的关键取决于测试设计者如何理解“可能的错误”。而在实际中，要求设计者做到这点是不可能的。
基于故障测试也可以用于组装测试，组装测试可以发现消息联系中“可能的故障”。
“可能的故障”一般为意料之外的结果、错误地使用了操作/消息、不正确引用等。为了确定由操作（功能）引起的可能故障必须检查操作的行为。
这种方法除用于操作测试外，还可用于属性测试，用以确定其对于不同类型的对象行为是否赋予了正确的属性值。因为一个对象的“属性”是由其赋予属性的值定义的。
应当指出，组装测试是从客户对象（主动），而不是从服务器对象（被动）上发现错误。正如传统的软件组装测试是把注意点集中在调用代码而不是被调用代码一样，即发现客户对象中“可能的故障”。
