09 第九讲 面向对象的软件测试.pptx

第1页：第九章面向对象的软件测试封面

第九章 面向对象的软件测试：本章讲解软件测试的基本概念、测试计划、测试模型、面向 UML 的测试、类的测试以及面向对象的集成测试。

第2页：本章主要内容

主要内容：

• 1. 基本概念
• 2. 测试计划
• 3. 测试模型
• 4. 面向 UML 的测试
• 5. 类的测试
• 6. 面向对象的集成测试

第3页：软件测试的基本概念

一、软件测试的基本概念：

软件错误

软件系统的功能和性能与预期的功能和性能不一致

软件测试

是发现软件错误的过程——尽早测试，经常测试，充分测试

目标

发现软件中的错误，提高软件质量

注意：软件测试中没有发现错误并不意味着软件就没有错误，只能说明测试不充分，潜在错误未能被发现。

第4页：白盒测试与黑盒测试

软件测试的方法：

白盒测试

已知程序内部工作流程，通过测试检验程序内部动作是否按规格说明书的规定正常运作

黑盒测试

根据已知程序的功能和性能（而不是内部细节），通过测试检验每个功能和性能是否正常

第5页：白盒测试的覆盖准则

白盒测试：

• 问题：如何设计测试用例？
• 覆盖准则：语句覆盖、分支覆盖、路径覆盖

第6页：黑盒测试的技术

黑盒测试：

• 测试软件是否满足功能和性能要求，不涉及模块的内部过程性细节
• 主要的黑盒测试技术：等价分类法、边界分类法

第7页：软件测试的步骤

软件测试的步骤：软件开发过程依次经过需求分析、概要设计、详细设计、编码；与之对应的软件测试过程依次进行单元测试、集成测试、确认测试。

第8页：面向对象测试的不同

面向对象软件测试有何不同：

• 面向对象编程的特性——继承、多态、数据隐藏使测试复杂化
• 开发过程以及分析和设计重点的改变——单元、集成的含义发生变化
• 分析模型、设计模型和代码之间的映射——能尽早进行测试

第9页：面向对象软件的测试内容

面向对象软件的测试内容：

• 模型测试
• 类测试
• 交互测试
• 系统测试
• 接收测试
• 发布／自我测试

第10页：测试计划需考虑的问题

二、测试计划 —— 测试需考虑的问题：

• 谁执行测试？
• 测试什么？
• 什么时候测试？
• 怎样测试？
• 测试应进行到何种程度？

第11页：测试计划及其关系

测试计划及其关系：项目测试计划之下包含类／组件测试计划、集成测试计划、系统测试计划与用例测试计划，各计划相互关联、共同构成完整的测试计划体系。

第12页：为什么要基于模型测试

三、测试模型 —— 为什么测试要基于模型：

• 测试必须是系统的
• 测试必须是集中的
• 测试最好是自动的

第13页：模型的四要素

模型的要素：

主题

飞机模型、气象模型、经济模型、被测模型

论点／理论

能够指导识别相关的问题及信息

表示

方程式、图形

技术

建模方法

第14页：状态机的定义与构成

状态机：

• 状态机是一个系统，它的输出是由当前的输入和过去的输入决定
• 状态机的构成：状态、转换、事件、动作

第15页：状态机的运行机制

状态机的机制：

• 1. 机器开始于初态
• 2. 机器在一个不确定的时间间隔等待一个事件
• 3. 如果一个事件在当前状态没有被接受，则被忽略
• 4. 如果事件在当前状态被接受，则说指定的转换被触发
• 5. 从第 2 步开始重复这个周期，直到结果状态变成终止状态

第16页：基于状态建模的适用范围

基于状态的行为建模的范围：

• Java AWT、MS/Windows、Unix X-Windows 等 GUI 界面元素的行为
• 商业对象（类）的行为和它们的生存循环：订单、顾客、存货单等
• 通信设备：路由器、modem 控制器、电话、手持无线设备等
• 具有重试、重新开始、重新恢复功能的设备驱动器
• 命令语法分析器
• 长期的数据库事务
• 移动控制系统：航空电子控制系统、自动巡航系统、机器人等

第17页：基于状态的测试设计

基于状态的测试设计：

• 实现必须符合指定的状态机的约束
• 了解实现如何与观察到的约束不相符合，为测试设计提供了重点，也为评估测试设计策略提供了基准

第18页：控制错误

控制错误：一个控制错误允许一个不正确的事件序列被接受，或产生一个不正确的输出动作序列。例如：交通灯直接由红变绿。

第19页：控制错误的类型

控制错误的类型：

• 丢失的或不正确的转换
• 丢失的或不正确的事件
• 丢失的或不正确的动作
• 多余的、丢失的或讹误状态
• 潜行路径（一个不应被接受的消息被接受）
• 非法消息的失效（一个不期望的消息引起的失效）
• 陷阱门（实现了没有定义的消息）

第20页：控制错误示例：丢失转换

示例：丢失转换 —— 以网球发球状态机为例，状态为「选手1发球」与「选手2发球」，事件为 P1_WinsVolley() 与 P2_WinsVolley()。对一个有效的事件／状态对，实现没有作出响应，即存在丢失的转换。

第21页：控制错误示例：不正确的转换

示例：不正确的转换 —— 在发球状态机中，转换的目标状态错误，实现的行为就像到达一个不正确的结果状态（如直接从「游戏开始」跳到错误的结束状态）。

第22页：控制错误示例：丢失动作

示例：丢失动作 —— 对一个转换，实现没有产生任何动作。图中 P1_Start( )/simulateVolley( ) 转换上标注了动作 simulateVolley()，但实现并未执行该动作。

第23页：控制错误示例：不正确的动作

示例：不正确的动作 —— 对一个转换，实现产生了错误的动作。图中 P1_WinsVolley( ) 应触发 this.p1AddPoint( )，P2_WinsVolley( ) 应触发 simulateVolley( )，实现却把动作张冠李戴。

第24页：控制错误示例：潜行路径

示例：潜行路径 —— 实现接受了一个非法的或在这一状态没有被规定的事件。图中在「选手2赢」状态下接受了 P2_Start( ) 这一未规定的事件。

第25页：控制错误示例：讹误状态

示例：讹误状态 —— 实现计算一个无效的状态，或是类或状态不变量被违反。图中在「选手1赢」状态上出现 P1_WinsVolley( )[this.p1_Score( )==20]/this.p1AddPoint( ) 这样的守卫与动作组合，导致状态被讹误。

第26页：控制错误示例：非法消息失效

示例：非法消息失效 —— 实现没有正确处理一个非法消息。图中传入 xDEADBEEF 之类的非法消息后，系统仍按 P2_WinsVolley( )[this.p2_Score( )==20]/this.p2AddPoint( ) 处理并进入「选手2赢」状态。

第27页：控制错误示例：陷阱门

示例：陷阱门 —— 实现接受了一个非法的或在这一状态没有被规定的事件（如 Scroll Lock Key Press）。产生原因：

• 1. 当一个类被修改时，已废弃的特征未被删除
• 2. 继承过来的特征和子类的需求不一致
• 3. 为调试而增添的特征
• 4. 怀有犯罪或恶意的目的而作出的蓄意破坏

第28页：开发可测的模型

开发可测模型：

• 并非所有的实现都非常适合基于状态的测试
• 当被测实现的责任包括顺序行为时，有效的测试设计依赖一个完全的、一致的、正确的状态模型的开发
• 一个测试模型必须正确地表示需求，准确地反映被测实现
• 使用检查表

第29页：状态模型检查表一：结构

状态模型检查表（一）：结构 —— 1. 模型在结构上是完全和一致的：

• 1.1 一个状态被指定为初态并且只有一个离开的转换
• 1.2 至少有一个终止状态并且只有一个进入转换
• 1.3 没有等价状态
• 1.4 每一个状态都可以从初态到达
• 1.5 从任何一个状态都可以到达终止状态
• 1.6 每一个被定义的事件和动作至少出现在一个转换上
• 1.7 除了初态和终态外，每个状态至少有一个输入转换和输出转换
• 1.8 对任一给定状态，同样的事件不能出现在多个转换上
• 1.9 状态机是完全确定的

第30页：状态模型检查表二：状态名称

状态模型检查表（二）：状态名称 —— 2. 不好的状态名经常是不完全和不正确设计的征兆：

• 2.1 状态名称在应用领域中是有意义的
• 2.2 当怀疑一个状态名时，就把它删掉
• 2.3 不要用「等待的 x」或「等待 x」作为状态名
• 2.4 状态名没有表达不相关的信息：2.4.1 没有名称重复状态变量不变式（如 100<x<1000）；2.4.2 没有名称描述和动作相关的过程（如 compute x）；2.4.3 没有名称用于输入描述（如鼠标点击、用户参数）

第31页：状态模型检查表三：条件转换

状态模型检查表（三）：受监视转换 —— 3. 条件转换：

• 3.1 在状态转换的条件集中，条件表达式产生的真值的全部范围必须被覆盖
• 3.2 对一个转换，每一个条件都和其它的条件相互排斥
• 3.3 一个抽象状态模型的条件变量是被测类的客户提供的输入
• 3.4 一个具体类状态模型的条件变量由被测类的实现定义（例如 self 或 this）
• 3.5 条件表达式的计算对被测类不会产生任何副作用

第32页：状态模型检查表四：子类行为

状态模型检查表（四）：好的子类行为 —— 4. 子类的行为是良定的：

• 4.1 子类没有删除任何超类状态：在超类中接受的转换也被子类接受
• 4.2 子类不会减弱任何超类状态的状态不变量
• 4.3 子类不会破坏任何超类状态的状态不变量
• 4.4 子类或者加强超类状态不变量或者仅仅继承它
• 4.5 子类可以添加由子类引入的实例变量定义的正交状态
• 4.6 超类转换中所有的条件和子类转换相同或弱于子类
• 4.7 所有被继承的输出动作和子类的责任一致
• 4.8 发送到对象的消息不会对被测类产生副作用

第33页：状态模型检查表五：健壮性

状态模型检查表（五）：健壮性 —— 5. 模型规定了健壮行为：

• 5.1 对没有被明确拒绝的事件，有一个明确规定的错误处理和异常处理机制
• 5.2 对于一个非法消息的结果，实现的状态不会被错误地改变、被讹误或没有被定义
• 5.3 对每一个动作，没有改变和这个动作相关的结果状态的副作用或异常
• 5.4 对前置、后置条件与不变式的冲突，规定了明确的异常、错误注册和恢复机制
• 5.5 对丢失或延迟的事件规定了明确的异常、错误注册和恢复机制
• 5.6 对每一个超时，规定了明确的异常、错误注册与恢复机制
• 5.7 被测系统的目标环境的主要和不重要的失败模式被分类，对每个失败模式规定了一个明确的异常机制
• 5.8 对每一失败模式，指定了结果状态或硬性的终止状态
• 5.9 重新开始机制被建模并定义了一个到正常状态的路径

第34页：面向UML的测试

四、面向 UML 的测试：

• UML 的灵活性允许准确，也允许模糊
• 片断性、不完全性、不一致性和二义性的模型很容易产生
• 用 UML 开发一个严格的应用模型是可能的
• 以图中的关系为基础进行测试

第35页：用例图的测试需求表

用例图的测试需求：对表中的每一种关系，至少应有一个测试用例加以检查。

第36页：类图的测试需求表

类图的测试需求：对表中的每一种关系，至少应有一个测试用例加以检查。

第37页：顺序图的测试需求表

顺序图的测试需求：对表中的每一种关系，至少应有一个测试用例加以检查。

第38页：活动图的测试需求表

活动图的测试需求：对表中的每一种关系，至少应有一个测试用例加以检查。

第39页：状态图的测试需求

状态图的测试需求：参见基于状态的测试（本章第三节），即按状态机的状态、转换、事件与动作设计测试，并覆盖各类控制错误。

第40页：协作图的测试需求表

协作图的测试需求：对表中的每一种关系，至少应有一个测试用例加以检查。

第41页：构件图的测试需求表

构件图的测试需求：对表中的每一种关系，至少应有一个测试用例加以检查。

第42页：配置图的测试需求表

配置图的测试需求：对表中的每一种关系，至少应有一个测试用例加以检查。

第43页：类的测试与单元测试

五、类的测试：

• 类的测试相对于传统单元测试
• 为什么？若类的测试不足，则很多错误不能被查出；通过客户类去测试服务类是困难的；错误发现得越晚，纠正的代价越大；有效的类测试减少开发时间，提高生产率

第44页：类测试的内容

类测试的内容：

• 方法范围的测试设计
• 类范围的测试设计
• 继承的测试

第45页：方法范围测试的基本过程

方法范围测试：基本过程

• 1. 设置测试消息的参数、类变量、全局变量为希望的状态
• 2. 设置被测对象为希望的状态
• 3. 从驱动模块向该 MUT（被测方法）发送测试消息
• 4. 测试检查：（1）比较从该 MUT 返回的值和期望的值，若不同则记录未通过；（2）比较该 MUT 的状态和期望的状态；（3）若使用按引用调用，比较测试消息参数的状态和期望的状态；（4）捕获所有异常，判断是否为期望的异常；（5）若一个断言的违反是期望的，确定它是否正确；（6）必要时比较类变量、全局变量的结果状态与期望的值
• 5. 假如发生任何未通过，诊断和矫正该问题

测试提示：记录所花费的时间，对度量进一步的测试预算有益。

第46页：方法范围测试的设计样式

方法范围测试设计样式：

• 1. 范畴划分
• 2. 组合功能测试
• 3. 递归功能测试
• 4. 多态消息测试

第47页：范畴划分

范畴划分：

目标

根据输入／输出分析，设计方法范围测试包

上下文和故障模型

假定故障与消息参数和实例变量值的组合有关，也假定这种故障将导致遗漏或错误的方法输出

策略

标识每个功能的输入参数的范畴，范畴必须导致不同的输出；把每个范畴划分为选择；通过枚举所有选择的组合产生测试实例

第48页：组合功能测试

组合功能测试：

目标

为了根据状态和／或消息值的组合选择状态，设计一个测试包

上下文和故障模型

一个方法根据消息参数和实例变量的组合选择很多不同动作中的一个时，选择输入组合以便适当地检测选择逻辑

策略

对每个动作最少开发一个测试

第49页：递归功能测试

递归功能测试：

目标

对一个调用自己的方法，设计一个测试包

上下文和故障模型

递归方法接受不正常的参数值、没有足够的栈空间或基本条件不能到达时，都会使递归失败

策略

零次递归；一次递归；递归最大允许的或可行的深度；破坏初始调用、下降阶段和上升阶段的前置、后置条件

第50页：多态消息测试

多态消息测试：

目标

多态服务执行所有客户与服务器的编联，对这种多态服务的一个客户开发测试

上下文和故障模型

不能满足所有可能编联的前置条件；不希望的名字解析或指针的不正确构造发生一个不希望的编联；服务类的实现发生了变化或扩充

策略

对 MUT 中每个多态消息的每种可能编联最少检测一次

第51页：类范围的测试设计样式

类范围测试设计样式：

• 1. 不变量边界
• 2. 非模态类测试
• 3. 准模态类测试
• 4. 模态类测试

第52页：类的模态性

类的模态性：

非模态类

对接受的消息序列不强加任何限制，例如 DateTime

单模态类

对可接受的消息序列有限制，但不管其内容，例如 TrafficLight

准模态类

对随对象的状态而改变的可接受消息进行顺序限制，例如 Stack

模态类

对可接受的消息序列进行消息和域的限制，例如 Account

第53页：不变量边界

不变量边界：

目标

为由复杂和原始数据类型组成的类、接口及构件选择能高效测试的测试值组合

上下文和故障模型

在 IUT 的范围内为所有变量提供值并运行一个测试；实例变量值的有效和无效组合可由类的不变量指定

策略

用断言表达不变量，例如 assert( (txCounter >= 0 && txCount <= 5000) && (creditlimit > 99.99 && creditLimit <= 1000000) && ((!account1.isClosed( ) || !account2.isClosed( ))) )

第54页：非模态类测试

非模态类测试：

目标

为不限制消息顺序的类开发一个类范围测试包

上下文和故障模型

拒绝一个合法的顺序；一个合法的顺序产生一个错误的值；接受非法的修改参数导致错误状态；错误的计算导致类不变量被破坏等

策略

随机序列；质疑序列

第55页：准模态类测试

准模态类测试：

目标

为对随类状态改变而改变的消息序列进行限制的类产生一个类范围测试包

上下文和故障模型

容器和收集类通常是准模态的；有效的测试必须区别决定行为的内容和不影响行为的内容

策略

定义不变量边界，集成操作序列

第56页：模态类测试

模态类测试：

目标

为一个在消息序列上有固定限制的类，开发一个类范围测试包

上下文和故障模型

对可接受的消息序列和域两方面的限制；需要验证所有合法状态：1）将要被接受的消息被接受；2）在这些状态下非法的消息被拒绝；3）接受或拒绝消息所得到的结果状态正确；4）对每个测试消息的响应是绝对正确的

策略

基于状态的测试

第57页：继承的测试

继承的测试：

• 重测试父类方法是为了确定继承的属性可在子类的环境中正确地运行
• 尽可能地复用父类测试包
• 测试子类中细化的／新的方法
• 对子类可以使用类范围内的测试

第58页：面向对象的集成测试

六、面向对象的集成测试：

• 集成测试是探寻导致构件交互错误的构件错误，集成测试策略包括：哪些构件是集成测试的重点？构件接口应该以什么样的顺序进行检测？应该使用哪种测试设计技术检测每个接口？
• 增量式集成是最有效的技术：一次增加少数几个构件，然后测试它们的互操作性

第59页：集成测试的范围

范围：面向对象开发中的集成测试开始得早，在所有范围中都会进行，并且在每个开发增量中重复：

• 在一个类中
• 在一个类层次中
• 在一个客户和它的服务者中
• 在一个相关类的簇中
• 在一个子系统中
• 在一个应用系统中

第60页：集成故障一

集成故障（1）：

• 配置／版本控制问题
• 遗漏、重叠或冲突的函数
• 文件或数据库使用不正确或不一致的数据结构
• 文件或数据库使用冲突的数据视图／用法
• 破坏全局存储或数据库的数据完整性
• 由于编码错误或未预料到的动态绑定导致的错误方法调用
• 客户发送违反服务对象前提条件的的消息
• 客户发送违反服务对象的顺序约束的的消息
• 错误的对象和消息的绑定（多态目标）

第61页：集成故障二

集成故障（2）：

• 错误参数或不正确的参数值
• 由不正确的内存管理分配／回收引起的失败
• 不正确地使用虚拟机、ORB 或 OS 服务
• 目标环境的服务已经过时
• 目标环境当前不支持试图使用的新服务
• 构件之间的冲突
• 资源竞争

第62页：集成测试的设计样式一

集成测试的设计样式（1）：

大爆炸集成

试图通过同时测试所有的构件以论证系统稳定性

自底向上集成

依据使用相依性来交错进行构件和集成测试

自顶向下集成

依据使用控制层次来交错进行构件和集成测试

协作集成

根据协作的构件和它们之间的相依性选择一个集成次序，通过一次测试一个协作组来检测接口

基干集成

结合了自顶向下、自底向上和大爆炸集成，以达到一个支持迭代开发的稳定系统

第63页：集成测试的设计样式二

集成测试的设计样式（2）：

层次集成

增量式地检测一个层次体系结构中的结构和构件

客户／服务器集成

检测一个构件松散连接的网络，其中所有构件使用一个公用的服务器构件

分布服务集成

检测一个对等构件松散连接的网络

高频集成

开发并重运行一个集成测试包进行每小时、每日或每周测试

第64页：大爆炸集成

大爆炸集成：

目标

通过少数测试运行检测整个系统来论证系统的稳定性

上下文和故障模型

不考虑构件之间的相依性或风险；只有少数几个构件被加入或修改；每个构件都通过了充分的构件范围测试；无法分别对构件进行检测

策略

在系统范围应用一个测试包

第65页：自底向上集成

自底向上集成：

目标

从具有最少相依性的构件开始，按照使用相依性的次序将构件加入被测系统，以证实稳定性

上下文和故障模型

具有最少相依性的构件最先测试，当这些构件通过测试后，用它们的客户对象替换驱动模块，再开始下一轮测试

策略

以在相依性树中从叶子移动到根的方式进行，如果树有 n 级，则需要 n 个阶段

第66页：自顶向下集成

自顶向下集成：

目标

从顶层控制对象开始，以控制层次的顺序向 SUT 增加构件以论证稳定性

上下文和故障模型

首先测试控制对象；增量式开发；并行硬件／软件开发；并行软件开发；框架开发

策略

从最高控制层构件开始测试，以桩的形式实现服务对象；每一层按宽度优先进行，用实现代替桩，并为下面低层服务对象设置桩对象，直到系统测试完

第67页：协作集成

协作集成：

目标

通过向 SUT 中加入构件集合证明稳定性，该集成被要求支持一个特定的协作

上下文和故障模型

检测协作参与者之间的接口并根据协作组织集成；它们的顺序可以根据相依性或顺序激活约束或根据二者共同来选择

策略

为被测系统开发相依性树；选择应用协作的序列；为协作开发运行测试包

第68页：基干集成

基干集成：

目标

结合自顶向下、自底向上和大爆炸集成，以验证紧密耦合的子系统之间的互操作性

上下文和故障模型

系统没有基干就不能运转；基干提供了运行测试和应用必须的服务；试图设置基干的桩可能不可行或非常复杂；中层由一些簇构成，簇间耦合较松散而簇内耦合紧密

策略

控制的顶层或第二层自顶向下测试；对低层的服务对象自底向上测试；基干构件被单独测试和大爆炸测试

第69页：层次集成

层次集成：

目标

使用增量式的方法验证一个层次体系结构中的稳定性

上下文和故障模型

为一个允许只有相邻层之间接口的层次建模；通过层间的消息传播可能必须满足一个严格的、实时的期限

策略

单独测试每一层；层次集成可能是自顶向下或自底向上的

第70页：客户/服务器集成

客户／服务器集成：

目标

从单独测试客户和服务对象开始，使用受控增加直到所有接口被测试

上下文和故障模型

通过客户／服务器集成序列达到；并行的开发和测试是可能的

策略

每个客户用服务器的桩测试；该服务器用所有客户类型的桩测试，然后去掉桩进行实际测试；可以递归地应用于三重或 n 重客户／服务器体系

第71页：分布服务集成

分布服务集成：

目标

论证松散耦合的对等构件之间的交互的稳定性

上下文和故障模型

被测系统包括许多并发运行，没有专一的控制轨迹；没有专一的服务器层

策略

风险驱动，从最可能有问题的接口和构件开始；反风险驱动，从最不可能有问题的接口和构件开始；相依性驱动，从依赖最少的构件开始；优先驱动，从验证高优先级性能需要的接口和构件开始

第72页：高频集成

高频集成：

目标

频繁地将新代码和已稳定化的基线集成在一起，以免集成故障不能被发现，以及防止运行的、稳定化的基线偏差

上下文和故障模型

一个稳定的增量是可得到的；大多有意义的功能增量可以在频率间隔内产生；测试和代码可并行开发；高频集成必须是自动化的；必须安装并常规使用配置管理工具

策略

开发者产生要集成的代码增量和相关的测试包；测试员将开发者的修改汇总并运行集成测试包；评价结果，并立即纠正任何问题

第73页：本章小结

小结 —— 面向对象的软件测试：

• 1. 基本概念
• 2. 测试计划
• 3. 测试模型
• 4. 面向 UML 的测试
• 5. 类的测试
• 6. 集成测试