1. 作业（第 7 章）
语句覆盖的测试用例
判定 输入 预期的输出
序号
1 2 3 A B C X Y Z
1 F F F 1 1 1 1 2 3
2 T T T 20 40 60 10 20 30

2. 作业（第 7 章） 路径覆盖的测试用例
预期的输
序 判定 输入
出
号
1 2 3 A B C X Y Z
1 F F F 1 1 1 1 2 3
2 F F T 1 1 60 1 2 30
3 F T F 1 40 1 1 20 3
4 F T T 1 40 60 1 20 30
5 T F F 20 1 1 10 2 3
6 T F T 20 1 60 10 2 30
7 T T F 20 40 1 10 20 3
8 T T T 20 40 60 10 20 30

3. 第 11 章 面向对象设计
11.1 面向对象设计的准 11.7 设计任务管理子系
则 统
11.2 启发规则 11.8 设计数据管理子系
11.3 软件重用 统
11.4 系统分解 11.9 设计类中的服务
11.5 设计问题域子系统 11.10 设计关联
11.6 设计人机交互子系 11.11 设计优化
统 小结

4. 11.1 OOD 准则
 模块化
 对象就是模块
 抽象
 OO
不仅支持过程抽象，而且支持数据抽象
 信息隐藏
 通过对象的封装性实现
 弱耦合
 不同对象之间相互关联的紧密程度
 交互耦合：对象之间的耦合通过消息连接来实现的
 继承耦合：子类继承父类

5. 11.1 OOD 准则
 强内聚
 服务内聚：一个服务应完成一个且仅完成一个功
能
 类内聚：一个类应该只有一个用途
 一般 - 特殊内聚：是对相应的领域知识的正确抽
取
 可重用
 使用已有的类
 创建新类考虑重用

6. 11.2 启发规则
 设计结果应该清晰易懂
 一般 - 特殊结构的深度应适当（ 7±2 ）
 设计简单的类
 使用简单的协议
 使用简单的服务
 把设计变动减至最小

7. 11.3 软件重用
 重用也叫再用或复用，是指同一事物不作修改
或稍加改动就多次重复使用。广义地说，软件
重用可分为以下 3 个层次
(1) 知识重用 ( 例如，软件工程知识的重用 ) 。
(2) 方法和标准的重用 ( 例如，面向对象方法或国家
制定的软件开发规范的重用 ) 。
(3) 软件成分的重用。
 代码重用
 设计结果重用
 分析结果重用

8. 3. 典型的可重用软件成分
（ 1 ） 项目计划。
（ 2 ） 成本估计。
（ 3 ） 体系结构。
（ 4 ） 需求模型和规格说明。
（ 5 ） 设计。
（ 6 ） 源代码。
（ 7 ） 用户文档和技术文档。
（ 8 ） 用户界面。
（ 9 ） 数据。
（ 10 ） 测试用例。

9. 11.3.2 类构件
 类构件
 独立、可塑、接口清晰
 实例重用
 创建类的实例，然后向所创建的实例发送适当的消
息，启动相应的服务，完成需要完成的工作。这是
最基本的重用方式。
 还可以用几个简单的对象作为类的成员创建出一个
更复杂的类，这是实例重用的另一种形式。

10.  继承重用
 提供了一种安全地裁剪已有类构件
 多态重用
 可以使对象的对外接口更加一般化 ( 基类与派生类
的许多对外接口是相同的 ) ，从而降低了消息连接
的复杂程度

11. 11.4 系统分解

12.  1 子系统之间的两种交互方式
 Client-supplier 和 peer to peer
 2 组织系统的两种方案
 层次组织和垂直块组织
 混合结构
 3 设计系统的拓扑结构
 管道型，树型，星型等

13. 11.5 设计问题域子系统
 1 调整需求
 2 重用已有的类
 3 把问题域类组合在一起
 4 增添一般化类以建立协议
 5 调整继承层次

14. 11.6 人机交互界面设计准则
 一致性
 减少步骤
 及时提供反馈信息
 提供撤消命令
 无须记忆
 易学
 富有吸引力

15. 11.6 设计人机交互子系统
 分类用户
 描述用户
 设计命令层次
 研究已有的人机交互含义和准则
 确定初始的命令层次
 精化命令层次
 设计人机交互类

16. 11.7 设计任务管理子系统
 分析并发性
 设计任务管理子系统
 确定事件驱动型任务
 确定时钟驱动型任务
 确定优先任务
 确定关键任务
 确定协调任务
 尽量减少任务数
 确定资源需求

17. 11.8 设计数据管理子系统
 选择数据存储模式
 文件管理系统
 关系数据库管理系统
 面向对象数据库管理系统
 设计数据管理子系统
 设计数据格式
 文件系统 / 关系数据库管理系统 / 面向对象数据库管理系统
 设计相应的服务

18. 11.9 设计类中的服务
 确定类中应有的服务
 把动态模型中对象的行为和功能模型中的数据处理
转换成适当的类所提供的服务
 设计实现服务的方法
 设计实现服务的算法
 选择数据结构
 定义内部类和内部操作

19. 11.10 设计关联
 1 关联的遍历
 单向遍历和双向遍历
 2 实现单向关联
 指针 / 指针集合
 3 实现双向关联
 只用属性实现一个方向的关联
 两个方向的关联都用属性实现
 用独立的关联对象实现双向关联
 4 关联对象的实现

20. 11.11 设计优化
 确定优先级
 在效率和清晰性之间折中
 提高效率的几项技术
 增加冗余关联以提高访问效率 (hash 表 )
 调整查询次序
 保留派生属性

21. 设计优化 cont
 调整继承关系
 抽象与具体
 为提高继承程度而修改类定义
 利用委托实现行为共享

22. 第 12 章 面向对象实现
12.1 程序设计语言
12.2 程序设计风格
12.3 测试策略
12.4 设计测试用例
12.5 小结

23. 12.1 程序设计语言
12.1.1 面向对象语言 OOL 的优
点
1. 一致的表示方法
面向对象开发基于不随时间变化的、一致的表
示方法 OO 模型： OOA ， OOD ， OOP 。
2. 可重用性
软件开发组织可重用 OOA, OOD 和 OOP 结果
。
3. 可维护性
保持文档与源程序一致的完全一致几乎不可能。
OOL 的可读性 ( 对象名等 ) = 可维护性。

24. 12.1.2 面向对象语言的技术特点
1. 支持类与对象概念的机制
2. 实现整体 - 部分 ( 即聚集 ) 结构的机制
3. 实现一般 - 特殊 ( 即泛化 ) 结构的机制
4. 实现属性和服务的机制
5. 类型检查
6. 类库
7. 效率
8. 持久保存对象
9. 参数化类
10. 开发环境

25. 12.1.3 选择面向对象语言
选择面向对象语言应考虑的因素 :
1. 将来能否占主导地位
语言的生命力及稳定性：维护的考虑。
2. 可重用性
影响重用的要素：封装，继承，多态。
3. 类库和开发环境
语言、开发环境和类库这 3 个因素共同决定可
重用性。
类库是否提供有价值的类？
开发环境是否提供使用方便的类库编辑和浏览
工具。

26. 4. 其他因素
在选择编程语言时，应该考虑的其他因素还有
： 对用户学习面向对象分析、设计和编码技术
所能提供的培训服务；
在使用这个面向对象语言期间能提供的技术支
持；能提供给开发人员使用的开发工具、开发
平台、发行平台；
对机器性能和内存的需求；
集成已有软件的容易程度 ( 调用其它语言的模
块 )。

27. 12.2 程序设计风格
为适应面向对象方法所特有的概念 ( 例如，继
承性 ) 而必须遵循的一些新准则。
12.2.1 提高可重用性
两种代码重用： 1) 本项目内的代码重用， 2)
重用旧 / 外项目的代码。
1) 内部重用 : 利用继承机制共享相同或相似的
部分

28. 12.2.1 提高可重用性
两种代码重用： 1) 本项目内的代码重用， 2)
重用旧 / 外项目的代码。
1) 内部重用 : 利用继承机制共享相同或相似的
部分

29. 实现两类重用的程序设计准则：
1. 提高方法的内聚
一个方法 ( 即服务 ) 只完成单个功能 , 否则把它
分解成几个更小的方法。
2. 减小方法的规模
把规模过大的方法 ( 代码长度超过一页纸 ) ，分
解成几个更小的方法。
3. 保持方法的一致性
功能相似的方法应该有一致的名字、参数特征
( 包括参数个数、类型和次序 ) 、返回值类型、
使用条件及出错条件等。

30. 4. 把策略与实现分开
两种不同类型的方法：策略与实现。
策略方法 ( 拼积木 ) 调用实现方法 ( 积木 ) 来完
成任务 ( 实现图案 ) 。
策略方法通常紧密依赖于具体应用。
实现方法针对具体数据完成特定处理，用于实
现复杂的算法。相对独立于应用，因此，较可
能被重用。

31. 5. 全面覆盖
方法的实现不仅满足当前应用而且应该考虑其
它应用的潜在需要。
此外，方法对空值、极限值及界外值等异常情
况也应该能够作出有意义的响应。
6. 尽量不使用全局信息
应该尽量降低方法与外界的耦合程度，不使用
全局信息，如类变量。

32. 7. 利用继承机制
继承是实现共享和提高重用的主要途径。
(1) 调用子过程：把公共的代码分离出来，构成
一个被其他方法调用的公用方法， 并在基类中
定义它。
(2) 分解因子。从不同类的相似方法中分解出不
同的“因子” ( 即不同的代码 ) ，把余下的代码
作为公用方法中的公共代码，把分解出的因子作
为名字相同 ( 多态性机制 ) 算法不同的方法，放
在不同类中定义，并被这个公用方法调用，如图
所示。
32

33. (3) 使用委托。仅当确实存在一般 - 特殊关系时
，使用继承才是恰当的，否则，可以利用委托
机制，如本书 11.11.3 小节所述。
(4) 把代码封装在类中。（与继承无关）
把被重用的代码封装在类中比较安全和修改。
33

34. 12.2.2 提高可扩充性
提高可重用性的准则，也能提高程序的可扩充
性。此外，下列准则也有助于提高可扩充性：
1. 封装实现策略
把类的实现策略 ( 包括描述属性的数据结构、
修改属性的算法等 ) 封装起来，将提高今后修
改数据结构或算法的自由度。
34

35. 2. 不要用一个方法遍历多条关联链
一个方法应该只包含对象模型中的有限内容，
除非内容与方法无关。否则将导致方法过分复
杂，既不易理解，也不易修改扩充。
3. 避免使用多分支语句
可以利用 DO_CASE 语句测试对象的内部状态
，而不要用来根据对象类型选择应有的行为
( 强耦合 ) ，否则在增添新类时将不得不修改原
有的代码。应该利用多态性机制，根据对象当
前类型，自动决定应有的行为。
35

36. 4. 精心确定公有方法
公有方法是向公众公布的接口。对这类方法的
修改往往会涉及许多其他类。为提高稳定性，
可修改性，降低维护成本，必须精心选择和定
义公有方法。
删除、增加或修改私有方法所涉及的面要窄得
多，因此代价也比较低。
36

37. 12.2.3 提高健壮性
既应该考虑效率，也应该考虑健壮性。需要在
健壮性与效率之间做出适当的折衷。
为提高健壮性应该遵守以下几条准则：
1. 预防用户的操作错误
软件系统必须具有处理用户操作错误的能力。
任何一个接收用户输入数据的方法，对其接收
到的数据都必须进行检查，发现了错误，应该
给出恰当的提示信息，并准备再次接收用户的
输入。
37

38. 2. 检查参数的合法性
对公有方法，尤其应该着重检查其参数的合法
性，因为调用公有方法时可能违反参数的约束
条件。
3. 不要轻易限定数据容量
在设计阶段，很难准确地预测出应用系统中数
据结构的最大容量需求。如果有必要和可能，
应该使用动态内存分配机制。
38

39. 4. 先测试后优化
测试程序的性能以确定是否为提高效率而进行
优化。
如果实现某个操作的算法有许多种，则应该综
合考虑内存需求、速度及实现的简易程度等因
素，经合理折衷选定适当的算法。
39

40. 12.3 测试策略
测试面向对象软件的策略与与面向过程的策略
基本相同，但也有许多新特点。
40

41. 12.3.1 面向对象的单
元测试
最小的可测试单元是单个封装起来的类和对象
。
测试一个类就是测试它的对象子集 ( 不可穷尽 ).
测试对象主要是测试它的操作 .
不能孤立地测试单个操作 :
同一个操作在不同状态下行为不同 .
同一个操作在不同类中有不同的实现 ( 多态性 ).
有必要在每个子类的语境中测试操作
比面向过程更复杂
41

42. 12.3.2 面向对象的集
集成 = 组装有关联的类
成测试
不存在层次的控制结构 ( 隐含在类中 )
传统的自顶向下 / 自底向上的集成策略无意义
。
42

43. 面向对象软件的集成测试的两种策略 :
（ 1 ） 基于线程的测试（ thread based
testing): 把响应系统的一个输入或一个事件所
需要的那些类 ( 线程 ) 集成起来。
（ 2 ） 基于使用的测试（ use based testing):
首先测试独立类 ( 几乎不使用其它类的类 ) ，再
测试使用独立类的下一个层次的类（称为依赖
类）。据此依赖关系持续下去，直至把整个软
件系统构造完为止。
集群测试（ cluster testing ）：用精心设计的
测试用例检查一群相互协作的类（通过研究对
象模型可以确定协作类），以发现不同的类之
43
间的协作错误。

44. 12.3.3 面向对象的确认测试
和传统的确认测试一样，面向对象软件的确认
测试也集中检查用户可见的动作和用户可识别
的输出。
从动态模型和描述系统行为的脚本可导出确认
测试用例，以发现用户交互需求可能错误的情
景。
黑盒测试方法也可用于设计上述确认测试用例
。
44

45. 12.4 设计测试用例
与传统软件测试不同，面向对象测试关注设计
适当的操作序列以检查类的状态。
（ 1 ）传统方法的可用性
 白盒测试：用于类级别的测试。测试类中封
装的操作，检查类的状态以确定是否存在错误
。
 黑盒测试：用于集成测试、确认测试。
12.4.1 测试类（单元）的方法
着重测试单个类和类中封装的方法主要有：随
机测试、划分测试和基于故障的测试等 3 种。
45

46. 1. 随机测试
随机选取测试类操作序列以测试该类对象不同
的生命历史
问题的性质隐含了一些限制
例：银行应用系统的 account( 账户）类有下列
操作： open( 打开）， setup( 建
立）， deposit( 存款）， withdraw( 取
款）， balance( 余额）， summarize( 清单）
， creditLimit( 透支限额）和 close( 关闭）。
限制：必须在其他操作前打开账户，完成了全
部操作之后才能 (/ 必须 ) 关闭账户。
46

47. 一个 account 类实例的最小 ( 正常 ) 行为历史包
含下列操作：
open·setup·deposit.withdraw·close
可能发生许多其他行为：
Open·setup·deposit· [deposit|withdraw|
balance|summarize|
creditLimit]n.withdraw·close
从上列序列可以随机地产生一系列不同的操作
序列：
#r1:open·setup·deposit·deposit·balance·s
ummarize.withdraw·close
#r2:open·setup·deposit·creditLimit·withdra
w·close
47
也要考虑异常（用户或编程 ) 序列：

48. 2. 划分测试
划分测试（ partition testing ）可以减少测试用
例的数量。
3 种划分：状态，属性，功能。
（ 1 ） 基于状态的划分
根据类操作是否改变类状态来划分。
考虑 account 类，状态操作包括 deposit 和
withdraw ，而非状态操作有 balance,
summarize 和 creditLimit 。
然后为每个类别设计测试序列。用例应覆盖各
类操作的每一操作。
48

49. （ 2 ） 基于属性的划分
根据类操作使用的属性来划分。
对于 account 类来说，可使用属性 balance( 余
额 = 状态 ) 把操作划分成 3 个类别：
使用 balance 的操作；
修改 balance 的操作；
不使用也不修改 balance 的操作。
用重要属性（状态）而非每个属性来划分。
49

50. （ 3 ） 基于功能的划分
根据类操作所完成的功能来划分。
例如，可以把 account 类中的操作分类为初始
化操作（ open,setup ），计算操作（ deposit,
withdraw ），查询操作（ balance,
summarize,creditLimit ）和终止操作
（ close ）。
50

51. 3. 基于故障的测试
Fault based testing 与传统的错误推测法类似
，首先推测软件中可能有的错误，然后设计出
最可能发现这些错误的测试用例。
它的效率依靠测试人员的经验和直觉。
它与面向对象的方法无关。
51

52. 12.4.2 集成测试方法
集成测试用例主要针对类间协作进行测试。
测试类间协作可运用基于使用的测试策略 , 找
出相互依赖的类 . 然后设计用例触发类间的各
种交互序列 .
测试类协作可以使用随机测试方法和划分测试
方法，以及基于情景 / 脚本的测试和行为测试
来完成。
UML 的协作图能帮助我们找出相互依赖的类和
交互序列 .
下图展示了一个银行系统的类协作图。
52

53. 箭头线上的标注 :
协作而调用的操作
图 12.3 银行系统的类 - 协作图
53

54. 1. 多类测试
生成多个类的测试用例步骤：
1) 对每个客户 /UI 类，为其生成一系列测试序
列来覆盖所有操作。
2) 对这些操作所生成的每个消息，确定接收消
息的协作类 / 服务器对象中的对应操作。
3 ）把每个 2 ）的操作，结合进测试序列中。
对每个产生消息的操作，继续 2 ）
54

55. 例，储户存款，操作序列：
ATM ： cardInserted.password.deposit
Bank: verifyAcct·verifyPIN·depositReq
ValidationInfo ： validAcct· validPIN
Account ： deposit
#r4:verifyAcctBank· ［ validAcctValidationInfo ］ ·ve
rifyPINBank· ［ validPINvalidationInfo ］ ·depositRe
q· ［ depositaccount ］
55

56. 多个类的划分测试方法类似于单个类。
另一种划分测试方法，根据与特定类的接口来
划分类操作。
Bank 类接收来自 ATM 类和 Cashier 类的消息
，
可以把 Bank 类中的方法划分成服务于 ATM 和
Cashier 的两类来测试它们。
56

57. 2. 从动态模型导出测试用例
类的状态图可以帮助我们导出测试该类（及与
其协作的那些类）的动态行为的测试用例。
57

58. 设计出的测试用例至少应该覆盖所有状态：
#s1:open·setupAccnt·deposit(initial)·withdr
aw(final)·close
导出更多测试用例，以保证所有行为都被测试
：
#s2:open·setupAccnt·deposit(initial)·deposi
t·balance·credit·withdraw(final)·close
#s3:open·setupAccnt·deposit(initial)·deposi
t·withdraw·accntInfo·withdraw(final)·close
在多个类协作的情况下，应该使用多个状态图
。
58

59. 12.5 小结
面向对象设计原则上不依赖于特定的实现环境
，
但实现结果和成本却取决于实现环境。
支持面向对象设计范式的程序语言、开发环境
及类库，对于面向对象的实现非常重要。
具有方便的开发环境和丰富的类库的面向对象
程序设计语言，是实现面向对象设计的最佳选
择。
良好的程序设计风格对于面向对象实现来说同
样重要。
59
传统的程序设计风格准则依然成立，面向对象

60. 面向对象测试的策略和技术与传统测试有所不
同，对象类成为测试的焦点。
测试类时使用的方法主要有随机测试、划分测
试和基于故障的测试。每种方法都测试类中封
装的操作。每种操作要在不同的对象状态（由
对象的属性值表示）下测试。
可以采用基于线程或基于使用的策略完成集成
测试。
从动态模型导出的测试用例，可以测试指定的
类及其协作者。
面向对象系统的确认测试可以用传统的黑盒方
法完成。
情景 / 脚本为系统确认测试提供了用例。 60

61. Test Tools
 CASE tool index - Quite a comprehensive
list of CASE Tools
 Old site:
http://www.cs.queensu.ca/Software-Engineering/
 400 categories; 10% for test
 List of Test related tools
61

62. LOGISCOPE
 LOGISCOPE: Software Quality, Testing,
Maintenance and Reverse-Engineering
 http://
www.telelogic.com/products/logiscope/overview
 VERILOG
 IBM Rational Performance Tester 和 HP
Mercury LoadRunner 的比较
 http://www.ibm.com/developerworks/cn/rational/
62

63. Mercury Interactive
www. Mercury.com
 With Mercury Quality Center, you can:
 Standardize and manage the entire quality process.
 Make quality decisions based on business risks and
priorities.
 Reduce application deployment risk.
 Improve application quality and reliability.
 Manage application change impact through manual and
automated functional testing.
 Track quality assets and progress across releases and test
cycles.
 Warehouse critical application quality project data.
 Test service-oriented architecture services for both
functionality and performance.
 Ensure support for all environments including J2EE, .NET,
Oracle and SAP. 63

64. IBM Rational quality
management
Requirements and Test Requirements, test planning, test results, test analysis,
Management
and reports and defects
Functional Testing Automated and manual functional testing and regression
testing of a wide array of applications including: Java,
.Net, SAP, Siebel and web services
Performance Testing Load testing, performance testing and scalability testing
for a wide array of applications including: Web, Java, .Net,
Citrix, IBM mainframe, SAP, Siebel and web services
Web Application Security
Automated application security scanning, testing and
reporting
Web Compliance Content scanning for privacy, quality and accessibility
compliance testing and reporting
Code Quality and Embedded Systems
Run-time analysis, memory leak detection, performance
profiling, and component testing
64