面向对象系统分析与设计Ch12软件构建与测试.ppt

Ch12软件构建与测试 信息系统一般是由软件 硬件 数据 人员和过程组成 本章集中讨论信息系统中的软件部分 包括软件设计的基本原则 软件构建框架 软件测试 探讨并阐述了当前广为接受的一些软件构建策略 为了说明一种好的编程方法 还介绍了软件的聚合与耦合策略 最后简要讨论了应用程序和代码生成器 12 1软件设计的一般原则 1软件能正确工作 2软件必须与项目分析阶段建立的以及在设计阶段以及在设计阶段添加的需求规格说明文档相一致 3软件必须长期可靠 最难完全应付 4软件必须易维护且易扩展 5软件必须容易使用 6软件应该易于测试和安装 7软件应有效利用计算机资源 12 2软件构建框架 实际软件构建之前应该准备软件蓝图即需求规格说明文档和其他支持文档 它们包括系统模型 尽管图12 1显示出软件构建是从一条条语句开始的 早在编出第一条语句以前 在准备文档中就已经设计好了模块 程序 子系统和系统及它们的功能 12 4面向对象的软件构建框架 12 5软件构建策略 自顶向下 自底向上 自中间向上下 或是前三种的任意组合 自顶向下通过分解功能来解决问题 从设计概要或系统高层视图出发 然后编码 直到底层模块 自底向上先为系统中最底层细节编程 逐步在更高层累计细节直至最终满足系统要求 最终到达顶层面向控制的模块 3 自中间向上下先开始做系统中看来容易的 再向相应的高层或底层扩展 12 6聚合和耦合聚合和耦合是与模块和服务相关联的概念 聚合是模块内各条语句相互关联程度的度量 耦合是模块间关联程度的度量 应努力维持高聚合和低耦合 聚合和耦合是一种平衡操作 1聚合聚合是单个模块中语句间相互相关紧密程度的度量 如图12 3所示偶然型聚合最差 模块进行了实际上无关操作逻辑型聚合模块进行了一系列相关操作 调用模块要求其中一个或多个操作 时间型聚合模块进行了一系列时间上相关的操作 过程型聚合模块进行了一系列与执行顺序有关的操作 优于时间型聚合 因为操作的相关是为了完成任务 并非是同时完成 通讯型聚合模块进行了一系列与执行顺序有关 并处理同一数据的操作 优于过程型聚合信息型聚合操作满足 1 有自己的入口 出口 2 代码彼此独立 3 作用于同一数据结构 这使得模块各段代码独立而功能相关 如图12 4 功能型聚合最好模块只进行一项操作 或只完成一个目标 便于在不同场合下重用 更易维护 几种聚合的比较如图12 3所示2耦合耦合的最终目标是使之最小化 即所有模块都只做一件事且和其他模块无关 耦合度高的模块更难维护和重用 内容型耦合最差指模块直接引用其他模块的内容 极难维护 公共型耦和至少两个模块要访问同一全局数据因为要在局部模块中修改全局变量 因而不易管理控制型耦合模块将控制元素传给另外的模块 以控制第二个模块的逻辑 标志型耦合模块可将完整的数据结构或记录传给另一模块 因为可能会误以为所有数据元素都已被使用 所以难以维护 数据型耦合最好把其他模块简单看作黑盒 接受其他模块数据变量输入 或向其他模块输出数据变量 或二者皆有几种耦合的比较如图12 5所示12 6 1面向对象的聚合和耦合用面向对象概念分析 设计和编程可以实现更优的聚合和耦合 当然很差的聚合和耦合也可能存在 对于面向对象软件 类的模式同时包入属性和服务 使其自身具有了较高的聚合和耦合 另外 面向对象创建对象 删除对象 修改属性的唯一办法是通过类包入的服务 这样也提高了聚合和耦合 事实上不可能让耦合高于控制型耦合 聚合低于过程型聚合 12 7软件测试12 7 1软件测试原则软件测试开始于测试计划 结束于用户验收测试后的软件 测试应致力于引出并发现错误 并不是为了证明程序可以正常工作 大力推行合理性规则 即测试应遵循一般可接受的测试技术 12 7 2软件测试策略软件测试策略与前述的软件构建策略相同 有自顶向下 自底向上 自中间出发 以及任一混合形式 另外 白盒 黑盒 Alpha Beta测试也都是用来实现自顶向下 自底向上 自中间出发及混合策略的附加策略 白盒与黑盒软件测试者通常把系统 子系统 程序和模块的一部分视作白盒或黑盒 白盒 从内部视角进行测试的那部分软件 通常是程序员对自己编写的代码进行白盒测试 可以修改 黑盒 从外部视角进行测试的那部分软件 无法对模块进行修改 将其报告给项目主管或编写它的程序员 Alpha测试与Beta测试在内部测试者测试完以后 这级测试被称为Alpha测试 即第一回合在内部测试者之间完成 然后进入下一层Beta测试 通常是由选定的一组顾客像在正常环境下使用软件一样进行测试 因此 Alpha测试友软件开发的内部人员进行 而Beta测试由顾客进行 12 7 2一般软件测试方法论不管软件是内部使用还是用来销售 下述的一般软件测试方法论都可适用 见图12 6 不论在方法论的哪一级上进行测试时发现了错误 都需要回到第一层以保证代码在各层测试都没错 不能假定程序在一段代码或模块中作了修改后不会影响软件的另一部分 单元 模块测试由编写软件的程序员 在创建软件模型或单元的过程中进行 使用解释型变成语言以节约测试时间和费用 并且可以得到及时地反馈 测试数据由程序员自己创建 集成测试将几个单元或模块组合起来作为整体进行测试 通常使用桩测试技术 桩测试 指模块以自顶向下 自底向上或自中间出发方式综合后 作为单个模块进行测试的方法 桩模块没有内部逻辑 只是模拟由程序员所测试的模块调用的 或被调用的模块 如图12 7 如图12 8程序员用编出一个调用模块以调用所测试的模块 或编出一个被调用模块 程序员自己创建数据进行测试功能测试组合一组或多组经过集成测试的模块以实现用户在需求说明文档中定义的功能 由数据管理组或负责创建测试数据的人来提供测试数据给程序员 我们之一在使用测试数据而不是真实数据 如图12 6所示 越靠近测试的外围 测试数据就应该越真实 但真实数据会使测试时间膨胀 阻碍测试工作 系统测试将所有用户定义的功能组和在一起组成子系统或系统 由数据管理组或负责创建测试数据的人来提供测试数据给程序员 除此之外 在系统测试时也会引入实际数据 通常为