SE09第9章面向对象实现.pptVIP

课程介绍 第9章 面向对象实现（OOP） 程序设计语言 程序设计风格 测试策略 设计测试用例 实现=编码+ 测试 编码：将软件设计翻译成用某种程序设计语言书写的OO程序 选择程序设计语言 编码风格 测试：测试并调试OO程序 OO的单元测试 OO的集成测试 OO的确认测试 9.1 程序设计语言（自学为主） OO语言的优点： 能够更完整、更准确地表达问题域语义 一致的表示方法 问题域→OOA →OOD →OOP 使用统一的概念、理解软件的各种配置成分 可重用性 可重用OOA 、OOD 、OOP各阶段的结果 可维护性（文档与源程序的一致） 例：源程序显式陈述的问题域语义：ATM、帐户、现金兑换卡 面向对象语言的技术特点 支持类与对象概念的机制 实现整体-部分结构的机制 实现一般-特殊结构的机制 实现属性和服务的机制 类型检查 类库 效率 持久保存对象 参数化类 开发环境 选择面向对象语言 将来能否占主导地位 可重用性 类库和开发环境 其他因素 9.2 程序设计风格（自学为主） 提高可重用性 提高可扩充性 提高健壮性 提高可重用性 编码阶段：代码的重用 内部重用：本项目内的代码重用。找出设计中相同或相似的部分，利用继承机制共享它们 外部重用：一个项目重用另一个项目的代码 提高可重用性的准则（1） 提高方法的内聚：完成单个功能 减小方法的规模：代码长度不超过一页 保持方法的一致：功能相似的方法应有 一致的名字 一致的参数特征：个数、类型、次序 一致的返回值类型 一致的使用条件 一致的出错条件 提高可重用性的准则（2） 把策略与实现分开 策略方法 负责做出决策、提供变元、管理全局资源 检查系统运行状态、处理出错情况 不直接完成计算或实现复杂的算法 依赖具体应用、容易编写和理解 实现方法 负责完成具体的操作、不知为什么执行和是否执行 针对具体数据完成特定处理 用于实现复杂的算法 相对独立于具体应用，可重用 提高可重用性的准则（3） 全面覆盖 针对输入条件的所有组合写出方法 一个方法不仅能处理正常值，对空值、极限值、界外值等异常情况也能作出有意义的响应 尽量不使用全局信息 降低方法与外界的偶合程度 提高可重用性的准则（4） 利用继承机制 调用子过程 分解因子 使用委托 把代码封装在类中 面向对象的软件测试* 目标：用最小的工作量发现最多的错误 OOT：基本目标不变，但改变了测试策略和测试战术 测试焦点：从过程构件（模块）→对象类 测试： 单元测试：测试类中封装的操作 集成测试：基于线程、基于使用 确认测试：基于情景的测试、黑盒测试 9.3 测试策略 9.3.1 OO的单元测试 单元概念的变化—封装的类或对象作为最小的可测试单位 一个类可以包含一组不同的操作，而一个特定的操作也可能存在于一组不同的类中。 不再孤立地测试单个操作(传统单元测试的视角),应将操作作为类的一部分来测试 传统软件的单元测试关注算法细节和模块接口间流动的数据 OO软件的类测试是由封装在类中的操作和类的状态行为驱动的（在每个子类的语境中测试继承的操作） 9.3.2 OO的集成测试 OO软件没有层次的控制结构,传统的自顶向下和自底向上的集成策略没有意义 OO软件集成测试的两种策略: 基于线程的测试(thread-based testing) 基于使用的测试(use-based testing) 9.3.3 OO的确认测试 在确认测试或系统测试层次,不再考虑类之间相互连接的细节 和传统的确认测试一样,OO软件的确认测试集中检查用户可见的动作和用户可识别的输出。 为导出确认测试用例, 应利用动态模型和描述系统行为的脚本，确定最可能发现用户交互需求错误的情景。 9.4 设计测试用例 OO软件的测试用例的设计方法，还处于研究、发展阶段 传统软件测试：用例的设计由软件的输入—处理—输出视图或单个模块的算法细节驱动 OO测试：关注于设计适当的操作序列以检查类的状态 9.4.1 测试类的方法 随机测试（random testing ） 划分测试 (partition testing) 基于状态的划分 基于属性的划分 基于功能的划分 基于故障的测试(fault_based testing) （1）随机测试 （2）划分测试 与测试传统软件时采用的等价类划分方法类似 优点:可以减少测试类时所需测试用例的数量 首先将输入、输出分类，然后设计测试用例以测试划分出的每个类别 划分类别的方法: 基于状态的划分 基于属性的划分 基于功能的划分 基于状态的划分 基于属性的划分 基于功能的划分 （3）基于故障的测试 与传统的错误推测法类似： 推测软件中可能有的错误 设计最可能发现这些错误的测试用例 如：问题的边界处 9.4.2 集成测试方法 开始集成OO系统以后, 进行类间协作测试. 与单个类