面向对象设计(OOD)的测试
考试要求: 掌握     
知识路径:  > 测试技术的分类  > 面向对象的软件测试技术  > 面向对象软件的测试策略


 
       在以往结构化的设计方法,用的“是面向作业的设计方法,它把系统分解以后,提出一组作业,这些作业是以过程实现系统的基础构造,把问题域的分析转化为求解域的设计,分析的结果是设计阶段的输入”。
       而面向对象设计(OOD)采用“造型的观点”,以OOA为基础归纳出类,并建立类结构或进一步构造成类库,以实现分析结果对问题空间的抽象。OOD归纳的类既可以是对象简单的延续,也可以是不同对象的相同或相似的服务。因此,OOD是OOA的进一步细化和更高层的抽象。所以,OOD与OOA的界限一般是很难严格区分的。OOD确定类和类结构不仅是满足当前需求分析的要求,更重要的是通过重新组合或加以适当的补充,能方便实现功能的重用和扩增,以不断适应用户的要求。因此,对OOD的测试,建议针对功能的实现和重用以及对OOA结果的拓展,从如下三方面考虑:
       . 对认定的类的测试。
       . 对构造的类层次结构的测试。
       . 对类库的支持的测试。
       对认定的类的测试
       OOD认定的类可以是OOA中认定的对象,也可以是对象所需要的服务的抽象,对象所具有的属性的抽象。认定的类原则上应该尽量具有基础性,这样才便于维护和重用。测试认定的类包括如下方面:
       . 是否涵盖了OOA中所有认定的对象。
       . 是否能体现OOA中定义的属性。
       . 是否能实现OOA中定义的服务。
       . 是否对应着一个含义明确的数据抽象。
       . 是否尽可能少地依赖其他类。
       . 类中的方法(在C++中即类的成员函数)是否是单用途。
       对构造的类层次结构的测试
       为了能够充分发挥面向对象的继承共享特性,OOD的类层次结构,通常基于OOA中产生的分类结构的原则来组织,着重体现父类和子类间的一般性和特殊性。在当前的问题空间,对类层次结构的主要要求是能在解空间构造实现全部功能的结构框架。为此,需要测试如下方面:
       . 类层次结构是否涵盖了所有定义的类。
       . 是否能体现OOA中所定义的实例关联。
       . 是否能实现OOA中所定义的消息关联。
       . 子类是否具有父类没有的新特性。
       . 子类间的共同特性是否完全在父类中得以体现。
       对类库支持的测试
       对类库的支持虽然也属于类层次结构的组织问题,但其强调的重点是再次软件开发的重用。由于它并不直接影响当前软件的开发和功能实现,因此,将其单独提出来测试,也可作为对高质量类层次结构的评估。拟定测试点如下:
       . 一组子类中关于某种含义相同或基本相同的操作,是否有相同的接口(包括名字和参数表)。
       . 类中方法(在C++中即类的成员函数)的功能是否较单纯,相应的代码行是否较少(建议为不超过30行)。
       . 类的层次结构是否是深度大,宽度小的。
       因为OOA、OOD阶段所建立的分析和设计模型不能进行传统意义上的测试,它们不能被执行,所以在每次迭代之后,一定要进行评审。评审主要针对以下两个方面。
       . 正确性
       OO开发模式为演化(重复迭代)性质,即系统的初期为非形式化表示,以后发展为类的细节模型、类的连接和关联,系统设计和配置,以及对类的设计(通过消息组成对象连接模型)。每一阶段都要进行评审。
       正确性主要在于分析和设计模型表示所使用的符号语法是否正确,语义是否正确(即模型与真实世界领域是否一致),以及类的关联(实例间的联系)是否正确地反映了真实世界对象间的关联。
       . 一致性
       由于演化性质,OOA和OOD模型(包括分析、设计和编码层次,即类、属性、操作、消息)不仅要正确,而且要一致。一致性可以用模型内各实体间的关联性来判断。
       为评估一致性,应检查每个类及其与其他类的连接。可运用类-责任-协作者(CRC)模型和对象-关系图。CRC模型由CRC索引卡片构成,每个CRC卡片列出类名、类的责任(操作)、以及其协作者类,类向它们发送消息并依赖它们完成自己的责任。协作包含了在OO系统的类之间的一系列关系(即连接),对象关系模型提供了类之间连接的图形表示。所有这些信息可以从OOA模型得到。
       为评估类模型,推荐采用以下步骤:
       ①再次考察CRC模型和对象-关系模型,进行交叉检查,以保证由OOA模型所蕴含的协作适当地反应在二者中。
       ②检查每个CRC索引卡片的描述,以确定是否某被授权的责任是协作者定义的一部分,例如,某个POS结账系统定义的类,称为credit sale,该类的CRC卡片如下图所示。
       
       一个用于复审的CRC卡片例子
       对于这组类和协作,我们问如果某责任(如,read credit card)被委托给指定的协作者(credit card),该责任是否将被完成,即,类credit card是否具有一个操作以使得它可以被读。在本例的情形中,我们的回答是:“是”。遍历对象关系,以保证所有这样的连接是有效的。
       ③反转该连接,以保证每个被请求服务的协作者正在接收来自合理源的请求,例如,如果credit card类接收来自credit sale类的purchase amount请求,则将会有问题,因为credit card并不知道purchase amount。
       ④使用在第③步检查的反转连接,确定是否可能需要其他的类,或责任是否被合适地在类间分组。
       ⑤确定是否被广泛请求的责任可被组合为单个的责任,例如,read credit card和get authorization在每种情况均发生,它们可以被组合为validate credit。request责任,它结合了获取信用卡号及获得授权。
       ⑥步骤①~⑤被迭代地应用到每个类,并贯穿于OOA模型的每次演化过程中。
       一旦已经创建了设计模型,也应该进行对系统设计和对象设计的复审。系统设计描述了构成产品的子系统、子系统被分配到处理器的方式,以及类到子系统的分配。对象模型表示了每个类的细节和实现类间的协作所必须的消息序列活动。
       通过检查在OOA阶段开发的对象-行为模型,和映射需要的系统行为到被设计用于完成该行为的子系统来进行系统设计的复审。也在系统行为的语境内复审并发性和任务分配,评估系统的行为状态以确定哪些行为并发地存在。
       对象模型应该针对对象-关系网络来测试,以保证所有设计对象包含为实现每张CRC索引卡片定义的协作所必须的属性和操作。
 

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2025 All Rights Reserved
软考在线版权所有