测试内容

概述

测试考虑方面

认定的对象的测试

认定的对象：对问题空间中的结构、其他系统、设备、被记忆的事件、系统涉及的人员等实际实例的抽象

（1）           是否全面，问题空间中的实例是否都反映在认定的抽象对象中了

（2）           是否具有多个属性，只具有一个属性的对象不抽象为为独立的对象

（3）           对认定为同一对象的实例是否有共同的、区别于其他实例的共同属性

（4）           对认定为同一对象的实例是否提供或需要相同的服务，如果服务随着实例的不同而变化，认定的对象就需要分析或利用继承性来分类表示

（5）           如果系统没有必要始终保持对象代表的实例信息，提供或者得到关于它的服务、认定的对象也无必要

（6）           认定的对象的名称要尽量准确、适用

认定的结构的测试

认定的结构：多种对象的组织方式，用来反映问题空间中的复杂实例和复杂关系，认定的结构分为两种：分类结构

组装结构

分类结构：体现问题空间中实例的一般与特殊的关系

（1）           结构中一种对象尤其是高层对象，是否存在不同于下一层对象的特殊的可能性，即是否能派生出下一层对象

（2）           结构中一种对象尤其是同一低层对象，是否能抽象出在现实中有意义的更一般的上层对象

（3）           对所有认定的对象，是否能向上层抽象出现实中有意义的对象

（4）           高层的对象的特性是否完全体现下层的共性

（5）           低层的对象是否有高层特性基础上的特殊性

组装结构：体现问题空间中实例的整体与局部的关系

（1）           整体对象和部件对象的组装关系是否符合现实的关系

（2）           整体对象和部件对象是否在考虑的问题空间中有实际关系

（3）           整体对象是否遗漏了在问题空间中有用的部件对象

（4）           部件对象是否能够在问题空间中组装成新的有意义的的整体对象

认定的主题的测试

主题：在对象和结构的基础上更高一层的抽象，是为了提供OOA 分析结果的可见性，如同文章中各章的摘要

（1）           贯彻George Miller的‘7+2’原则。如果主题个数超过7个，对有较密切属性和服务的主题归并

（2）           主题所反映的一组对象和结构是否具有相同或相近的属性和服务

（3）           认定的主题是否是对象和结构更高一层的抽象，是否便于理解OOA 结果的概括

（4）           主题间的消息联系（抽象）是否代表了主题所反映的对象和结构之间的所有关联

对定义的属性和实例关联的测试

属性：用来描述对象或结构所反映的实例的特性

实例关联：反映实例集合间的映射关系

（1）           定义的属性是否对相应的对象和分类结构的每个现实实例都适用

（2）           定义的属性在现实世界是否与这种实例关系密切

（3）           定义的属性在问题空间是否与实种实例关系密切

（4）           定义的属性是否能够不依赖于其他属性被独立理解

（5）           定义的属性在分类结构中的位置是否恰当，低层对象的共有属性是否在上层对象属性中体现

（6）           在问题空间中每个对象的属性是否定义完整

（7）           定义的实例关联是否符合现实

（8）           在问题空间中实例关联是否定义完整，特别需要注意‘一对多’、‘多对多’的实例关联

对定义的服务和消息关联的测试

定义的服务：定义的每一种对象和结构在问题空间所要求的行为

消息关联：问题空间中实例之间必要的通信，需要定义相应的消息关联

（1）           对象和结构在问题空间中的不同状态是否定义相应的服务

（2）           对象和结构所需的服务是否都定义了相应的消息关联

（3）           定义的消息关联所指引的服务是否正确

（4）           沿着消息关联执行的线程是否合理，是否符合现实过程

（5）           定义的服务是否重复，是否定义了能够得到的服务

测试名称

概述

测试考虑方面

认定的类的测试

认定的类：可以是OOA中认定的对象，或对象所需要的服务的抽象、对象所具有的属性的抽象。认定的类尽量具有基础性，便于维护和重用

（1）           是否涵盖了OOA中所有认定的对象

（2）           是否能体现OOA中定义的属性

（3）           是否能实现OOA中定义的服务

（4）           是否对应着一个含义明确的数据抽象

（5）           是否尽可能少地依赖其他类

（6）           类中的方法是否是单用途

构造的类层次结构的测试

类层次结构：通常基于OOA中产生的分类结构的原则来组织，着重体现父类和子类一般性和特殊性，在当前问题空间中，主要要求是能在解空间中构造全部功能的结构框架

（1）           类层次结构是否涵盖了所有定义的类

（2）           是否体现了OOA中所定义的实例关联

（3）           是否实现了OOA中所定义的消息关联

（4）           子类是否具有父类没有的新特性

（5）           子类间的共同特性是否完全在父类中得以体现

类库的支持的测试

类库的支持：也属于类层次结构的组织问题，但重点是再次软件开发的重用。作为高质量类层结构的评估

（1）           一组子类中关于某种含义相同或基本相同的操作，是否有相同的接口

（2）           类中方法的功能是否较单纯，相应的代码行是否较少（<30）

（3）           类的层次结构是否是深度大，宽度小

因为OOA、OOD阶段分析和设计的模型不能进行测试，不能被执行，所以每次迭代后要进行评审，针对两个方法：正确性、一致性

正确性：主要在于分析和设计模型表示所使用的符号语法是否正确，语义是否正确以及类的关联（实例间的联系）是否正确地反映了真实世界对象间的关联

一致性：OOD和OOA模型（分析、设计和编码层次即类、属性、操作、消息）要一致，可以用模型内各实体之间的关联性判断；评估方法：检查每个类与其他类的连接，采用CRC（类－责任－协作者）模型和对象－关系图

CRC模型：由CRC索引卡片构成，卡片中列出类名、类的操作、以及其他协作类，类完成的责任

对象－关系图：提供了类之间连接（关系）的图形表示

评估类模型，采用步骤

（1）           再次考察CRC模型和对象－关系模型，进行交叉检查，保证OOA模型所包含的协作都能体现

（2）           检查每个CRC索引卡片的描述，以确定是否某被授权的责任是协作者定义的一部分

（3）           反转该连接，保证每个被请求的服务的协作者正在接收来自合理源的请求

（4）           使用在（3）的反转连接，确定是否可能需要其他的类，或责任是否被合适地在类间分组

（5）           确定是否被广泛请求的责任可被组合为单个的责任

（6）           步骤（1）～（5）被迭代地应用到每个类，并贯穿于OOA模型的每次演化中

创建设计模型，应对系统设计和对象设计进行复审

系统设计：描述构成产品的子系统、子系统分配到处理器的方式，类到子系统的分配；通过检查在OOA阶段开发的对象－行为模型，和映射需要的系统行为到被设计用于完成该行为的子系统来进行复审。在系统行为语境中复审并发性和任务分配，评估系统的行为状态以确定哪些行为为并发存在

对象模型：表示了每个类的细节和实现类间的协作所必须的消息序列活动；针对对象－关系网络来测试，以保证所有设计对象包含为实现每张CRC索引卡片定义的协作所必须的属性和操作