【文章摘要】
面向对象的软件测试摘 要: 如今，面向对象开发技术正大力地的推动着软件产业的快速发展。在保证软件产品质量的手段中，最有效、最重要的技术要数软件测试技术。然而，传统的测试技术和方法，对面向对象技术开发的的软件多少显得有些力不从心。鉴于此，提出了面向对象的测试技术！在此，本文通过翻阅大量的文献，总结出着实有效的面向对象的软件测试技术。首先，阐明面向对象软件测试的基本概念；然后，分别讨论分析和设计……
【文章正文】
面向对象的软件测试
摘 要: 如今，面向对象开发技术正大力地的推动着软件产业的快速发展。在保证软件产品质量的手段中，最有效、最重要的技术要数软件测试技术。然而，传统的测试技术和方法，对面向对象技术开发的的软件多少显得有些力不从心。鉴于此，提出了面向对象的测试技术！
在此，本文通过翻阅大量的文献，总结出着实有效的面向对象的软件测试技术。首先，阐明面向对象软件测试的基本概念；然后，分别讨论分析和设计模型测试技术、类测试技术、对象交互测试技术、类层次结构测试技术、面向对象系统测试技术；最后，对面向对象软件测试的实施进行小结。
关键词：面向对象；软件测试；类测试；对象交互；测试用例
Object-Oriented Software Test
Abstract：Now, Object-Oriented development technique is strongly pushing the fast development of the software industry．In the means of the assurance software product quality, most valid，the most important technique wants the few software test technique．However, the traditional test technique and method, the opposite develops toward the object technique of software how much seem to be some to lack the ability to do．Owing to this, put forward to the Object-Oriented test technology!
Here, this text passes to browse a great deal of cultural heritage, tallying up to really effectively Object-Oriented software test technique。First, clarify the basic concept of Object-Oriented software test；then, discuss respectively the Class test technique；a test technique，object hands over to with each other test the technique，a layer structure test technique, the distribute type object test technique and face to the object system test technique; finally，the implement that tests toward the object software in front carries on the sub-footing.
Key Words：Object-Oriented ；Software test；Class test；Object interact；Test case
引 言
软件测试的发展历程 软件测试是伴随着计算机软件的产生而产生的。在早期软件开发的过程中，软件就是由程序员写的简单计算机程序代码。因而，软件测试的含义比较狭窄 ---- 测试等同于 “调试”。软件测试的目的就是为寻找和纠正软件中的故障，这部分的工作常常由开发人员自己完成。
直到上世纪 80 年代早期，“质量” 的号角才开始吹响。软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。制定了各类标准，包括 IEEE（Institute of Electrical and Electronic Engineers）标准、美国 ANSI（American national Standard Institute）标准以及 ISO（International Standard Organization）国际标准。1983 年，Bill Wetzel 在《软件测试完全指南》（Complete Guide of Software Testing）一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度。”Myers 和 Wetzel 的定义至今仍被引用。
到了 2002 年，Rick 和 Stefan 在《系统的软件测试》（Systematic Software Testing）中对软件测试做了进一步定义：“测试是为了度量和提高被测软件的质量，对测试件进行工程设计、实施和维护的整个生命周期过程。” 这些经典论著对软件测试研究的理论化和体系化产生了巨大的影响。
近 20 年来，随着计算机和软件技术的飞速发展，软件测试技术研究也取得了很大的突破。测试专家总结了很好的测试模型，比如著名的 V 模型、W 模型等，在测试过程改进方面提出了 TMM（Testing Maturity Model）的概念，在单元测试、自动化测试、负载压力测试以及测试管理等方面涌现了大量优秀的软件测试工具。
虽然软件测试技术的发展很快，但是其发展速度仍落后于软件开发技术的发展速度，使得软件测试在今天面临着很大的挑战。软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题。尤其是面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步。
面向对象软件开发过程及其特点 面向对象的开发方法（简称 OO）的基本思想认为，客观世界是由各种各样的对象组成的，每种对象都有各自的内部状态和运动规律，不同的对象之间的相互作用和联系就构成了各种不同的系统。故面向对象软件开发的工作过程为：
1. 调查、分析系统需求，建立一个全面、合理、统一的模型。
2. 在繁杂的问题域中抽象地识别出对象以及其行为、结构、属性、方法
3. 对象设计——即对分析的结果作进一步地抽象、归类、整理，并最终以范式的形式将它们确定下来。
4. 程序实现——即用面向对象的程序设计语言将上一步整理的范式直接映射（直接用程序语言来取代）为应用程序软件。
面向对象开发的特点是遵循一下三项原则：
1. 抽象原则（abstraction）——指为了某一分析目的而集中精力研究对象的某一性质，它可以忽略其它与此目的无关的部分
2. 封装原则（encapsulation）即信息隐藏——指在确定系统的某一部分内容时，应考虑到其它部分的信息及联系都在这一部分的内部进行, 外部各部分之间的信息联系应尽可能的少。
3. 继承原则（inheritance）——指能直接获得已有的性质和特征而不必重复定义它们
1. 面向对象的软件测试的基本概念
面向软件测试技术是新兴的软件测试技术，是专门针对使用面向对象技术开发的软件而提出的一种测试技术。其目的是为了解决传统的软件测试技术，面对面向对象技术开发的软件多少显得有些力不从心的现象。面向对象开发技术和传统的开发技术相比，新增了多态、继承、封装等特点。这些新特点使得开发出来的程序，具有更好的结构更规范的编程风格, 极大地优化了数据使用的安全性, 提高了代码的重用率。由此可见，它们是面向对象开发技术产生巨大吸引力的重要因素。然而，另一方面也影响了软件测试的方法和内容；增加了软件测试的难度；带来了传统软件设计技术所不存在的错误；或者使得传统软件测试中的重点不再显得突出；或者使原来测试经验认为和实践证明的次要方面成为了主要问题。
面向对象软件测试是根据面向对象的软件开发过程结合面向对象的特点提出的。它包括分析与设计模型测试技术、类测试技术、对象交互测试技术、类层次结构测试技术、面向对象系统测试技术五大部分。下面分别围绕这五部分展开讨论。
2. 分析和设计模型测试技术
面向对象软件开发的起始步骤是开发分析和设计模型。UML（统一建模语言）能在面向对象技术开发中广泛应用，也是因为构建模型能帮助开发者理解正在解决的问题；构建模型能帮助管理正在开发的系统的复杂性；分析和设计阶段建构的模型最后将对具体地实现起指导作用。如果模型的质量很高对项目来说就很有价值；但是如果模型有错误，那么它对项目的危害就无可估量。
2.1. 分析和设计模型测试的内容
分析和设计模型测试的重点是测试模型的完整性和一致性, 其主要内容有：
1. 对确定的对象的测试；
2. 对确定的结构的测试；
3. 对确定的主题的测试；
4. 对定义的属性和实例关联的测试；
5. 对定义的服务和消息关联的测试。
2.2. 分析和设计模型测试的方法
分析与设计模型的测试主要是对分析与设计模型进行测试，找出模型中的错误，其采用的方法是指导性审查 (guided inspection)。指导性审查技术通过使用明确的测试用例为查找工作成果中的缺陷提供了客观的、系统的方法。是一种增强了的专为检验模型的检测技巧，也可用来验证模型是否能符合项目的需求。其基本步骤如下：
1. 定义测试位置。
2. 使用特定的策略从测试位置选择测试值。
3. 将测试值应用到被测试的产品中。
4. 对测试结果以及对模型的测试覆盖率（基于某中标准）进行评估。
这些步骤经过具体化后形成下列详细步骤：
1. 制订检查的范围和深度：范围将通过描述材料的实体或一系列详细的用例来定义。对小的项目来说，范围可以是整个模型。深度将通过指定须要测试的模型（MUT）的某种 UML 图的集合层次中的级别来定义。
2. 确定 MUT 产生的基础：除原始模型之外，所有的 UMT 的基础是前一开发阶段创建的一系列模型：比如，应用分析模型就是以域分析模型和用例模型为基础。起初模型则是基于所选择的一组人头脑里的知识。
3. 为每一个评价标准开发测试用例，标准在应用时使用基本模型的内容作为输入。这种从用户用例模型出发的方式对许多模型的测试用例来说是一个很好的出发点。
4. 为测量测试的覆盖率建立标准。比如对一个类图来说，如果图中每一个类都被测试到了，那么覆盖率就算不错了。
5. 使用合适的检查列表进行静态分析。将 MUT 与基本的模型相比较可以确定 2 个图型之间的连贯性。
6. “执行” 测试用例。
7. 使用测试用例覆盖率衡量法对测试的效率进行评价，计算覆率率百分比。比如，测试用例 “涉及” 到了包含 18 个类的类图中的 12 个类，那么测试的覆盖率就是 75%。鉴于分析和设计模型的测试如此高级，以至于要达到好的结果，必须有 100% 的覆盖率。
8. 如果覆盖率不充分，就要对测试进行扩充并应用额外的测试用例。否则终止正在进行的测试。通常无法在检查片断的过程中写下附加的测试用例。测试者确定哪些地方没有覆盖到并与开发者一起确定将触及未覆盖的模型组件的潜在的测试用例。然后，测试者创建整个的测试用例并且进行另一次检查。
采用指导性审查技术对分析和设计产生的文本进行正确性验证, 是软件开发前期的关键性测试。
3. 类测试技术
面向对象软件产品的基本组成单位是类，从宏观上来看，面向对象软件是各个类之间的相互作用。在面向对象系统中, 系统的基本构造模块是封装了的数据和方法的类和对象, 而不再是一个个能完成特定功能的功能模块。每个对象有自己的生存周期, 有自己的状态。消息是对象之间相互请求或协作的途径, 是外界使用对象方法及获取对象状态的惟一方式。对象的功能是在消息的触发下, 由对象所属类中定义的方法与相关对象的合作共同完成。且在不同状态下对消息的响应可能完全不同。工作过程中对象的状态可能被改变, 产生新的状态。对象中的数据和方法是一个有机的整体, 测试过程中不能仅仅检查输入数据产生的输出结果是否与预期的吻合, 还要考虑对象的状态，且在不同状态下对消息的响应可能完全不同。工作过程中对象的状态可能被改变, 产生新的状态。对象中的数据和方法是一个有机的整体, 测试过程中不能仅仅检查输入数据产生的输出结果是否与预期的吻合, 还要考虑对象的状态。
类测试是由那些与验证类的实现是否和该类的说明完全一致的相关联的活动组成的。该类测试的对象主要是指能独立完成一定功能的原始类。如果类的实现正确，那么类的每一个实例的行为也应该是正确的。
3.1. 类测试的内容
类测试的目的主要是确保一个类的代码能够完全满足类的说明所描述的要求．对一个类进行测试以确保他只做规定的事情，对此给与关注的多少，取决于提供额外的行为的类相关联的风险．在运行了各种类的测试后，如果代码的覆盖率不完整，这可能意味着该类包含了额外的文档支持的行为．需要增加更多的测试用例来进行测试。
3.2. 类测试的时间
类测试的开始时间一般在完全说明这个类，并且准备对其编码后不久，就开发一个测试计划——至少是确定测试用例的某种形式。如果开发人员还负责该类的测试，那么尤其应该如此。因为确定早期测试用例有利于开发人员理解类说明，也有助于获得独立代码检查的反馈。
类测试可以在开发过程中的不同位置进行。在递增的反复开发过程中，一个类的说明和实现在一个工程的进程中可能会发生变化，所以因该在软件的其它部分使用该类之前执行类的测试。每当一个类的实现发生变化时，就应该执行回归测试。如果变化是因发现代码中的缺陷（bug）而引起的，那么就必须执行测试计划的检查，而且必须增加或改变测试用例以测试在未来的测试期间可能出现的那些缺陷。
3.3. 类测试的测试人员
类测试通常由他的开发人员测试，让开发人员起到测试人员的作用，就可使得必须理解类说明的人员数量减至最少。而且方便使用基于执行的测试方法，因为他们对代码极其的熟悉。由同一个开发者来测试，也有一定的缺点：开发人员对类说明的任何错误理解，都会影响到测试。因此，最好要求另一个类的开发人员编写测试计划，并且允许对代码进行对立检查。这样就可以避免这些潜在的问题了。
3.4. 类测试的方法
类测试的方法有代码检查和执行测试用例。在某些情况下，用代码检查代替基于执行的测试方法是可行的，但是，和基于执行的测试相比，代码检查有以下两个不利之处：
1． 代码检查易受人为因素影响。
2． 代码检查在回归测试方面明显需要更多的工作量，常常和原始测试差不多。
尽管基于执行的测试方法克服了以上的缺点，但是确定测试用例和开发测试驱动程序也需要很大的工作量。在某些情况下，构造一个测试驱动程序的工作量比开发这个类的还多，此时就应该评估在使用了这个类的系统之外测试测试这个类所花的代价和带来的收益。
一旦确定了一个类的可执行测试用例，就必须执行测试驱动程序来运行每一个测试用例，并给出每一个测试用例的结果。
3.5. 测试程度
可以根据已经测试了多少类实现和多少类说明来衡量测试的充分性。对于类的测试，通常需要将这两者都考虑到，希望测试到操作和状态转换的各种组合情况。一个对象能维持自己的状态，而状态一般来说也会影响操作的含义。但要穷举所有组合式不可能的，而且是没必要的 。因此，就因该结合风险分析进行选择配对系列的组合，以致达到使用最重要的测试用例并抽取部分不太重要的测试用例。
3.6. 构建类测试用例
要对类进行测试，就必须先确定和构建类的测试用例。类的描述方法有 OCL, 自然语言，和状态图等方法，可以根据类说明的描述方法构件类的测试用例。因而，构建类的测试用例的方法有：根据类说明（用 OCL 表示）确定测试用例和根据类的状态转换图来构建类的测试用例。
根据类的说明确定测试用例 用 OCL 表示的类的说明中描述了类的每一个限定条件条件。在 OCL 条件下分析每个逻辑关系，从而得到由这个条件的结构所对应的测试用例。这种确定类的测试用例的方法叫做根据前置条件和后置条件构建测试用例。其总体思想是：为所有可能出现的组合情况确定测试用例需求。在这些可能出现的组合情况下，可满足前置条件，也能够到达后置条件。根据这些需求，创建测试用例；创建拥有特定输入值（常见值和特殊值）的测试用例；确定它们的正确输出——预期输出值。
根据前置条件和后置条件创建测试用例的基本步骤如下：
1． 确定在表 1 中与前置条件形成相匹配的各个项目所指定的一系列前置条件的影响。
2． 确定在表 2 中与后置条件形成相匹配的各个项目所指定的一系列前置条件的影响。
3． 根据影响到列表中各个项目的所有可能的组合情况从而构造测试用例需求。一种简单的方法就是：用第一个列表中的每一个输入约束来代替第二个列表中每一个前置条件。
4． 排除表中生成的所有无意义的条件。
表 1 前置条件对测试系列的影响
前置条件影 响
True(true 、post)
A(A、post)
(not A、exception) *
Not A(not A、post)
(A、exception) *
A and B(A and B、post)
(not A and B、exception) *
(A and not B、exception) *
(not A and not B、exception) *
A or B(A、post)
(B、post)
(A and B、post)
(not A and not B、post)
A xor B(not A and B、post)
(A and not B、post)
(A and B、exception) *
(not A and not B、exception) *
A implies B (not A、post)
(B、post)
(not A and B、post)
(A and not B、exception) *
if A then B
else C endif(A and B、post)
(not A and C、post)
(A and not B、exception) *
(not A and not C、exception) *
注：①．A、B、C 代表用 OCL 表示的组件。
②．假如类说明中的保护性设计方法是隐式的，那么也必须对那些标记有 * 的测试用例进行阐述。如果保护性设计方法在类的说明中是显式出现的，那么测试用例也就确定了。
表 2 后置条件对测试系列的影响
后置条件影 响
A(pre ；A)
A and B(pre ；A and B)
A or B(pre ；A)
(pre ；B)
(pre ；A or B)
A xor B(pre ；not A or B)
(pre ；A or not B)
A implies B(pre ；not A or B)
if A then B
else C endif(pre and * ；B)
(pre and not * ；C)
注：①．A、B、C 代表用 OCL 表示的组件。
②．对于 “if A then B else C endif” 这个后置条件，假如测试用例不会对表达式 A 产生影响那么在用这个后置条件时，* = A else * 就是使得 A 为真的一个条件
根据状态转换图构建测试用例 状态转换图以图例的形式说明了与一个类的实例相关联的行为。状态转换图可用来补充编写的类说明或者构成完整的类说明。状态图中的每一个转换都描述了一个或多个测试用例需求。因而，可以用过在转换的每一端选择有代表性的值和边界来满足这些需求。如果转换是受保护的，那么也应该为这些保护条件选择边界。状态的边界值取决于状态相关属性值的范围，可以根据属性值来定义每一个状态。
由此可见，和根据前置条件和后置条件创建类的测试用例相比，根据状态转换图创建类的测试用例有非常大的优势。在类的状态图中，类相关联的行为非常的明显和直观，测试用例的需求直接来自于状态转换，因而很容易确定测试用例的需求。不过基于状态图的方法也有其不利的方面。如要完全理解怎样根据属性值来定义状态；事件是如何在一个给定的状态内影响特定值等。这都很难仅从简单的状态图中确定。因此，在使用基于状态转换图进行测试时，务必在生成的测试用例时检查每个状态转换的边界值和预期值。
4. 类层次结构测试技术
继承作为代码复用的一种机制，可能是面向对象软件开发产生巨大吸引力的一个重要因素。继承由扩展、覆盖和特例化三种基本机制实现的。其中，扩展是子类自动包含父类的特征；覆盖是子类中的方法与父类中的方法有相同的名字和消息参数以及相同的接口，但方法的实现不同；特例化是子类中特有的方法和实例变量。好的面向对象程序设计要求通过非常规范的方式使用继承——即代码替代原则。在这种规则下，为一个类确定的测试用例集对该类的子类也是有效的。因此，额外的测试用例通常应用于子类。通过仔细分析根据父类定义的子类的增量变化，有时候，子类中的某些部分可以不做执行测试。因为应用于父类中的测试用例所测试的代码被子类原封不动的继承，是同样的代码。
类的层次结构测试就是用来测试类的继承关系的技术，主要是用来测试层次关系的一系列类（包括父类和子类）。其测试的方法有用于测试子类的分层增量测试和用于测试父类的抽象类测试。
4.1. 分层、增量测试
C
D
Void op1 ( );
Void op2 ( );
Void op2 ( );
Void open ( );
Newvar type;
说 明
子类 D 添加了一个新的实例变量（NewVar）和一个新的操作（newop()）。D 重载了 C 中定义的方法 op2()，因为该操作在 D 中有新的规范或操作的实现
图 1 类的派生及增量变化
分层增量测试（hierarchical incremental testing(HIT)）指通过分析来确定子类的哪些测试用例需要添加，哪些继承的测试用例需要运行，以及哪些继承的测试用例不需要运行的测试方法。如图一，展示了 C 类和它的派生类 D 类，以及它们之间的增量变化。C 类和它的派生类 D 类间的增量变化能够用来帮助确定需要在 D 中测试什么。
由于 D 类是 C 类的子类，则所有用于 C 类的基于规范的测试用例也都适用于 D 类。那么，哪些继承的测试用例（用于子类的测试用例）适用于子类的测试，哪些又不必在子类中执行呢？要解决以上问题，可通过对子类的增量分析。可能情况如下：
1. D 的接口中添加一个或多个新的操作，并且有可能 D 中的一个新方法实现一个新操作。新的操作引入了新的功能和新的代码，这些都需要测试。如果操作不是抽象的并且有具体的实现，那么为了合乎测试计划中的覆盖标准，需要添加基于规范和基于交互的测试用例。
2. 通过两种方式改变由 C 申明的操作的规范和实现：一. 在 D 中改变那些在 D 中申明的操作规范。二. 在 D 中覆盖那些在 C 中实现了某个操作并且被 D 继承了的方法。
3. 在 D 中添加一个或多个实例变量来实现更多的状态和属性。新添的变量最有可能与新的操作和重载方法中代码有关，而且对测试的处理也与他们有关。如果新的变量没有在任何地方使用，那么就不必做任何的变化。
4. 在 D 中改变类常量。类常量组成每个侧使用例的附加的后置条件，并且，“类常量句柄” 在每个测试用例输出中是显示的。因此，如果类常量变化了，就需要重新运行所有继承的测试用例以验证常量句柄。
从基类派生出派生类时，不必为那些未经变化的操作添加基于规范的测试用例，测试用例能够不加修改的复用。如果测试的操作没有以任何方式加以修改，就不必运行这些测试用例中的任何一个。但是，如果一个操作的方法被间接的修改了，不但需要重新运行那些操作的任何一个测试用例，还需要运行附加的机遇实现的测试用例。
4.2 抽象类测试
对类基于执行的测试时，需要建构一个类的实例。然而，一个继承体系的根类通常是抽象的，许多编程语言在语义上不允许建构抽象类的实例。这位抽象类的测试带来了很大的困难。在此，提出三种测试抽象类的方法：
1． 需要测试的抽象类单独定义一个具体的子类。通过对具体子类创建的实例测试，来完成对抽象类的测试。这种方法的缺点是，如果不是用多层继承，抽象类的方法的实现就不能轻易的传递给抽象子类。但是大部分面向对象的编程语言都不支持多重继承，而且不提倡将多重继承用在这些方面。
2． 将抽象类作为测试第一个具体子孙的一部分进行测试。这种方法不需要开发额外的用于测试的目的类，但需要考虑到为每一个祖先提供恰当的、正确的测试用例和测试脚本方法，而增加了测试具体类的复杂性。
3． 以对用于测试目的的抽象类的具体版本作直接实现，尝试找到一种为类编写源代码的方法，从而使得该类可以做为一个抽象或具体类而很容易编译。然而，不管是基于编辑遗产方案还是基于条件编译的方案都没有产生好的结果。应为合成代码都很复杂，而且难以阅读，很容易出错。
5．对象交互测试技术
面向对象的软件是由若干对象组成的，通过这些对象的相续协作来解决某些问题。对象的交互和写作方式决定了程序能作什么，从而决定了这个程序执行的正确性。也许可信任的原始类的实例可能不包含任何错误，但是如果那个实例的服务部被其他程序组件正确的使用的话，那么这个程序也就包含了错误。因此，程序中对象的正确协作——即交互——对于程序的正确性是非常关键的。
对象的交互测试的重点是确保对象（这些对象的类已经被单独测试过）的消息传送能够正确进行。交互测试的执行可以使用嵌入到应用程序中的交互对象，或者在独立的测试工具（例如一个 Tester 类）提供环境中，交互测试通过使得该环境中的对象相互交互而执行。
根据类的类型可以将对向交互测试分为汇集类测试和协作类测试。
5.1．汇集类测试
汇集类指的是这样的一种类，这些类在他们的说明中使用对象，但是实际上从不和这些对象中的任何一个进行协作——即他们从不请求这些对象的服务。相反，他们会表现出以下的一个或多个行为：
1. 存放这些对象的引用（或指针），通常表现程序中的对象之间一对多的关系。
2. 创建这些对象的实例。
3. 删除这些对象的实例。
可以使用测试原始类的方法来测试汇集类，测试驱动程序要创建一些实例，作为消息中的参数被传送给一个正在测试的集合。测试用例的中心目的主要是保证那些实例被正确加入集合和被正确的从集合中移出，以及测试用例说明的集合对其容量有所限制。因此，每个对象的准确的类（这些对象是用在汇集类的测试中）在确定汇集类的正确操作是不重要的，因为在一个集合实例和集合中的对象之间没有交互。假如在实际应用中可能要加入 40 到 50 条信息，那么生成的测试用例至少要增加 50 条信息。如果无法估计出一个有代表性的上限，就必须使用集合中大量的对象进行测试。
如果汇集类不能为增加的新元素分配内存，就应该测试这个汇集类的行为，或者是可变数组这一结构，往往一次就为若干条信息分配空间。在测试用例的执行期间，可以使用异常机制，帮助测试人员限制在测试用例执行期间可得到的内存容量的分配情况。如果已经使用了保护设计方法，那么，测试系列还应该包括否定系列。即当某些即和已拥有有限的制定容量，并且有实际的限制，则应该用超过指定的容量限制的测试用例进行测试。
5.2．协作类的测试
凡不是汇集类的非原始类（原始累即一些简单的，独立的类，这些类可以用类测试方法进行测试）就是协作类。这种类在它们的一个或多个操作中使用其它的对象并将其作为他们的实现中不可缺少的一部分。当接口中的一个操作的某个后置条件引用了一个协作类的对象的实例状态，则说明那个对象的属性别使用或修改了。由此可见，写作类的测试的复杂性远远高于汇集类或者原始类测试的复杂性。鉴于协助类的测试需要根据具体的情况来定，而具体情况复杂多变，在此，就方便不论述了。
6．面向对象系统测试技术
通过类测试、对象交互测试、类层次结构测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。为此，对完成开发的软件必须经过规范的系统测试。换个角度说，开发完成的软件仅仅是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作。
系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考 OOA 分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全 "再现" 问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。
这里说的系统测试是对测试步骤的抽象描述。它体现的具体测试内容包括：
1. 功能测试：测试是否满足开发要求，是否能够提供设计所描述的功能，是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试，通常还会以正式的软件说明书为测试标准。
2. 强度测试：测试系统的能力最高实际限度，即软件在一些超负荷的情况，功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大量复杂的查询等。
3. 性能测试：测试软件的运行性能。这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标，如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。
4. 安全测试：验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。安全测试时需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。
5. 恢复测试：采用人工的干扰使软件出错，中断使用，检测系统的恢复能力，特别是通讯系统。恢复测试时，应该参考性能测试的相关测试指标。
6. 可用性测试：测试用户是否能够满意使用。具体体现为操作是否方便，用户界面是否友好等。
7. 安装 / 卸载测试（install/uninstall test）等等。
系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例。
总 结
面向对象软件测试仍处于发展阶段。本论文根据面向对象开发方法过程和特点讨论了面向对象的软件测试，提出了一系列实用的面向软件测试技术。如，分析和设计模型测试技术、类测试技术、对象交互测试技术、类层次结构测试技术、面向对象系统测试技术等。，尽管上面说得很轻松，软件测试是一项非常麻烦的工作因此。有一些常用的小技巧留给大家讨论：
1. 尽早的开始测试工作
2. 从测试第一个模型开始应用指导性检查，直到模型不再更新。
3. 创建测试用例时使用 SYN-PATH 分析以确保覆盖所有可能的故障。
4. 当需要运行的测试多于现有资源所能运行的测试用例的测试时，一定要考虑分层增量测试。
由于面向对象软件的复杂性，本文还有许多的面向对象软件测试的问题还没有讨论到。比如，分布式系统的测试、对象的多态性和动态绑定的测试等等。因此有待于进一步研究
参 考 文 献
[1] McGregor．J．D. 等著；杨文宏等译．《面向对象的软件测试》[M]．机械工业出版社，2002.8.
[2] BinderRobertV．等著；华庆一，陈莉等译．《面向对象系统的测试》[M]．北京: 人民邮电出版社，2001
[3] 赵元聪，朱三元．面向对象软件测试的认识 [J]．计算机应用与软件，1996，17(3)：1~4
[4] 郭菏清主编．《现代软件工程——原理，方法，与管理》[M]．广州：华南理工大学出版社，2004.2（2005.1）
[5] 齐治昌等编著．《软件工程》[M]．北京：高等教育出版社，2001.8（2002 重印）
[6] 郑人杰等编著．《基于软件能力成熟度模型（CMM）的软件过程改进——方法实施》[M]. 北京：清华大学出版社，2003
[7] 周梦醒．面向对象软件的测试 [OL]．http://www.m1570.com/Article/article_view.asp?id=159，2006.2
[8] 姬莹，罗钧日，钟联炯．面向对象软件测试主要问题的探讨 [J]．西安工业学院学报，2001，21(1)：31237
[9] 杨小平，王胜开．面向对象软件测试探讨 [J]．计算机工程与应用，2000，36(1)：44246.
[10] Ma Yu-Seung，Kwon Yong-Rae，Jeff Offutt．Inter-class mutation operators for Java [A]．Thirteenth International Symposium on Software Reliability Engineering，Annapolis,MD,2002.
[11] Perry．D．E，Kaiser．G．E ．《Adequate Testing and Object-oriented Programming》[M]．Journal of Object-oriented Programming．1998, 2
[12] DUSTINE，RASHKAJ，PAULJ．Automated Software Testin[M]．Addison2Wesley,1999.
[13] 作者不详．使用面向对象的思想进行测试（游戏测试相关）[OL]．http://www.iceshi.com/html/2006-3/200634044842188.htm，2006-3-4
[14] 张海藩．软件工程导论 [Ｍ]．北京：清华大学出版社，1998．
[15] 张毅坤．面向对象软件测试的特点及方法 [Ｊ]．西安理工大学学报，2002，18(4)：361 365．
作者：西边人
头条号、公众号请搜索（软件测试资源站）
关注后私信回复 【入群】，加入自学微信社群联盟。
QQ群:3303744