即是长期使用、临时使用、实验用或测试用等。 使用它的程序，具体内容有：
　　约定：为了使用本数据库而需要了解的约定，如建立标号、标识的约定， 标识不同版本的约定，标识库内文件、记录、数据项的约定等。
　　专门指导：向研制、测试、维护人员提供的指导，例如被送入数据库的 数据格式和标准、输入操作、建立和维护操作等。
③结构设计 结构设计可包括概念结构设计、逻辑结构设计和物理结构设计三部分。 概念结构设计：说明本数据库将反映的现实世界的实体、属性和它们之
间关系等的原始数据形式，包括数据项、记录等内容的标识符、定义、类型、 度量单位和值域等，建立各种用户视图（E—R 图）。
逻辑结构设计：由现实世界的实体和属性转换成计算机世界的数据结构
（数据模型），包括所确定的关键字和属性、重新确定的记录结构和文卷结 构、所建立的各个文卷之间的关系等，形成数据库管理员视图。
　　物理结构设计：建立程序员视图，如：数据在内存的安排（包括索引区、 缓冲区的设计）；所使用的外存设备和外存空间的组织（包括索引区、数据 块的组织与划分）；访问数据的方式方法。
④运用设计
　　数据字典设计：把需求说明书中的数据字典转换成数据库所需要的，如 标识符的命名、有关信息等。
安全保密设计：说明数据库用户的不同类型和所具有的不同操作权限。
（3）组装测试计划 包括测试策略、方案、测试用例、预期结果、进度计划等。 二、详细设计
1.详细设计的任务
详细设计是系统设计的
　　第二个阶段。详细设计阶段的主要任务，是在概要设计说明书的基础 上，对概要设计中产生的功能模块进行过程描述，设计功能模块的内部细节， 包括算法和详细数据结构，为编写源代码提供必要的说明，并建立“模块开 发卷宗”及“详细设计说明书”。
概要设计解决了信息系统总体结构设计的问题，包括整个信息系统的结
构、模块划分、模块功能和模块间的联系等。详细设计则要解决如何实现各 个模块的内部功能，即模块设计。具体地说，模块设计就是要为每个模块设 计详细的算法、内部数据结构和程序逻辑结构。在概要设计阶段，有时也要 进入模块内部，但其目的不是为每一个模块设计算法和数据结构，而是考察 该模块的内聚类型，看它是否能被继续分解为更多的模块。
　　详细设计不是编码，它只是对实现细节作精确的描述。但是，从某种意 义上说，详细设计也是系统的实现，它与编码阶段用具体的语言实现的不同 之处在于，它是逻辑上的实现。详细设计工作完成之后，产生“详细设计说 明书”及“模块开发卷宗”，这样，编码阶段可将详细设计中对功能实现的 描述，直接翻译、转化为用某种程序设计语言书写的程序。
　　由于详细设计的结果直接影响代码的生成，所以详细设计的结果基本决 定了最终程序代码的质量。因此，详细设计阶段不仅要考虑功能的逻辑实现， 逻辑的正确性和性能是否达到要求，也要关注处理过程应简单易懂，易于理
　　
解和维护。尽量引导程序编写人员以良好的风格书写高质量的代码。 因此，详细设计所完成的工作是：
　　①详细地规定了各程序模块之间的接口，包括参数的形式和传送方式、 上下层的调用关系等。
②确定了模块内的算法及数据结构。
2.详细设计的实施步骤
　　（1）将概要设计产生的构成软件系统的各个功能模块逐步细化，形成若 干个程序模块（可编程模块）。
　　虽然一些模块对概要设计而言已无需进一步划分了，但详细设计是为编 码作准备，故就实现而言，从程序结构的清晰和设计算法考虑，常常还可根 据情况细化出若干个程序模块。
（2）采用某种详细设计表示方法对各个程序模块进行过程描述。 详细设计的表示方法应便于编码实现时向某种程序设计语言的直接对
应，经常使用的方法可分为图形描述方法、语言描述方法和表格描述方法三 类。
（3）确定各程序模块之间的详细接口信息。
（4）建立“模块开发卷宗” “模块开发卷宗”是详细设计产生的重要文档，本节稍后将对其内容作
粗略描述。
（5）拟定模块测试方案 模块测试又叫单元测试，它是每一个模块实现后所进行的最基本测试，
是对每一个模块功能的确认。模块测试是最先实施的测试。
（6）评审 对以上各步骤的结果进一步审查，确认其正确性和有效性。
3.详细设计的文档
详细设计结束后，应完成以下文档：
■详细设计说明书
■模块开发卷宗 下面详细说明两文件的内容。
（1）详细设计说明书
　　详细设计说明书又叫程序设计说明书。说明书的目的是用来说明一个软 件系统的各个层次中的每个程序（每个模块或子程序）的设计考虑。如果系 统比较简单，层次很少，可以不单独编写，把有关的内容并入概要设计说明 书中。详细设计说明书的内容包括引言、程序系统的组织结构以及各个程序 的设计说明几个部分。
①引言 引言论述详细设计说明书的编写目的、背景，需特别说明的定义和有关
的参考资料等内容。
②程序系统的组织结构 用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）
的名称、标识符和它们之间的层次结构关系。
③程序（标识符）设计说明 程序（标识符）设计说明对本程序系统内的各个程序（包括每个模块和
子程序）的有关设计内容作逐一说明，对每个程序的说明包括以下 13 项内

容。
　　程序描述：简要说明程序的主要内容，如：本程序的目的、意义，本程 序的特点（是否常驻内存，是否有子程序，是否可重入，有无覆盖要求，是 顺序还是并发处理等。）
功能：采用某种设计方法对各个子程序模块进行过程描述。 性能：是对程序系统运行效率的说明，包括空间要求、算法精度、灵活
性、时间特性等。 输入项：列举每个输入项的名称、标识、数据的类型和格式、数据值的
有效范围、输入的方式、数量和频度、输入媒体、输入数据来源和安全保密 等。
输出项：内容同输入项类似，但加上输出的图形和符号说明。 算法：详细描述具体的实现算法，包括计算公式和计算步骤等。 接口：说明本程序和上、下层模块的关系，参数赋值和调用方式，和它
直接相关的数据结构（数据库、数据文卷等）。 流程逻辑：用图表的形式说明程序的处理流程。 存贮分配：说明程序对存贮器的使用和分配情况。 注释设计：说明需在程序中安排的注释。如：加在模块首部的注释，加
在各分支点处注释，对各变量的功能、范围、缺省条件注释等，对使用逻辑
等所加的注释。 限制条件：说明本程序系统在运行时所受到的限制。
测试计划：对本程序进行单元测试的计划，包括：测试的技术要求、输
入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的 规定。
（2）模块开发卷宗
　　模块开发卷宗是在模块开发过程中逐步编写出来的，每完成一个模块或 一组密切相关的模块的复审时编写一份。应把所有的模块开发卷宗汇集在一 起，目的是记录和汇总低层次开发的进度和结果，以便于对整个模块开发工 作的管理和复审，并为将来的维护提供非常有用的技术信息。模块开发卷宗 是组织和保存开发过程中不断产生的文档的有效方法。
模块开发卷宗包括以下内容：
①标题封面；
②模块开发情况表：用二维表格说明开发进度；
③功能说明；
④设计说明；
⑤源代码清单；
⑥测试说明；
⑦复审的结论。
第二节 系统设计的原则 一、结构化设计和结构程序设计
1.结构化设计
　　结构化设计是概要设计中被广泛使用的一种方法。它最早由美国 IBM 公 司的 W.Stevens、G.Myers 和 L.Constantine 三人所提出的。结构化设计的思
　　
想可应用于任何软件系统的设计，而且可成为衔接需求分析阶段的主要方法
——结构化分析方法和详细设计阶段的结构化程序设计方法之间的工具，三 者可以配合使用，形成一套系统的软件开发方法。
　　结构化设计的基本思想是将系统设计成由相对独立、功能单一的模块群 组成的结构。它的基本内容有以下三个方面：
■研究模块分解的影响。
■提出评价模块结构质量的两个具体标准——耦合度和内聚度。
■从数据流图导出模块结构的规则。
2.结构化程序设计
　　结构化程序设计是 60 年代产生的一种程序设计理论和方法，它是目前使 用最为广泛且为实践所证明行之有效的程序设计方法。
　　结构化程序设计方法是针对传统的非结构化程序设计而言的。在计算机 技术的发展过程中，由于早期的计算机内存容量小，运行速度慢，为使程序 得以装入内存并有可接收的运行效率，程序设计人员不得不精打细算，力争 节约每一个存贮单元，抓住每一个可以提高运行速度的机会，结果形成强调 技巧，重视效率的程序设计习惯。同时，由于软件开发没有一定的规范，程 序设计又带有强烈的个人色彩，一些程序设计人员将设计看作是表现个人技 巧及个性，显示聪明才智的机会，程序设计风格因人而异，而所设计出的程 序往往是结构混乱、晦涩难懂。不仅其他人难以理解，就是设计者本人，经 过一段时间之后，都无法读懂。而随着计算机硬件技术的发展，内存和速度 已不再是制约程序设计的因素。同时，由于软件需求不断增加，要开发的软 件数量和规模越来越大，程序设计已不再是一种个体行为，而成为群体合作 的项目；程序设计也不再是一次性的编码，而需要反复地维护。大规模高效 率的软件生产要求有新的方法指导程序设计，结构化程序因此而产生了。
结构化程序设计的概念最早是由 E.Dijkstra 提出的。由于 GOTO 语句是
实现随意控制的极好工具，极易造成 BS（ABOWLOFSPAGHETTI）型的结构混乱 的程序，1965 年 Di－jkstra 主张从一切语言中取消 GOTO 语句。他认为，程 序的质量同程序中 GOTO 语句中数量成反比。但由于当时 GOTO 语句是 FORTRAN 语言实现程序控制的重要语句，而 FORTRAN 是当时最为盛行的程序设计语 言。因而 Dijkstra 的主张并未引起人们的注意。1964 年 Boehm 和 Jacopini 证明，只用“顺序”、“选择”和“循环”就可实现所有单入口、单出口的 程序。图 3—2—1 为这三种结构的控制流程。由于循环控制可用顺序和选择 结构来实现，因而本质上只有两种基本结构。1966 年 Boehm 和 Jacopini 以 “流图、图灵机和仅含两个格式规则的语言”为题，在极有影响的杂志 Communi－cationofACM 上发表了他们的研究成果，并在文中断言，用任何高 级语言编写的程序都可以分解为上述三种基本控制结构及它们的组合。他们 的证明使人们开始重视 Dijkstra 的观点，并为结构化程序设计奠定了理论基 础。


　　60 年代中，Dijkstra 进一步提出程序设计的层次化和抽象的观点，并多 次建议从一切高级语言中取消 GOTO 语句，他的这种对 GOTO 语句根本性的否 定态度引起激烈的争论。经过争论，人们意识到，不是简单地取消一个语句 的问题，而是要确立一种新的程序设计方法和思想，以显著地提高软件生产 率和降低维护代价。经过长期的努力，结构化程序设计的思想和方法逐步建 立和完善起来。
随着软件开发工程化观念的提出和建立，结构化程序设计（SP）又向软
件设计阶段扩展，形成结构化设计（SD），结构化设计又向软件分析阶段扩 展，形成了结构化分析（SA），从而形成了系统的结构化方法。
结构化程序设计的基本原则是：
①采用自顶向下，逐步求精的设计方法；
②用顺序、选择和循环三种基本控制结构实现单入口和单出口的程序。 一个不含 GOTO 语句，并仅由以上三种控制结构形成的具有单入口和单出
口的结构化程序有以下两方面的优点：
■程序的动态结构和静态结构一致，易于理解和维护。
　　■有利于程序正确性的证明。只有三种结构的程序可用严格的方法证明 其正确性。
二、系统设计的原则
　　在长期的软件开发实践中，为了提高软件的开发质量，人们总结出了一 些软件开发的基本原则，结构化设计最为直接地体现了这些原则的应用。下 边具体说明这些原则的基本内容。
1.模块化
　　人们在解决问题，尤其是大规模的复杂问题时，常常使用“分解”的方 法，将问题划分若干个较小的问题，通过对各个较小问题的求解，达到对复 杂问题的解决。模块化就是体现人类在问题求解时的这一方法和思想。为了 使一个复杂的大型程序系统能被人的智力所管理，模块化是复杂软件系统必 须具备的属性。因为，如果不把一个大型的、复杂的系统分解成若干模块， 将很难对其开发和管理。
　　所谓模块化（Modularity），就是依据一定的原则，将欲开发的软件系 统分解为若干部分，即模块。如果对
　　第一次划分出的模块直接求解复杂度仍较高，则可继续分解，直到划分 为易于直接解的规模为止。模块的概念我们在本章
　　
　　第一节中曾提到。所谓模块，就是实现某种功能独立、逻辑完整的程序 段落，模块也是数据说明，是可执行语句等程序对象的集合。模块被单独命 名，并能通过名字被访问。模块化降低问题的复杂程度可从下边说明中得到 论证。
　　设函数 C（x）表示问题的复杂程度，函数 E（x）表示求解问题所需的工 作量，若有两个问题 P1 和 P2，如果
C（P1）＞C（P2）则显然有 E（P1）＞E（P2）
　　同时，我们还有另外一条规律，若一个问题 P 可被分解为两个子问题 P1 和 P2，即：
　　　　P=P1＋P2 则
　　　　C（P）＞C（P1）＋C（P2） 因而
E（P）＞E（P1）＋E（P2）
　　以上规律充分说明，模块化降低了问题的复杂程度，减少了求解问题的 工作量。
但是，我们并不可由此得出结论，在软件开发时，模块划分得越多越好，
问题分解得越细越好，当模块被划分成最基本的操作，问题就自然而然得到 解决了。事实上，模块化要掌握适当的程度。因为，模块划分降低了问题的 复杂程度，但也增加了模块间相互协调工作，即配合完成任务的接口复杂度。 若将接口因素考虑进去，则上述规律可做如下修正：
仍设 P=P1＋P2
设 I（i，j）为模块 Pi 对模块 Pj 的接口复杂度因子； I（i，j）×Pi 为模块 Pi 对模块 Pj 的接口工作量；
则有
C（P）→C（P1＋I（1，2）×P1）＋C（P2＋I（2，1）×P2） E（P）→E（P1＋I（1，2）×P1）＋E（P2＋I（2，1）×P2）
显然，不同的模块划分有不同的接口因子。只有当模块划分合理，数量
规模适当，接口因子较小时，才有下式成立： C（P）＞C（P1＋I（1，2）×P1）＋C（P2＋I（2，1）×P2） E（P）＞E（P1＋I（1，2）×P1）＋E（P2＋I（2，1）×P2）
因此，在模块划分时，存在着一个最佳模块数，最佳的模块划分应符合
模块独立性原则。
图 3-2-2 表示了最佳模块划分的范围。 结构化设计就是根据这一规律，提出把系统设计成由若干模块所组成的
结构。每个模块都相对独立、功能单一。这样，各个模块可以独立地被理解、 编写、测试、排错和修改。整个系统结构清晰，易于实现、理解和维护。结 构化设计能提高软件系统的质量和可靠性，也有助于整个工程的开发和管 理。


2.抽象
　　抽象（Abstraction）是人类认识问题和解决问题的基本工具和方法。在 解决复杂的具体问题时，人们往往先忽略其细节和非本质的方面，而集中注 意力去分析问题的本质和主要方面，搞清所要解决的问题的本质所在；同时 人们在总结认识和实验规律时，也往往突出各类问题的共性，找出各种客观 事物、状态和过程间的联系和相似性，加以概括和提取，即抽象。抽象是具 有有限思维能力的人类个体同复杂外部世界相互了解的有力工具。
抽象在软件开发过程中也具有重要的地位。复杂软件系统的构造就是一
个运用抽象的过程。通过对所要解决问题的抽象，进行需求分析；然后借助 较低层次上的抽象，采用更加过程化、形式化的方法，进行系统设计；最后， 在最低的抽象层次上，用可以直接实现的方法，叙述问题的解法。
因此，在本质上，抽象的过程是一个逐步求精的过程。Wirth 曾对抽象
作过如下解释：抽象是我们对付复杂问题最重要的办法，所以，对一个复杂 的问题，不应马上用计算机指令、数字与逻辑字来表示，而应该用较为自然 的抽象语句来表示，从而得出抽象程序。抽象程序对抽象的数据进行某些特 定的运算并用某些合适的记号（可能是自然语言）来表示。对抽象程序作进 一步的分解，并进入下一层的抽象，这样的精细化过程一直进行下去，直到 程序能被计算机接受为止。
3.信息隐藏和信息局部化
　　信息隐藏 （ InformationHiding ）和信息局部化 （ Inforam － tionLocalization）是软件设计中另外两项重要原则。所谓信息隐藏，是指 在设计和确定模块时，应使一个模块内包含的信息（过程和数据）对于不需 要这些信息的模块来说是不可访问的。
　　信息隐藏使得模块间尽可能彼此独立，有利于过程和数据的保护，避免 了错误的传递，提高了系统的可靠性。信息隐藏尤其为软件系统的维护提供 了良好的基础。
　　信息局部化是指将一些关系密切的成份，设计时放得彼此靠近。局部化 有利于模块的单独开发和调试，因而简化了整个系统的设计和实现。同时， 局部化也是信息隐藏的手段。
4.一致性、完整性和确定性
　　一致性、完整性和确定性是针对软件大规模长时间的生产，对生产过程 的规范、统一提出的要求。
所谓一致性（Uniformity），是指软件系统各部分中符号的表达使用、

对象及过程的描述和调用形式、操作的控制结构都一致，以免造成混乱。 完整性（Completeness）是说对一对象、过程的表达描述及处理应该完
备，没有遗漏重要的内容或成份。 确定性（Comfirmability），又称可验证性，是指系统中的对象、过程
定义明确，无二义性，容易测试。
　　　　　　　第三节 系统设计中的图形方法 一、图形工具——模块结构图
　　模块结构图（ModuleStructureChart）是结构化设计的主要工具，它被 广泛地使用在概要设计之中。模块结构图是由美国的 Yourdon 于 1974 年首先 提出，并用来描述软件系统的组成结构及相互关系。它即反映了整个系统的 结构，即模块划分，也反映了模块间的联系。
1.符号规定
（1）模块 用一个方框来表示软件系统中的一个模块，框中写模块名。名字要恰当
地反映模块的功能，而功能在某种程度上反映了块内各成份间的联系。如图
3-3-1 所示。

（2）调用 用一个带箭头的线段表示模块间的调用关系。它联结调用和被调用模
块，箭头指向被调模块，箭头发出模块为调用模块。如图 3—3—2 所示。根
据调用关系，模块可相对地分为上层模块和下层模块。具有直接调用关系的 模块之间相互称为直接上层模块和直接下层模块。如图 3—3—2 所示的模块
A 和模块 B，及模块 B 和模块 C。

图 3-3-2 模块间的调用 调用是模块间唯一的联系方式。通过调用，各个模块有机地组织在一起，
协调完成系统功能。一般只允许上层模块调用下层模块，而不允许下层模块 调上层模块。
（3）数据 用小箭头表示模块间在调及过程中相互传递的数据信息。数据信息传递
画在调用箭头旁边，小箭头指出传送方向。如图 3—3—3a 和 3—3—3b 所示。 模块间传递的数据信息还可进一步分为两类：作数据用的信息和作控制 用的信息。若需要进一步区分，可在小箭头的尾部使用不同的标记表示，具
体可分为以下三种箭头： 尾部无标记，表示不区分两类信息。

尾部有小空心圆圈标记，表示作数据用的信息。 尾部有小实心圆圈标记，表示作控制用的信息。
（4）调用编号和参数表

　　当模块间输入输出数据较多，用数据小箭头表示无法将数据名称写清楚 时，可采用此种方法。模块调用较多时通过参数表，数据传递也表示得更加 清晰。
用参数表表示时，给每个调用箭头一个顺序编号，然后按编号列出输入
输出参数表。如图 3—3—4a 所示。

　　输入输出表和完整的结构图功能是相同的，如图 3-3-4a 和 3-3-4b 所示。 采用哪种形式要根据具体情况。
（5）辅助符号
为表示模块间复杂的调用关系，模块结构图使用了两种辅助符号表示不 同的调用，它们是：












　　选择调用（或称条件调用）：在调用箭头的发出端用一个小菱形框表示。 选择调用为上层模块根据条件调用它的多个下层模块中的某一个。如图 3-
3-5a 和图 3-3-5b 所示。


　　循环调用：在调用箭头的发出端用一带箭头的圆弧表示。循环调用为上 层模块反复调用它的一个或若干个模块。如图 3—3—6 所示。
2.对模块结构图的说明
①模块结构图和程序流程图外型相似，但两者意义完全不同。一个程序 系统有两方面的性质，一是过程性，一是层次性。过程性说明程序执行的先 后次序，流程图是描述过程性的，其箭头表示的是执行顺序，而不说明程序 系统的层次关系；层次性则说明模块之间的层次结构，模块结构图就是说明 层次性的，其箭头是表示调用关系（层次关系）而不表示执行的先后次序。









　　②模块结构图的最后形态是多种多样的，有树形的，也有清真寺形的（上 下部分窄，中间部分宽）。不同的形态对应不同的结构划分。
③模块结构图并不严格地表明调用次序。虽然多数人习惯按调用次序由
左向右画，但模块结构图无此规定。
　　④模块结构图也不指明什么时候调用下层模块。通常模块中除了调用语 句之外，还有其它语句，但模块内究竟还有其它什么内容，执行顺序如何， 模块结构图没有说明。
二、其它图形工具
　　在系统的概要设计和详细设计中，还有一些其它的图形工具，如 HIPO 图、PAD 图，盒图等，被广泛使用。下边逐一作介绍。
1.HIPO 图
　　HIPO 图是一个同模块结构图等价的结构化设计图形工具，它也被广泛地 使用在概要设计阶段。
　　HIPO 图（HierachyInputProcessOutput），即层次化的输入—处理—输 出图。它是美国 IBM 公司于 70 年代中期采用的。HIPO 图实际上是层次图和 IPO 图的结合。有人把 H 部分叫目录表。两者结合后在功能上相当于模块结 构图。
为说明 HIPO 图，我们先简要介绍 IPO 图和层次图。
（1）IPO 图
　　IPO 图是输入—输出—处理图的简称。它也是美国 IBM 公司发展并完善 起来的一种图形工具。它具有简单、易用、描述清晰的特点，用来表示一个
　　
加工比较直观，对设计很有帮助。
一个完整的 IPO 图由三个大方框组成。左边的方框内写有关的输入数 据，称输入框；中间的方框列出对输入数据的处理，称处理框；右边的方框 写处理所产生的输出数据，称输出框。处理框中从上至下的顺序表明系统操 作的次序。输入数据同处理的关系，处理同输出数据的关系，用联接有关部 分的箭头来表示。如图 3-3-7 所示。









（2）层次图
层次图也叫 H 图，它是一个表示信息系统结构的有效工具。同模块结构 图类似，但比较简单。层次图一个方框表示一个模块，方框内写模块名称。 用方框间的连线表示模块间的层次关系。层次图非常自然地表达了自顶向下 的分析思想。图 3—3—8 为一个层次图的实例。
















　　层次图除以上部分外，为清晰和方便，还可以使用编号和表格，用表格 说明编号的具体名称或内容。
需特别注意的是，虽然层次图和模块结构图外型相似，但两者所表示的
内容完全不同。层次图说明模块之间的层次关系，但这种层次关系是包含关 系而非调用关系，层次图也无法表达调用过程中的数据交换。
以上简要介绍了 IPO 图和层次图。这两个图形工具不仅可以作为概要设
计的工具，也可以作为需求分析的工具，关键在于它们所表达的数据、处理 和功能的详略层次。
（3）HIPO 图
　　HIPO 图是在 IPO 图和层次图基础上发展起来的，它是两图的有机结合。 HIPO 图首先用一个层次图描述软件系统的结构，对于层次图中的每一个模 块，都附加一个 IPO 图，用以说明具体的输入输出数据和处理过程。即在 HIPO 图中，每一个层次图都对应一套 IPO 图。为使对应关系明确，除最顶层图外， 对层次图中每个模块都给一个编号，同该模块对应的 IPO 图也给一个相同的 编号，编号规则同数据流图。如图 3-3-9a 和 3-3-9b 所示。
　　



2.程序流程图、PAD 和盒图
　　与上边所介绍的概要设计时使用的图形工具不同，程序流程图、PAD 图 和盒图是详细设计时所使用的工具。这些工具均能精确描述程序的处理过 程，无歧义地表达处理功能和控制流程，乃至数据的作用范围，并能在编码 阶段直接将其翻译成为用某种具体的程序设计语言书写的程序代码。
在详细设计阶段，用于设计分析和结果描述的方法有三类，即图形描述
方法、语言描述方法和表格描述方法。这里只介绍图形描述方法。
（1）程序流程图 程序流程图（FlowChart）又叫框图，是一种传统的过程描述方法。其特
点是直观、灵活、方便。它所使用的基本符号有：
方框：表示一个处理，处理内容写于框内。 菱形框：表示一个判断，判断条件写于框内。 椭圆框：表示开始或结束。 箭头：表示程序流程。
图 3-3-10 为一个流程图的例子。
　　由于程序流程图有十分灵活的特点，其箭头使用有很强的随意性，使设 计人员的思想不受任何约束，因而使用不当会导致产生非结构化程序和十分 混乱结果。这是它的一个致命缺点。同时，程序流程图不能表示数据结构； 它诱导设计人员过早地考虑程序实现的细节，而非系统的总体结构。因而， 它不是结构化设计工具，不能体现自顶向下的设计思想。所以长期以来，很 多人一直建议停止使用它。
（2）PAD 图


　　PAD 图又称问题分析图（ProblemAnalysisDiagram）。它是 70 年代日本 的日立公司发明使用的，是一种具有很强结构化特征的分析工具。目前已被 广泛地使用在详细设计中。PAD 图是由其基本符号沿两个方向展开，图 3—3
—11 显示了它所使用的基本符号。

PAD 图具有很强的结构化描述特征。它的基本图形符号只能构成三种控 制流程，即顺序、选择和循环结构。如图 3—3—12 所示。






















PAD 图具有以下特点：
　　①具有强烈的结构化特征，支持自顶向下、逐步求精的设计方法，设计 出的结构必然是结构化的；
②逻辑清晰，易懂、易用；

③即要设计程序结构，又可表示数据结构；
④容易将图直接转换为高级语言程序。
（3）盒图
盒图（BoxDiagram）又称 N—S 图，它是为满足结构化程序设计的需要， 克服传统设计工具的缺点，特别是为取消程序流程图的随意转向功能，于 70 年代由 Nassi 和 Shneider－man 提出使用的，故称 N-S 图。盒图的符号规定 和使用如图 3-3-13 所示。




















盒图具有以下特点：
①过程的作用域明确；
②不能随意转移控制；
③容易区分全局变量和局部变量；
④容易表示嵌套关系和层次关系；
⑤强烈的结构化特征。
第四节 内聚度和耦合度 一、联系
　　当个程序段或语句（指令）引用了其它程序段或语句（指令）中所定义 或使用的数据名（即存贮区、地址等）或代码时，他们之间就发生了联系。 一个程序被划分为若干模块时，联系既可存在于模块之间，也可存在于一个 模块内的程序段或语句之间，即模块内部。联系反映了系统中程序段或语句 之间的关系，不同类型的联系构成不同质量的系统。因此，联系是系统设计 必须考虑的重要问题。
　　系统被分成若干模块后，模块同模块的联系称为块间联系；一个模块内 部各成份的联系称为块内联系。显然，模块之间的联系多，则模块的相对独 立性就差，系统结构就混乱；相反，模块间的联系少，各个模块相对独立性 就强，系统结构就比较理想。同时，一个模块内部各成份联系越紧密，该模 块越易理解和维护。
二、评判模块结构的标准
1.模块独立性
模块化是软件设计和开发的基本原则和方法，是概要设计最主要的工

作。模块的划分应遵循一定的要求，以保证模块划分合理，并进一步保证以 此为依据开发出的软件系统可靠性强，易于理解和维护。根据软件设计的模 块化、抽象、信息隐蔽和局部化等原则，可直接得出模块化独立性的概念。 所谓模块独立性，即：不同模块相互之间联系尽可能少，应尽可能减少公共 的变量和数据结构；一个模块应尽可能在逻辑上独立，有完整单一的功能。 模块独立性（Moduleindependence）是软件设计的重要原则。具有良好 独立性的模块划分，模块功能完整独立，数据接口简单，程序易于实现，易 于理解和维护。独立性限制了错误的作用范围，使错误易于排除，因而可使
软件开发速度快，质量高。 为了进一步测量和分析模块独立性，软件工程学引入了两个概念，从两
个方面来定性地度量模块独立性的程度，这两个概念是模块的内聚度和模块 的耦合度。
2.块间联系的度量—耦合度
　　耦合度是从模块外部考察模块的独立性程度。它用来衡量多个模块间的 相互联系。一般来说，耦合度应从以下三方面来考虑，即：
　　耦合内容的数量，即模块间发生联系的数据和代码的多少，同这些数据 和代码发生联系的模块的多少，多的耦合强，少的耦合弱；
模块的调用方式，即模块间代码的共享方式。可分为用 CALL 语句调用方
式和用 GOTO 语句直接访问方式； 模块间的耦合类型。耦合类型有以下几种方式：
①独立耦合
②数据耦合
③控制耦合
④公共耦合
⑤内容耦合 下面重点对各种类型的耦合作进一步的说明。
（1）独立耦合
　　指两个模块彼此完全独立，没有直接联系。它们之间的唯一联系仅仅在 于它们同属于一个软件系统或同有一个上层模块。这是耦合程度最低的一 种。当然，系统中只可能有一部分模块属此种联系，因为一个程序系统中不 可能所有的模块都完全没有联系。
（2）数据耦合
　　指两个模块彼此交换数据。如一个模块的输出数据是另一个模块的输入 数据，或一个模块带参数调用另一个模块，下层模块又返回参数。应该说， 在一个软件系统中，此种耦合是不可避免的，且有其积极意义。因为任何功 能的实现都离不开数据的产生、表示和传递。数据耦合的联系程度也较低。
（3）控制耦合 若在调用过程中，两个模块间传递的不是数据参数而是控制参数，则模
块间的关系即为控制耦合。控制耦合属于中等程度的耦合，较之数据耦合模 块间的联系更为紧密。但控制耦合不是一种必须存在的耦合。
　　当被调用模块接收到控制信息作为输入参数时，说明该模块内部存在多 个并列的逻辑路径，即有多个功能。控制变量用以从多个功能中选择所要执 行的部分，因而控制耦合是完全可以避免的。排除控制耦合可按如下步骤进 行：
　　
①找出模块调用时所用的一个或多个控制变量；
②在被调模块中根据控制变量找出所有的流程；
③将每一个流程分解为一个独立的模块；
④将原被调模块中的流程选择部分移到上层模块，变为调用判断。 通过以上变换，可以将控制耦合变为数据耦合。由于控制耦合增加了设
计和理解的复杂程度，因此在模块设计时要尽量避免使用。当然，如果模块 内每一个控制流程规模相对较小，彼此共性较多，使用控制耦合还是合算的。
（4）公共耦合 公共耦合又称公共环境耦合或数据区耦合。若多个模块对同一个数据区
进行存取操作，它们之间的关系称为公共耦合。公共数据区可以是全程变量、 共享的数据区、内存的公共复盖区、外存上的文件、物理设备等。当两个模 块共享的数据很多，通过参数传递可能不方便时，可以使用公共耦合。公共 耦合共享数据区的模块越多，数据区的规模越大，则耦合程度越强。公共耦 合最弱的一种形式是：两个模块共享一个数据变量，一个模块只向里写数据， 另一个模块只从里读数据。
　　当公共耦合程度很强时，会造成关系错综复杂，难以控制，错误传递机 会增加，系统可靠性降低，可理解、维护性差。
（5）内容耦合
　　内容耦合是耦合程序最高的一种形式。若一个模块直接访问另一模块的 内部代码或数据，即出现内容耦合。内容耦合的存在严重破坏了模块的独立 性和系统的结构化，代码互相纠缠，运行错综复杂，程序的静态结构和动态 结构很不一致，其恶劣结果往往不可预测。
内容耦合往往表现为以下几种形式：
①一个模块访问另一模块的内部代码或数据；
　　②一个模块不通过正常入口而转到另一个模块的内部（如使用 GOTO 语句 或 JMP 指令直接进入另一模块内部）；
③两个模块有一部分代码重迭（可能出现在汇编程序中，在一些非结构
化的高级语言，如 COBOL 中也可能出现）；
④一个模块有多个入口（这意味着一个模块有多种功能）。 一般讲，在模块划分时，应当尽量使用数据耦合。少用控制耦合（尽量
转成数据耦合），限制公共耦合的范围，完全不用内容耦合。
3.块内联系的度量——内聚度
　　内聚度（Cohesion）是模块内部各成份（语句或语句段）之间的联系。 显然，模块内部各成份联系越紧，即其内聚度越大，模块独立性就越强，系 统越易理解和维护。具有良好内聚度的模块应能较好地满足信息局部化的原 则，功能完整单一。同时，模块的高内聚度必然导致模块的低耦合度。理想 的情况是：一个模块只使用局部数据变量，完成一个功能。
按由弱到强的顺序，模块的内聚度可分为以下 7 类，现分述于下。
（1）偶然内聚 块内的各个任务（通过语句或指令来实现的）没有什么有意义的联系，
它们之所以能构成一个模块完全是偶然的原因。如下图 3-4-1 所示。
　　在模块 T 有三条语句。至少从表面上看不出这三条语句之间有什么联 系，只是由于 P，Q，R，S 四个模块中都有这三条语句，为了节省空间才把它 们作为一个模块放在一起。这完全是偶然性的。偶然内聚的模块有很多缺点：
　　
由于模块内

　　没有实质性的联系，很可能在某种情况下一个调用模块需要对它修改而 别的模块不需要。这时就很难处理。同时，这种模块的含义也不易理解，甚 至难以为它取一个合适的名字，偶然内聚的模块也难于测试。所以，在空间 允许的情况下，不应使用这种模块。
（2）逻辑内聚 一个模块完成的任务在逻辑上属于相同或相似的一类（例如，用一个模
块产生各种类型的输出），则该种模块内的联系称为逻辑内聚。如图 3-4-2a
和 3-2-2b 所示。

在图 3-4-2a 中，模块 A，B，C 的功能相似但不相同，如果把它们合并成 一个模块 ABC，如图 3-4-2b 所示，则这个模块就为逻辑内聚，因为它们是由 于逻辑上相似而发生联系的。逻辑内聚是一种较弱的联系。实际执行时，当 X，Y，Z 调用合成的模块 ABC 时，由于原 A，B，C 并不完全相同，所以还要 判别是执行不同功能的哪一部分。










逻辑内聚存在的问题是：
①修改困难，调用模块中有一个要对其改动，还要考虑到其它调用模块；
②模块内需要增加开关，以判别是谁调用，因而增加了块间联系；
　　③实际上每次调用只执行模块中的一部分，而其它部分也一同被装入内 存，因而效率不高。
（3）时间内聚 时间内聚是指一个模块中包含的任务需要在同一时间内执行（如初始
化，结束等所需操作）。如图 3—4—3 所示的模块。与偶然内聚和逻辑内聚 相比，这种内聚类型要稍强些，因为至少在时间上，这些任务可以一起完成。 但时间内聚和偶然内聚、逻辑内聚一样，都属低内聚度类型。
（4）过程内聚

如果一个模块内的各个处理元素是相关的，而且必须按固定的次序执 行，这种内聚就叫做过程内聚。过程内聚的各模块内往往体现为有次序的流 程。如图 3-4-4 所示的处理模块。









（5）通信内聚 若一个模块中的各处理元素需引用共同的数据（同一数据项、数据区或
文件），则称其元素间的联系为通信内聚。通信内聚的各部分间是借助共同 使用的数据联系在一起的，故有较好的可理解性。如图 3—4—5 所示。通信 内聚和过程内聚都属中内聚度型模块。
（6）顺序内聚 若一个模块内的各处理元素关系密切，必须按规定的处理次序顺序执
行，这样的模块为顺序内聚类型。顺序内聚的模块内，后执行的语句或语句 段往往依赖先执行的语句或语句段，以先执行的部分为条件。由于模块内各 处理元素间存在着这种逻辑联系，所以顺序内聚模块的可理解性很强，属高 内聚度类型模块。如图 3-4-6 所示的例子。










（7）功能内聚 功能内聚是内聚度最高的一种模块类型。如果模块仅完成一个单一的功
能，且该模块的所有部分是实现这一功能所必须的，没有多余的语句，则该
模块为功能内聚。功能内聚模块的结构紧凑、界面清晰，易于理解和维护， 因而可靠性强；又由于其功能单一，故复用率高。所以它是模块划分时应注 意追求的一种模块类型。如图 3—4—7 是模块划分时得到的功能内聚模块。 在模块设计时应力争做到高内聚，并且能够辨别出低内聚的模块，加以
修改使之提高内聚度并降低模块间的耦合度。具体设计时，应注意：
①设计功能独立单一的模块；
②控制使用全局数据；
③模块间尽量传递数据型信息。
第五节 系统设计的方法 一、面向数据流的设计方法
　　数据流图（DFD）是结构化分析的主要方法。作为需求分析的结果，数据 流图描述了系统的逻辑结构，而功能模块图是概要设计中重要的设计和表示 方法。由于任何可以用计算机处理的流程都可用数据流图来分析和描述，所
　　
以确立一种方法、原则和步骤，将数据流图映射为功能模块图就显得十分重 要。
　　面向数据流的设计方法就是以数据流图为基础，通过一系列系统的步 骤，将数据流图转换为功能模块图，从而导出软件的结构的方法。面向数据 流的设计方法是需求分析阶段结构化分析方法的延续，是结构化设计的主要 方法。
1.数据流的两种类型——事务流和变换流
（1）变换流 任何以数据流图表示的软件系统，从总体上看，都包括三个功能部分，
即接收数据、加工处理和输出数据。加工处理部分利用外部的输入数据，完 成本身的逻辑功能，并产生新的数据作为输出。抽象地看，加工处理部分可 以被看作是一个将输入数据变换为输出数据的变换机构，我们把有以上过程 的数据流称为变换流。变换流的一般形式可用图 3-5-1 来表示。
在图 3-5-1 所示的变换流中，引入了几个新的概念。它们是：

1）输入流 输入流由一个或多个数据加工组成。其作用是将最初接收到的系统外部
输入的数据，由其外部形式变成内部形式，即将系统得到的物理输入变为系
统可用的形式。一般来说，输入流的处理工作是对数据格式进行转换，即对 数据进行分类、排序、编辑、整理、有较性检验等。
2）变换流
　　此处的变换流是指将输入流转换为输出流的数据变换过程和机制。变换 流接收的数据是系统可处理的，处理后以系统的内部形式送给输出流。
3）输出流
　　输出流将变换流发来的内部形式的数据经过加工处理变为外部系统可接 收的形式并输出。
请看图 3-5-2 所表示的身份证号查询的数据流过程。 其中，虚线内部分为变换流，虚线外的两部分为输入流和输出流。











（2）事务流

　　一般来说，所有数据流均可看作是变换流。但是，有一类数据流本身有 较明显的特点，可以将它区分出来作单独处理。若在一个数据流中，存在一 个加工只接收一个输入数据，然后根据这个输入数据从若干个处理序列中选 择一个路径执行，则具有这种类型的数据流叫做事务流（TransationFlow）。 如图 3-5-3 所示。
　　在这里，称输入数据为事务，称根据事务作出判断，并选择多个处理路 径中的一条来执行的加工为事务中心，事务中心的作用是：
1）接收输入数据（事务）；
2）根据事务作出判断，并选择处理路径；
3）沿处理路径执行。
2.由变换型数据流图导出模块结构图（变换分析）
　　对于变换型数据流图，可以根据一定的规则将它直接映射为功能模块 图。规则具体步骤为：
（1）确定变换流、输入流和输出流部分 一般说，只要对系统流程比较熟悉，找出变换流和输入流、输出流的边
界不是很难的。几个数据流汇集的地方，常常是加工的开始。如果一时找不 出，可以用下述方法先区分出输入流部分和输出流部分，这样，变换流也就 自然明确了。















　　从最外层的流入（物理的）出发，逐步向里，直到一个加工的流入数据 流不能看作输入，则它以前的数据流就是输入流。
同样，从最外层的流出（物理的）逐步向里，直到一个加工的流出数据
流不能看作输出，则它以后的数据流就是输出流。输入流和输出流之间，就 是变换流。
　　也有这样的情况，即输入流和输出流是连在一起的，物理输入的结束就 是物理输出的开始，则这样的系统就没有变换流。
（2）设计模块结构的顶层和
第一层 变换流部分即系统结构的顶层所在，同时它也对应一个
　　第一层模块。而输入流的每一输入数据、变换流给输出流的每一输出数 据都分别对应一个
第一层模块。 顶层模块表示整个系统要完成的功能，常常称其为总控模块。对于没有
变换流的结构，可以没有变换模块，也可以把输出中重要的加工提升为变换 模块，这要根据具体情况而定。在映射过程中要注意，模块之间的数据交换

应当和数据流图中的数据流一致。
（3）设计中下各层 一般说，输入流中的每个加工可以对应成两个模块，即接受输入数据模
块和将输入数据变换成其调用模块所需数据模块，然后再如此逐层细分。每 个输出部分也可以按输入部分作相似的处理。这两部分的转换可以自上而下 递归对应，直到物理输入的数据源和物理输出的数据池为止。
　　对于变换流中的每一个加工，可依次对一个模块，流入加工的数据映射 为模块的输入参数，流出加工的数据流映射为输出参数。具体请看图 3-5-4 所示的过程。
　　这样得出的模块结构图是和数据流图严格对应的初始结构，一般不是最 优的。需要对初始模块结构图进一步修改，才能得到较理想的结果。
3.由事务型数据流图导出模块结构图（事务分析）
　　对于事务型数据流图，通过事务分析，可以导出它所对应的标准形式的 模块结构图。事务分析也是采用“自顶向下，逐步求精”的分析方法。具体 步骤为：
①根据事务功能设计一个顶层总控模块；
②将事务中心的输入数据流对应为一个
第一层的接收模块及该模块的下层模块，具体可用变换分析方法；
③将事务中心对应为一个
第一层的调度模块；

　　④对每一种类型的事务处理，在调度模块下设计一个事务处理模块；然 后为每个事务处理模块设计下面的操作模块及操作模块的细节模块，每一处 理的对应设计可用变换分析方法。具体见图 3-5-5 所示对应关系。
　　




第四章 系统实现与测试
第一节 系统实现 一、系统实现任务和步骤
1.系统实现的任务
　　系统分析和系统设计工作完成之后，信息系统的功能、模块结构、数据 组成和数据结构已基本确定，接下来的工作就是系统实现。系统实现阶段的 任务是将详细设计的结果转化为用具体的程序设计语言所书写的程序，即编 写程序代码。同时，系统实现还要对所编写的源程序进行程序单元测试，并 验证各程序模块单元间的接口。
因此，系统实现阶段有以下三方面的工作：
①以模块为程序单元编写代码；
②测试每一个程序单元；
③测试各个程序单元间的功能与数据是否协调一致。 如果经过单元测试发现所编写的程序存在错误，则需要修改源程序，然
后再测试，直到没有错误为止。
2.系统实现的步骤
系统实现有以下 6 个步骤，它们是：
①对每个程序模块用所选定的程序设计语言进行编码；
②按照测试方案产生测试数据；
③按照测试方案中规定的方法进行程序单元测试；
④书写“模块开发卷宗”中相应于该阶段的内容；
⑤编写操作手册和用户手册；
⑥评审。
二、系统实现应注意的问题
　　由于信息系统开发中的困难主要集中在系统分析和系统设计阶段的工 作，因而分析和设计工作是整个开发工作的基础。编码是将详细设计中得出 的算法转换成用程序设计语言编写出来的程序，相对而言，它较前几个阶段 的工作要简单。但是，编码工作也是相当重要的。由于系统的质量最终是通 过程序来体现的，如果编码工作未能实现系统分析和系统设计的要求，则整
　　
个系统开发工作就无法完成。同时，编码也有自身的规律和技巧。以下是编 码时应注意的一些问题。
1.编码质量要求
　　大规模复杂信息系统的编码工作要求众多程序员之间的密切合作，因 此，编码不仅要考虑程序的正确性，更要考虑程序的可理解性、可测试性和 可维护性，因而，编码应注意以下几方面的要求：
①可靠性 可靠性的含义是：在正常情况下，系统能够正确工作；而在意外情况下，
系统能做出适当处理，不会造成严重损坏。所谓意外情况，一般指硬件故障、 输入输出错误等。
②可读性 可读性即程序的可理解性。逻辑结构清晰、变量命名合理、书写编排规
范的程序可读性强，反之，可读性差。
③可测试性 可测试性是指所编程序易于用现有方法验证及发现其中的错误。
④可维护性 可维护性是指易于对所编的程序进行修改和扩充。
要使编码质量达到这些要求，需要注意解决几个问题，其中最主要的是
程序的结构性和编写程序的风格。
2.程序的风格
　　程序的风格即所书写的程序特征。编程人员往往具有各自不同的风格。 具有良好风格的程序易于理解、测试和维护。以下是一些与程序风格有关的 设计规则。
·不要为了“效率”而丧失清晰性
·重复使用的表达式，要用调用公共函数去代替
·使用括号以避免二义性
·选用不会混淆的变量名
·使用有意义的变量名和语句标号
·用缩排格式限定语句群的边界
·和谐的格式有助于读者理解程序
·缩排书写要显示程序的逻辑结构
·让程序按自顶向下方式阅读
·避免不必要的转移
·采用三种基本控制结构
·首先使用易理解的伪编码语言编写，然后再翻译成你所使用的语言
·把与判定相联系的动作尽可能近地紧跟着判定
·对递归定义的数据结构使用递归过程
·测试输入的合法性和合理性
·结束输入要用文件结束标记，而不要用计数
·采用统一的输入格式
·把输入和输出局限在子程序中
·确信在使用之前，所有的变量都已被赋初值
·在出现故障时不要停机
·注意因错误引起的中断

·避免从循环引出多个出口
·将数据编制成文件
·选用能使程序更简单的数据表示法
·确信注释与代码一致
第二节 系统测试 一、系统测试的基本概念
1.测试的目的
　　测试是寻找程序中错误的过程。对于系统测试，很多人往往存在着误解， 认为测试的目的是证明程序的正确性。事实上，企图通过测试断定程序的正 确性几乎是不可能的。对测试目的之理解直接影响测试的过程。对于想通过 测试证明程序正确的开发人员来说，常会不自觉地使用那些能证明程序正确 的测试数据，结果隐蔽了程序中的错误。正确的测试目的是尽可能多地发现 系统存在的问题，进而加以改进。
2.测试工具
　　由于测试工作量大，且存在很多简单、重复性的工作，所以应尽可能利 用计算机来完成其中机械性的工作。近年来已有一些测试工具问世。这些测 试工具可在测试中协助人的工作。
①静态分析工具
　　静态分析是在不执行被测程序的情况下对程序进行的测试。静态分析工 具和作用是扫描被测试程序的正文，检查可能导致错误的异常情况，如是否 使用了未赋值的变量、是否有从未使用过的变量、实在参数和形式参数类型 或个数是否不符、是否有程序从未执行等。
②文件比较程序
　　文件比较程序通过分析测试结果来测试程序。例如可将预期输出结果编 成一个文件，测试后的实际输出结果也编成一个文件，然后通过文件比较程 序比较两个结果文件，检索有无差异。由于很多测试输出的数据量都很大， 有的还很复杂，所以使用文件比较程序可大大减少测试人员的工作负担。
③覆盖监视工具
　　覆盖监视工具又叫做动态分析程序。动态分析是通过运行被测程序进行 测试的方法。监视工具被安插在程序的适当位置，以便对被测程序进行监视， 它们还可以产生带有统计数字的报告。监视工具还可用在编码过程中，开发 人员可以在程序中加入监控语句，并通过输出的监控结果来调试程序。
④驱动工具等 采用自底向上的测试方法时，由于被测模块的上层模块尚未经测试，所
以需要编写模拟调用本模块的上层模块，驱动工具可协助测试人员完成有关 的工作。
3.测试用例
　　测试用例是测试时所选用的数据。一般认为，测试是通过输入一定的测 试数据运行被测程序来完成的。因而，测试的关键是选择好测试用例。但是， 需要明确的是，要穷举所有的测试数据来测试程序常常是不可能的，因而需 要选择一些被认为是好的测试用例。好的测试用例可以理解为：在一定的时 间和经费的限制下，能尽可能多地发现错误的测试用例。事实上，穷举所有
　　
测试用例是完全不必要的，反复地使用那些能证明程序正确执行的测试用例 也是绝对不必要的。
　　测试用例应该包括两部分：输入数据和预期输出结果。输入数据即前面 说的测试数据，预期输出结果即根据输入数据推断出来的可能输出，把它也 作为测试用例的一部分是为了在执行测试之后，和实际的输出结果相比较。
二、测试的过程
系统测试可分为三个过程，即：单元测试、组装测试和确认测试。
1.单元测试
单元测试是对基本的程序模块所做的测试，其具体内容包括：
①模块间的接口；
②模块内局部数据结构；
③程序的执行路径，包括计算和运行控制；
④程序的错误处理能力。
2.组装测试
（1）组装测试的内容 组装测试是根据概要设计中各功能模块的说明及制定的组装测试计划，
将经过单元测试的模块逐步组装并进行测试。 组装测试的内容有：
①测试模块间的连接；
②测试系统或子系统的输入/输出处理，使其达到设计要求；
③测试系统或子系统正确处理能力和经受错误的能力。 具体地说，组装测试主要作以下检查：通过模块间接口的数据是否丢失；
一个模块的运行会不会破坏别的模块的功能；一些模块组合之后所形成的总
功能是否保持系统设计的要求；全程数据在程序运行中能否保持正常；几个 模块运行后的误差积累是否超过规定范围；单元测试中尚未查出的错误等。
（2）组装测试的方式
　　根据组装测试中各个模块联结方式，可将组装测试分为非渐增式测试和 渐增式测试两种方式。
①非渐增式
　　非渐增式先对系统的单个模块进行个别测试，然后再将所有模块组合在 一起测试。
②渐增式
　　渐增式也是先对系统的单个模块进行个别测试，但在模块组合时，不是 一次组合所有的模块，而是先组合测试少数几个模块，然后逐渐加多，直到 所有模块都组合在一起为止。
　　渐增式的组合方向有自顶向下联结和自底向上联结两种。自顶向下联结 从模块结构图的顶端开始，逐层向下联结。自底向上与此刚好相反。
3.确认测试
　　确认测试又叫验收测试，其任务是根据软件需求说明书中定义的全部功 能和性能要求，以及确认测试计划测试整个系统是否达到了要求。并提交最 终的用户手册和操作手册。
确认测试包括以下内容：
　　①在模拟的环境中进行强度测试，即在事先规定的一个时期内运行软件 的所有功能，以证明该软件无严重错误。
　　
②执行测试计划中提出的所有确认测试。
　　③使用用户手册和操作手册，以进一步证实其实用性和有效性，并改正 其中的错误。
④分析测试结果，找出产生错误的原因。
⑤书写确认测试分析报告。
⑥确认测试结束后，书写整个项目的开发总结报告。 三、测试方法 目前最基本的测试方法有两种，它们是白盒法和黑盒法。
　　白盒法又叫逻辑覆盖法。之所以称为白盒法，是指测试时需深入到程序 内部。对测试人员而言，整个程序就像一个敞开的盒子，因而使用这种方法 的基础是对程序内部的逻辑结构有清楚的了解，即测试时需要有被测程序的 源代码。白盒法要求测试用例要尽可能复盖程序模块内部的所有逻辑路径。 黑盒法和白盒法的测试依据正相反，黑盒法不需要测试人员了解被测程序内 部的逻辑结构，程序内部的源代码就像被一个黑盒法隐藏起为，所以称为黑 盒法。在黑盒法中，测试人员不是根据程序内部的逻辑结构而是根据程序的 功能来设计测试用例。
　　白盒法和黑盒法各自有其优点和不足，也各有其应用的条件和限制，它 们分别适宜于不同情况下的测试。
1.白盒法
（1）白盒法的基本概念 前边说过，白盒法又称逻辑覆盖法。所谓逻辑覆盖是指使用一定的测试
数据所能执行的语句范围，这些被执行的语句所组成的路径，称为逻辑路径。
如果整个程序是顺序结构，从头到尾只有一条路径，则执行程序必然会覆盖 所有路径，测试起来就很简单。而在具有选择结构或循环结构的程序中，由 于有了两个或两个以上的分支，程序的一次执行肯定不会覆盖所有的分支， 从而产生了多种逻辑覆盖类型。
例 4.2.1 设有如下一程序段。
if（A＞1andB＝＝0） X＝X/A；
if（A==2orX＞1）
X=X＋1；
　　该程序段的流程图如图 4-2-1 所示，它有两个复合判定，两条可执行语 句。因而逻辑路径则有：
ace，两条语句均被执行； abd，两条语句均不执行； acd，只执行 X=X/A； abe，只执行 X=X＋1。 这样，一共有 4 条逻辑路径。
下面根据对这个程序段的分析来说明各种逻辑覆盖类型。


（2）逻辑覆盖类型
1）语句覆盖 语句覆盖是指选用的测试用例将执行程序中的每个语句。
　　对于所举的例子，语句覆盖应执行 c 和 e 两个语句。要做到这一点，当 然可以有多个测试用例，有的执行 c，有的执行 e，但理想的测试用例应当是 最少的，即最好用一个执行 ace 这一逻辑路径的测试用例。选用如下测试用 例就能满足语句覆盖的要求。
A=2
B=0
X=3 可以看出，语句覆盖的测试效果是相当弱的。因为就这个程序段讲，一
共有 4 条逻辑路径，要对它进行比较全面的测试，则每条路径至少要执行一
遍，而语句覆盖只执行了 1 条。
2）判定覆盖 判定覆盖是指执行测试用例时，要使程序中每个判定都能够获得一次真
值和伪值。即使每个分支路径都被执行一次。
根据这一要求，比较理想的情况是使用如下测试用例： A=3
B=0
X=1 则程序运行时
第一个判定为真，能够执行 X/A，但由于执行后 X=1/3，
第二个判定为伪，所覆盖的是 acd 这一逻辑路径。 再用如下测试用例：
A=2
B=1
X=3 则程序运行时
第一个判定为伪，而
第二个判定为真，所覆盖的是 abe 逻辑路径。 由于使用这两个测试用例后，每个判定都取过真和伪，已经满足判定覆
盖标准，因而不必再选其它测试用例。
　　然而这样执行的结果只经过 acd 和 abe 两条逻辑路径，还有其它两条没 有被执行。所以判定覆盖尽管比语句覆盖的测试效果要强些，但距完整、全 面的测试仍有一定的差距。
3）条件覆盖

　　条件覆盖是指执行测试用例时，要使得程序判定中的每个条件都能获得 一次真值和伪值。
　　判定由条件组成，只包含一个条件的判定称为简单条件判定。对于简单 条件判定，条件覆盖和判定覆盖是一致的；包含两个或两个以上条件的判定 称为复合条件判定。对于复合条件判定，由于一个判定由多个条件组成，所 以两种覆盖的程序不同。一般讲，条件覆盖的测试效果比判定覆盖强。
在上例中，一共有四个条件，即： A＞1
B=0
A=2
X＞1 为使每一个条件在测试中都要取一次真和一次伪。可选用如下两个测试
用例：
测试用例 1 测试用例 2
A=2 A=1
B=0 B=1
X=4 X=1
4）判定/条件覆盖 判定/条件覆盖是覆盖范围更全面的一种覆盖类型。在判定/条件覆盖
中，通过执行足够的测试用例，使每个判定都能取各种可能的值，同时使每
个条件也都能取各种可能的值。 对于上面的程序段，条件覆盖所选的两个测试用例就可以满足这种覆盖
标准。
5）条件组合覆盖 条件组合覆盖是通过执行足够的测试用例，使得每个判定中条件的各种
可能组合至少出现一次。由于考虑到判定中各种条件的可能组合，满足这种
覆盖标准的测试用例一定能满足前述的其它覆盖类型。 对于上例中的程序段，四个条件共有八种组合，即： A＞1，B=0
A＞1，B≠0
A＜1，B=0
A＜1，B≠0
A=2，X＜1
A=2，X＜1
A≠2，X＞1
A≠2，X＜1 用四个测试用例就可以实现上述八种组合，这些测试用例是： A=2，B=0，X=4
A=2，B=1，X=1
A=1，B=0，X=2
A=1，B=1，X=1 条件组合覆盖的覆盖效果应当是最强的，但它也不一定能覆盖程序所有
的逻辑路径。如本例中，acd 就没有执行。
2.黑盒法

　　和白盒法不同，黑盒法的测试用例很大程度上是根据经验总结出来的。 在选择测试用例时，一般有等价分类法、边缘值分析法和错误推断法等几种 方法。
（1）等价分类法 黑盒法是根据程序的功能来选择测试用例的。彻底的黑盒法应当用所有
可能的输入数据来进行测试，但这常常是不可能的。因此测试时只能挑选适 当的、有代表性的测试用例，即组织一个数量有限、但能尽可能多地代表其 它各种未被选为测试用例的测试数据集合。这就是等价分类法的基本思想。 等价分类法把输入数据的所有可能值分成若干个“等价类”，对测试而言， 每个等价类中的数据作用结果是相同的。因而，测试时从中选择一个数据即 可。等价分类法的关键是划分等价类。
　　划分等价类和程序功能有关。一般说来，程序功能所要求的输入决定了 等价类，因此应当从程序的功能找出输入条件，再把所有可能的输入条件划 分成若干等价类，对于每一个等价类则要举出合理的和不合理的两种例子。 划分的方法是带有试探性的，目前还没有很明确的规则，只有些可供参
考的做法。
　　1）如果输入条件说明了输入数据的取值的范围，则可以把规定的取值范 围划分为一个合理的等价类，而把超出此范围的划分为两个不合理的等价 类。例如，如果输入值在 1～100 之间则合理等价类为“1≤X≤100”；而两 个不合理的等价类为“Y＜1”和“Y＞100”。
2）如果输入条件说明了输入数据的个数，则可以把规定个数作为一个合
理的等价类，而把在此之外的个数划分为两个不合理的等价类。例如，如果 每个学生可以借 5 本书，则一个合理的等价类是 1～5；两个不合理的等价类 分别是未借书和借书超过 5 本。
3）如果输入条件说明了一个“必须成立”的情况，则此情况可以作为一
个合理的等价类，而与此相反的情况则是一个不合理等价类。例如，如果某 数据要求
第一字节规定为“1F”，则“1F”为合理等价类，而以外字符均属于不
合理等价类。
　　4）如果输入条件说明了输入数据的一组可能的值，而且程序是用不同方 式来处理每一种值的，则可以划分合理的和不合理的等价类各一个。如读者 的借书量是按工人、学生、研究生、教师和馆员来确定的，则合理的输入等 价类是工人、学生、研究生、教师和馆员的集合，而不合理的等价类是这五 种以外的其他人。
　　5）如果认为程序将按不同的方式来处理等价类中的各种例子，则应将这 个等价类再细分成几个更小的等价类。
（2）边缘值分析法 边缘值分析法是等价分类法的一种特殊情况。它的“特殊”之处在于：
　　1）它对同一等价类的所有例子不是等同看待，而是把目标放在反映该等 价类的边缘情况的例子上，因而它不是从同一等价类中随意挑选测试用例， 而是着重从边界情况来分析可能挑选的测试用例。
　　2）等价分类法仅仅从输入条件进行分类和挑选测试用例，而边缘值分析 法除此之外还要根据输出的情况来设计测试用例。
应用边缘值分析法需要一定的经验和技巧，还要有一定的创造性。这里

只能列举一些例子供参考。
　　1）如果输入条件说明了取值范围，则可以在取值的边界附近来选取合理 的和不合理的测试用例，并使不合理到合理正好越过边界。
　　如输入范围为；-1.0～1.0，则取-1.001，-1.0，1.0，1.001 四个测试 用例，
第 1 和
第 4 是不合理的，
第 2 和
第 3 是合理的，由 1 到 2 和由 3 到 4 正好两次跨越输入范围的边界。
　　2）如果输入条件指出输入数据的个数，可以取其范围中的最小个数、最 大个数，比最小个数少 1、比最大个数多 1 作为边缘值。
如某个数据文件可以 1～65535 个记录，则可取 0 个，1 个，65535 个，
65536 个作为边缘值。
　　3）把 1）用于输出条件。如某个程序的功能是计算商品销售折扣量，最 低折扣量为 0 元，最高可到 1050 元，则可设计一些有关商品价格的测试用例， 使输出分别为 0 和 1050，还可以考虑是否能设计输出为负值或大于 1050 的 例子。
4）把 2）用于输出条件。如某情报检索系统对于命中文献，最多只能打
印 100 篇，就可以设计打印出 0 篇，1 篇，100 篇，101 篇作为边缘值。
　　5）如果程序的输入或输出是有序集合，如顺序文件、线性表等，则应特 别注意集合的
第一个和最后一个元素。
3.错误推测法
　　错误推测法是指测试人员凭借经验来推测程序中可能存在的错误，从而 有针对性地编写检查这些错误的测试用例。
错误推测法没有确定的步骤，很大程度上凭借经验，如输入数据为 0 或
输出数据为 0 易发生错误；又如，输入表格为空或只有一行也容易发生错误， 因而可以选择这些情况作为测试用例。
4.综合策略
　　由于程序的情况多种多样，因而具体测试时，需要综合运用各种测试方 法，即把选择测试用例的各种方法结合起来，形成一些综合性的策略。具体 应用要根据情况灵活处理，比如，不了解程序内部的具体逻辑处理流程是无 法使用白盒法的。
根据各种方法的特点，综合策略有如下几种：
①任何情况下，都需要用边缘值分析法；
②必要时再用等价分类法补充测试用例；
③再用错误推测法；
　　④如果能使用白盒法，则可检查上述例子的逻辑覆盖程度，如发现不够， 可再增加测试用例以使逻辑覆盖尽可能全面。
　　总之，系统测试有多种方法，实际测试时应根据具体情况，选择适当的 方法。