第四部分第23章面向对象测试.ppt

第四部分 第23章 面向对象测试 第23 章 面向对象测试 随着OOA 和OOD 的成熟，更多的设计模式的复用将加快OO 系统的设计; 但并不能减少繁重的测试量。因为每次复用是一个新的使用语境，要谨慎地重新测试。 为了获得面向对象系统的高可靠性，将需要更多、而不是更少的测试。 为了充分地测试OO 系统，必须做好三件事： (1) 测试的定义必须扩大到包括用于OOA 和OOD 模型的错误发现技术； (2)单元和集成测试策略必须有很大的改变； (3)测试用例的设计必须考虑OO 软件的独特特征。 23.1 扩大测试的视角 OO 分析和设计模型的复审是特别有用的; 相同的语义结构,如，类、属性、操作、消息,出现在分析、设计和代码阶段; 在分析阶段发现的类属性定义中的问题将遏制问题传播到设计和编码阶段。 23.2 测试OOA 和OOD 模型 分析和设计模型不能进行传统意义上的测试，因为它们不能被执行。 正式的技术复审可用于检查分析和设计模型的正确性、完整性和一致性。 完整性是对模型的包含性的测量。模型中是否遗漏了某个必须的或至少是有用的元素？ 为了确定模型是否确实在事实上反应了现实世界，它应该被送给问题域专家; 专家将检查类定义和类层次以发现遗漏和歧义性。并评估类关系(实例连接)以确定它们是否精确地反应了现实世界的对象连接. 23.2.2 OOA 和OOD 模型的一致性 一致性是对在模型内部以及当前模型和它的基础模型之间是否存在矛盾的测量。 为了评估一致性，应该检查每个类及其和其他类的连接。可运用类—责任—协作者(CRC)模型和对象—关系图. 协作蕴含了在OO 系统的类之间的一系列关系 对象-关系模型提供了类之间连接的图形表示。 一致性检查能决定在一个图例的内部或者是两个图例之间是否存在任何矛盾或冲突的地方。 一旦已经创建了设计模型，也应该进行对系统设计和对象设计的复审。 系统设计描述了构成产品的子系统、子系统被分配到处理器的方式、以及类到子系统的分配。 对象模型表示了每个类的细节和实现类间的协作所必需的消息序列活动. 通过检查在OOA 阶段开发的对象—行为模型，和映射需要的系统行为到被设计用于完成该行为的子系统来进行系统设计的复审。 在系统行为的语境内复审并发性和任务分配，评估系统的行为状态以确定哪些行为并发地存在。 对象模型应该针对对象—关系网络来测试，以保证所有设计对象包含所必须的属性和操作。 此外，使用传统的检查技术来实现复杂操作细节的详细规约(即，实现操作的算法)。 23.3 面向对象的测试策略 在传统应用中，单元测试集中在最小的可编译程序单位——子程序(如，模块、子例程、进程)， 一旦这些单元均被独立测试后，它被集成进程序结构中，这时要进行一系列的回归测试以发现由于模块的接口所带来的错误和新单元加入所导致的副作用， 最后，系统被作为一个整体测试以保证发现在需求中的错误。 23.3.1 在OO 语境中的单元测试 考虑面向对象软件时，单元的概念发生了变化。 封装驱动了类和对象的定义，这意味着每个类和类的实例(对象)包装了属性(数据)和操纵这些数据的操作(方法或服务)，而不是个体的模块。 最小的可测试单位是封装的类或对象， 类包含一组不同的操作，并且某特殊操作可能作为一组不同类的一部分存在; 不再孤立地测试单个操作(传统的单元测试观点)，而是将操作作为类的一部分。 OO 软件的类测试等价于传统软件的单元测试 和传统软件的单元测试不一样，它往往关注模块的算法细节和模块接口间流动的数据， OO 软件的类测试是由封装在类中的操作和类的状态行为所驱动的。 如果类的实现正确，则类的每个实例的行为也应该是正确的。 23.3.2 在OO 语境中的集成测试 因为面向对象软件没有层次的控制结构，传统的自顶向下和自底向上集成策略就没有意义， 此外，一次集成一个操作到类中(传统的增量集成方法)经常是不可能的，这是由于“构成类的成分的直接和间接的交互” 对OO 软件的集成测试有两种不同策略: 第一种称为基于线程的测试(thread－based testing)： 集成响应系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，应用回归测试以保证没有产生副作用。 第二种称为基于使用的测试(use－based testing)： （1）通过测试那些几乎不使用服务器类的类(称为独立类)来开始系统的构造， （2）在独立类测试完成后，下一层的使用独立类的类，称为依赖类，被测试。 （3）这个依赖类层次的测试序列一直持续到构造完整个系统。 与传统集成不同，尽可能避免使用驱动程序和桩(stubs)作为替代操作。 23.3.3 在OO 语境中的确认测试 在确认或系统层次，类连接的细节消失了。 和传统确认一样，O