面向对象系统分析与设计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所示，越靠近测试的 外围，测试数据就应该越真实。但真实 数据会使测试时间膨胀，阻碍测试工作 。 系统测试 将所有用户定义的功能组和在一起组成 子系统或系统。 由数据管理组或负责创建测试数据的 人来提供测试数据给程序员。除此之外， 在系统测试时也会引入实际数据。通常为