下面关于软件测试模型的描述中，不正确的包括（21)。<br />①V模型的软件测试策略既包..

免费智能真题库 > 历年试卷 > 软件评测师 > 2010年下半年软件评测师上午试卷综合知识

第21题

知识点： H模型 V模型 W模型测试策略测试实施软件测试策略编码测试过程概要设计软件测试生命周期详细设计需求分析

关键词： V模型编码并发测试策略测试过程对象概要设计软件测试软件开发周期生命周期详细设计需求分析源代码正确性测试开发开发周期软件开发需求章/节：软件测试过程模型

下面关于软件测试模型的描述中，不正确的包括（21)。
①V模型的软件测试策略既包括低层测试又包括髙层测试，高层测试是为了源代码的正确性，低层测试是为了使整个系统满足用户的需求
②V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段
③W模型可以说是V模型自然而然的发展。它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试
④H模型中软件测试是一个独立的流程，贯穿产品的整个生命周期，与其他流程并发地进行
⑤H模型中测试准备和测试实施紧密结合，有利于资源调配

A. ①⑤

B. ②④

C. ③④

D. ②③

相关试题：软件测试过程模型

更多>

第48题 2009年上半年

42%

以下说法不正确的选项包括（48).
①软件测试不仅仅指测试的执行，还包括很多其他的活动
②软件测试是一个独立的流程，..

第54题 2012年下半年

30%

通用的风险分析表应包括（54）。
①风险问题②发生的可能性③影响的严重性 ④风险预测值⑤风险优先级

第47题 2009年上半年

39%

以下关于基于W原理的W模型的叙述中，（47）是错误的。


知识点讲解
· H模型 · V模型 · W模型 · 测试策略 · 测试实施 · 软件测试策略 · 编码 · 测试过程 · 概要设计 · 软件测试 · 生命周期 · 详细设计 · 需求分析

H模型

H模型建立

V模型和W模型均存在一些不妥之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在互相牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以，相应的测试之间也不存在严格的次序关系。同时，各层次之间的测试也存在反复触发、迭代和增量关系。其次，V模型和W模型都没有很好地体现测试流程的完整性。

为了解决以上问题，有专家提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

H模型应用

H模型的简单示意图如下图所示。

软件测试H模型

这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程自身。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。

概括地说，H模型揭示了：

. 软件测试不仅仅指测试的执行，还包括很多其他的活动。

. 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

. 软件测试要尽早准备，尽早执行。

. 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

V模型

V模型是最具有代表意义的测试模型，如下图所示。V模型最早是由Paul Rook在20世纪80年代后期提出的，V模型在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果。

在传统的开发模型中，比如瀑布模型，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时测试工作会占用整个项目周期一半的时间，但是有人仍然认为测试只是一个收尾工作，而不是主要的过程。V模型的推出就是对此种认识的改进。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如模型图（下图）中所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

软件测试V模型

V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。

V模型指出，单元和集成测试是验证的程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。

V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。

W模型

W模型建立

V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是与此相并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE std 1012-1998《软件验证和确认（V&V）》的原则。

一个基于V&V原理的W模型示意图如下图所示。

软件测试W模型

W模型应用

W模型由Evolutif公司提出，相对于V模型，W模型更科学。W模型可以说是V模型自然而然的发展。它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。这样，只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。

如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地面对规格说明书的挑战。这意味着测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。

根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例，这些工作对测试的各级别都有意义。当需求被提交后，就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后，就需要确定测试条件来查找该阶段的设计缺陷。

W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充，或者根本没有文档的做法下（这已成为一种开发的文化），开发人员和测试人员都面临同样的困惑。

测试策略

由于标准符合性测试的不同分类，其相应的测试原理也不尽相同。

数据内容类标准

如《教育管理信息化标准》（第1部分《学校管理信息标准》），在测试工具设计上，其实现原理如下所示。

. 将符合标准的信息集（表结构）与代码集（表内容）构建在测试工具数据库中，即建立标准模板；

. 测试工具通过ODBC、JDBC等数据库连接方式连接被测软件的数据库；

. 测试工具提供人工或自动方式建立模板库与被测库之间的关联，读取并验证相关数据表信息；

. 生成信息集与代码集标准符合性检测结果报告。

注意，在实际应用中，从易维护的角度出发，被测软件的代码集可能不是多个不同类别的小代码表集，而是一个包含各种类别的大代码表，但测试工具模板库往往是多个不同类别的小代码表集，这就要求测试工具能够实现一对多或多对多的关联设置。

而对于检察机关网络应用软件的数据格式规范与代码符合性规范的测试工具，可采用网上已有的相关工具或自行开发。如数据格式规范测试可辅助采用已有的XML解析器进行，而代码符合性规范可采取自行开发测试工具方式执行，测试步骤包括工具中建立标准模板、连接被测软件、与标准模板比对测试和输出测试结果。

通信协议类标准

测试工具的实现原理与第一类标准基本相似，如中国远程教育CELTS-20教学管理标准中的，基于HTTP协议绑定规范的，测试工具可以这样实现：①建立标准模拟课件；②导入模拟课件到被测平台；③测试工具自动运行模拟课件，主动与被测平台进行数据通信；④将二者通信内容与工具中的标准模板内容进行比较，得出比较分析结果。

开发接口类标准

SQL标准符合性测试

按照SQL92/97标准，全面测试一个SQL产品的功能特性。在详细研究美国标准技术研究所（NIST）的测试用例库（即在整个测试过程中，只需要执行全部的测试用例文件，最后统计通过的测试用例即可）的基础上，可自行开发一个集测试和结果的定量分析于一体的自动化测试工具，利用该测试工具可以直接选择被测文件，运行并统计运行的结果。

通过的入门级测试用例数占入门级测试用例总数的比例，即为入门级测试通过率。通过的过渡级测试用例数占过渡级测试用例总数的比例，即为过渡测试通过率。

为了保证测试结果的真实性，还可采用交互式测试用例验证测试结果，如果发现问题，则相应的嵌入式测试用例的结果视为不通过。

ODBC标准

可采用SWsoft Inc开发的ODBC2.5标准符合性测试工具进行测试。在此基础上，按照ODBC3.0标准对测试用例进行相当规模的修改和扩充，并且将微软的QUICK TEST测试工具的部分模块集成到该测试工具中，同时对测试结果进行了定量的分析。

其中，对API函数的测试，参照微软的测试工具（QuickTest）对每个函数选定一种最简单的参数组合来测试，仅用其作简单的支持性测试。此项测试根据通过测试的函数的百分比来计算。对于其他的更重要的应用功能，是通过其他更详细、更复杂的测试用例来验证的，其执行结果的成功与否直接记录为测试结果。

JDBC标准

可在SUN公司开发的JDBC标准符合性测试工具基础上，按照JDBC3.0标准对测试用例进行修改和扩充，同时加入对测试结果的定量分析功能。

JDBC标准符合性测试完成后，统计各个接口或类中API函数通过的测试用例点的数量，按用例通过的比例和每个类或接口所占的权值计算总体得分。

信息编码类标准

例如，对GB 18030中文符合性测试，包括字汇完整性和体系正确性两方面。

对于字汇完整性可采用抽样测试的方法，其过程如下。

. 生成标准测试文件。即依照GB 18030的字符集生成字符数据文件（如.TXT），包括GB 18030中定义的全部汉字区、符号区、保留区和用户自定义区。

. 运行被测软件，打开已生成的标准文本文件，将屏幕显示内容与GB 18030中指定内容进行对比，记录屏幕显示对比结果。

. 运行待测软件，打开已生成的文本文件并打印其内容，将打印结果与GB 18030中指定内容进行对比，记录打印对比结果。

. 抽样对比。例如：抽样方法可定义为单字节抽样率达到100%，双字节1区抽样率达到约20%，双字节2区抽样率达到约15%，双字节3区抽样率达到约10%，双字节4区抽样率达到约5%，双字节5区抽样率达到约20%和四字节区抽样率达到约5%。抽样范围包括边界字符和中间随机字符，如有错误则抽样率加倍，直至抽样率达到100%。各区矩阵的抽样率均应达到100%。抽样对比测试办法如下：单字节区，逐字对比。双字节1～5区，以第一字节相同的所有字符构成一个矩阵为一个检查单位，每矩阵抽查第一个字符、最后一个字符，在其他字符中按前述抽样率随机抽查数个字符，如果被抽样字符中出现对比结果不符合现象，或发现明显的“？”、方框、连续空白，则按前述抽样方法进行。双字节用户区1～3，与用户文档中承诺的用户自定义字符列表或用户自定义界面的输入结果进行对比，抽样率为10%；如没有用户自定义字符，则应不显示字符。四字节区，每区抽查第一个字符、最后一个字符，在其他字符中随机抽查数个字符（区抽样率≥5%），如果被测字符中出现对比结果不符合现象，或发现明显的“？”、方框、空白，则对比整个矩阵。

对于体系正确性测试，其测试过程包括：

. 生成随机文件，即从GB 18030定义的全部字符中随机抽取，而形成的大于5000字符的文本。文本中包括单字节区、各双字节区、四字节区中的字符，所有字符随机组合。

. 编辑处理，即在被测的软件平台上，将已生成的随机文件打开，并进行编辑处理，包括插入字符、删除字符、存储字符、复制粘贴、打印等操作，各类操作均包括单字节区、各双字节区、四字节区中的字符。

. 记录结果，即记录编辑处理文本文件的结果。

对于字汇完整性，符合以下所有条件的，字汇完整性成绩为通过，其他情况为不通过。

. 单字节区显示和打印的符合率均等于100%。

. 双字节各区显示和打印的符合率均大于98%。

. 四字节区显示和打印的符合率均大于97%。

对于体系正确性，插入字符、删除字符、存储字符、复制粘贴、打印等编辑操作处理正确为通过，出现乱字符、多字符、丢字符或其他影响编辑操作的处理结果为不通过。只有在字汇完整性与体系正确性的成绩均为通过时，总成绩为通过。其他情况为不通过。

目前，由于GB 18030的测试主要依靠人工验证，所以测试过程相对繁琐一些。

测试实施

标准符合性测试工具与一般功能和负载压力测试工具有着明显的不同，它是为明确的应用对象和测试目的服务的，具有更强的针对性，应用范围相对而言更具体、更狭隘一些。标准符合性测试的基本原理，就是将被测软件产品的功能与性能指标，和标准规定必须满足的功能和性能指标进行比较，从而确定软件产品对标准的符合程度。

一般来说，标准符合性测试可以按以下步骤实施。

①阅读和理解标准：很多人可能不理解或者不认为应该将它归为标准符合性测试的第一步，但它确实是实施有效的标准化符合性测试的前提。因为，大多数情况下制定标准和进行标准符合性测试的不是同一组人，因此，在测试正式开始之前，首先就必须很好地阅读并理解标准的目的、意义、范围和具体的指标内容，否则测试结果就会产生偏差。

②确定测试工具：标准符合性自动化测试一般需要依靠特定的测试工具来完成，可以选择适当的商业化测试工具，也可以根据情况决定自主开发相应的测试工具。如前所述，由于标准具有特定性，所以大多数情况下，针对标准的符合性测试工具，需要测试组自行开发或者修改已有的测试工具。如果需要开发测试工具，则必须执行一个严格的开发流程，确保测试工具本身的正确性和有效性。

③确定用例文件：对于测试标准并不包含测试用例的，测试组需要根据标准规定的格式定义各种测试用例，当然应该包含正常的和异常的测试用例。

④执行用例文件：确定了相应的测试工具和测试用例后，就可以执行测试并记录测试执行的结果。

⑤分析测试结果：“标准符合性”顾名思义应该就有一个测试结果基准库，通常情况下，它规定了输入与输出的对应关系，标准符合性的测试过程就是将测试用例（被测产品）的输入输出与基准库定义的输入输出相比较，从而对与标准不一致的输入输出进行统计分析，确定测试结果以及被测产品对标准的符合程度。

在测试结果的分析与评价上主要有两种形式：一种认为要全部符合标准才算通过，即Yes or No方式；一种则通过测试符合标准的程度来判定，如认为80%以上的符合率即为基本符合标准。

正是信息技术的深入发展，及相关应用间方便快捷地进行通信和数据交换的迫切需要，使得信息技术标准化和标准符合性测试的重要性日益凸现。

在实际应用中，根据不同的层面，对标准的分类有多种方式，这里仅从信息技术不同标准的内容划分为主要的四类，并就相应常用的测试原理进行了阐述。

标准的价值在于应用。因此，如何准确高效地实施测试、衡量标准的应用是重要的环节。第三方测试机构代表国家对相关产品及相关设备进行评测的过程中，也是严格依据标准本身对产品进行标准符合性测试的，这必将进一步推动我国信息技术标准化建设更上新的台阶。

软件测试策略

测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试和系统测试。如下图所示显示出软件测试经历的4个步骤。

软件测试的过程

开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。然后，把已测试过的模块组装起来，进行集成测试（组装测试），主要对与设计相关的软件体系结构的构造进行测试。为此，在将一个一个实施了单元测试并确保无误的程序模块组装成软件系统的过程中，对正确性和程序结构等方面进行检查。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。最后是系统测试，把已经经过确认的软件纳入实际运行环境中，与其他系统成分组合在一起进行测试。严格地说，系统测试已超出了软件工程的范围。

测试信息流

测试信息流如下图所示。测试过程需要以下三类输入。

测试信息流

软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。

测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程中，测试配置只是软件配置的一个子集。

测试工具：为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。

测试之后，要对所有测试结果进行分析，即将实测的结果与预期的结果进行比较。如果发现出错的数据，就意味着软件有错误，就需要开始排错（调试）。即对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。

排错的过程是测试过程中最不可预知的部分，即使是一个与预期结果只相差0.01%的错误，也可能需要花上一个小时、一天、甚至一个月的时间去查找原因并改正错误。也正是因为排错中的这种固有的不确定性，使得我们很难确定可靠的测试进度。

通过收集和分析测试结果数据，开始针对软件建立可靠性模型。如果经常出现需要修改设计的严重错误，那么软件质量和可靠性就值得怀疑，同时也表明需要进一步测试。如果与此相反，软件功能能够正确完成，出现的错误易于修改，那么就可以断定：或者是软件的质量和可靠性达到可以接受的程度，或者是所作的测试不足以发现严重的错误。如果测试发现不了错误，那么几乎可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用过程中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40~60倍。

分析设计阶段

分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。下述章节将详细论述。

需求说明书评测

由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。

因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。

什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。

. 编制良好的需求说明书8条原则。

1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。

原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。

原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。

原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。

原则4：规格说明必须包括系统运行的环境。

原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。

原则7：规格说明必须容许不完备性并允许扩充。

原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。

尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其他各种形式的规格说明都适用。当然要结合实际来应用上述的原则。

. 需求说明书的框架。

需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。如下表中列出了需求说明书的框架。

需求说明书的框架

. 需求说明书评测内容。

需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：

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

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

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

④与所有其他系统成份的重要接口是否都已经描述；

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

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

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

⑧软件的行为和它必须处理的信息、必须完成的功能是否一致；

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

⑩是否考虑了开发的技术风险；

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

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

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

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

?用户是否审查了初步的用户手册或原型；

?项目开发计划中的估算是否受到了影响。

为保证软件需求定义的质量，评测应由专门指定的人员负责，并按规程严格进行。评审结束，应有评审负责人的结论意见及签字。除承建单位分析员之外，业主单位人员和测试单位都应当参加评测工作。需求说明书要经过严格评测，一般，评测的结果都包括了一些修改意见，待修改完成后再经评测，才可进入设计阶段。根据上述讨论的评测内容，可以制定需求说明书评测规范，如下表所示。

填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

需求说明书评测规范

在需求说明书评测结束后，测试单位应将评测意见以专题报告的形式提交业主单位。

概要设计说明书评测

. 设计说明书的框架。如下表所示为软件设计规格说明的大纲。

软件设计规格说明大纲

软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列设计质量的评测，以便及时发现和解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。

. 概要设计说明书评测的内容。

①可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成份是否可追溯到某一项需求。

②接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。

③风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。

④实用性：即确认该软件设计对于需求的解决方案是否实用。

⑤技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。

⑥可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。

⑦质量：即确认该软件设计是否表现出良好的质量特征。

⑧各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。

⑨限制：评估对该软件的限制是否现实，是否与需求一致。

⑩其他具体问题：对于文档、可测试性、设计过程等进行评估。

在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。

为评测设计是否达到目标，必须建立衡量设计的技术标准。如下：

①设计出来的结构应是分层结构，从而建立软件成分之间的控制。

②设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。

③设计应当既包含数据抽象，也包含过程抽象。

④设计应当建立具有独立功能特征的模块。

⑤设计应当建立能够降低模块与外部环境之间复杂连接的接口。

⑥设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。

根据上述讨论的评测内容以及评测标准，可以建立概要设计说明书评测规范，如下表所示。

填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

概要设计说明书评测规范

详细设计说明书评测

详细设计说明书的评测标准和评测内容与概要设计说明书基本相同，这里不再赘述。如下表所示为详细设计说明书评测规范。

填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

详细设计说明书评测规范

软件编码规范评测

程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。下面分别论述评测内容以及相应的评测标准。

. 源程序文档化。

①符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。

名字不是越长越好，应当选择精炼的、意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。

②程序的注释。夹在程序中的注释是程序员日后与程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。注释分为序言性注释和功能性注释。

序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其他有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。

功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：描述一段程序，而不是每一个语句；用缩进和空行，使程序与注释容易区别；注释要正确。

③标准的书写格式。视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中的程序段语句向右作阶梯式移行。使程序的逻辑结构更加清晰。

. 数据说明。

在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。

①数据说明的次序应当规范化。数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。

②说明语句中变量安排有序化。当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。

③使用注释说明复杂数据结构。如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。

. 语句结构。

在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。

比如：在一行内只写一条语句；程序编写首先应当考虑清晰性；程序要能直截了当地说明程序员的用意；除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；首先要保证程序正确，然后才要求提高速度，反过来说，在使程序高速运行时，首先要保证它是正确的；避免使用临时变量而使可读性下降；对编译程序做简单的优化；尽可能使用库函数；避免不必要的转移；尽量采用基本的控制结构来编写程序；避免采用过于复杂的条件测试；尽量减少使用“否定”条件的条件语句；尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；数据结构要有利于程序的简化；程序要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见；利用信息隐蔽，确保每一个模块的独立性；从数据出发去构造程序；不要修补不好的程序，要重新编写。

. 输入和输出

输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入/输出风格还受到许多其他因素的影响。如输入/输出设备（终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。

①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；

②检查输入项的各种重要组合的合理性，必要时报告输入状态信息；

③使输入的步骤和操作尽可能简单，并保持简单的输入格式；

④输入数据时，应允许使用自由格式输入；

⑤应允许缺省值；

⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；

⑦在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；

⑧当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性；

⑨给所有的输出加注解，并设计输出报表格式。

开发阶段

单元测试

单元测试又称模块测试，是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

. 单元测试的内容。

在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。

在单元测试中进行的测试工作如下图所示，需要在五个方面对所测模块进行检查。

单元测试的工作

①模块接口测试。

在单元测试的开始，应对通过所测模块的数据流进行测试。如果数据不能正确地输入和输出，就谈不上进行其他测试。为此，对模块接口可能需要如下的测试项目：调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；是否修改了只作输入用的形式参数；输出给标准函数的参数在个数、属性、顺序上是否正确；全局量的定义在各模块中是否一致；限制是否通过形式参数来传送。

当模块通过外部设备进行输入/输出操作时，必须附加如下的测试项目：文件属性是否正确；OPEN语句与CLOSE语句是否正确；规定的I/O格式说明与I/O语句是否匹配；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写/输入错误，以及I/O错误是否检查并做了处理。

②局部数据结构测试。

模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误：不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量；错误的初始值或错误的缺省值；变量名拼写错或书写错；不一致的数据类型。可能的话，除局部数据之外的全局数据对模块的影响也需要查清。

③路径测试。

由于通常不可能做到穷举测试，所以在单元测试期间要选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试，可以发现大量的路径错误。

常见的不正确计算有：运算的优先次序不正确或误解了运算的优先次序；运算的方式错，即运算的对象彼此在类型上不相容；算法错；初始化不正确；运算精度不够；表达式的符号表示不正确。

常见的比较和控制流错误有：不同数据类型的相互比较；不正确的逻辑运算符或优先次序；因浮点数运算精度问题而造成的两值比较不等；关系表达式中不正确的变量和比较符；“差1”错，即不正确地多循环一次或少循环一次；错误的或不可能的循环中止条件；当遇到发散的迭代时不能中止的循环；不适当地修改了循环变量等。

④错误处理测试。

比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。这种出错处理也应当是模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。

⑤边界测试。

在边界上出现错误是常见的。例如，在一段程序内有一个n次循环，当到达第n次重复时就可能会出错。另外，在取最大值或最小值时也容易出错。因此，要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。

此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。

虽然模块测试通常是由编写程序的人自己完成的，但是项目负责人应当关心测试的结果。所有测试用例和测试结果都是模块开发的重要资料，必须妥善保存。

总之，模块测试针对的程序规模较小，易于查错；发现错误后容易确定错误的位置，易于排错，同时多个模块可以并行测试。做好模块测试可为后续的测试打下良好的基础。

. 单元测试的步骤。

通常单元测试是在编码阶段进行的。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。

模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：

驱动模块（driver）——相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实测结果。

桩模块（stub）——也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

所测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如下图所示。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产品的一部分一同交付，而且它们的编写需要一定的工作量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了能够正确地测试软件，桩模块可能需要模拟实际子模块的功能，这样，桩模块的建立就不是很轻松了。

单元测试的测试环境

模块的内聚程度高，可以简化单元测试过程。如果每一个模块只完成一种功能，则需要的测试用例数目将明显减少，模块中的错误也容易被预测和发现。

当然，如果一个模块要完成多种功能，且以程序包（package）的形式出现的也不少见，这时可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

集成测试

集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

. 组装时需要考虑的问题。

①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

②一个模块的功能是否会对另一个模块的功能产生不利的影响；

③各个子功能组合起来，能否达到预期要求的父功能；

④全局数据结构是否有问题；

⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。

因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。

子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。

选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。

. 模块组装成为系统的方式。

模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。

①一次性组装方式（big bang）。

它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。

一次性组装方式

在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。

②增殖式组装方式。

这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。

. 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。

自顶向下的增殖方式

自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。

. 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。

以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。

一次性组装方式

自底向上的增殖方式

. 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。

自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。

自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。

在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：

. 满足某些软件需求；

. 在程序的模块结构中位于较高的层次（高层控制模块）；

. 较复杂、较易发生错误；

. 有明确定义的性能要求。

在做回归测试时，也应该集中测试关键模块的功能。

. 集成测试的组织和实施。

集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：

①采用何种系统组装方法来进行集成测试。

②集成测试过程中连接各个模块的顺序。

③模块代码编制和测试进度是否与集成测试的顺序一致。

④测试过程中是否需要专门的硬件设备。

解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。

在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。

. 集成测试完成的标志。

集成测试完成的标志主要有以下几项。

①成功地执行了测试计划中规定的所有集成测试。

②修正了所发现的错误。

③测试结果通过了专门小组的评审。

集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。

在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。

集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。

确认测试

确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查，确认测试一般由独立的第三方测试机构进行。

. 进行有效性测试。

有效性测试是在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。为此，需要制定测试计划、测试步骤以及具体的测试用例。通过实施预定的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到。所有的文档都是正确且便于使用的。同时，对其他软件需求，例如可移植性、可靠性、易用性、兼容性、可维护性等，也都要进行测试，确认是否满足。

在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类。

①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而接受了这部分程序。

②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。

. 软件配置复查。

软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。

在确认测试的过程中，还应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查文档资料的完整性和正确性。

系统测试

系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行（使用）环境下，对计算机系统进行一系列测试。

系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。

验收测试

验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试。

目前在国内实际软件开发，特别是系统集成的过程中，验收测试往往在系统测试完成后、项目最终交付前进行。验收测试的测试计划、测试方案与测试案例一般由开发方制定，由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与确认测试及系统测试不同的是，验收测试往往不是对系统的全覆盖测试，而是针对用户的核心业务流程进行的测试；同时，测试的执行人员也不是开发方的测试组成员，而是由用户方的使用人员完成。

近年来，越来越多的开发方及用户方认识到对项目进行最终验收测试的重要意义，因此，由第三方完成的专业化全覆盖型技术测试得到了广泛应用。由专门从事测试工作的第三方机构，根据系统的需求分析、用户手册、培训手册等，在开发人员及最终使用人员的配合下，完成对系统全面的测试工作。

软件验证与确认（V&V）过程

软件的验证与确认（V&V）是贯穿软件生命周期的重要的质量保证过程，国际标准化组织IEEE在1986年颁布了软件V&V标准，又于1998年修订颁布了IEEE/ANSI Std 1012-1998软件验证与确认计划。标准规定了软件验证和确认过程（简称V&V）和软件验证和确认计划（简称SVVP）编制要求。我国软件验证与确认（V&V）的国家标准也即将颁布实施，将在我国软件的质量保证和软件测试的工作中发挥重要作用。

软件的V&V过程是确定按照规定的软件过程开发的产品是否符合活动的要求，软件是否满足它的预期用途和用户需要。软件的V&V过程包括软件产品和过程的分析、评价、评审、审核、评估和测试。

软件测试活动是软件V&V过程的一个组成部分。软件测试过程的任务与管理也要符合软件V&V过程的有关规定。下面重点介绍软件V&V中的测试过程与管理。

V&V基本概念

. 验证（Verification）：通过检查和提供客观证据，证实规定的需求已满足。

. 确认（Validation）：通过检查和提供客观证据，证实预期用途的需求是否得到满足。

. 独立验证和确认（IV&V Independent Verification and Validation）：由在技术、管理和财务上与开发组织有规定程度独立性的组织执行的V&V过程。

V&V框架是由与软件开发过程同步的V&V过程、各阶段的V&V活动和任务组成的，如下图所示。

V&V结构

对每个V&V活动都规定了它的输入、任务和输出，如下图所示。

V&V活动过程

软件V&V过程

. 软件生存周期的V&V过程框架。

整个软件生存周期的V&V过程框架结构描述了各阶段的V&V过程、活动和任务的层次关系，如下图所示。

V&V过程、活动和任务的层次关系

. 软件开发过程的V&V概述。

IEEE Std 1012-1998中开发过程的V&V，如下图所示。

软件开发过程的V&V

软件V&V过程中的测试

. 测试过程。

GB/T 18905.5中规定的开发过程中的软件测试过程包括：测试计划过程、测试设计过程、测试执行过程和测试结束过程。如下图所示。

软件测试过程

. 需求V&V活动中的测试。

需求V&V活动中有两项测试任务：系统V&V测试计划生成和验证、验收V&V测试计划生成和验证。两项V&V的任务、输入和输出如下表所示。

需求V&V活动中的测试任务、输入和输出

. 设计V&V活动中的测试。

设计V&V活动中有三项测试任务：单元V&V测试计划生成和验证、集成V&V测试计划生成和验证与V&V测试计划生成和验证。三项V&V的任务、输入和输出如下表一和如下表二所示。

设计V&V活动中的测试任务、输入和输出

设计V&V活动中的测试任务、输入和输出（续）

. 实现V&V活动中的测试。

实现V&V活动中有三项测试任务：V&V测试用例生成和验证、V&V测试规程生成和验证以及部件V&V测试计划执行和验证。三项V&V的任务、输入和输出如下表所示。

实现V&V活动中的测试任务、输入和输出

软件测试V&V活动

测试V&V活动覆盖了集成测试、系统测试和验收测试。测试V&V活动及它与软件生存期的关系如下图所示。V&V的目标是确保通过执行集成测试、系统测试和验收测试使软件需求和分配给软件的系统需求得到满足。

V&V测试产品和测试执行任务的时段图

测试的V&V工作应生成自己的V&V测试件（包括计划、设计、用例和规程），执行并记录自己的测试，并对照软件需求验证测试计划、设计、用例、规程和结果；测试的V&V工作应验证测试活动和测试件（包括计划、设计、用例、规程和执行结果）。测试V&V活动的任务、输入与输出的关系如下表一和如下表二所示。

测试V&V活动中的测试任务、输入和输出

测试V&V活动中的测试任务、输入和输出（续）

编码

编码过程

在给定了软件设计规格说明书后，下一步的工作就是编写代码。一般来说，编码工作可以分为四个步骤：

（1）确定源程序的标准格式，制订编程规范。

（2）准备编程环境，包括软硬件平台的选择，包括操作系统、编程语言、集成开发环境等。

（3）编写代码。

（4）进行代码审查，以提高编码质量。为提高审查的效率，在代码审查前需要准备一份检查清单，并设定此次审查须找到的bug数量。在审查时，要检查软件规格说明书与编码内容是否一致；代码对硬件和操作系统资源的访问是否正确；中断控制模块是否正确等。

编码准则

在嵌入式系统中，由于资源有限，且实时性和可靠性要求较高，因此，在开发嵌入式软件时，要注意对执行时间、存储空间和开发／维护时间这三种资源的使用进行优化。也就是说，代码的执行速度要越快越好，系统占用的存储空间要越小越好，软件开发和维护的时间要越少越好。

具体来说，在编写代码时，需要做到以下几点：

.保持函数短小精悍。一个函数应该只实现一个功能，如果函数的代码过于复杂，将多个功能混杂在一起，就很难具备可靠性和可维护性。另外，要限制函数的长度，一般来说，一个函数的长度最好不要超过100行。

.封装代码。将数据以及对其进行操作的代码封装在一个实体中，其他代码不能直接访问这些数据。例如，全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性，提高了对象的内聚性，使封装后的代码对其他行为的依赖性较小。

.消除冗余代码。例如，将一个变量赋给它自己，初始化或设置一个变量后却从不使用它，等等。研究表明，即使是无害的冗余也往往和程序的缺陷高度关联。

.减少实时代码。实时代码不但容易出错、编写成本较高，而且调试成本可能更高。如果可能，最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。

.编写优雅流畅的代码。

.遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜，而且能捕捉到通过传统测试检查不到的各种问题。

编码技术

编程规范

在嵌入式软件开发过程中，遵守编程规范，养成良好的编程习惯，这是非常重要的，将直接影响到所编写代码的质量。

编程规范主要涉及的三方面内容：

.命名规则。从编译器的角度，一个合法的变量名由字母、数字和下画线三种字符组成，且第一个字符必须为字母或下画线。但是从程序员的角度，一个好的名字不仅要合法，还要载有足够的信息，做到“见名知意”，并且在语意清晰、不含歧义的前提下，尽可能地简短。

.编码格式。在程序布局时，要使用缩进规则，例如变量的定义和可执行语句要缩进一级，当函数的参数过长时，也要缩进。另外，括弧的使用要整齐配对，要善于使用空格和空行来美化代码。例如，在二元运算符与其运算对象之间，要留有空格；在变量定义和代码之间要留有空行；在不同功能的代码段之间也要用空行隔开。

.注释的书写。注释的典型内容包括：函数的功能描述；设计过程中的决策，如数据结构和算法的选择；错误的处理方式；复杂代码的设计思想等。在书写注释时要注意，注释的内容应该与相应的代码保持一致，同时要避免不必要的注释，过犹不及。

性能优化

由于嵌入式系统对实时性的要求较高，因此一般要求对代码的性能进行优化，使代码的执行速度越快越好。以算术运算为例，在编写代码时，需要仔细地选择和使用算术运算符。一般来说，整数的算术运算最快，其次是带有硬件支持的浮点运算，而用软件来实现的浮点运算是非常慢的。因此，在编码时要遵守以下准则：

.尽量使用整数（char、short、int和long）的加法和减法。

.如果没有硬件支持，尽量避免使用乘法。

.尽量避免使用除法。

.如果没有硬件支持，尽量避免使用浮点数。

下图是一个例子，其中两段代码的功能完全一样，都是对一个结构体数组的各个元素进行初始化，但采用两种不同的方法来实现。下图（a）采用数组下标的方法，在定位第i个数组元素时，需要将i乘以结构体元素的大小，再加上数组的起始地址。下图（b）采用的是指针访问的方法，先把指针fp初始化为数组的起始地址，然后每访问完一个数组元素，就把fp加1，指向下一个元素。在一个奔腾4的PC上，将这两段代码分别重复10 700次，右边这段代码需要1ms，而左边这段代码需要2.13ms。

算术运算性能优化的例子

测试过程

软件测试过程一般包括：测试需求分析、测试策划、测试设计和实现、测试执行、测试总结（包括评价过程和总结），如下图所示。

软件测试过程

测试需求分析

根据被测软件的需求规格说明或设计文档，进行测试需求分析，包括：

（1）确定需要的测试类型及其测试要求并进行标识（编号），标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试级别（单元测试、部件测试、配置项测试、系统测试）、测试类型相匹配。

（2）确定每个测试项的优先级。

（3）确定每个测试项的测试充分性要求。

（4）根据被测软件的重要性、测试目标和约束条件，确定每个测试项应覆盖的范围及范围所要求的覆盖程度。

（5）确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。

（6）确定测试项与软件需求规格说明或设计文档的追踪关系。

将测试需求分析结果按所确定的文档要求，形成测试需求规格说明或写入测试计划。

应对测试需求规格说明或测试需求分析结果进行评审，评审内容如下：

（1）测试级别和测试对象所确定的测试类型及其测试要求是否恰当。

（2）每个测试项是否进行了标识，并逐条覆盖了测试需求和潜在需求。

（3）测试类型和测试项是否充分。

（4）测试项是否包括了终止要求。

（5）文档是否符合规定的要求。

测试策划

根据软件需求规格说明或设计文档等进行测试策划，策划一般包括：

（1）确定测试策略，如部件或配置项测试策略。

（2）确定测试需要的技术或方法，如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术。

（3）确定要受控制的测试工作产品，列出清单。

（4）确定用于测试的资源要求，包括软硬件设备、环境条件、人员数量和技能等要求。

（5）进行测试风险分析，如技术风险、人员风险、资源风险和进度风险等。

（6）确定测试任务的结束条件。

（7）确定被测软件的评价准则和方法。

（8）确定测试活动的进度。应根据测试资源和测试项，确定进度。

应将测试策划结果，按所确定的文档要求形成测试计划。

测试设计和实现

应根据测试需求规格说明和测试计划进行测试设计和实现，应完成如下工作：

（1）按需要分解测试项。将需要测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有接口和要测试的接口。

（2）说明最终分解后的测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等。

（3）设计测试用例。

（4）确定测试用例的执行顺序。

（5）准备和验证所有的测试用数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等。

（6）准备并获取测试资源，如测试环境所必须的软、硬件资源等。

（7）必要时，编写测试执行需要的程序，如开发部件测试的驱动模块和桩模块以及测试支持软件等。

（8）建立和校核测试环境，记录校核结果，说明测试环境的偏差。

应将测试设计与实现的工作结果，按照所确定的文档要求编写测试说明，测试说明一般应包括：

（1）测试名称和项目标识。

（2）测试用例的追踪。说明测试所依据的内容来源，并跟踪到相应的测试项的标识（编号）。

（3）测试用例说明。简要描述测试的对象、目的和所采用的测试方法。

（4）测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置）等的初始化要求。

（5）测试用例的输入。每个测试用例输入的描述中应包括的内容：

①每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）。

②测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）。

③测试输入是真实的还是模拟的。

④测试输入的时间顺序或事件顺序。

（6）测试用例的期望测试结果。期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不确切的概念或笼统的描述。必要时，应提供中间的期望结果。

（7）测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息，如：

①实际测试结果所需的精确度。

②允许的实际测试结果与期望结果之间差异的上、下限。

③时间的最大或最小间隔。

④事件数目的最大或最小值。

⑤实际测试结果不确定时，重新测试的条件。

⑥与产生测试结果有关的出错处理。

⑦其他有关准则。

（8）实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括：

①每一步所需的测试操作动作、测试程序输入或设备操作等。

②每一步期望的测试结果。

③每一步的评估准则。

④导致被测程序执行终止伴随的动作或指示信息。

⑤需要时，获取和分析中间结果的方法。

（9）测试用例的前提和约束。在测试用例中还应说明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响。

（10）测试终止条件。说明测试用例的测试正常终止和异常终止的条件。

（11）确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。

（12）测试说明应经过评审，得到相关人员的认同，测试说明评审内容如下：

①测试说明是否完整、正确和规范。

②测试设计是否完整和合理。

③测试用例是否可行和充分。

测试执行

应按照测试计划和测试说明的内容和要求执行测试，主要完成下列工作：

如实填写测试记录，当结果有量值要求时，应准确记录实际的量值。

（1）测试记录应受到严格管理，并规范格式，至少包括测试用例标识、测试结果和发现的缺陷。

（2）应根据每个测试用例的期望测试结果、实际测试结果和评估准则，判定测试用例是否通过。

（3）当测试用例不通过时，应根据不同的缺陷类型，采取相应的措施：

①对测试工作中的缺陷，如测试说明的缺陷、测试数据的缺陷、执行测试步骤时的缺陷、测试环境中的缺陷等，记录到相应的表格中，并实施相应的变更。

②对被测软件的缺陷应记录到软件问题报告中。

③软件问题报告的格式应规范。

（4）当所有的测试用例都执行完毕后，实验室应根据测试的充分性要求和有关记录，分析测试工作是否充分，是否需要进行补充测试：

①当测试过程正常终止时，如果发现测试工作不足，或测试未达到预期要求时，应进行补充测试。

②当测试过程异常终止时，应记录导致终止的条件、未完成的测试或未被修正的错误。

测试总结

应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录、测试问题及变更报告和软件问题报告等，对测试工作和被测软件进行分析和评价，主要完成下列工作：

（1）对测试工作进行分析和评价，分析和评价内容应包括：

①总结测试需求规格说明、测试计划和测试说明的变化情况及其原因。

②在测试异常终止时，说明未能被测试活动充分覆盖的范围及其理由。

③确定无法解决的软件测试事件并说明不能解决的理由。

（2）对被测软件进行分析和评价，分析和评价内容应包括：

①总结测试中所反映的被测软件与软件需求（或软件设计）之间的差异。

②可能时，根据差异评价被测软件的设计与实现，提出改进的建议。

③当进行配置项测试或系统测试时，当需要时，测试总结中应对配置项或系统的性能做出评估，指明偏差、缺陷和约束条件等对于配置项或系统运行的影响。

（3）分析测评项目中的数据和文档，以供以后的测试使用。数据如：缺陷数据（包括缺陷描述、类型、严重性等）、用例数据、管理数据（如生产率、工作量、进度等）；文档如：好的用例设计、好的需求规格说明等。

（4）应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录和软件问题报告等有关文档，对测试结果和问题进行分类和总结，按所确定的文档要求编写测试报告。测试报告除了应包括对测试结果的分析，还应包括对被测软件的评价和建议。

测试总结评审应在测试报告编制工作完成后进行，以确定是否达到测试目的，给出评审结论。评审的具体内容和要求包括：

（1）审查测试文档与记录内容的完整性、正确性和规范性。

（2）审查测试活动的独立性和有效性。

（3）审查测试环境是否符合测试要求。

（4）审查软件测试报告与软件测试原始记录和问题报告的一致性。

（5）审查实际测试过程与测试计划和测试说明的一致性。

（6）审查测试说明评审的有效性，如是否评审了测试项选择的完整性和合理性、测试用例的可行性和充分性。

（7）审查测试结果的真实性和正确性。

概要设计

1）设计软件系统总体结构

设计软件系统总体结构的基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。

2）数据结构及数据库设计

（1）数据结构的设计。在需求分析阶段，已经通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。

（2）数据库的设计。数据库的设计是指数据存储文件的设计，主要指以下几个方面。

①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用ER模型来表述数据模型。

②逻辑设计。ER模型是独立于数据库管理系统（DBMS）的，要结合具体的DBMS特征来建立数据库的逻辑结构。

③物理设计。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。

3）编写概要设计文档

文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。

4）评审

对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性以及各部分之间的一致性等都一一进行评审。

软件测试

测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。

软件测试是针对一个程序的行为，在有限测试用例集合上动态验证软件是否达到预期的行为。

软件测试过程如下：

（1）拟定测试计划。

（2）编制测试大纲。

（3）设计和生成测试用例。

（4）实施测试。

（5）生成测试报告。

软件测试方法：

.人工测试：采用人工方式进行测试，目的是通过对程序静态结构的检查，找出编译时不能发现的错误。人工测试包括个人复查、抽查和会审等。

.机器测试：把设计好的测试用例作用于被测程序，比较测试结果和预期结果是否一致。机器测试包括黑盒测试（功能测试）和白盒测试（结构测试）。

软件测试伴随软件开发和维护过程，通常可以在概念上划分为以下三个阶段：

.单元测试：也称为模块测试，在模块编写完成且无编译错误后就可以进行。

.集成测试：也称为组装测试，就是把模块按系统设计说明书的要求组合起来进行测试。

.系统测试：是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种组装和确认测试。其目的是通过与系统需求相比较，发现所开发的系统与用户需求不符合的地方。

生命周期

IT服务生命周期由规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision）5个阶段组成，简称“PIOIS”。

（1）规划设计：从客户业务战略出发，以需求为中心，参照ITSS对IT服务进行全面系统的战略规划和设计，为IT服务的部署实施做好准备，以确保提供满足客户需求的IT服务。

（2）部署实施：在规划设计基础上，依据ITSS建立管理体系、部署专用工具及服务解决方案。

（3）服务运营：根据IT服务部署情况，依据ITSS，采用过程方法，全面管理基础设施、服务流程、人员和业务连续性，实现业务运营与IT服务运营的全面融合。

（4）持续改进：根据IT服务运营的实际情况，定期评审IT服务满足业务运营的情况，以及IT服务本身存在的缺陷，提出改进策略和方案，并对IT服务进行重新规划设计和部署实施，以提高IT服务质量。

（5）监督管理：本阶段主要依据ITSS对IT服务质量进行评价，并对IT服务供方的服务过程、交付结果实施监督和绩效评估。

详细设计

总体设计只是为整个信息系统提供了一个设计思路和框架，框架内的血肉需要系统的设计人员在详细设计这个阶段充实。总体设计完成后，设计人员要向用户和有关部门提交一份详细的报告，说明设计方案的可行程度和更改情况，得到批准后转入系统详细设计。详细设计阶段主要是在总体设计的基础上，将设计方案进一步详细化、条理化和规范化，为各个具体任务选择适当的技术手段和处理方法。系统的详细设计一般包括如下。

（1）代码设计。

代码设计就是信息分类和编码的工作，是将系统中有某些共同属性或特征的信息归并在一起，并利用便于计算机和人识别和处理的符号来表示这些信息的设计工作。

（2）数据库设计。

数据库设计就是构建既能客观、准确地反映外部世界，又便于人类大脑认识的概念模型，并在此基础上对数据进行建模，转化为数据库管理系统所支持的数据模型；选择合适的存储结构和存储方法，最终完成数据库的设计工作。

（3）输入／输出设计。

输入／输出设计主要是对以记录为单位的各种输入输出报表格式的描述。另外，对人机对话格式的设计和输入输出装置的选择也在这一步完成。

（4）用户界面设计。

用户界面设计是指在用户与系统之间架起一座桥梁。主要内容包括：定义界面形式；定义基本的交互控制形式；定义图形和符号；定义通用的功能键和组合键的含义及其操作内容；定义帮助策略，等等。

（5）处理过程设计。

总体设计将系统分解为许多模块，并基本决定了每个模块的功能和界面。处理过程设计则定义每个模块的内部执行过程，包括数据的组织、控制流、每一步的具体加工要求和实施细节。通过处理过程设计，为编写程序制定一个周密的计划。一般来说，每一个功能模块都应设计一个处理流程。

需求分析

需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：

（1）结构化分析方法。本节后续内容将详细讨论SA的内容。

（2）面向对象分析方法。将在10.3节中进行详细介绍。

（3）面向问题域的分析（Problem Domain Oriented Analysis, PDOA）方法。PDOA更多地强调描述，而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素，是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图，但不同的是上下文图的建模对象是针对解系统，而问题框架则是针对问题域。也就是说，问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段，并未广泛应用。

业务流程分析

业务流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系和每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流程变化提供依据。

业务流程分析的步骤如下：

（1）通过调查掌握基本情况。

（2）描述现有业务流程（绘制业务流程图）。

（3）确认现有业务流程。

（4）对业务流程进行分析。

（5）发现问题，提出解决方案。

（6）提出优化后的业务流程。

在业务流程图中使用的基本符号如下图所示。

数据流图

DFD是结构化分析中的重要方法和工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型，在信息系统开发中，一般将它作为需求说明书的组成部分。

业务流程图符号

DFD从数据传递和加工的角度，利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。具体来说，DFD的主要作用如下：

（1）DFD是理解和表达用户需求的工具，是系统分析的手段。由于DFD简明易懂，理解它不需要任何计算机专业知识，因此通过它同客户交流很方便。

（2）DFD概括地描述了系统的内部逻辑过程，是系统分析结果的表达工具，因而也是系统设计的重要参考资料，是系统设计的起点。

（3）DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。

在DFD中，通常会出现4种基本符号，分别是数据流、加工、数据存储和外部实体（数据源及数据终点）。数据流是具有名字和流向的数据，在DFD中用标有名字的箭头表示。加工是对数据流的变换，一般用圆圈表示。数据存储是可访问的存储信息，一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示。下图是一个典型的DFD示例。

办理取款手续的DFD

为了表达数据处理过程中的数据加工情况，用一个DFD是不够的。稍微复杂的实际问题，在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的DFD反映这种结构关系，能清楚地表达整个系统。

下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1，第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，它的上层图称为父图，在它下一层的图则称为子图。

分层数据流图

概括地说，画DFD的基本步骤，就是“自顶向下，逐层分解”。检查和修改的原则如下：

（1）DFD中的所有图形符号只限于前述4种基本图形元素。

（2）顶层DFD必须包括前述4种基本元素，缺一不可。

（3）顶层DFD中的数据流必须封闭在外部实体之间。

（4）每个加工至少有一个输入数据流和一个输出数据流。

（5）在DFD中，需按层给加工框编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。

（6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。

（7）可以在DFD中加入物质流，帮助用户理解DFD。

（8）图上每个元素都必须有名字。

（9）DFD中不可夹带控制流。

数据字典

数据字典是关于数据的信息的集合，也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD，数据字典难以发挥作用；没有数据字典，DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起，才能共同构成系统的规格说明。

数据字典的设计包括：数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息：名称、别名或编号、分类、描述、何处使用。

对加工的描述是数据字典的组成内容之一，常用的加工描述方法有结构化语言、判定树及判定表。

（1）结构化语言：介于自然语言和形式语言之间的一种半形式语言，在自然语言基础之上加了一些限度，使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句，即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定，与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇：祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。

（2）判定树：若一个动作的执行不只依赖一个条件，而与多个条件有关，那么这项策略的表达就比较复杂。如果用结构化语言的判断语句，就有多重嵌套，层次一多，可读性就会下降。用判定树来表示，可以更直观一些。

（3）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。

题号导航 2010年下半年软件评测师上午试卷综合知识

本试卷我的完整做题情况



	第21题在手机中做本题