三级信息管理重点难点分析

三级信息管理技术分章节考试要点

软件工程(结构化生命周期方法之结构化分析方法)

结构化分析方法

结构化分析是面向数据流进行需求分析的方法。20世纪70年代末，经YourdonE.、C

on-stantineL.、DeMarcoT.等人提出和发展，至今已得到广泛应用。结构化分析方法的一些

重要概念也渗透在其他开发方法中。例如，结构化分析与设计技术(StructuredAnalysisan

dDesignTechnique,SADT)、面向对象技术(Object-OreintedTechnique,OOT)、IDEF

方法等。

结构化分析方法适合于数据处理类型软件的需求分析。由于利用图形表达需求，显得清

晰、简明，易于学习和掌握。具体来说，结构化分析方法就是用抽象模型的概念，按照软件

内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软

件为止。根据DeMarco的论述，结构化分析方法使用的工具有:数据流图、数据词典、结构

化英语、判定表、判定树。结构化分析方法有两个明显特点。

采用简明易懂、直观的描述方式

1.数据流图

数据流图也称为BubbleChart或dataFlowGraph»是描述数据处理过程的工具。数据

流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。

(1)数据流图的主要图形元素

从数据流图中可知，数据流图的基本图形元素有4种。

数据流是沿箭头方向传送数据的通道，它们大多是在加工之间传输加工数据的命名通

道，也有连接数据存储文件和加工的没有命名的数据通道。这些数据流虽然没有命名，但因

联接着有名加工和有名文件，所以其含意也是清楚的。同一数据流图上不能有同名的数据流。

多个数据流可以指向同个加工，也可以从一个加工散发出许多数据流。

加工是以数据结构或数据内容作为加工对象的。加工的名字通常是一个动词短语，筒明

扼要地表明完成的是什么加工。

文件在数据流图中起保存数据的作用，因而称为数据存储(DataStore),它可以是数

据库文件或任何形式的数据组织。指向文件的数据流可理解为写入文件或查询文件，从文件

中引出的数据流可理解为从文件读取数据或得到查询结果。

数据流图中第4种元素是数据源点或汇点，它表示图中要处理数据的输入来源及处理结

果要送往何处。由于它在图中的出现仅仅是•个符号，并不需要以软件的形式进行设计和实

现，因而，它只是数据流图的外围环境中的实体，故称外部实体。在实际问题中它可能是计

算机外围设备或是传感装置。

(2)数据流与加工之间的关系

在数据流图中，如果有两个以上的数据流指向一个加工，或是从一个加工中引出两个以

上的数据流，这些数据流之间往往存在一定的关系。

(3)分层的数据流图

为了表达数据处理过程的数据加工情况，用个数据流图是不够的。为表达稍为复杂的

实际问题需要按照问题的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系。

先把整个数据处理过程暂且看成一个加工，它的输入数据和输出数据实际上反映了系统

与外界环境的接U。这就是分层数据图的顶层。但只此一图并未表明数据的加工要求，需要

进一步细化。如果这个数据处理包括3个子系统，就可以画出表示这3个子系统1、2、3

的加工及其相关的数据流。这是顶层下面的第一层数据流图，记为DFD/L1。继续分解这3

个子系统，可得到第二层数据流图DFD/L2.1、DFD/L2.2,及DFD/L2.3,它们分别是子系统。

1、2和3的细化。仅以DF/2为例，其中的4个加工的编号均可联系到其上层图中的子系统

2。这样得到的多层数据流图可十分清晰地表达整个数据加工系统的真实情况。对任何一层

数据流图来说，称它的上层图为父图，在它下一层的图则称为子图。

在多层数据流图中，可以把顶层流图、底层流图和中间层流图区分开。顶层流图仅包含

一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统的输出数据。

顶层流图的作用在于表明被开发系统的范围，以及它和周围环境的数据交换关系。底层流图

是指其加工不须再做分解的数据流图，其加工称为“原子加工”。中间层流图则表示对其上层

父图的细化。它的每一加工可以继续细化，形成子图。中间层次的多少视系统的复杂程度而

定。

(4)数据流图画法

画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。具

体步骤可按如下来做。

①先找系统的数据源点与汇点。它们是外部实体，由它们确定系统与外界的接口。②找

出外部实体的输出数据流与输入数据流。③在图的边上画出系统的外部实体。

④从外部实体的输出数据流(即系统的源点)出发，按照系统的逻辑需要，逐步画出一

系列逻辑加工，直到找到外部实体所需的输入数据流(即系统的汇点)，形成数据流的封闭。

⑤按照下面所给的原则进行检查和修改。

⑥按照上述步骤，再从各加工出发，画出所需的子图。

(5)进行检查和修改的原则

①数据流图上所有图形符号只限于前述四种基本图形元素。②数据流的主图必须包括前

述4种基本元素，缺一不可。

③数据流图的主图上的数据流必须封闭在外部实体之间，外部实体可以不只一个。④每

个加工至少有一个输入数据流和一个输出数据流。

⑤在数据流图中，需按层给加工框编号。编号表明该加工处在哪•层，以及上下层的父

图与子图的对应关系。

⑥任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据

流必须一致。即父图与子图的平衡，它表明了在细化过程中输入与输出不能有丢失和添加。

⑦图上每个元素都必须有名字。表明数据流和数据文件是什么数据，加工做什么事情。

⑧数据流图中不可夹带控制流。因为数据流图是实际业务流程的客观映象，说明系统“做

什么''而不是要表明系统“如何做”，因此不是系统的执行顺序，不是程序流程图。⑨初画时

可以忽略琐碎的细节，以集中精力于主要数据流。

在需求分析期间，有时会要求修改系统的某些方面。使用数据流图可以很容易地把需

要修改的区域分离出来。只要清楚地了解穿过要修改区域边界的数据流，就可以为将来的修

改做好充分的准备，而且在修改时能够不打乱系统的其他部分.

2.数据词典

数据词典的任务是对于数据流图中出现的所有被命名的图形元素在数据词典中作为一

个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。

数据词典中所有的定义应是严密的、精确的，不可有半点含糊，不可有二义性。

(1)数据词典的定义

对在数据流图中每一个命名的图形元素均给予定义，其内容有图形元素的名字、别名或

编号、分类、描述、定义、位置等。以下是不同词条应给出的内容。

①数据流词条描述

数据流是数据结构在系统内传播的路径。•个数据流词条应有以下几项内容：

数据流名：

说明:简要介绍作用即它产生的原因和结果。

数据流来源:来自何方。

数据流去向:去向何方:数据流组成:数据结构。

每个数据量:数据量、流通量。

②数据元素词条描述

图中的每一个数据结构都是山数据元素构成的，数据元素是数据处理中最小的，不可再

分的单位，它直接反映事物的某一特征。对于这些数据元素也必须在数据词典中给出描述。

其描述需要以下信息：

数据元素名

类型:数字（离散值，连续值），文字S（编码类型）。

长度。

取值范围。

相关的数据元素及数据结构。

数据元素的取值可分数字型与文字型。数字型又有离散值与连续值之分。离散值或是枚

举的，或是介于上下界的一组数;连续值•一般是有取值范围的实数集。对于文字型，需给予

编码类型，文字值需加以定义。③数据文件词条描述

数据文件是数据结构保存的地方。一个数据文件词条应有以下几项内容。数据文件名。

简述:存放的是什么数据。输入数据。输出数据。

数据文件组成:数据结构。

存储方式:顺序、直接、关键码。存取频率。

④加工逻辑词条描述

加工比较复杂，它到后来就是段程序。加工的表达方式有判定表、判定树和结构化英

语等等，它们要全部写在一个词条中是有困难的。主要描述有:加工名。

加工编号:反映该加工的层次。简要描述:加工逻辑及功能简述。输入数据流。输数据

流。

加工逻辑:简述加工程序、加工顺序。⑤源点及汇（终）点词条描述

对于一个数据处理系统来说，源点和汇点应当比较少。如果过多就缺少独立性，人一机

界面太复杂，这时就要考虑减少，提高系统独立性。定义源点和汇点时，应包括:名称:外部

实体名。

简要描述:什么外部实体。有关数据流。数目。

（2）数据词典的使用

在结构化分析的过程中，可以通过名字，方便地查阅数据的定义:同时可按各种要求，

随时列出各种表，以满足分析员的需要。还可以按描述内容（或定义）来查询数据的名字，

通过检查各个加工的逻辑功能，可以实现和检查在数据与程序之间的,致性和完整性，在以

后的设计与实现阶段，以至于到维护阶段。都需要参考数据词典进行设计、修改和查询。

（3）数据结构的描述

在数据词典的编制中，分析员最常用的描述数据结构的方式有定义式和Warnier图。①

定义式

在数据流图中，数据流和数据文件都具有一定的数据结构。因此必须以一种清晰、准确、

无二义性方式来描述数据结构。

这种定义方法是自顶向下，逐级给出定义式，直到最后给出基本数据元素为止。②War

nier图

Wamier图是表示数据层次结构的一种图工具。它用树形结构描绘数据结构，它还能指

出某一类数据或某一数据元素重复出现的次数，并能指明某一特定数据在某一类数据中是否

是有条件的出现。在进行软件设计时，从Wamier图入手，能够很容易转换成软件的设计描

述。

3.加工逻辑说明

在数据流图中，每一个加工框只简单地写上了一个加工名，这显然不能表达加工的全部

内容。随着自顶向下逐层细化，功能越来越具体，加工逻辑也越来越精细。到最底一层，加

工逻辑详细到可以实现的程序，因此称为“原子加工''或"基本加工”。如果能够写出每一个基

本加工的全部详细逻辑功能，再自底向上综合，就能完成全部逻辑加工。在写基本加工逻辑

的说明时，应满足如下的要求：

•对数据流图的每一个基本加工，必须有一个加工逻辑说明；

・加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则；

・加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。

目前用于写加工逻辑说明的工具有结构化语言、判定表和判定树。下面分别介绍。

（1）结构化语言

结构化语言也称为PDL,是一种介于自然语言和形式化语言之间的半形式化语言。它

是在自然语言基础上加了一些限制而得到的语言,是使用有限的词汇和有限的语句来描述加

工逻辑。结构化语言的词汇表由英语命令动词、数据词典中定义的名字、有限的自定义词和

控制结构关键词IF-THEN-ELSE、WHELE-DO、REPEAT-UNTIL、CASE-OF等组成。其动

词的含义要具体，尽可能少用或不用形容词和副词。

语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示。其基本控

制结构有简单陈述句结构、判定结构和重复结构。此外在书写时，必须按层次横向向右移行，

续行也同样向右移行，对齐。

要了解基本加工逻辑的来龙去脉、在数据流图中的位置、加工的使用情况等有更清楚的

了解，一般对结构化英语的描述加一些外层说明。

(2)判定表

在某些数据处理问题中，某数据流图的加工需要依赖于多个逻辑条件的取值，就是说完

成这一加工的一组动作是由于某一组条件取值的组合而引发的。这时使用判定表来描述比较

合适。下面以''检查发货单”为例，说明判定表的构成。判定表由4个部分组成，双线分割开

的4部分是：

条件桩(ConditionStub)---左上部分:列出了各种可能的条件。除去某些问题中对

各个条件的先后次序有特定的要求以外，通常判定表中对各条件的先后次序不要求。条件项

(ConditionEntry)--------右上部分:给出各个条件的条件取值的组合。

动作桩(ActionStub):---左下部分:列出了可能采取的动作。这些动作的排列顺序

没有限制，但为便于阅读也可令共按适当的顺序排列。

动作项(ActionEntry):---右下部分:是和条件项紧密相关的，它指出了在条件项的

各种取值的组合情况下一步应采取什么动作。这里将任一条件取值组合及其相应要执行动作

作称为规则，它在判定有中是纵贯条件项和动作项的一列。显然，判定表中列出了多少个条

件取值的组合，也就有多少条规则，即条件项一动作项有多少列。

在实际使用判定表时，常常先把它化简。如果表中有两条或更多的规则具有相同的动作,

并且其条件项之间存在着某些关系，就可设法将它们合并。就是说要执行的动作与第三条件

的取值无关，这样，便可将这两条规则合并，合并后的第三条件取值用“一”表示，即与取值

无关。类似地，无关条件项“一”，在逻辑上又可包含其他项值，具有相同动作的规则还可以

进一步合并。判定表能够把在什么条件下，系统应完成哪些操作，表达得十分清楚、准确、

一目了然。这是用语言说明难以准确、清楚表达的，但是用判定表描述循环比较困难。有时，

判定表可以和结构化语言结合起来使用。

(3)判定树

判定树也是用来表达加工逻辑的一种工具。有时候它比判定表更直观，用它来描述加工,

很容易为用户接受。

没有一种统一的方法来构造判定树，也不可能有统一的方法。因为客观存在是用结构化

语言，甚至是自然语言写成的叙述文作为构造树的原始依据的，但可以从中找些规律。首先,

应从文字资料中分清哪些是判定条件，哪些是判定做出的结论。

在表达一个基本加工逻辑时，结构化语言、判定表和判定树常常交*使用，互相补充。

因为这3种手段各有优缺点。

总之，加工逻辑说明是结构化分析方法的一个组成部分，对每个加工都要加以说明。使

用的手段，应当以结构化语言为主，对存在判断问题的加工逻辑，可辅之以判定表和判定树。

4.软件需求说明

软件需求规格说明书包括的主要内容如下：

(1)概述

(2)数据描述①数据流图②数据字典

③系统接口说明④内部接口说明

(3)功能描述①功能②处理说明③设计的限制

(4)性能描述①性能指标②测试种类

③预期的软件响应性能④其它

(5)参考文献目录

(6)附录

其中概述是从系统的角度描述软件的目标和任务。软件需求文档的生成方法有以下两

种。

(1)计算机辅助生成:由于需求文档的规模较大，并且需要经常查询、维护，所以使用

计算机辅助的软件需求分析工具，来实现软件需求文档的自动生成，是非常有意义的。197

7年最先推出了需求陈述语言RSL(RSL中的语句是计算机可以处理的)。同年美国密执安

大学开发了PSL/PSA(问题陈述语言/问题陈述分析程序)系统。它是信息系统开发自动化

支持环境1SD0S的•个组成部分。其中PSL是用来描述系统的形式语言，它可以对系统需

求的一致性进行检查，并可根据开发者的需要，随时生成需求文档。

(2)手工与半手工方式:这种方法难以保证文档质量。半手工方式是利用正文编辑程序

及其他实用程序辅助手工方式来生成文档，这类方法难以保证文档的正确性、一致性和完整

性。

■三级信息管理技术分章节考试要点：软件工程(结构化生命周

期方法之软件设计)

软件设计

在明确了用户的需求以后，下一步的任务就是对未来的软件系统进行设计。软件设计通

常可分为概要设计和详细设计。概要设计的任务是确定软件系统的结构，进行模块划分，确

定每个模块的功能、接口以及模块间的调用关系。详细设计的任务是为每个模块设计实现的

细节。此外，在概要设计阶段还应对全局数据结构进行设计，详细设计阶段还应对局部数据

结构进行设计。有的设计方法不区分概要设计和详细设计，统称为软件设计。

人们在开发过程中，总结出许多软件设计的概念和原则，这些概念和原则对提高软件的

设计质量有很大的帮助。

1.抽象

抽象是指忽视一个主题中与当前目标无关的那些方面，以便更充分地注意与当前目标有

关的方面。抽象是认识复杂问题的过程中人类使用的最有力的思维工具，它抽取出事物的本

质特性而暂时不考虑它的细节。

软件工程中从软件定义到软件开发要经历多个阶段,在这个过程中每前进一步都可看作

是对软件的抽象层次的一次细化。抽象的最低层次就是实现该软件的源程序代码。在进行模

块化设计时可以有多个抽象层次，最高抽象层次的模块用概括的方式叙述问题的解法，较低

抽象层次的模块是对较高的抽象层次模块对问题解决描述的细化。过程抽象和数据抽象是常

用的两种主要抽象手段。

过程抽象是指任何一个完成明确功能的操作都可被使用者当作单个的实体看待,尽管这

个操作实际上可能由一系列更低级的操作来完成。过程抽象常常也称为功能/子功能抽象。

例如函数、子程序。

数据抽象定义了数据类型和施加于该类型的操作，并限定了对象值的范围，只能通过使

用这些操作修改和观察这些数据，例如抽象数据类型。

2.模块化

模块化是指将一个待开发的软件分解成若干个小的简单的部分模块，每个模块可

独立地开发、测试，最后组装成完整的程序。这是一种复杂问题的“分而治之''的原则，模块

化的目的是使程序的结构清晰，容易阅读，容易理解，容易测试，容易修改。

模块是指执行某一特定任务（也可以是实现某一特定的抽象数据类型）的数据结构和程

序代码。一个模块有它的外部特征和内部特征。外部特征包括模块的接口（即它的输入/输

出参数，引用的全局变量和它需调用的其他模块）和模块的功能，内部特征包括模块的局部

数据和实现该模块的程序代码。调用一个模块只需知道它的外部特征，而不必了解其内部特

征。

3.信息隐蔽

信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单

一的设计模块中，定义每一个模块时尽可能少地显露其内部的处理。

在设计时首先列出一些可能发生变化的因素,在划分模块时将一个可能发生变化的因素

隐蔽在某个模块的内部，使其他模块与这个因素无关。在这个因素发生变化时，我们只需修

改含有这个因素的模块，而与其他模块无关。

隐蔽的对象可以有:什么样的决策、可能修改的决策、数据结构的内部连接以及对它所

做的操作细节、内部特征码、与计算机硬件有关的细节等。

信息隐蔽原则对提高软件的可修改性、可测试性和可移植性都有重要的作用。

4.模块独立

模块独立是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系简

单。衡量模块独立程序的度量标准有两个:耦合和内聚。耦合是指模块之间联系的紧密程度。

耦合度越高则模块的独立性越差。内聚是指模块内部各元素之间联系的紧密程度。例如一个

完成多个功能的模块的内聚度就比完成单一功能的模块的内聚度低。内聚度越低模块的独立

性越差。因此，模块独立就是希望每个模块都是高内聚低耦合的。

(1)耦合

两个模块之间的耦合方式通常有如下7种，下面按它们的耦合度从低到高的次序依次作

介绍。①非直接耦合:非直接耦合是指两个模块没有直接的联系，它们中的任一个都能不依

赖于对方而独立地工作。

②数据耦合:数据耦合是指两个模块借助于参数表传递简单数据。

③标记耦合(stampcoupling):当一个数据结构的一部分(如记录的一部分)借助于模

块接口被传递时就发生标记耦合。

④控制耦合:控制耦合指两个模块间传递的信息中包含用于控制模块内部逻辑的控制信

息。⑤外部耦合:当模块与软件以外的环境有关时就发生外部耦合。例如，输入/输出把一个

模块与特定的设备、格式、通信协议耦合在一起。

⑥公共耦合:多个模块引用一全局数据区的模式称为公共耦合。例如FORTRAN语言中

的COMMON语句、C语言中的external数据类型、一个磁盘文件等都是全局数据区。⑦内

容耦合呐容耦合指两上模块之间出现了下列情况之一：

・一个模块访问另一个模块的内部数据；

・一个模块不通过正常入口转到另一模块的内部;•两个模块有一部分程序代码重叠；

・一个模块有多个入口。

(2)内聚

模块的内聚种类通常可分成7种，下面按内聚度从低到高的次序依次作介绍。

①偶然内聚:如果一个模块完成一组任务，这组任务彼此间即使有关系，其关系也是很

松散的，这个模块属于偶然内聚。

②逻辑内聚:如果一个模块完成逻辑上相关的一组任务，这个模块是逻辑内聚的。例如，

产生与类型无关的全部输出的模块。

③瞬时内聚（temporalcohesion）:如果一个模块所包含的任务必须在同一-时间间隔内执

行，这个模块属于瞬时内聚。例如初始化模块。

④过程内聚:如果一个模块的处理元素是相关的，而且必须按特定的次序执行，这个模

块属于过程内聚。

⑤通信内聚:如果一个模块的所有处理元素集中在一个数据结构的区域上，该模块属于

通信内聚。例如，一个模块中的所有处理元素使用同一输入数据。

⑥顺序内聚:如果一个模块的处理元素是相关的，而且必须顺序执行，这个模块属于顺

序内聚。⑦功能内聚:如果一个模块完成••个单一的功能，模块中的各部分在此目标下协同

工作，而且都是为完成这一功能而不可缺少的，那么这个模块是功能内聚的。

5.模块分解时应遵循的准则

（1）满足信息隐蔽原则。

（2）尽量使得模块的内聚度高，模块间的耦合度低。

（3）模块的大小适中（通常一个模块以50〜100个语句行为适宜）。

（4）模块的调用深度不宜过大。一个模块A可以调用另一模块B,模块B还可调用模

块C,称模块A直接调用模块B,模块A间接调用模块C,被间接调用的模块还可调其他

模块，这样可形成一棵调用树，我们把以某个模块为根结点的调用树的深度称为该模块的调

用深度。

（5）模块的扇入应尽量大，扇出不宜过大。一个模块的扇入是指直接调用该模块的上

级模块个数。一个模块的扇出是指该模块直接调用的下级模块的个数。扇入大表示模块的复

用程度高，扇出大表示模块的复杂度高。

（6）设计单入口和单出口的模块。

（7）模块的作用域应在控制域之内。模块的作用域是指受该模块内一个判定影响的所

在模块的集合。模块的控制域是指该模块本身以及被该模块直接或间接调用的所有模块的集

合。在设计时，作用域应是控制域的子集，作用域最好是做出判定的模块本身以及它的直属

下级模块（直接调用的模块）。

（8）模块的功能应是可以预测的，功能可预测是指对相同的输入数据能产生相同的输

出。

■三级信息管理技术分章节考试要点：软件工程（结构化生命周

期方法之软件需求分析）

软件需求分析

软件需求分析工作是软件生存期中重要的一步，也是决定性的一步。只有通过软件需求

分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开

发的基础。软件需求分析工作也是一个不断认识和逐步细化的过程。该过程将软件设计阶段

所确定的软件范围（工作域）逐步细化到可详细定义的程度，并分析出各种不同的软件元素,

然后为这些元素找到可行的解决方法。

制定软件的需求规格说明不只是软件开发人员的事，用户也起着至关重要的作用。用户

必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而软件分析人员则要认真了解

用户的要求，细致地进行调查分析，把用户“做什么”的要求最终转换成一个完全的、精细的

软件逻辑模型并写出软件的需求规格说明，准确地表达用户的要求。

1.软件需求分析任务

需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其

他系统元素的接口细节。定义软件的其他有效性需求。

分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开

发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示。在软件完成后，制

定的软件需求规格说明还要为评价软件质量提供依据。

需求分析阶段研究的对象是软件项目的用户要求。需要注意的是，必须理解用户的各项

要求，但又不能全盘接受所有的要求。因为并非所有用户要求都是合理的。对其中模糊的要

求还需要澄清，然后才能决定是否可以采纳。对于那些无法实现的要求应向用户做充分的解

释，以求得谅解。

准确地表达所接受的用户要求，是需求分析的另一个重要方面。只有经过确切描述的软

件需求才能成为软件设计基础。

通常软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素，

并将功能和数据结构分配到这些系统元素中，它是软件实现的基础。但是目标系统的具体物

理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。与物理模型不同，逻

辑模型忽视实现机制与细节，只描述系统要完成的功能和要处理的数据。作为目标系统的参

考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系

统的“做什么''的问题。

（1）获得当前系统的物理模型。当前系统可能是需要改进的某个已在计算机运行的数

据处理系统，也可能是个人工的数据处理过程。在这一步首先分析、理解当前系统是如何

运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一

个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。

(2)抽象出当前系统的逻辑模型。在理解当前系统"怎样做''的基础上，抽取其“做什么”

的本质，从而从当前系统的物理模型抽象出当前系统的逻辑模型。

在物理模型中有许多物理因素，随着分析工作的深入，有些非本质的物理因素就成为不

必要的负担，因而需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本

质的因素即可获得反映系统本质的逻辑模型。

(3)建立目标系统的逻辑模型。分析目标系统与当前系统逻辑上的差别，明确目标系

统统到底要“做什么”，从当前系统的逻辑模型导出目标系统的逻辑模型。

(4)为了对目标系统做完整的描述，还需要对得到的逻辑模型做•些补充。

①说明目标系统的用户界面。根据目标系统所处的应用环境及它与外界环境的相互关

系，研究所有可能与它发生联系和作用的部分，从而决定人机界面。

②说明至今尚未详细考虑的细节。这些细节包括系统的启动和结束、出错处理、系统的

输入输出和系统性能方面的需求。

③其他。例如系统的其他必须满足的性能和限制等等。

2.需求分析的过程

需求分析阶段的工作，可以分成以下4个方面:对问题的识别、分析与综合、制定规格

说明和评审。

(1)问题识别

首先系统分析人员要研究计划阶段产生的可行性分析报告(如果有的话)和软件项目实

施计划。主要是从系统的角度来理解软件并评审用于产生计划估算的软件范围是否恰当。确

定对目标系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求Y铜降谋

曜肌R簿褪且笏⑷研整裁矗幽绞裁闯潭取U庞丁彬蟀？

・功能需求:列举出所开发软件在职能上应做什么。这是最主要的需求。

・性能需求:给出所开发软件的技术性能指标，包括存储容量限制、运行时间限制、安全

保密性等。

・环境需求:这是对软件系统运行时所处环境的要求。例如在硬件方面，采用什么机型、

有什么外部设备、数据通信接口等等。在软件方面，采用什么支持系统运行的系统软件(指

操作系统、网络软件、数据库管理系统等)。在使用方面，需要使用部门在制度上、操作人

员的技术水平上应具备什么样的条件等等。

•可靠性需求:各种软件在运行时，失效的影响各不相同。在需求分析时，应对所开发软

件在投入运行后不发生故障的概率，按实际的运行环境提出要求，对于那些重要的软件，或

是运行失效会造成严重后果的软件，应当提出较高的可靠性要求，以期在开发的过程中采取

必要的措施，使软件能够高度可靠地稳定运行，避免因运行事故而带来的损失。

•安全保密要求:工作在不同环境的软件对其安全，保密的要求显然是不同的。应当把这

方面的需求恰当地做出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全方

面的性能得到必要的保证。

・用户界面需求:软件与用户界面的友好性是用户能够方便、有效、愉快地使用该软件的

关键之一。从市场角度来看，具有友好用户界面的软件有很强的竞争力。因此，必须在需求

分析时，为用户界面细致地规定达到的要求。

•资源使用需求:这是指所开发软件运行时所需的数据、软件、内存空间等各项资源外，

软件开发时所需的人力、支撑软件、开发设备等则属于软件开发的资源，需要在需求分析时

加以确定。

・软件成本消耗与开发进度需求:在软件项目立项后，要根据合同规定，对软件开发的进

度和步骤的费用提出要求，作为开发管理的依据。

・预先估计以后系统可能达到的目标。这样，在开发过程中，可对系统将来可能扩充与

修改做准备。一旦需要时，就比较容易进行补充和修改。

•功能性需求是人们普遍关注的，但常常忽视对非功能性需求的分析。其实非功能性需

求并不是无关紧要的，它们涉及到的方面多而广，因而容易被忽略。如果在进行需求分析之

前没有做过可行性分析，那么补充完成这部分工作往往是必要的。从问题定义和调查研究入

手，与用户密切联系，详细了解问题提出的背景，弄清要解决什么问题。然后从软件系统特

性和用户目标出发，做市场调查和现场考察。仔细收集信息之后进行数据分析和功能分析，

建立系统的高层逻辑模型，再进一步做成本/效益分析。最后提交一份可行性分析报告，从

技术、经济、社会效应等方面论证可行性，以确认软件开发的目标是否可行。

问题识别的另一项工作是建立分析所需要的通信途径，以保证能顺利地对问题进行分

析。分析员必须与用户、软件开发机构的管理部门、软件开发组的人员建立联系。项目负责

人在此过程中起协调人的作用。分析员通过这种通信途径与各方商讨，以便能满足用户的要

求。

(2)分析与综合

需求分析的第二步工作是问题分析和方案的综合。分析员需从数据流和数据结构出发，

逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制分析它们

是否满足功能要求，是否合理。依据功能需求、性能需求、运行特性和设计上的限制分析它

们是否满足功能要求，是否合理。依据功能需求、性能需求、运行环境需求等，剔除其不合

理的部分，增加其需要的部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。

在这个步骤中，分析和综合工作反复地进行。在对现行问题和期望的信息（输入和输出）

进行分析的基础匕分析员开始综合出个或几个解决方案，然后检查这些方案是否符合软

件计划中规定的范围等等，再进行修改。总之，对问题进行分析和综合的过程将一直持续到

分析员与用户双方都感到有把握正确地制定该软件的规格说明为止。

常用的分析方法有面向数据流的结构化分析方法（简称SA）、面向数据结构的Jacks。

n方法（简称JSD）、面向对象的分析方法（简称00A）等，以及用于建立动态、模型的

状态迁移图或Petri网等。这些方法都采用图文结合的方式，可以直观地描述软件的逻辑模

型。

（3）编制需求分析的文档

」经确定的需求应当得到清晰准确的描述。通常把描述需求的文档叫做软件需求规格说

明书。同时，为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及编写

初步的用户手册，着重反映被开发软件的用户界面和用户使用的具体要求。

此外，依据在需求分析阶段对系统的进一步分析，从目标系统的精细模型出发，可以更

确切地估计所开发项目的成本与进度，从而修改、完善与确定软件开发的实施计划。

（4）需求分析评审

作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完

整性和清晰性，以及其他需求给予评价。评审的主要内容是：

•系统定义的目标是否与用户的要求一致；

•系统需求分析阶段提供的文档资料是否齐全；

■文档中的所有描述是否完整、清晰、准确所反映用户要求；

•与所在其他系统成分的重要接口是否都已经描述；

•所开发项目的数据流与数据结构是否足够、确定；

•所有图表是否清楚，在不补充说明时能否理解；

・主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

•设计的约束条件或限制条件是否符合实际；

•开发的技术风险是什么；

•是否考虑过软件需求的其他方案；

■是否考虑过将来可能会提出的软件需求;

■是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;

•有没有遗漏、重复或不一致的地方；

•用户是否审查了初步的用户手册；

・软件开发计划中的估算是否受到了影响。

为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审

结束应有评审负责人的结论意见及签字。除分析员之外，用户，开发部门的管理者，软件设

计、实现、测试的人员都应当参加评审工作。通常，评审的结果都包括了一些修改意见，待

修改完成后再经评审通过，才可进入设计阶段。

3.软件需求分析的原则

近年来已提出了许多软件分析与说明的方法，虽然各种分析方法都有其独特的描述方

法，但总的看来，所有分析方法还是有它们共同适用的基本原则。

(1)必须能够表达和理解问题的数据域和功能域

所有软件定义与开发工作最终是为了解决数据处理问题，就是将一种形式的数据转换成

另一种形式的数据。其转换过程必定经历输入、加工数据和产生结果数据等步骤。对于计算

机程序处理的数据，其数据域应包括数据流、数据内容和数据结构。

数据流即数据通过一个系统时的数据存储(如磁盘文件或内存缓冲区)中引入附加数据。

对数据进行转换是程序中应有的功能或子功能。两个转换功能之间的数据传递就确定了功能

间的接口。

数据内容即数据项。例如，学生名册包含了班级、人数、每个学生的学号、姓名、性别、

各科成绩等。学生名册的内容由它所包含的项定义。为了理解对学生名册的处理，必须要理

解它的数据内容。

数据结构即各种数据项的逻辑组织。数据是组织成表格，还是组织成有层次的树型结构?

在结构中数据项与其他哪些数据项相关?所有数据是在一个数据结构中，还是在几个数据结

构中?一个结构中的数据与其他结构中的数据如何联系?这些问题都由数据结构分析来解决。

(2)必须按自项向下、逐层分解的方式对问题进行分解和不断细化

如果将软件要处理的问题作为•个整体来看，显得太大太复杂很难理解。如果把问题以

某种方式分解为几个较易理解的部分，并确定各部分间的接口，从而实现整体功能。

在需求分析阶段，软件的功能域和信息域都能做进•步的分解。这种分解可以是同一层

次上的，称为横向分解;也可以是多层次的纵向分解。

例如，把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向

分解。但如果继续分解，把某些子功能又分解为小的子功能，某个小的子功能又分解为更小

的功能，这就属于纵向分解了。

（3）要给出系统的逻辑视图和物理视图

给出系统的逻辑视图（逻辑模型）和物理视图（物理模型），这对系统满足处理需求所

提出的逻辑限制条件和系统中其他成分提出的物理限制条件是必不可少的。软件需求的逻辑

视图给出软件要达到的功能和要处理的数据之间的关系，而不是实现的细节。例如，一个商

店的销售处理系统要从顾客那里获取订单，系统读取订单的功能并不关心订单数据的物理形

式和用什么设计读入，也就是说无需关心输入的机制，只是读取顾客的订单而已。类似的，

系统中检查库存的功能只关心库存文件的数据结构，而不关心在计算机中的具体存储方式。

软件需求的逻辑描述是软件设计的基础。

软件需求的物理视图给出处理功能和数据结构的实际表示形式，这往往是由设备决定

的，如一些软件靠终端键盘输入数据，另一些软件靠模拟数据转换设备提供数据。分析员必

须弄清系统元素对软件的限制并考虑功能和信息结构的物理表示。

4.软件需求分析方法

需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。大多数的

需求分析方法是山数据驱动的，也就是说，这些方法提供了一种表示数据域的机制。分析员

根据这种表示，确定软件功能及其他特性，最终建立一个待开发软件的抽象模型，即目标系

统的逻辑模型。数据域具有3种属性:数据流、数据内容和数据结构。通常，一种需求分析

方法总要利用其中的一种或几种属性。

目前已经出现了许多需求分析方法，每一种分析方法都引入了不同的记号和分析策略。

但是它们仍具有以下的共性：

（1）支持数据域分析的机制

尽管每种方法进行数据域分析的方式不同，但它们仍有一些共同点。所有的方法都宜接

或间接地涉及到数据流、数据内容或数据结构域的属性。在多数情况下，数据流特征是用将

输入转换成输出的变换（功能）过程来描述的，数据内容可以用数据词典机制明确表示，或

者通过描述数据或数据对象的层次结构隐含地表示。

（2）功能表示的方法

功能般用数据变换或加工来表示，每项功能可用规定的记号（圆圈或方框）标识。功

能的说明可以用自然语言文本来表达，也可以用形式化的规格说明语言来表达，还可以用上

述的两种方式的混合方式-----结构化语言来描述。

（3）接口的定义

接口的说明通常是数据表示和功能表示的直接产物。某个具体功能的流进和流出数据流

应是其他相关功能的流出或流入的数据流。因此，通过数据流的分析可以确定功能间的接口。

(4)问题分解的机制以及对抽象的支持

问题分解和抽象主要依靠分析员在不同抽象层次上表示数据域和功能域，以逐层细化的

手段建立分层结构来实现。例如，无论使用哪种分析方法，都能表示“计算职工每月工资”

之类的功能，并在这个抽象层次上操纵这个功能。另外，所有的分析方法都提供逐层分解的

机制，把“计算职工每月工资”功能划分成一些子功能，如计算房租、计算用电费、计算用水

费、计算养老保险费等等。其中，每项子功能还可以在更低的•级抽象层次上表示。

(5)逻辑视图和物理视图

大多数方法允许分析员在着手问题的逻辑解决方案之前先分析物理视图。通常，同一种

表示法既可用来表示逻辑视图，也可用来表示物理视图。

(6)系统抽象模型

为了能够比较精确地定义软件需求，可以建立待开发软件的一个抽象的模型，用基于抽

象模型的术语来描述软件系统的功能和性能，形成软件需求规格说明。这种抽象的模型是从

外部现实世界的问题领域抽象而来，在高级层次上描述和定义系统的服务。

对于比较简单的问题，不必建立抽象系统模型。或者可以认为，系统模型在分析员头脑

中形成，直接由分析员写成规格说明。但对于比较复杂的问题，仅有在头脑中想象的模型是

不够的，必须建立适当的比较形式化的抽象系统模型，才能准确全面地反映问题领域中各种

复杂的要求。不同类型的问题有不同的需要解决的中心问题，因而要建立不同类型的系统模

型。对于数学软件，设计的中心问题是算法，软件人员主要力量要花在数学模式算法的考虑

上。对于数据通信软件，中心问题是数据传送和过程控制，实现算法简单，采用数据流模型

比较合适。对于涉及大量数据的数据处理软件，中心问题是数据处理，包括数据的采集、数

据的传送、存储、变换、输出等，一旦了解了数据结构，与它相关的算法就很简单了。如果

系统要求有数据支持，通过数据库获取和存放信息，还需要考虑数据在数据库中的组织方式

和存取方法，建立数据库模型。因此，在分析过程中数据模型是首先要集中精力考虑的问题。

系统模型的建立是对现实世界中存在的有关实体和活动的抽象和精化，其建立过程包括

观察分析、模型表示和模型检查3个阶段。

首先，分析员和用户合作，从各方面观察现实世界中的有关实体和活动，建立理解的共

同基准，分清哪些概念与系统相关，必须纳入系统模型，哪些是系统模型不必关心的，分析

员和用户在共同理解的基础上，建立系统模型，包括系统提供的各种系统服务，模型表示的

细节应有:系统输入、系统输出、系统数据处理、系统控制等。

建立系统模型以后，还要进行检查。除了静态检查之外，系统描述可以部分地模拟执行,

将执行情况与对外部现实世界系统观察得到的系统跟踪信息进行对照，检查模型是否符合要

求。这种建立系统模型并模拟执行和检查的方法叫做系统原型开发。

■三级信息管理技术分章节考试要点：软件工程(结构化生命周

期方法之系统需求)

结构化生命周期方法

结构化分析与设计方法在软件工程中应用已很普遍，并且越来越成熟。有许多大、中型

项目都采用了这种方法进行开发并取得了显著的成果。

按B.W.Boehm的描述，瀑布模型的的软件生命周期可划分七个阶段:系统需求分析、软

件需求分析、概要设计、详细设计、编码、测试和运行维护。

(―)系统需求

“系统需求'’包括:问题定义、可行性研究及软件计划。

1.问题定义

软件开发的第一步就是进行问题定义。问题定义阶段必须回答的关键问题:“软件要解决

的问题是什么?''如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费

时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明

显的，但是在实践中它却可能是最常被忽视的一个步骤。这里所说的问题，就是指用户的基

本要求。说得通俗些，问题定义实际上就是了解用户到底要建立什么系统，并确定分析员下

一步应该做什么。因此，问题定义的来源是用户。

通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面

报告。这一阶段的分析员应尽可能站在较高的角度去抽象、概括所要干的事情，不要拘泥于

问题实现的细节。尽管用户可能总是习惯于这样做，但分析员在这一阶段必须超脱出来，居

高临下鸟瞰系统的全貌。通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要

地写出他对问题的理解，并在使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不

清的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。

当用户的要求不是很多并且不太复杂时，一两个分析员用上一两天就可以完成这一工作

了。但当系统比较大，且复杂时，恐怕就要组织一个问题定义小组，花上一两个星期，甚至

数月来定义用户的问题。

如果分析员和用户及使用部门的负责人对所要解决的问题取得完全一致的看法，而且使

用部门的负责人同意开发工程继续进行下去，那么开发工程将转入生命周期的下一个阶段一

——可行性研究。

2.可行性研究

并不是所有问题都有简单明显的解决办法，事实上，许多问题不能在预定的系统规模之

内解决。如果问题没有可行的解，那么花费在这项开发工程上的任何时间、资源、人力和经

费和都是无谓的浪费。

可行性研究的目的在于用最小的代价确定在问题定义阶段所确定的系统的目标和规模

是否现实，所确定的问题是否可以解决，系统方案在经济上、技术上和操作上是否可以接受。

可行性研究着重对如下具体方案考虑：

(1)经济可行性。估计开发费用以及新系统可能带来的收益，将两者进行权衡，看结

果是否可以接受。

(2)技术可行性。对要求的功能、性能以及限制条件进行分析，是否能够做成一个可

接受的系统。所考虑的因素通常还应包括开发的风险，是否能够得到需要的软件和硬件资源

和一个熟练的有能力的开发队伍，与系统开发有关的技术是否足以支持系统的研制。技术可

行性的估计，需要有经验的人员去完成。

(3)操作可行性。判断系统的操作方式在该用户组织内是否可行。

分析、设计人员应以新系统的目标和作用范围为依据提出一种以上的设计方案，从技术

可行性、经济可行性、操作可行性等方面进行比较，并选择出综合最优的方案。

Examda提示：根据可行性研究结果要做出的决定是:是否继续按预定目标进行这项开发

工程，可行性分析人员必须清楚地表明他对这个关键性决定的建议。如果认为值得继续进行

这项开发工程，则应提供选择一种最好的解法并说明理由。可行性分析是在问题的目标和约

束之间的一种权衡，还可能有的结果则是修改目标或放宽约束。

3.软件计划

分析人员应该为推荐的系统草拟一份软件计划，其中描述的是为了成功地进行一个软件

项目，其所需要做的工作、需要的资源、需要的工作量和费用以及应遵循的进度安排。

软件计划由两项任务组成:分析和估算。分析是对系统内各软件功能的界限的划定。估

算是指根据已有的定性数据和已往的经验对系统开发的资源、费用和进度进行定量的估计。

软件开发项目的进度安排可以从两种观点来考虑：是项目的交付日期已定，负责开发

工作的软件机构被限制在一个规定的时间范围内分配其工作量。二是项目最后的交付日期由

软件机构自己确定，可以从最佳的利用各种资源的角度出发来分配工作量，项目最后的交付

日期经过对软件各部分仔细分析后才确定。在多数项目中，遇到的往往是第一种情况。

软件计划的阅读者可以包括软件主管部门、用户和技术人员。所确定的成本与进度可供

主管部门复审。它同时也给出了整个软件生命周期的基本成本预算的进度安排。

■三级信息管理技术分章节考试要点：软件工程（软件测试之白

盒测试的测试用例设计）

白盒测试的测试用例设计

白盒测试是根据程序的内部逻辑来设计测试用例，常用的技术是逻辑覆盖，即考察用测

试数据运行被测程序时对程序逻辑的覆盖程度。主要的覆盖标准有6种:语句覆盖、判定覆

盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。

为了提高测试的效率，应选择最少的测试用例来满足指定的覆盖标准。

1.语句覆盖

Examda提示：语句覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程

序的每个语句至少执行一次。

2.判定覆盖

判定覆盖又称为分支覆盖。它是指选择足够的测试用例，使得运行这些测试用例时，每

个判定的所有可能结果至少出现一次（即判定的每个分支至少经过一次）。

3.条件覆盖

在软件设计过程中，一个判定往往山多个条件组成，判定覆盖仅考虑了判定的结果而没

有考虑每个条件的可能结果。

条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中的每个条件的所

有可能结果至少出现一次。

4.判定/条件覆盖

判定/条件覆盖是指选择足够的测试用例。使得运行这些测试用例时，判定中每个条件

的所有可能结果至少出现一次，并且每个判定本身的所有可能结果至少出现一次。

显然，满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖

标准。在某些程序的测试中，如果选择得好，判定覆盖、条件覆盖和判定/条件覆盖可以使

用相同的最少的测试用例。

5.条件组合覆盖

在条件覆盖中考虑了判定中每个条件的所有可能结果，但并未考虑条件的组合情况。条

件组合覆盖是指选择足够的测试用例，使得运行这些测试用例时，每个判定中条件结果的所

有可能组合至少出现一次。

Examda提示：由于条件组合覆盖使每个判定中条件结果的所有可能组合都至少出现一

次，因此判定本身的所有可能结果也•定至少出现一次，同时也使每个条件的所有可能结果

至少出现一次。因此，条件组合覆盖是上述5种覆盖标准中最强的一种。然而，条件组合覆

盖还不能保证程序中所有可能的路径都被覆盖。

6.路径覆盖

路径覆盖是指选择足够的测试用例，使得运行这些测试用例时.，程序的每条可能执行到

的路径都至少经过一次（如果程序中有环路，则要求每条环路至少经过一次）。

路径覆盖实际上是考虑了程序中各种判定结果的所有可能组合，但它并未考虑判定中的

条件结果的组合，因此它是•种比较强的覆盖标准,但并不能代替条件覆盖和条件组合覆盖。

■三级信息管理技术分章节考试要点：软件工程（软件测试之测

试步骤）

测试步骤

软件测试的主要步骤有单元测试、集成测试和确认测试。

1.单元测试（unittesting）

单元测试也称模块测试。通常单元测试可放在编码阶段，程序员在编写好一个模块后，

总会（也应该）对自己编写的模块进行测试，检查它是否实现了详细设计说明书中规定的模

块功能和算法。单元测试主要发现编码和详细设计中产生的错误，通常采用白盒测试。

测试一个模块时需要编写一个驱动模块和若干个桩（stub）模块，如下图所示。驱动模

块的功能是向被测试模块提供测试数据，驱动（即调用）被测模块，并从被测模块中接受测

试结果。桩模块的功能是模拟被模块所调用的子模块，它接受被测模块的调用，检验调用参

数，模拟被

调用的子模块功能，把结果送回给被测模块。在模块结构图中，顶层模块测试时不需要

驱动模块，最底层的模块测试时不需要桩模块。

2.集成测试(integrationtesting)

集成测试也称组装测试，它是对由各模块组装而成的程序进行测试，主要检查模块间的

接口和通信。集成测试主要发现设计阶段产生的错误，通常采用黑盒测试。

集成的方式可分成非渐增式集成和渐增式集成。非渐增式集成是先测试所有的模块，然

后把这些模块集成在一起对整个程序进行测试。渐增式集成是将单元测试和集成测试合并在

一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它同已经测试好的模块组

合在一起对整个程序进行测试，每次增加一个模块，直至所有模块全部集成在程序中。

渐增式集成又可分成自顶向下集成和自底向上集成。自顶向下集成先测试上层模块，再

测试下层模块。山于测试下层模块时它的上层模块已测试过，所以可以用其上层模块作为它

的驱动模块，而不必另编驱动模块。自底向上集成先测试下层模块，再测试上层模块。同样

道理，在自底向上集成时可用下层模块作为上层模块的桩模块，而不必另外编写桩模块。

3.确认测试(walidationtesting)

确认测试的任务是检查软件的功能、性能及其他特征是否与用户的需求一致，它是以需

求规格说明书(即需求规约)作为依据的测试。确认测试通常采用黑盒测试。

确认测试首先测试程序是否满足需求规格说明书所列的各项要求,然后要进行软件配置

复查，特别是文档是否齐全，各方面的质量是否符合要求等。如果一个软件是为某个客户定

制的，那么最后由客户来实施验收测试(acceptancetesting),以便客户确认该软件是否他

所需要的。如果一个软件是作为产品被许多客户使用的话，那不可能为每个客户进行验收测

试。大多数软件生产者使用一种Alpha测试和Beta测试的过程，来揭露仅由最终用户才能

发现的错误。

Alpha测试是在开发者的现场由客户来实施的，被测试的软件是在开发者从用户的角度

进行常规设置的环境下运行的。Beta测试是在一个或多个客户的现场由该软件的最终用户

实施的。与Alpha测试不同的是，Beta测试时开发者通常是不在场的。Alpha测试和Beta

测试除了进一步发现程序中的错误外，还能发现使用上的问题。经过确认测试后的软件通常

就可交付使用了。

■三级信息管理技术分章节考试要点：软件工程(软件测试之测

试的基本概念)

软件测试

在软件开发的一列活动中，为了保证软件的可靠性，人们研究并使用了很多方法进行分

析、设计及编码实现。但是由于软件产品本身无形态，它是复杂的、知识高度密集的逻辑产

品，其中不可能没有错误。物理产品在出厂前都要进行严格的检验，软件产品也不例外。软

件开发总伴随着软件质量保证的活动，而软件测试是主要活动之-»软件测试代表了需求分

析、设计、编码的最终复审。

测试是一项很艰苦的工作，其工作量约占软件开发总工作量的40%以匕特别对一些

关系到人的生命安全的软件，共测试成本可能相当于开发阶段总成本的3〜5倍。

（-）测试的基本概念

1.测试的目的

软件测试的目的是尽可能多地发现软件产品（主要是指程序）中的错误和缺陷。

明确测试的目的是•件非常重要的事，因为在现实世界中对测试工作存在着许多模糊或

者错误的看法，这些看法严重影响着测试工作的顺利进行。

有人认为测试是为了证明程序是正确的，也就是说程序不再有错误，事实证明这是不现

实的。因为要通过测试来发现程序中的所有错误就要穷举所有可能的输入数据，检查它们是

否产生正确的结果。例如，一个需要3个16位字长的整型输入数据的程序，输入数据的所

有组合情况大约有3x1014种，若每组数据的测试时间为1ms,那么即使一年365天，每

天24小时地测试，也大约需要1万年的时间。

2.测试用例

要进行测试，除了要有测试数据（或称输入数据）外，还应同时给出该组测试数据应该

得以怎样的输出结果，我们称它为预期结果。在测试时将实际的输出结果与预期结果比较，

若不同则表示发现了错误，因此测试用例是由测试数据和预期结果构成的。

为了发现程序中的错误，应竭力设计能暴露错误的测试用例。一个好的测试用例是极有

可能发现迄今为止尚未发现的错误的测试用例。一次成功的测试是发现了至今为止尚未发现

的错误的测试。

3.测试的原则

基于上述测试目的，我们可以考虑以下有关测试的原则：

（1）确定预期输出结果是测试用例必不可少的一部分。如果只有测试数据而无预期结

果，那么就不易判断测试结果是否正确。

（2）程序员应避免测试自己的程序，程序设计机构不应测试自己的程序。这是因为程

序中的错误往往是由于程序员对问题说明的误解，由他来测试自己的程序就不易找出因这种

误解而产生的错误。此外，开发程序是一项建设性的工作，而测试则是一项破坏性的工作（证

明程序有错），这对开发人员或机构来说在心理上一是难以容忍的。为了证明自己的程序没有

错误或错误很少，他们往往不去选择容易发现错误的测试用例，而选择容易通过的测试用例。

当然，这并不意味着程序员都不能测试自己的程序，如单元测试通常就是由程序员自己测试

的。

(3)彻底检查每个测试结果。如果不仔细检查测试结果，有些已经测试出来的错误也

可能被遗漏掉。

(4)对非法的非预期的输入数据也要像合法的和预期的输入数据•样编写测试用例。

(5)检查程序是否做了应做的事是成功的一半，另一半是看程序是否做了不该做的事。

(6)除了真正没有用的程序外，一定不要扔掉测试用例。因为在改正错误或程序维护

后还要进行重新测试。

(7)在规划测试时不要设想程序中不会查出错误。

(8)程序模块经测试后，残存的错误数目往往与已发现的错误数目成比例。实践证明，

程序中的大量错误仅与少量的程序模块有关，因此当A模块找出的错误比B模块多得多时，

很可能A模块残存的错误仍比B模块残存的错误多多。

4.白盒测试和黑盒测试

测试的关键是测试用例的设计，其方法可分成两类:白盒测试和黑盒测试。

白盒测试是把程序看成装在一只透明的白盒子里，测试者完全了解程序结构和处理过

程。它根据程序的内部逻辑来设计测试用例，检查程序中的逻辑通路是否都按预定的要求正

确地工作。黑盒测试是把程序看成一只黑盒子，测试者完全不了解(或不考虑)程序的结构

和处理过程。它根据规格说明书规定的功能来设计测试用例，检查程序的功能是否符合规格

说明的要求。

■三级信息管理技术分章节考试要点：软件工程(软件测试之黑

盒测试的测试用例设计简介)

黑盒测试的测试用例设计简介

黑盒测试是根据规格说明所规定的功能来设计测试用例，它不考虑程序中的内部结构和

处理过程。常用的黑盒测试技术有等价类划分、边值分析、错误猜测等。

1.等价类划分

提示:前面已经讲过，不能穷举所有可能的输入数据来进行测试，所以只能选取少量有

代表性的输入数据，来揭露尽可能多的程序错误。

这里首先要介绍一个有效的输入数据和无效的输入数据。有效的输入数据是指符合规格

说明要求的合理的输入数据，它主要用来检验程序是否实现了规格说明中的功能。无效的输

入数据是指不符合规格说明要求的不合理或非法的输入数据，它主要用来检验程序是否做了

规格说明以外的事。

Examda提示：如果把所有可能的输入数据（有效的和无效的）划分成若干个等价类，

那么可以合理地做出假定:如果等价类中的一个输入数据能检测出•个错误，那么等价类中

的其他输入数据也能检测出同一个错误;反之，如果一个输入数据不能检测出某个错误，那

么等价类中其他输入数据也不能发现这一错误（除非这个等价类的某个子集还属于另一等价

类）。

等价类划分方法首先把输入数据划分成若干个有效等价类和若干个无效等价类,然后设

计测试用例覆盖这些等价类。

2.边值分析

大量的实践说明，程序中在处理边界情况时出错的概率比较大，因此设计一些测试用例,

使程序运行在边界情况附近，这样揭露程序中错误的可能性就更大。

所谓边界条件是指相对于输入与输出等价类直接在其边界上，或稍高于其边界，或稍低

于其边界的这些状态条件。

使用等价类划分方法设计测试用例时，原则上讲，等价类中的任•输入数据都可作为该

等价类的代表用作测试用例。而边值分析则是专门挑选那些位于边界附近的值作为测试用

例。由于边值分析方法所设计的测试用例，更有可能发现程序中的错误，因此经常把边值分

析方法与其他设计测试用例方法结合起来使用。

3.错误猜测

错误猜测是•种凭直觉和经验推测某些可能存在的错误，从而针对这些可能存在的错误

设计测试用例的方法。这种方法没有机械的执行步骤，主要依靠直觉和经验。等级站收集整

理！

三级信息管理技术分章节考试要点：软件工程（软件管理确定工作范围和资源）

软件工程项目高质量高效率的完成与其他产品的工程项目一样，不仅取决于所采用的技术、

方法和工具，还决定于