（管理科学与工程专业论文）面向对象的软件测试研究.pdf

中文摘要 现代的软件开发工程， 规模日 趋庞大。 面向 对象方法在软件工程中的逐渐成 熟， 使面向 对象测试技术也越来越被人们所关注。 但随着面向 对象分析、 设计的 不断完善，此类软件的测试技术已 越来越滞后于开发技术的发展。 本文根据面向 对象软件的 实 际 特点， 分析了由 此而引 发的测试新问 题， 并指 出了 此类软件的测试重点及难点。 在此基础上， 引入了 组合逻辑、 状态机、 域模 型等可测模型技术， 将复杂的 软件系统模型化以 支持测试设计。 文中 使用了 面向 对象的建模语言u m l 作为辅助建 模工具， 使模型表达更加规范化和清晰化。 在构 建模型的基础上， 作者又针对不同范围的测试， 根据面向 对象的特点提出了基于 不同 情况下的测试设计样式。 侧试设计样式根据不同的软件需求， 基于一定的建 模技术为具有指定特征的软件侧试提供了标准的通用解. 最后， 作者对测试自 动 化中的内 嵌测试方法作以 简要 介 绍。 作者在对测试模型及样式 进行了深入研究的基础上， 综合运用以 上模型， 引 用两个实际问题为例， 对文中的 两种样式进行了实证研究， 产生了 较好的测试效 果。本文所述观点及测试技术方法对许多测试设计问 题提供了实用的综合指导。 关键词:面向 对 象 u m l组 合 模 型状态 机 域 测 试 模 型 测 试 样 式 a b s t r a c t w i t h t h e d e v e lo p m e n t o f s o f t w a r e e n g i n e e r i n g , t h e o b j e c t - o r i e n t e d ( 0 0 ) s o f t w a r e t e c h n o l o g y h a s b e e n m o r e e x t e n s i v e l y u s e d . b u t t h e d e v e l o p m e n t o f t h e 0 0 s o f t w a r e t e s t i n g t e c h n o l o g y h a s g o n e f a r b e h in d t h a t o f 0 0 a n a l y s i s a n d 0 0 d e s i g n . a c c o r d i n g t o t h e s p e c i a l t y o f o b j e c t - o r i e n t e d s o f t w a r e , t h e p a p e r a n a l y z e s n e w p r o b l e m s a n d d i f f i c u l t y i t h a s b ro u g h t t o t h e f i e l d o f s o f t w a r e t e s t i n g . t h e n c o m b i n a t i o n a l l o g i c mo d e l , s t a t e ma c h i n e m o d e l a n d d o m a i n t e s t i n g m o d e l a r e i n t r o d u c e d t o s u p p o rt t h e t e s t i n g d e s i g n b y m e a n s o f b u i l d i n g m o d e l s t o c o m p l i c a t e d s y s t e m s . u n i f i e d m o d e l i n g l a n g u a g e i s u s e d a s a m o d e li n g to o l i n t h e p a p e r s o a s t o m a k e t h e m o d e l c l e a r a n d s ta n d a r d . o n t h e b a s i s o f m o d e l s , t h e p a p e r p u t s f o r w a r d t e s t i n g p a t t e rn s i n c o n n e c t i o n w i t h d i f f e r e n t t e s t i n g r a n g e s a n d c o n d it i o n s , w h ic h c a n p ro v i d e s t a n d a r d a n d g e n e r a l s o l u t i o n s t o s o f t w a r e t e s t i n g a c c o r d i n g t o d i f f e r e n t r e q u e s t s o f m o d e l - b a s e d t e c h n o lo g y . f i n a l l y , t h e p a p e r g iv e s a b r i e f i n t r o d u c t i o n t o b u i l d - i n t e s t , w h i c h i s a b r a n c h o f t e s t i n g a u t o m a t i o n . a f te r a t h o r o u g h a n a l y s i s t o m o d e l s a n d p a t t e rn s , t w o a u t h e n t i c p r o o f s a re g i v e n t o s u p p o rt t h e m e t h o d s a n d s t r a t e 乡 e s i n t h e p a p e r , w h i c h c a n p ro v i d e g u i d a n c e t o p r a c t i c e . k e y s t a t e w o r d s : o b j e c t - o r i e n t e d u m l ma c h i n e mo d e l t e s t i n g mo d e l c o m b i n a t i o n a l l o g i c mo d e l t e s t p a t t e rn 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的 研究成果， 除了文中 特别加以 标注和致谢之处外， 论文中不包含其他人己 经发表 或 撰 写 过 的 研 究 成 果 ， 也 不 包 含 为 获 得 k 建 大. 一 或 其 他 教 育 机 构 的 学 位 或 证 书而使用过的材料。 与 我一同工作的同志对本研究所做的任何贡献均己在论文中 作了明确的la明并表示了谢意。 学 位 论 “ 作 者 签 “ : 价 叔孙 字 日 ” : z n o 年 月 rs 1 学位论文版权使用授权书 本 学 位 论 文 作 者 完 全 了 解一 k 建 k 生一 有 关 保留 、 使 用 学 位 论 文 的 规 定 。 特 授 权 一 孟 生人生一 可以 将 学 位 论 文 的 全 部 或 部分内 容 编 入 有关 数 据 库 进 行 检 索， 并采用影印、 缩印 或扫描等 复 制 手段保存、 汇编以 供查阅和借阅。 同意学校 向国家有关部门或机构送交论文的复印 件 和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名: 签 字 日 期 : 。 ; 年 ” 师 签 “ : 群手 签 字日 期 :3 年 i月比日 第一章软件测试概述 第一章 软件测试概述 1 . 1 软件测试的概念 1 . 1 . 1 定义 由 于软件系统复杂性和 人类本身能力的局限性， 人们在分析、 设计和编程中 难免会犯各种各样的 错误。 为了 确保程序的正确性和健 壮性， 必须对软件进行严 格检查。 软件测试是一种特殊的软件系统的设计和实现， 即执行另一个以 发现错 误为目 标的 软 件系统。 概 括来 说， 软 件 测试 是使用为 指出 软 件 系 统 缺陷 而 执行代 码的 过程。 测试目 的 在于发现其中的 错误并 及时纠正， 而不是证明 其不存在错误。 1 . 1 . 2测试的局限 经验表明， 任何软件系统都会 有错误。 我们不能事先知道什么样的执行顺序、 状态 及输入的组合会导致失败。 仅 有一个测试通过并不能说明 错误不存在了， 通 常在一个实现中只有一小部分代 码使用了 给定的测试输入。 输入空间 一 个普通的程序所包含的 输 入输出 的组合数目 是非常惊人的。 假设一个平 面包 含7 8 6 4 3 2 ( 1 0 2 4 x 7 8 6 ) 个点 ， 那么 一 条 直 线 可以 用7 8 6 4 3 2 2 中 方 式 画出 。 显然，我们根本无法测试所有的输入、状态或输出. ， 执行顺序 在一个带有条件分支或循环的 程序中， 对每一条分支进行组合会导致一个数 目 庞大的 执行路径数。 简单的 循 环重复会把可能的 执行路径数目 增大到一个天文 数字。 故障敏感性和巧 合正 确性 代码对测试包隐藏故障的能力 称为故障敏感性。 从测试的 观点看， 最好的错 误类型就是每次执行都会引发一次失败。 但大多数错误并非如此。 即使当错误代 码执行时， 它们仍能隐 藏。 对某种 输入， 错误代码却 产生正 确结果时， 得到了 巧 合正确性。 假设x + x 是x * x 的 错 误代码， 则当x = 2 是一个测试实例时，这个代 码就隐藏了 错误: 它从错误代码中 产生了 一个正确结 果。 1 .2 面向对象的软件测试 第一章软件测试概述 1 . 2 . 1 故障概述 任何软件系统中都存在未 知的错误，但通常我们不知道这些错误的确切位 置。 因 此任何合理的测试策略都必须由某种故障模型来指导。 故障模型是关于故 障可能在何处被发现的一个假设， 它表明被测系统中最有可能发生的错误。 面向 对象编程将操作和变 量 封装在一个类里， 将复杂的 行为压缩为一些简单 语句， 由 此导致一些不可避免的结 果。 一个继承层次的较低层对所继承的特征能 产生一个新的运行环境; 一个较高 层的正确行为无法保证较低层的正确性。 消息 序列与状态间的相互影响常常是 微妙而复杂的。 多态性和动态绑定将增加执行的 路径数。 封装也防止了 在一些 过 程 语言中由 于全局数据和模块间的副作用而导致 的错误. 虽然如此， 编码错误发生的可能和过程语言一样。 面向 对象程序具有许 多小的构件和较过程语言更多 的接口，接口 错误更可能发生。 1 . 2 . 2 具体特点引发的副作用 1 . 2 .2 . 1 对象 对象是一个可操作的实体， 它既包含了特定的数据， 也包含了对这些数据的 操作。 在程序运行时， 对象的 行为是否符合它的说明规定， 该对象与和它相关的 对象是否协同工作， 这两方面是面向 对象软件所关注的焦点。 对象可以 用它的生 命周期来描述。 当一个对象被创建时它的生命周期开始， 这个过程贯穿于对象的 一系列状态，当一个对象被删除时 它的生命周期结束。 从测试的角度看， 可以得 到以下结论: 对象的封装:封装性支持了 信息的隐蔽和模块化，有助于防止过程语言共 有的全局变量访问的问题。 尽管封装不能直接促成错误的发生， 它却可以带来测 试的 障碍。 测试要求精确报告一个对象的具体和抽象的状态。 面向对象语言使得 直接获取和设置对象的 具体 状 态 变 得很困 难。 对象的生命周期: 在对象生 命周期的不同阶段，为了确定对象的状态是否 符合它的生命周期， 对象可能会被从各方面进行检测。 过早的创建一个对象或过 早的删除一个对象，都是造成错误的常见原因。 1 . 2 . 2 . 2 消息 消息是对象的操作将要执行的一种请求。 面向 对象程序执行的典型过程首先 是实例化对象， 然后将一条消息传送给其中的某个对象. 消息的接收者把它自己 产生的 消息发送给其它对象( 或自 己) 来执行计算。 比如在一些由事件驱动的环 境下， 环境会不断的发送消息并且等待诸如鼠标点击等外部事件的响应。 从测试 的角度看，可以得到以下结论: 消息发送者可以决定何时发送消息，并且可能会作出错误的决定。 消息接收者接收到一条 非预期的消息时，可能会对此做出不正确的反应。 第一章软件测试概述 消息可能包含参数: 在处理一条消息时， 参数能被接受者使用或更改。 如 果传递的参数是对象， 那么在消息被处理前和处理后， 对象必须处于正确的状态。 1 . 2 . 2 . 3 类 面向对象程序运行的基本元素是对象， 而类则是用来定义对象的。 在程序中， 任何被描述的概念最初都必须声明为类， 然后创建由该类定义的对象。 创建对象 的过程被称作实例化，而创建的结果被称为实例。 类测试是测试过程中的一个重要方面，因为面向对象程序主要是由类构成 的， 类是所有实例共性的一种抽象。 在类测试过程中要保证测试那些具有代表性 的类的成员。从测试的角度来说，可得出下列设计和实现中的错误原因: 类在定义自己的行为和属性时， 也依赖于跟它协作的其它类。 例如， 类的 成员变量可能是其它类的实例。 如果在类的定义中使用了 包含有不正确实现的其 它类，就会使类发生错误。 类的实现必须满足类本身的说明，但并不保证类的说明就是正确的。 类的实现可能执行一些错误的操作。 类中的某些操作需要指定前置条件， 即操作执行前应满足的条件。 在发送 者发送一条消息之前，它也可能 不提供检查前置条件的方法。 1 . 2 . 2 . 4 继承 继承是类之间的一种联系， 它允许新类在一个己 有类的基础上进行定义。 即 一个类对另一个类的依赖， 使得已有类的说明和实现可以 被复用。 从测试的角度 看，可以得到以下结论: 继承削弱了 封装性， 产生了 类似于过程式语言中全局数据的 错误风险. 另 外， 一个深层次的最底层的子类可能只有一行或两行代码， 但可能继承了上百种 特征。 没有一个类扁平化器的帮助， 这些继承特征之间的相互作用是难以理解的。 。 继承将支持偶然的复用， 这也能导致错误。 假定类x 是为一个应用系统开 发的类， 但没有设计为可复用。 这个类被测试过且在原来的应用系统中能正确运 行。然而后来，类y是从类x继承来的子类并用于一个新的 应用中。 x的超类 方法在y中被继承， 在新的系 统中就可能产生不可预料的错误行为。 。 不规范的类层次会引起不正确的操作。 多继承和抽象类也会产生更多的风 险。 1 . 2 . 2 .5 多态 多态性是指: 通过继承而相关的不同类， 它们的对象能够对同一个函数调用 作出不同的响应。 尽管多态性可以用来产生高效率的代码， 但这也带来了许多新 的问 题。 假定超类方法x 已 被验证，随后一个子类方法重载了方法x 。 子类x 的 正确性是不能被保证的，因为它的运行条件可能不与超类x 相同。 第一章软件测试概述 多态消息每个可能的绑定 都是一个单独的计算。 一个绑定能正确的 工作并不 能保证所有的绑定都能正确的 运行。 绑定 对象多态性可能很容易使消息发送给错 误的类，识别和检测所有这样的绑定是困难的。 . 3 u m l ( u n i f i e d m o d e l i n g l a n g u a g e ) 测试初探 ， 3 . 1 u m l 定义 统一建模语言 ( u m l )是为 表示面向 对象模型而采用的一种符号句法。 它 已 成为面向 对象建模的事实上的标准。 在u ml中， 模型即是一系列图例， 每个 模型反映系统的一个特定抽象 层。 u m l支持多种图 例，以 下对本文涉及到的图 例作以 简要介绍，具体用法参见 “ 测试样式” 一章. 1 ， 3 . 2用例图 从本质上讲， 一个用例是 用户与计算机之间的一次典型交互作用。 以 字处理 软件为例，“ 将某些正文置为黑体” 和“ 创建一个索引” 便是两个典型的用例。在 u m l中，用例被定义成系统执行的一系列动作， 动作执行的结果能被指定执行 者察觉到。 用例仅关心从系统外部界面可见的特征。 它表示了系统和外部动作者 之间的 对话. 一个用例实例定 义了 特定的 输入值和预期的结果。 一个用例由 操作 组成。 一个操作是一个由 外部 输入初始化的， 在对象之间 互相交换消息的 特定 序 列。 用例对理解需求是非常有效的， 但用例并不一定会体现每一个需求。 用例并 不代表软件， 因此不能 对用例进行测试. 需求对测试来说是非常重要的， 因 为它 们是为 测试用例的来 源服务的、 并且能够形成系统测试所需的测试用例。 1 . 3 . 3类图 类图 描述类和类之间的静 态关系。 类图 是定义其它图的 基础。 在类图的 基础 上， 状态图、 协作图 等进一步 描述了 系 统其他方面的 特性。 类图能 够展示每个类 之间的操作和属性， 也能表现对象之间的约束关系。 大多数类符元素都用一个其内 部被分割为三个格的矩形框表示。 对一种类符 可以 指定一个关键字。 类图 在建模中 具 有重要的作 用， 它可以 描述类、 类的 特征 以 及类之间的关系。 它能够反映软件的结构，也是建模测试的主要内容。 1 . 3 . 4顺序图 顺序图反映了在对象之间、对象建立以及消息回应时消息的传递顺序。 顺 序图可以 在任意的抽象层上建立。 用例的详细情景可用一个顺序图进行表达， 类 中单个操作的算法也能用这种形式的说明予以描述. 顺序图能体现对象间的协作 第一章软件测试概述 关系. 一般的， 垂直线表示对象， 水平线表示从一个对象发送到另一个对象的消 息。 1 . 3 . 5 状态图 状态图根据对象的状态来描述对象的行为， 并能描绘出当一个影响对象的事 件发生时， 对象的状态如何改变. 在后面的状态机模型中将详细讨论状态图， 一 个状态图的u m l 定义为基于 状态的测试提供了 许多必要的信息。 第二章 测试模型 第二章 测试模型 2 . 1 测试模型的概念 进行软件测试，首先得了 解被测实现要做什么。由于软件的复杂性，需要 开发模型来支持测试设计。对被测软件进行建模，是因为建模能帮助人们理解 他们正在解决的问题，并能帮助管理正在开发的系统的复杂性。 2 . 1 . 1 测试必须基干模型的原因 测试可以看成是一个搜索问 题，即在数百万计的输入及其组合中寻找那些 极少数能够发现错误的输入组合。 在这种规模下，查找必须是系统的、集中的 和自 动的。 若要确保每一个目 标组合被测试，则测试必须是系统的，否则测试 的规模和复杂性将使测试难以 进行。若要利用现有错误出 现位置的 信息的话， 测试必须是集中的。没有错误的地方，要比有错误的地方多的多。若要产生和 运行大量一致的和可重复的测试，测试必须能自 动进行。 基于模型的测试满足上述 三点。模型支持输入及其组合的系统枚举。虽然 通常不能产生被测实现的每一个输入及其组合，但对被测实现的模型可以实现 这一目的。一个有用的测试模型把注意力集中在那些可能出错的地方。自 动测 试使测试效率大大提高，测试模型逼真的描绘了 测试目 标。 2 . 1 . 2 模型的定义 模型不但抓住了目 标系统 最本质的关系，而且比目 标系统更易于开发和分 析。 模型有四要素: 主题:模型必须有定义完整的主题，如飞机模型、建筑模型、气象模型 和经济模型等。 而测试中，我 们感兴趣的是能帮 助我们找到有效测试实 例的 被 测实现模型。 理论:一个模型必须以 一定的理论为基础，该理论能够指导识别相关的 问题及信息。软件测试模型表达所要求的行为，并且把精力放在可能出 错的结 构或要素上。 表示: 一个建模技术必 须具有表达某一特定模型的 方法， 例如一辆汽车 车 身的c a d 金属 框架图 模型 或 某 个 数学 模型的 方 程 式。 许多 软 件测 试 模型用图 来表示。 技术:建模是复杂的人工制品，技术的好坏与建模者有密切的关系。 2 . 2组合模型 第二章 测试模型 d 重复第2 和第3 步直到 所有的叶结点被标记为终端。 对转换树的每一条从根到叶结点的路径设计测试实例， 形成符合度测试包。 该测试包可能发现几类重要的错误:不正确的或丢失的转换，一个转换上 不正确的或丢失的响应， 丢失的状态和一些讹误状态。如果所有测试通过，则 说明被测类符合显式的行为模 型。 潜行路径:非法转换和规避监视 通过上面的测试包，说明了 被测实现在它的显式行为模型中没有包含前面 讨论的错误。我们还必须说明 被隐含排除的转换也被正确处理。对一个明确指 明所有的事件肤态对的实现， 可以 跳过潜行路径的处理。 对于没有完全规定的 机器， 潜行路径测试包是必 须的. 对每一个没有被规定的转换和受监视转换的谓词为假的情况，都有一个可 能的潜行路径。为了 确信没有潜行路径存在，我们必须对每一个状态的非法事 件进行测试二用响应矩阵开发潜行路径测试包。 2 . 4 域测试模型 没有选择测试值，测试是不能完成的。域分析是直接、有效的选择测试值 的办法。 2 . 4 . ，域分析 一个域是某被测实现的 所 有输入集， 一个子域是一个由 边界条件定义的域 的划分，而边界条件则是被测实现的输入变量上的一个布尔表达式。在类范围 边界条件中的变量是消息参数和实例变量。 域测试故障模型是指被测实现不正确的实现了一个边界。常见的四种类型 域故障包括平移、倾斜、丢失 及外加边界.一个域测试包用域分析开发: 对所有输入变量标识边界条件。 对每个边界中的每个变 量选择测试值。 对边界中没有给出的变量选择测试值。 。 对这些输入确定期望的结果。 例如要为下面的c + + 函数 参数开发测试实例: v o i d a f u n c t i o n ( i n t x , f l o a t y , s t a c k a s t a c k ) / * * / ; 该f l o a t 类型假定提供六位小数精度，a f u n c t i o n 要求输入参数满足断言: a s s e r t ( ( y = 1 . 0 ) 假如边界是开放的， 一个离点就是域的里面。 2 . 4 . 3有两个或更多变f的 边界条 件 假如一个边界条件使用两 个或两个以 上的变童， 那么，能 通过解该相关等 式找到上点和离点. 一般的， 假如有k 个独立变量 ( 在右边的变量) ， 就有k 个 上点。例如，条件5 涉及两个变量，可以 解该条件隐含的等式找到上点。插入 任意独立变量( 本例中是 x ) 的 组 合， 它使该边界等式为真， 而不使其他的条件为 假。首先试独立变量的中间点: y = 1 4 . 0 - x y = 1 4 . 0 - 7 y = 7 , x = 7 5 到1 0 之间的 任何x 值都可以 满足， 但出了该范围 将违反其它边界。 2 . 4 . 4模型化对象的域 对原始数据类型找离点、 上点、内 点 和外点是直观的。 但对复杂类型 ( 即 类)怎么样呢?面向对象实 现的 输入域通常包括复杂数据类型。然而，当用复 杂对象定义领域边界时，不能只关注这种对象的单个变量，我们必须至少考虑 所有对象的接口变量。 第二章 测试模型 从域的角度看， 有些类与 原始类形是相同的， 其它类则并非如此。 一个状 态抽象可架起对象和原始数据类型之间的 桥梁。 我们可以 用一个抽象状态不变 量对任何对象的需求建模。 例 如， . f u n c t i o n 的输入域需要. s t a c k 没有满， 这 种情况用抽象状态不变量函 数! . s t a c k . i s f u l l ( ) 建模。 类s t a c k 的对象可以 是 三个状态之一:e m p t y , l o a d e d 或f u l l 。该抽象状态变量是: e m p t y ( s t a c k . s i z e ( ) “ 二 伪 l o a d e d ( s t a c k . s i z e ( ) 7 0 us t a c k . s i z e ( ) m a x s t a c k ) f u l l ( s t a c k . s i z e ( 卜= m a x s t a c k ) 对每个状态的上点和离点 通过对 对象选择测试值来决定，该 对象应该满足 边界 条件状态不变量 ( 假定m a x s t a c k = 3 2 7 6 7 ) 0 抽象状态上点。一个抽象状态上点是这样一个点，对任何状态变量的任 何小的 变化都将产生状态的变 化。 例如， 在有3 2 , 7 6 6 个项的l o a d e d 状态下， 加一项将导致f u l l 状态。 另外， 弹出 最后一项将进入，p t y 状态。 因此， s t a c k 在状态l o a d e d 的上点是1 和3 2 7 6 6 . 抽象状态离点。一个聚焦状态是在域边界内指定的状态，即要研究的状 态。一个抽象状态离点是满足下列情况的点:( a ) 不属于聚焦状态，( b )很小 的 变化将导致状态的改变。 例如， 假定聚焦状态是l o a d e d 状态， 如果元素的数 目 是零或最大值，那么 s t a c k 不在 l o a d e d 状态。而可通过在这两种情况下对 s t a c k . s i z e 的加 1 或减1 ( 增减最小数量级) 导致到l o a d e d 状态。 因此， s t a c k 在状态l o a d e d 的离点是0 和3 2 7 6 7 0 抽象状态内点。一个抽象状态内 点是 任何值的 组合。 这种组合把一个该 类的 对象置为一个给定抽象状态，且不是抽象状态的 上点。 例如， s t a c k在状 态l o a d e d 的内点是1 o瑞 。! 阮，! 二 1 0瑞1 0l 际1 1一 一 垂创的i n一”2 34 s67， 1。 r . ) 二 i o d (k犯疡: 卿 训11 阮 i。 的 翩1 ( 二 1 氏0 加的阮 l1 o . 耐 卜 ，11 氏 0 的 1 了 二 1 4于x阮 7 . 00的1 阮 ，际 的 。 1 再形的; 。 卜 ， 7 。 ， d ， 龙 3 s d卜 1 1 5 3 尝坛 . 1 4 了 2 崖3 . 3 3 3 3 么陈 . 1 1 : 。 5 栈 ! 贻 f u 】心 阮 3 2 龙 6 1 hail 含 2 7 6 7 典 习 的 漏 夕 导1 、 3 2 、 的 6 12 二 213 2 7 1 8。 1 ， ， 3 7 1 82 o 5 。 : 职 娜 兹 具x 、 、 x 孑 、 1了 x 护 x 、x 注:x 二 被测实现拒绝该 输入，孑 二 被测实现接受该值并产生正确输出; 栈值是栈的大小 第三章 测试样式 第三章 测试样式 3 . 1 概述 3 . 1 . 1 定义 样式是对一个特定的、重复出现的问题的一个通用解。从特定范围来讲， 它们对开发和执行测试计划提供标准的 解。一个样式有一个上下文，即决定样 式的应用环境。当满足了在上下文中的条件表达式，则样式所提出的解策略是 一个非常好的解决问题的方式。 3 . 1 . 2 测试设计样式模板 ( 1 ) 名字 用来标识样式和建议其通用方法的字或短语。 ( 2 )目标 样式能产生怎样的测试包. ( 3 ) 上下文 样式解决怎样的测设计问 题?何时用这个样式? 针对何种类型软件? ( 4 ) 故障模型 该样式针对什么类型的故 障? 为什么要针对它们? 对一个成功并揭示了故 障的 测试包来讲，一定要发生下面三种事情: 必须到达故障. 测试的 输入必须使故障所在的代码段执行。 。 必须激发失败。当到达一个缺陷时，并不总是产生不正确的结果。测试 输入必须使故障所在的段产生不正确的结果。 必须传播失败.不正确的结果必须对测试者是可观察的。 ( 5 ) 策略 最好的测试包如何设计和实现。 测试模型:为需求和实 现定义一个表示方法。 测试过程:用模型产 生的 测试实例定义一个算法、 技术。 预测: 评估测试结果是否通过。 自 动化: 评估讨论侧 试自 动化方法。 由 于篇幅所限， 本文所涉及样式将 不讨论自 动化方法。 ( 6 ) 入口 标准 使用这个样式的应满足的条件。 ( 7 )出口标准 第三章测试样式 为满足这种样式的测试目 标必须获得什么样的条件。 ( 8 )结论 该样式的优点和缺点。讨论采用这种样式的花费、利益风险和一般情况。 3 . 1 . 3基本步骤 使用一个测试样式的基本步骤如下: 在开发过程早期，根据被开发系统选择测试样式。 对被测实现开发一个测试模型。 . 用测试模型产生测试包。 . 开发测试自 动化实现. 运行和评价测试，如果出口 标准建议的覆盖没有达到，则需要修订测试 包。 3 . 2类范围 3 . 2 . 1 类范围测试的必要性 类范围测试相当于传统的单元测试. 对类进行测试，可明显的提高软件的 质量和产量。 在类范围 进行测试的必要性如下: 若不进行类范围测试， 则很多错误不能查出。系统层测试不像类范围测 试那样对构件有相同的检测程度。 。 客户类通常不会使用服务类的所有特征， 也不检测它所使用的所有特征。 因此， 把一个应用客户作为驱动程序去有效的测试一个服务类是困难的。 错误产生到其发现的时间 越长， 纠正的代价就越大， 那些应在早期剔除 而没剔除掉的错误， 对系统测试期间的 调试来说也是一种浪费。 有效的类范围测试减少了 时间进度，提高了产量。一个项目 组能并行的 测试很多类，但子系统和系统测试一般会降低这种并行测试的 数目。 3 . 2 . 2类流图 类范围的 测试设计必须产生方法激活 序列以 便检测 类内 部 ( 方法间) 的 控 制和数据流。一个方法流图 对状态如何被计算进行了 建模， 但没有表达方 法之 间是如何相关的。一个状态转换图 表示了 发送给方法的消息， 把一个状态转换 成另一个状态，这样一个模型能提供在类方法之间遗漏的连接。类流图通过连 接这种图 而构造，提供一个类内 部所有控制流路径的 模型。 类流图显示了方法间的路径彼此怎样连接，支持类内部路径的分析。类流 图由f r e e 类状态模型和每个方法的流图 来构造。 类流图的 基本构造可用类x 第兰章 测试样式 来描述。 类x有三 个方法: x .a . x .b 和x . c 。图3 - 1 最左侧的图显示单个的方 法流图， 中间的图 显示类x的 状态模型， 它包括三个活动状态 ( 1 、n 和m) 和a 、。 状态。a 是一个占 位状态， 它便于图的构造， 它对应于一个对象的声 明。同 样，。 状态表达了 对象析构后的状态。这种显式的空状态使测试模型中 构造器和析构器能一致的表达。 方法图 结果类流图 图3 - 1类流图的构造 因为 状态是方法激活的结果， 可以 用方法图代替状态图中的转换。 嵌入在 状态模型中的流图 提示了 每一个状态是怎 样计算的 ( 图3 - 1 ) 。以 下为它的 构造 过程: 对被测类开发一 个f r e e 状态模型。 对被测 类中的 每 个方法开发一 个流图。 在状态转换图中， 对每个转换: 删除该转换边。 把这个转换方法图 贴到 类流图中 被删除边的中间位置。 从接受状态结点到该方法图入口 结点增加一条边。 从该方法出口 结点到结果状态结点增加一条边。 第三章 测试样式 d校订以减少视觉混乱。 3 . 2 . 3方法范围测试设计样式 3 . 2 . 3 . 1概述 测试一个类需要检测它的 所有方法。因此，方法测试是一个类测试包必要 的组成部分。一个方法实现一个类功能的一部分，单个方法的责任叫功能。一 个方法可能实现一到多个功能，两个或多个功能间的目 标祸合称为功能内聚。 当一个模块的所有部件都支持同一目 标时，产生强内聚:当一个模块的部分服 务于若干不相关目 标， 或服务目 标与软件需求不相关时， 产生弱内聚。 3 . 2 . 3 . 2样式 下面列出四个方法范围的测试设计样式，它们符合一个方法执行的一般功 能。 范畴一 划分 ( c a t e g o r y - p a r t i t i o n ) 。可用于任何范围的 任何方法或可测 试函数。 组合功能测试 ( c o m b i n a t i o n - f u n c t i o n t e s t ) 。适用于实现复杂的选择 算法、商业规则、或类似的 逻辑方法。 递归功能测试 ( r e c u r s i v e f u n c t i o n t e s t ) . 适用于自己调用自己的方 法。 多 态消息测试 ( p o l y m o r o p h i c m e s s a g e t e s t ) 。 适用于一个提供多态服 务的客户测试包。 下面以组合功能测试样式为例作以 简要介绍。价 ( 1 )目标 根据状态或消息值的组合选择响应动作，设计一个测试包。 ( 2 ) 上下文 当一个方法根据消息参数和实例变量的很多组合， 选择不同动作中的一个 时，选择输入组合以适当的检测选择逻辑。 ( 3 ) 故障模型 见2 . 2 . 5 . 1 “ 故障 模型” 。 ( 4 )策略 测试模型。 组合功能可 用判定表建模。 本文2 . 2 节 详细讨论了 判定表建模和 测试的产生。一张判定表有条件和动作，当判定表中的某一行的所有条件都为 真时，相应的动作发生。 具体实现方法参见5 . 1 “ 案例一” 。 测试过程。 根据判定表大小及实际需求， 选择合适的 测试策略。 例如， 可以 用全显式测试策略对每个变式最少开发一个测试，产生相应的测试包。如果判 第三章测试样式 定变量不是布尔值，那么应增加它们的 边界条件测试。 ( 5 ) 入口标准 无。 ( 6 ) 出口 标准 每个变式最少产生一个测试实例。 。 假如被测方法能够检 捌不正确的输入或其它异常， 测试包应该 最少强迫 每个异常一次。 应达到被测方法的 分支覆盖。 假如所有指定的动作都己 产生， 一个没有 检测的分支就意味着一个意外动作或遗漏了测试实例。假如用了一个 c a s e ( s w i t c h ) 语句， 就要 保证 覆 盖 每 种情 况。 。 多态编联经常被用于代替分情形语句去选择一个动作。 在这种情况下， 分支援盖将不再有意义。相反， 要保证每种可能的编联最少被检测一次。 ( 7 ) 结论 一张判定表经常揭示设 计错误和遗漏。 对小的 判定表， 建模和测试的 产生 是一件容易的任务。自 动化支 持对四 到 六个决策变量是有用的，对七或七个以 上变蚤是必要的。 3 . 2 . 4 类 范围 测试设计 样式 3 . 2 . 4 . 1 概述 面向对象程序的基本单位是 类。 在一个类的内 部， 所有的实例变量对类中 所 有方法是 可见的。 假 如 只在 方 法范围 进 行测试， 就容易 遗 漏与 类内 部 使 用相 关的 错误。方法交叉是一种常见的 错误源。检测各种序列中的 方法对揭示类内 部的错误是必要的。 3 . 2 . 4 . 2类模态性 某些类被设计接受任何 状态下的 任何消息， 但另一些类基于以 前的 消息或 当 前内 容限制以 后的消息顺序。 基于以 上考虑， 提出 类的模态性概念。 模态性 是在内 容和消息序列上进行限 制的结果。 对于测试， 有四 种模态性: . 非模态( n o n m o d a l ) 类对接受的消息序列不加任何限 制。 例如， d a t e t i m e 类的 一 个对象 会接受 任何修 改 / 获 取的 消息 序列。 基本数 据类 型的 类通常 是非 模 态的. 单模态 ( u n i m o d a l ) 类对可 接受的 消息序列有限 制， 但不管其内 容。 例 如， t r a f f i c s i g n a l 类的一个对象只有在接受一个y e l l o w l i g h t o n 消息之后才 能接受r e d l i g h t o n 修改消息。 提供应用控制的类是典型的 单模态的。 准模态 ( q u a s i - m o d a l ) 类对随对象的状态而改变的可接受消息进行限 制。 例如， 如果栈已 满， s t a c k 类对象将拒绝一个入栈消息， 但在其它情况下 第三章 测试样式 在父类的转换上产生错误行为。 ( 4 ) 策略 测试模型。 这种测试模型与模态类采用的相同。 但是， 在这种样式中， 状态 机必须反映展平类的状态和事件。展平状态机模型的开发在前文继承和类的展 平中 讨论。 一个完整的 例子已 在前述中 的t h r e e p l a y e r g a m e 中 提供。 ( 5 ) 入口 标准 所通过运行a 一 。 周期以表明一个子类中的所有方法均是可操作的。 所有的 父类通过了 它们的测试包。 ( 6 )出口 标准 与模态类测试相同，但它们是在展平范围上的。 3 . 3可复用构件 3 . 3 . 1测试和复用 面向 对象的语言能通过继承、动态编联等方式表达复用现象。 构件是可被 应用于多种上下文中的标准软件制品。复用可通过源代码扩展，编译时编联和 链接/ 运行时 接口实现。 宏替换、 继承和组合支持编译时的复用。 基本类库通过 继承支持编译时的复用，用户可设计子类来完成特定的应用要求。 抽象类提供的方法接口并没有在抽象类中实现。抽象类通常被作为多态性 层次中的根类，它为一组子类的实现提供一个统一的界面以支持动态多态性。 尽管不能将抽象类实例化为对象， 但可以声明一个抽象类的实例。具体的子类 实例将会被动态的绑定到这个名字。这样就允许任何子类对象都可按抽象类定 义的方法接受消息。 类属类要求为特定的类型指定类属实例变量和操作，它提供静态多态性。 c + + 的 模板类支持这一 概念。 c + + 标准模板库充分说明了 类属类如何支持复用。 用静态编联提高了效率和类型安全性， 并能避免使用继承和动态多态性的问题。 但这种方法灵活性少。 3 . 3 . 2测试设计样式 下面以抽象类测试 ( a b s t r a c t c l a s s t e s t )为例作以简要介绍。 ( 1 )目 标:开发 抽象类接口 的 测试实 现和 测试包。 ( 2 ) 上下文: 一个抽象类不能被实例化， 因 此无法测试。 但它可通过实现抽象类 中的所有没有实现的方法开发一个子类进行测试。在 c + 十 中，一个抽象类是任 何至少包含一个纯虚函数的类。 第三章测试样式 ( 3 ) 故障模型: 包括设计错误和简单的代码错误。常见的设计错误包括责任的不完整性和 不一致性、接口 中责任的不完整性和不一致性、 应该延期定义的实例变量和遗 漏性能。 ( 4 )策略 为测试抽象类，需要开发一个实现所有抽象方法的 子类。 接着，用适当的 方法和类范围的测试设计样式为展开子类开发一个测试包。 为 每个抽象超类方法的子类方法开发测试实例， 并在子类对象上运行该测 试实例。抽象超类也可能己 实现了 一些方法，对这些方法也要设计测试实例并 运行之，这些测试实例也可能被子类复用。如果一个具体的超类方法给自己的 一个抽象方法发送一个消息，那么就延迟这个方法的 测试直到子类实现了 该抽 象方法。 ( 5 ) 入口 标准: 当 抽象类被编译时，它应该被测试。 ( 6 ) 出口 标准: 测试实例应满足覆盖原则，方法范围的分支覆盖是最小的要求. 3 . 4 子系统 3 . 4 . 1概述 子系统是指任意类、对象、构件和模块的可测试的集合。它可以 是由 几个 类的一个小簇组成，也可能是由 包括若干个具有百 万行代码的 类的 源代码组成 的庞大的层次结构.子系统有以下特征: 子系统整体上是可执行和可测试的。 子系统具有