|
|
知识路径： > 测试技术的分类 > 面向对象的软件测试技术 > 面向对象软件的测试策略 > 面向对象设计（OOD）的测试 >
|
|
相关知识点：3个
|
|
|
|
|
对类库的支持虽然也属于类层次结构的组织问题，但其强调的重点是再次软件开发的重用。由于它并不直接影响当前软件的开发和功能实现，因此，将其单独提出来测试，也可作为对高质量类层次结构的评估。拟定测试点如下：
|
|
|
|
. 一组子类中关于某种含义相同或基本相同的操作，是否有相同的接口（包括名字和参数表）。
|
|
|
|
. 类中方法（在C++中即类的成员函数）的功能是否较单纯，相应的代码行是否较少（建议为不超过30行）。
|
|
|
|
|
|
因为OOA、OOD阶段所建立的分析和设计模型不能进行传统意义上的测试，它们不能被执行，所以在每次迭代之后，一定要进行评审。评审主要针对以下两个方面。
|
|
|
|
|
|
OO开发模式为演化（重复迭代）性质，即系统的初期为非形式化表示，以后发展为类的细节模型、类的连接和关联，系统设计和配置，以及对类的设计（通过消息组成对象连接模型）。每一阶段都要进行评审。
|
|
|
|
正确性主要在于分析和设计模型表示所使用的符号语法是否正确，语义是否正确（即模型与真实世界领域是否一致），以及类的关联（实例间的联系）是否正确地反映了真实世界对象间的关联。
|
|
|
|
|
|
由于演化性质，OOA和OOD模型（包括分析、设计和编码层次，即类、属性、操作、消息）不仅要正确，而且要一致。一致性可以用模型内各实体间的关联性来判断。
|
|
|
|
为评估一致性，应检查每个类及其与其他类的连接。可运用类-责任-协作者（CRC）模型和对象-关系图。CRC模型由CRC索引卡片构成，每个CRC卡片列出类名、类的责任（操作）、以及其协作者类，类向它们发送消息并依赖它们完成自己的责任。协作包含了在OO系统的类之间的一系列关系（即连接），对象关系模型提供了类之间连接的图形表示。所有这些信息可以从OOA模型得到。
|
|
|
|
|
|
①再次考察CRC模型和对象-关系模型，进行交叉检查，以保证由OOA模型所蕴含的协作适当地反应在二者中。
|
|
|
|
②检查每个CRC索引卡片的描述，以确定是否某被授权的责任是协作者定义的一部分，例如，某个POS结账系统定义的类，称为credit sale，该类的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索引卡片定义的协作所必须的属性和操作。
|
|
|
