软件工程讲义_第十六章 测试面向对象的应用系统

面向对象测试方法

面向对象体系结构导致封装了协作类 的一系列分层子系统的产生。每个系 统成分（子系统和类）完成有助于满 足系统需求的功能。有必要在不同的 层次上测试面向对象系统，以发现错 误。在类相互协作以及子系统穿越体 系结构层通信时可能出现这些错误。
面向对象测试方法
对于面向对象测试用例的设计，[Ber93]已经提出了总体方 法： 1.每个测试用例都应该唯一地标识，并明确地与被测试的类 相关联。 2.应该叙述测试的目的。 3.应该为每个测试开发测试步骤，并包括以下内容： a.将要测试的类的指定状态列表 b.作为测试结果要进行检查的消息和操作列表 c.对类进行测试时可能发生的异常列表 d.外部条件列表 e.有助于理解或实现测试的补充信息 面向对象测试与传统的测试用例设计是不同的，传统的测试 用例是通过软件的输入-处理-输出视图或单个模块的算法细 节来设计的，而面向对象测试侧重于设计适当的操作序列以 检查类的状态。
面向对象环境的集成测试

当进行面向对象系统的集成测试时， 驱动程序和桩程序的使用也发生变化。 驱动程序可用于测试低层中的操作和 整组类的测试。驱动程序也可用于代 替用户界面以便在界面实现之前就可 以进行系统功能的测试。桩程序可用 于在需要类间的协作但其中的一个或 多个协作类仍未完全实现的情况下。
面向对象环境的集成测试

ห้องสมุดไป่ตู้
基于故障的测试
集成测试寻找操作调用或信息连接中的似然错误。在这 种环境下，有三种错误可以发现：非预期的结果、错误 的操作/消息使用，以及不正确的调用。为确定函数(操 作)调用时的似然故障，必须检查操作的行为。 集成测试适用于属性与操作。对象“行为”通过赋予属 性值来定义。测试应该检查属性以确定不同类型的对象 行为是否存在合适的值。 集成测试试图发现用户对象而不是服务对象中的错误。 集成测试的重点是确定调用代码而不是被调用代码中是 否存在错误。利用操作调用为线索，是找出检查调用代 码的测试需求的一种方式。

基于故障的测试
在面向对象系统中，基于故障测试的目标是设 计最有可能发现似乎可能故障(以下称为似然故 障)的测试。由于产品或系统必须符合用户需求， 完成基于故障的测试所需的初步计划是从分析模 型开始的。测试者查找似然故障。为确定这些故 障是否存在，设计测试用例以检查设计或代码。 若分析和设计模型可以洞察有可能出错的事物， 则基于故障的测试可以花费相当少的工作量而发 现大量的错误。
面向对象环境的集成测试

面向对象系统的集成测试有两种不同的策 略。一是基于线程的测试，集成响应系统 的一个输入或事件所需的一组类。每个线 程单独地集成和测试。应用回归测试以确 保没有副效应产生。另一种方法是基于使 用的测试，通过测试很少使用服务类(如果 有的话)的那些类(称之为独立类)开始构造 系统，独立类测试完后，利用独立类测试 下一层次的类(称之为依赖类)。继续依赖类 的测试直到完成整个系统。
测试面向对象的应用系统

为了充分测试面向对象的系统，必须做3 件事情：(1)对测试的定义进行扩展，使 其包括应用于面向对象分析和设计模型的 错误发现技术；(2)单元测试和集成测试 策略必须彻底改变；(3)测试用例设计必 须考虑面向对象软件的独特性质。
扩展测试的视野
面向对象软件的构造开始于需求分析和设计模 型的创建。由于面向对象软件工程模式的进化特 性，这些模型开始于系统需求的不太正式的表示， 并进化到更详细的类模型、类关系、系统设计和 分配以及对象设计。在每一个阶段，都要对模型 进行“测试”，尽量在错误传播到下一轮迭代之 前发现错误。 面向对象分析和设计模型的评审非常有用，因 为相同的语义结构出现在分析、设计和代码层次。 因此，在分析期间所发现的类属性的定义问题会 防止副作用的发生。如果问题直到设计或编码阶 段还没有发现，副作用就会发生。

簇测试是面向对象软件集成测试中的 一步。这里，利用试图发现协作中的 错误的测试用例来测试(通过检查CRC 和对象-关系模型所确定的)协作的类 簇。
面向对象环境的确认测试
在确认级或系统级，类连接的细节消失了。 如传统的确认方法一样，面向对象软件的 确认关注用户可见的动作和用户可以辨别 的来自系统的输出。为了辅助确认测试的 导出，测试人员应该拟定出用例，用例是 需求模型的一部分，提供了最有可能发现 用户交互需求方面错误的场景。 传统的黑盒测试方法可用于驱动确认测试。 另外，测试人员可以选择从对象-行为模型 导出测试用例，也可以从创建的事件流图 导出测试用例。

面向对象概念的测试用例设计的含义

类经过分析模型到设计模型的演变，它成 为测试用例设计的目标。由于操作和属性 是封装的，从类的外面测试操作通常是徒 劳的。尽管封装是面向对象的本质特征之 一，但它可能成为测试的一个小障碍。 “测试需要对象的具体和抽象状态”。然 而，封装使获取这些信息有些困难，除非 提供内置操作来报告类的属性值。

面向对象模型的一致性 面向对象模型的一致性可以通过这样的方 法来判断：“考虑模型中实体之间的关系。 不一致的分析模型或设计模型在一部分中 的表示没有正确地反映到模型的其他部 分”。 为了评估一致性，应该检查每个类及与其 他类的连接。可以使用CRC模型或对象关系图来辅助此活动。

面向对象模型的一致性
用于评审的CRC索引卡片实例
图16-1 用于评审的CRC索引卡片实例
面向对象模型的一致性

一旦创建了设计模型，就可以进行系统设 计和对象设计的评审了。系统设计描述总 体的产品体系结构、组成产品的子系统、 将子系统分配给处理器的方式、将类分配 给子系统的方式以及用户界面的设计。对 象模型描述每个类的细节以及实现类之间 的协作所必需的消息传送活动。

推荐使用下面的步骤对类模型进行评估： 1.检查CRC模型和对象-关系模型。 2.检查每一张CRC索引卡片的描述以确定委托责 任是定义协作者的一部分。 3.反转连接，确保每个提供服务的协作者都从合 理的地方收到请求。 4.使用步骤3中反转后的连接，确定是否真正需 要其他类，或者责任在类之间的组织是否合适。 5.确定是否可以将广泛请求的多个责任组合为一 个责任。
面向对象环境的单元测试

面向对象软件的类测试等同于传统软 件的单元测试。不同的是传统软件的 单元测试侧重于模块的算法细节和穿 过模块接口的数据，面向对象软件的 类测试是由封装在该类中的操作和类 的状态行为驱动的。
面向对象环境的集成测试

由于面向对象软件没有明显的层次控 制结构，因此，传统的自顶向下和自 底向上集成策略已没有太大意义。另 外，由于类的成分间的直接或间接相 互作用，每次将一个操作集成到类中 往往是不可能的。
面向对象概念的测试用例设计的含义
继承也为测试用例设计者提出了额外的挑战。 即使已取得复用，每个新的使用环境也需要重新 测试。另外，由于增加了所需测试环境的数量， 多重继承使测试进一步复杂化。 若从超类中派生的子类实例使用在相同的问题 域，则当测试子类时，使用超类中生成的测试用 例集是可能的。然而，若子类用在一个完全不同 的环境中，则超类的测试用例将具有很小的可应 用性，因而必须设计新的测试用例集。

传统测试用例设计方法的可应用性
白盒测试方法可以应用于类中定义的操作。 基本路径、循环测试或数据流技术有助于 确保测试一个操作的每条语句。然而，许 多类操作的简洁结构使某些人认为：用于 白盒测试的工作量最好直接用于类层次的 测试。 与利用传统的软件工程方法所开发的系统 一样，黑盒测试方法也适用于面向对象系 统。用例可为黑盒测试和基于状态的测试 设计提供有用的输入。
面向对象环境的单元测试

不再孤立地对单个操作进行测试(传统的单 元测试观点)，而是将其作为类的一部分。 为便于说明，考虑一个类层次结构，在此 结构内对超类定义某操作X，并且一些子类 继承了操作X。每个子类使用操作X，但它 应用于为每个子类定义的私有属性和操作 的环境内。由于操作X应用的环境有细微的 差别，在每个子类的环境中测试操作X是必 要的。这意味着在面向对象环境中，以独 立的方式测试X往往是无效的。
扩展测试的视野

如果问题没有在设计期间检测出来，并传 递到编码活动中，将增加可观的工作量生 成代码，实现不必要的属性、两个不必要 的操作、驱动对象间通信的消息以及很多 其他相关的问题。另外，类的测试会消耗 更多不必要的时间。一旦最终发现了这个 问题，一定对系统执行修改，由变更所引 起的潜在副作用将永远存在。
扩展测试的视野
在开发的后期，面向对象分析和面向对象 设计模型提供了有关系统结构和行为的实 质性信息。因此，在代码生成之前，需要 对这些模型进行严格的评审。 应该在模型的语法、语义和语用方面对所 有的面向对象模型进行正确性、完整性和 一致性测试。

测试OOA和OOD模型

不能在传统意义上对分析和设计模型进行 测试，因为这些模型是不能运行的。然而， 可以使用技术评审检查模型的正确性和一 致性。
测试面向对象的应用系统

面向对象测试与传统系统测试相类似，但它们 的测试战术是不同的。由于面向对象分析与设计 模型在结构和内容上与所得的面向对象程序相类 似，因此，“测试”可以起始于对这些模型的评 审。一旦产生了代码，真正的面向对象测试以设 计一系列检验类操作的“小型测试”以及当一个 类与其他类进行协作时是否出现错误开始。当集 成类形成一个子系统时，结合基于故障的方法， 运用基于使用的测试对相互协作的类进行完全检 查。最后，利用用例发现软件确认层的错误。
OOA和OOD模型的正确性
用于表示分析和设计模型的符号和语法是与为 项目所选择的特定分析和设计方法连接在一起的。 由于语法的正确性是基于符号表示的正确使用来 判断的，必须对每个模型进行评审以确保维持了 正确的建模习惯。 在分析和设计期间，可以根据模型是否符合真 实世界的问题来评估模型的语义正确性。如果模 型准确地反映了真实世界，则在语义上是正确的。 实际上，为了确定模型是否反映了真实世界的需 求，应该将其介绍给问题领域的专家，由专家检 查类定义和层次中遗漏和不清楚的地方。要对类 关系进行评估，确定这些关系是否准确地反映了 真实世界的对象连接。

扩展测试的视野

例如，在分析和第一轮迭代中，考虑定义 了很多属性的一个类。一个无关的属性被 扩展到类中，然后指定了两个操作来处理 此属性。分析模型进行了评审，领域专家 指出了这个问题。在这个阶段去除无关的 属性，可以在分析阶段避免一些问题和不 必要的工作量。如果问题没有在分析期间 被发现并进一步传播，在设计期间也会发 生问题。(课本292页)
面向对象模型的一致性
系统设计评审是这样进行的：检查面向对象分 析期间所开发的对象-行为模型，并将所需要的 系统行为映射到为完成此行为而设计的子系统上。 在系统行为的范畴内也要对并发和任务分配进行 评审。对系统的行为状态进行评估以确定并发行 为。使用用例进行用户界面设计。 对照对象-关系网检查对象模型，确保所有的设 计对象包括必要的属性和操作，以实现为每个 CRC索引卡片所定义的协作。另外，要对操作 细节的详细规格说明进行评审。
软件工程
第16章 测试面向对象的应用系统
主要内容
扩展测试的视野 测试OOA和OOD模型 面向对象测试策略 面向对象测试方法 类级可应用的测试方法 类间测试用例设计 小结

测试面向对象的应用系统

面向对象体系结构导致包括相互协作 类的一系列分层子系统的产生。每个 系统成分完成有助于满足系统需求的 功能。有必要在不同的层次上测试面 向对象系统，以发现错误。在类相互 协作以及子系统跨体系结构层次通信 时可能出现这些错误。

面向对象环境的单元测试

当考虑面向对象软件时，单元的概念发生 了变化。封装导出了类的定义。这意味着 每个类和类的实例(对象)包装有属性(数据) 和处理这些数据的操作(函数)。封装的类常 是单元测试的重点，然而，类中包含的操 作是最小的可测试单元。由于类中可以包 含一些不同的操作，且特殊的操作可以作 为不同类的一部分存在，因此，必须改变 单元测试的战术。