面向对象实现 文档.pptVIP

集成 = 组装有关联的类 不存在层次的控制结构 ( 隐含在类中 ) 传统的自顶向下 / 自底向上的集成策略无意义。 12.3.2 面向对象的集成测试 31 面向对象软件的集成测试的两种策略 : （ 1 ） 基于线程的测试（ thread based testing): 把 响应系统的一个输入或一个事件所需要的那些类 ( 线程 ) 集成起来。 （ 2 ） 基于使用的测试（ use based testing): 首先 测试独立类 ( 几乎不使用其它类的类 ) ，再测试使用 独立类的下一个层次的类（称为依赖类）。据此依 赖关系持续下去，直至把整个软件系统构造完为止。 集群测试（ cluster testing ）：用精心设计的测试用 例检查一群相互协作的类（通过研究对象模型可以 确定协作类），以发现不同的类之间的协作错误。 32 和传统的确认测试一样，面向对象软件的确认测试 也集中检查用户可见的动作和用户可识别的输出。 从动态模型和描述系统行为的脚本可导出确认测试 用例，以发现用户交互需求可能错误的情景。 黑盒测试方法也可用于设计上述确认测试用例。 12.3.3 面向对象的确认测试 33 与传统软件测试不同，面向对象测试关注设计 适当的操作序列以检查类的状态。 （ 1 ）传统方法的可用性 白盒测试：用于类级别的测试。测试类中封装的 操作，检查类的状态以确定是否存在错误。 黑盒测试：用于集成测试、确认测试。 12.4 设计测试用例 34 着重测试单个类和类中封装的方法主要有：随 机测试、划分测试和基于故障的测试等 3 种。 12.4.1 测试类（单元）的方法 1. 随机测试 ? 随机选取测试类操作序列以测试该类对象不 同的生命历史 ? 问题的性质隐含了一些限制 例：银行应用系统的 account( 账户）类有下 列操作： open( 打开）， setup( 建立）， deposit( 存款）， withdraw( 取款）， balance( 余额）， summarize( 清单）， creditLimit( 透支限额）和 close( 关闭）。 限制：必须在其他操作前打开账户，完成了 全部 操作之后 才能 (/ 必须 ) 关闭账户。 35 一个 account 类实例的最小 ( 正常 ) 行为历史包 含下列操作： open· setup· deposit.withdraw· close 可能发生许多其他行为： Open· setup· deposit· [deposit|withdraw|bala nce|summarize|creditLimit] n .withdraw· close 从上列序列可以随机地产生一系列不同的操 作序列： #r1:open· setup· deposit· deposit· balance· su mmarize.withdraw· close #r2:open· setup· deposit· creditLimit· withdraw · close 36 2. 划分测试 划分测试（ partition testing ）可以减少测试 用例的数量。 3 种划分：状态，属性，功能。 （ 1 ） 基于状态的划分 根据类操作是否改变类状态来划分。 考虑 account 类，状态操作包括 deposit 和 withdraw ， 而非状态操作有 balance, summarize 和 creditLimit 。 然后为每个类别设计测试序列。用例应覆盖各类操 作的每一操作。 37 （ 2 ） 基于属性的划分 根据类操作使用的属性来划分。 对于 account 类来说，可使用属性 balance( 余 额 = 状态 ) 把操作划分成 3 个类别： 使用 balance 的操作； 修改 balance 的操作； 不使用也不修改 balance 的操作。 用重要属性（状态）而非每个属性来划分。 38 （ 3 ） 基于功能的划分 根据类操作所完成的功能来划分。 例如，可以把 account 类中的操作分类为初 始化操作（ open,setup ），计算操作 （ deposit, withdraw ），查询操作（ balance, summarize,creditLimit ）和终止操作 （ close ）。 39 第 12 章 面向对象的实现 第 12 章 面向对象实现