CMM对软件测试没有提供单独的关键过程领域（KPA)，所以许多研究机构和测试服务机构从不..

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

第6题

知识点：软件测试过程软件测试过程模型 CMM 测试过程初始级定义级过程模型能力成熟度模型软件测试

关键词： CMM 测试过程能力成熟度模型软件测试测试章/节：软件过程管理

CMM对软件测试没有提供单独的关键过程领域（KPA)，所以许多研究机构和测试服务机构从不同角度出发提出了有关软件测试方面的能力成熟度模型，其中软件测试成熟度模型（TMM)是当前影响力最大的软件测试过程模型。TMM制定了5个成熟度等级，它们依次是：初始级、阶段定义级、集成级、.管理和度量级、(6)。

A. 优化、缺陷预防和可重复级

B. 优化、缺陷预防和质量控制级

C. 缺陷预防和质量控制级

D. 优化和质量控制级

相关试题：软件能力成熟度模型

更多>

第29题 2009年上半年

43%

软件能力成熟度模型（CMM)将软件能力成熟度自低到高依次划分为5级。目前，达到CMM第3级（已定义级）是许多组织努力的目标，该级的..


知识点讲解
· 软件测试过程 · 软件测试过程模型 · CMM · 测试过程 · 初始级 · 定义级 · 过程模型 · 能力成熟度模型 · 软件测试

软件测试过程

开发过程的质量决定了软件的质量，同样地，测试过程的质量决定了软件测试的质量和有效性。软件测试过程的管理是保证测试过程质量、控制测试风险的重要活动。软件测试和软件开发一样，都遵循软件工程的原理，有它自己的生命周期。软件的测试过程一般分成测试计划、测试设计与开发、测试实施、测试评审与测试结论等阶段。对每个阶段的任务、输入和输出都有明确的规定，以便对整个测试过程进行质量控制和配置管理。

软件测试过程是一种抽象的、遵循GB/T 18905（ISO 14598.5）《评价者用的过程（Process for Evaluator）》中定义软件评价过程的模型，是国际上共同遵守的软件评测过程标准，是软件测试过程管理的精髓。标准定义了分析各类软件产品的评测需求，规定、设计、实施、评审以及对评测做出结论所需的各种活动。本章介绍的主要内容，可作为软件测试过程工作内容与管理的基本原则。为符合GB/T 18905基本原理，仍保留“评价过程”的标准用语。

软件测试过程模型

在软件开发几十年的实践过程中，人们总结了很多的开发模型，比如瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发（RAD）以及最近比较流行的Rational统一过程（RUP）等，这些模型对于软件开发过程具有很好的指导作用，但是，非常遗憾的是，在这些过程方法中，并没有充分强调测试的价值，也没有给测试以足够的重视，利用这些模型无法更好地指导测试实践。软件测试是与软件开发紧密相关的一系列有计划的系统性的活动，显然软件测试也需要测试模型去指导实践，非常可喜的是软件测试专家通过测试实践总结出了很多很好的测试模型。当然由于测试与开发的结合非常紧密，在这些测试模型中也都把开发过程进行了很好的总结，体现了测试与开发的融合，下面对主要的模型做一简单的介绍。

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

H模型

H模型建立

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

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

H模型应用

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

软件测试H模型

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

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

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

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

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

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

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

其他模型

X模型

由于V模型受到了很多人的质疑，因此，也有人提出了一些不同的观点和意见。在此，我们向大家介绍另外一种测试模型，即X模型，其目标是弥补V模型的一些缺陷。

X模型的基本思想是由Marick提出的，但首先Marick不建议建立一个替代模型，同时，他也认为他的观点并不足以支撑一个模型的完整描述。不过，Robin F. Goldsmith先生在自己的文章里将其思想定义为X模型，理由是，在Marick的观点中已经具备一个模型所需要的一些主要内容，其中也包括了像探索性测试这样的亮点。软件测试X模型如下图所示。

软件测试X模型

Marick对V模型最主要的批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接、频繁重复的集成以及需求文档的缺乏等。Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。

X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后，将进行频繁的交接，通过集成最终合成为可执行的程序。这一点在图的右上方得以体现，而且这些可执行程序还需要进行测试，已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。

同时，X模型还定位了探索性测试，即如上图中右下方所示。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下，结果会怎么样”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

Marick对V模型提出质疑，也是因为V模型是基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。因为在实践过程中，很多项目是缺乏足够的需求的，而V模型还是从需求处理开始。

Marick也质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。Marick担心人们盲目地跟随“学院派的V模型”，按照模型所指导的步骤进行工作，而实际上某些做法并不切合实用。

前置测试模型

前置测试模型是由Robin F. Goldsmith等人提出的，它是一个将测试和开发紧密结合的模型，该模型提供了轻松的方式，可以使你的项目加快速度。前置测试模型如下图所示。

前置测试模型

前置测试模型体现了以下的要点。

. 开发和测试相结合：前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。并且标识了这些行为在项目周期中的价值所在。如果其中有些行为没有得到很好的执行，那么项目成功的可能性就会因此而有所降低。如果有业务需求，则系统开发过程将更有效率。我们认为在没有业务需求的情况下进行开发和测试是不可能的。而且，业务需求最好在设计和开发之前就被正确定义。

. 对每一个交付内容进行测试：每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是惟一需要测试的内容。图中的椭圆框表示了其他一些要测试的对象，包括可行性报告、业务需求说明，以及系统设计文档等。这同V模型中开发和测试的对应关系是一致的，并且在其基础上有所扩展，变得更为明确。

. 在设计阶段进行测试计划和测试设计：设计阶段是作测试计划和测试设计的最好时机。很多组织要么根本不作测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和测试设计。在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。

. 测试和开发结合在一起：前置测试将测试执行和开发结合在一起，并在开发阶段以编码—测试—编码—测试的方式来体现。也就是说，程序片段一旦编写完成，就会立即进行测试。一般情况下，先进行的测试是单元测试，因为开发人员认为通过测试来发现错误是最经济的方式。但也可参考X模型，即一个程序片段也需要相关的集成测试，甚至有时还需要一些特殊测试。对于一个特定的程序片段，其测试的顺序可以按照V模型的规定，但其中还会交织一些程序片段的开发，而不是按阶段完全地隔离。

. 让验收测试和技术测试保持相互独立：验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。验收测试既可以在实施阶段的第一步来执行，也可以在开发阶段的最后一步执行。前置测试模型提倡验收测试和技术测试沿循两条不同的路线来进行，每条路线分别地验证系统是否能够如预期设想的那样进行正常工作。这样，当单独设计好的验收测试完成了系统的验证时，我们即可确信这是一个正确的系统。

测试模型的使用

前面我们介绍了几种典型的测试模型，应该说这些模型对指导测试工作的进行具有重要的意义，但任何模型都不是完美的。我们应该尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没有实际意义。

在这些模型中，V模型强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地指出应该对软件的需求、设计进行测试，而这一点在W模型中得到了补充。W模型强调了测试计划等工作的先行和对系统需求和系统设计的测试，但W模型和V模型一样也没有专门针对软件测试的流程予以说明，因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发部的组织，就每一个软件测试的细节而言，它都有一个独立的操作流程。比如，现在的第三方测试，就包含了从测试计划和测试案例编写，到测试实施以及测试报告编写的全过程，这个过程在H模型中得到了相应的体现，表现为测试是独立的。也就是说，只要测试前提具备了，就可以开始进行测试了。当然，X模型和前置测试模型又在此基础上增加了许多不确定因素的处理情况，因为在真实项目中，经常会有变更的发生，例如需要重新访问前一阶段的内容，或者跟踪并纠正以前提交的内容，修复错误，排除多余的成分，以及增加新发现的功能等。

因此，在实际的工作中，我们要灵活地运用各种模型的优点，在W模型的框架下，运用H模型的思想进行独立地测试，并同时将测试和开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。

CMM

CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准。

（1）初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行时没有政策、资源等方面的保证，那么它仍然被视为初始级。

（2）可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

（3）已定义级：用于管理方面和工程方面的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。它要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。

（4）已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变成为一个工业生产活动。

（5）优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。如果一个企业达到了这一级，表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域（Key Process Area，KPA），一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标。每个级别对应的关键过程域见下表。

关键过程域的分类

测试过程

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

软件测试过程

测试需求分析

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

（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）审查测试结果的真实性和正确性。

初始级

软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行时没有政策、资源等方面的保证，那么它仍然被视为初始级。

定义级

在定义级，企业全面采用综合性管理及工程过程管理，对整个软件生命周期的管理与工程化过程都已标准化，并综合成软件开发企业标准的软件过程。企业标准软件过程通过证明是正确且实用的，所有开发的项目须根据标准过程，剪裁出与项目适宜的过程，并执行这些过程。

过程模型

产品开发生命周期通常使用过程模型进行表示。过程模型习惯上也称为开发模型，它是系统开发全部过程、活动和任务的结构框架。典型的开发过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。

瀑布模型（Waterfall Model）

瀑布模型是将系统生存周期各个活动规定为依线性顺序连接的若干阶段的模型，也称为线性模型。它包括需求分析、设计、实现、测试、运行和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落，如下图所示。

瀑布模型

瀑布模型为系统的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于系统需求很明确的软件项目的模型。

瀑布模型假设一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现产生。瀑布模型的优点是，容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或三个阶段中，很难评估真正的进度状态；当接近项目结束时，出现了大量的集成和测试工作；直到项目结束之前，都不能演示系统的能力。在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。

瀑布模型的一个变体是V模型，如下图所示。V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。随着团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其实际上是执行了一系列测试（质量保证活动），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。

V模型

增量模型（Incremental Model）

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”，如下图所示。当使用增量模型时，第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

增量模型

增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：第一个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布了第一个版本，因此可以减少用户需求的变更；运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。

增量模型有以下不足之处：如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力。

原型模型（Prototype Model）

并非所有的需求都能够预先定义，大量的实践表明，在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于客户往往不能准确地表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型（rapid prototype）这种新的开发方法。原型方法比较适合于用户需求不清、需求经常变化的情况，是一种演化模型（Evolutionary Model）。当系统规模不是很大也不太复杂时，采用该方法比较好。

原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。当然，能够采用原型方法是因为开发工具的快速发展，使得能够迅速地开发出一个让用户看得见、摸得着的系统框架。这样，对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求，开发初始原型，然后征求用户对初始原型的改进意见，并根据意见修改原型。原型模型如下图所示。

原型模型

原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制定原型开发的计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。被开发的原型应交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。

根据使用原型的目的不同，原型可以分为探索型原型、实验型原型和演化型原型3种。探索型原型的目的是要弄清目标的要求，确定所希望的特性，并探讨多种方案的可行性。实验型原型的目的是验证方案或算法的合理性，是在大规模开发和实现前，用于考查方案是否合适、规格说明是否可靠等。演化型原型的目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。

螺旋模型（Spiral Model）

对于复杂的大型系统，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。螺旋模型是一种演化模型。

螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，如下图所示。在每个螺旋周期分为如下4个工作步骤。

螺旋模型

（1）制订计划。确定系统的目标，选定实施方案，明确项目开发的限制条件。

（2）风险分析。分析所选的方案，识别风险，消除风险。

（3）实施工程。实施系统开发，验证阶段性产品。

（4）用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。

螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。因此特别适用于庞大、复杂并且具有高风险的系统。

与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高产品的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了系统开发的风险。在使用螺旋模型进行系统开发时，需要开发人员具有相当丰富的风险评估经验和专门知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。

喷泉模型（water fountain model）

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性，如下图所示。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它不像瀑布模型那样，需求分析活动结束后才开始设计活动，设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。

喷泉模型

喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行。其优点是可以提高项目开发效率，节省开发时间。由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大。

形式化方法模型（Formal Methods Model）

形式化方法是用于将复杂系统建模为数据实体的技术，是建立在严格数学基础上的一种开发方法，其主要活动是生成计算机软件形式化的数学规格说明。

形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。

统一过程（UP）模型

统一过程的特色是“用例和风险驱动，以架构为中心，迭代的增量开发过程”。迭代的意思是将整个产品开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。

统一过程定义了5个阶段及其制品。

（1）起始阶段（inception phase）。起始阶段专注于项目的初创活动，产生的主要工作产品有构想文档（vision document）、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划（阶段及迭代）、业务模型以及一个或多个原型（需要时）。本阶段的里程碑是生命周期目标。

（2）精化阶段（elaboration phase）。精化阶段在理解了最初的领域范围之后进行需求分析和架构演进，产生的主要工作产品有用例模型、补充需求（包括非功能需求）、分析模型、体系结构描述、可执行的体系结构原型、初步的设计模型、修订的风险列表、项目计划（包括迭代计划、调整的工作流、里程碑和技术工作产品）以及初始用户手册。本阶段的里程碑是生命周期架构。

（3）构建阶段（construction phase）。构建阶段关注系统的构建，产生实现模型，产生的主要工作产品有设计模型、系统构件、集成的增量、测试计划及步骤、测试用例以及支持文档（用户手册、安装手册和对于并发增量的描述）。初始运作功能。

（4）移交阶段（transition phase）。移交阶段关注于系统提交方面的工作，产生系统增量，产生的主要工作产品有提交的系统增量、β测试报告和综合用户反馈。本阶段的里程碑是产品发布版本。

（5）生产阶段（production phase）。生产阶段对持续使用的软件进行监控，提供运行环境（基础设施）的支持，提交并评估缺陷报告和变更请求。

在每个迭代中，有5个核心工作流：捕获系统应该做什么的需求工作流，精化和结构化需求的分析工作流，用系统构架实现需求的设计工作流，构造系统的实现工作流，验证实现是否如期望那样工作的测试工作流。

统一过程的典型代表是RUP（Rational Unified Process），主要针对前4个技术阶段。RUP是UP的商业扩展，完全兼容UP，但比UP更完整、更详细。

敏捷方法（Agile Development）

敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在产品开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。

敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念（敏捷宣言）。

（1）极限编程（XP）。XP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。

.4大价值观：沟通、简单性、反馈和勇气。

.5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。

.12个最佳实践：计划游戏（快速制订计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后再编写程序）、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本）、每周工作40个小时、现场客户和编码标准。

（2）水晶法（Crystal）。水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论。

（3）并列争球法（Scrum）。并列争球法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。。

（4）自适应软件开发（ASD）。ASD有6个基本的原则：有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的，因此“重做”与“做”同样关键；变化不被视为改正，而是被视为对软件开发实际情况的调整；确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险也包含其中。

能力成熟度模型

能力成熟度模型（简称CMM）是对一个组织机构的能力进行成熟度评估的模型。成熟度级别一般分成五级：1级-非正式执行、2级-计划跟踪、3级-充分定义、4级-量化控制、5级-持续优化。其中，级别越大，表示能力成熟度越高，各级别定义如下：

. 1级-非正式执行：具备随机、无序、被动的过程；

. 2级-计划跟踪：具备主动、非体系化的过程；

. 3级-充分定义：具备正式的、规范的过程；

. 4级-量化控制：具备可量化的过程；

. 5级-持续优化：具备可持续优化的过程。

目前，网络安全方面的成熟度模型主要有SSE-CMM、数据安全能力成熟度模型、软件安全能力成熟度模型等。

SSE-CMM

SSE-CMM（Systems Security Engineering Capability Maturity Model）是系统安全工程能力成熟度模型。SSE-CMM包括工程过程类（Engineering）、组织过程类（Organization）、项目过程类（Project）。各过程类包括的过程内容如下表所示。

SSE-CMM系统安全工程能力成熟度模型过程清单

SSE-CMM的工程过程、风险过程、保证过程的相互关系如下图所示。

SSE-CMM的工程过程、风险过程、保证过程关联图

SSE-CMM的工程过程关系如下图所示。

SSE-CMM的工程过程关联图

SSE-CMM的工程质量来自保证过程，如下图所示。

SSE-CMM的保证过程图

数据安全能力成熟度模型

根据《信息安全技术数据安全能力成熟度模型》，数据安全能力成熟度模型架构如下图所示。

数据安全能力成熟度模型架构

数据安全能力从组织建设、制度流程、技术工具及人员能力四个维度评估：

.组织建设——数据安全组织机构的架构建立、职责分配和沟通协作；

.制度流程——组织机构关键数据安全领域的制度规范和流程落地建设；

.技术工具——通过技术手段和产品工具固化安全要求或自动化实现安全工作；

.人员能力——执行数据安全工作的人员的意识及专业能力。

详细情况参考标准。

软件安全能力成熟度模型

软件安全能力成熟度模型分成五级，各级别的主要过程如下：

. CMM1级——补丁修补；

. CMM2级——渗透测试、安全代码评审；

. CMM3级——漏洞评估、代码分析、安全编码标准；

. CMM4级——软件安全风险识别、SDLC实施不同安全检查点；

. CMM5级——改进软件安全风险覆盖率、评估安全差距。

软件测试

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

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

软件测试过程如下：

（1）拟定测试计划。

（2）编制测试大纲。

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

（4）实施测试。

（5）生成测试报告。

软件测试方法：

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

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

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

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

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

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

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

本试卷我的完整做题情况



	第6题在手机中做本题