1.5 软件测试过程模型

1.5.1 V模型

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

软件测试的V模型如图1-1所示。

图中的箭头代表时间方向，左边由高向低的过程表示开发过程的各个阶段。与此相对应的是右边由低向高则代表测试过程的各个阶段。

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

V模型指出，单元测试和集成测试是验证软件设计，开发人员和测试组应检测软件的执行是否满足软件设计的要求；系统测试应当验证系统设计，并检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行的软件验收测试检查其基本软件需求说明书，以确认软件的实现是否满足用户需求或合同的要求。V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，容易使人理解为测试是软件开发的最后的一个阶段，主要是针对软件进行测试以寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。

1.5.2 W模型

1.W模型建立

V模型的局限性在于，没有明确地说明早期测试不能体现“尽早和不断地进行软件测试”的原则，在该模型中增加软件各开发阶段应同步进行的测试被演化为一种W模型。因为实际上开发是“V”，测试也是与此相并行的“V”，从而构成图1-2所示的模型。

基于“尽早和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE Std 1012-1998《软件验证和确认（V&V）》的原则。

2.W模型应用

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

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

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

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

1.5.3 X模型

X模型也是对V模型的改进，该模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接和集成最终合成为可执行的程序，X模型如图1-3所示。

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

X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接并通过集成最终合成为可执行的程序，这一点在图1-3的右上方得以体现。而且这些可执行程序还需要进行测试，已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分；同时，X模型还定位了探索性测试，如图1-3中右下方所示。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下，结果会怎么样”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。Marick对V模型提出质疑也是因为V模型是基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。因为在实践过程中很多项目是缺乏足够的需求的，而V模型还是从需求处理开始。Marick也质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。Marick担心人们盲目地跟随“学院派的V模型”，并按照模型所指导的步骤进行工作，而实际上某些做法并不切合实际。

1.5.4 H模型

1.H模型建立

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

为了解决以上问题，人们提出了H模型，它将测试活动做成一个完全独立的流程，从而将测试准备活动和测试执行活动清晰地体现出来，如图1-4所示。

2.H模型应用

图1-4仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”，图中的其他流程可以是任意开发流程，如设计流程和编码流程。也可以是其他非开发流程，如软件质量保证（SQA）流程，甚至是测试流程自身。也就是说只要测试条件成熟且测试准备活动完成，测试执行活动就可以（或者说需要）进行。概括地说，H模型揭示了如下内容。

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

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

（3）软件测试要尽可能早地准备和执行。

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

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

1.5.5 前置测试模型

前置测试模型是将测试和开发紧密结合而形成的模型，该模型提供了轻松的方式可以使项目加快速度，如图1-5所示。

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

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

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

（3）在设计阶段编写测试计划并进行测试设计：设计阶段是编写测试计划和测试设计的最好时机，很多组织要么根本不编写，要么在即将开始执行测试之前编写。在这种情况下，测试只是验证了软件的正确性，而不是验证整个系统本应实现的目标。

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

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

1.5.6 成熟度模型

1.CMM（Capability Maturity Model For Software，能力成熟度模型）

CMMI（Capability Maturity Model Integration，能力成熟度模型集成）在CMM的基础上发展而来，是由美国卡耐基梅隆大学软件工程研究所（Software Engineering Institute，SEI）组织全世界的软件过程改进和软件开发管理方面的专家历时4年而开发成功并在全世界推广实施的一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估。

CMM模型自20世纪80年代末推出并于20世纪90年代广泛应用于软件过程的改进以来，极大地促进了软件生产率的提高和软件质量的提高，为软件产业的发展和壮大做出了巨大的贡献。

CMM模型主要用于软件过程的改进，促进企业软件能力成熟度的提高。但它对于系统工程、集成化产品和过程开发、供应商管理等领域的过程改进都存在缺陷，因而人们不得不分别开发软件以外其他学科的类似模型。

自从引入基于模型的过程改进之后工程界至少在如下重要领域已经有了变化。

（1）执行工程的环境变得更加复杂，工程量更大、需要更多的人员，工程会跨越公司界限，发布范围更宽更广；同时必须继续加快实现的进度以满足客户的需要，这样导致各种协调工作的大量增加。

（2）执行工程任务的方式已经有了进化，交叉学科群组、并行工程、高度自动化的过程及多国标准等都影响到工程实践，这样一个工程项目可能要涉及多个国际标准。

（3）CMM的成功导致了各种模型的衍生，而每一种模型都探讨了某一特定领域中的过程改进问题，各机构也已采用多种改善模型分别处理各自的关键过程问题。在工程组织中模型的繁衍导致了过程改进目标和技术的冲突，也导致了实践人员在应用各种不同的模型来实现特定的需求时容易产生混淆，这就要求培训工作量也随之增长。

所有这些变化都表明有必要将各种过程的改进工作集成起来，包含在当代工程中各种各样的学科和过程是密切交叉在一起的。在应用不同模型时效率低下且容易混淆，常常要付出极其高昂的代价。因而需要有一种单一的过程改进框架而又能跨越多种学科的工具，CMMI就是用来解决以下3类问题的。

（1）解决软件项目的过程改进难度增大问题：CMM成功实施以后极大地提高了软件企业的开发效率和软件产品的质量，从而也提高了软件产品的可靠性和软件产业的信誉。这样人们就对软件寄予了更大的希望，希望软件能够完成更多、更大、更复杂的任务。

（2）实现软件工程的并行与多学科组合：CMM模型的成功实践促进了工程和产品开发的组织发生了巨大的变革，变革的目标主要是为了消除与分段开发有关的低效。在分段开发过程中中间产品传给下一阶段的工作人员时，有可能要进行大量的返工，以纠正原先的理解错误。并行工程、交叉学科群组、交叉功能群组、集成化产品群组，以及集成化产品和过程开发等都代表了在产品或服务的整个生命周期的合适时间内处理这类问题的不同方法。这种倾向意味着设计人员和客户要与制造人员、测试人员和用户共同工作，以支持开发需求的制造组织，这种工作方式蕴涵着所有关键的相关人员要支持产品或服务开发的所有阶段。

（3）实现过程改进的更大效益：尽管过程改进存在复杂化的因素，但软件管理专家相信其中的许多障碍可以通过一个集成过程改进的公共模型来克服，这种信念反映了在集成方面所进行的工作和CMM项目的作者和评审人员的经验。人们相信正如通过CMM的过程改进能够产生显著的效益一样，集成过程改进也能产生更大的效益。

从根本上来说，过程改进集成主要影响4个方面，即成本、侧重点、过程集成和灵活性。其中某些变化可能比另一些变化容易量化，但所有这些都体现了过程改进集成的真正优势。

在CMMI中每一种学科模型都有两种表示法，即阶段式表示法和连续式表示法。不同表示法的模型具有不同的结构，阶段式表示法强调的是组织的成熟度。从过程域集合的角度考察整个过程成熟度阶段，其关键术语是“成熟度”；连续式表示法强调的是单个过程域的能力，即从过程域的角度考查基线和度量结果的改善，其关键术语是“能力”。具体说明如下。

（1）阶段式表示法。

软件CMM是一种阶段式模型，该模型经过多年的成功使用已经被证明是有效的，这为选择阶段式表示法模型提供了最强有力的证据。考虑从不成熟组织向成熟组织的发展过程，阶段式表示法具有如下两方面优势。

1）为支持组织的过程改进提供了一个过程平台，该表示法将软件组织的软件能力成熟度描述为5级。对于着眼于改善过程成熟度的组织来说，阶段式表示法提供了一种明确且行之有效的跨越式发展途径。在阶段式模型中所描述的组织的5个成熟度等级中每实现一次等级间的跨越，组织就致力于解决某一方面的问题。例如，组织从成熟度等级1到成熟度等级2主要致力于项目管理过程的改进；从成熟度等级2到成熟度等级3主要致力于广泛的组织级过程的改进；从成熟度等级3到成熟度等级4主要致力于过程定量管理的过程的改进；从成熟度等级4到成熟度等级5主要致力于技术革新和优化过程的改进，通过这种方式阶段式表示法确定了组织进行过程改进的最佳次序。

2）阶段式表示法可以为组织定义一个过程成熟度等级，便于进行跨组织的比较。在该表示法中每一个过程域都被指定归属到一个成熟度等级中，因此基于阶段式表示法为组织所定义的成熟度等级中过程域的预期范围和应用将变得非常清晰。这样在对不同的组织进行比较时，只要对比其所达到的不同的成熟度等级即可知道该组织在过程域方面所存在的差别。

阶段式表示法存在两方面的不足，一是采用分组形式，将过程域划分到5个等级中。在一般情况下一个组织要到达某一个等级，必须满足该等级及其低等级的所有过程域，因而缺乏灵活性；二是每个等级都会出现同时进行多个过程改进的情况，因而工作量大，所花费的成本也很大。

（2）连续式表示法。

相比之下，连续式表示法不如阶段式表示法常用，采用该表示法有如下两个优势。

1）为用户进行过程改进提供了比较大的自由度。如上所述，阶段式表示法确定了组织进行过程改进的最佳次序，但同时也限定了必须遵循的单一改善路径。而连续式表示法则允许用户根据组织的业务目的来选择过程改进活动的次序。在该表示法中用户可以选择定义组织的成熟度等级，还可以选择定义更适合自身业务环境的过程域的次序。组织可以在一个自己选择的次序中使过程域达到给定的能力成熟度等级，而不必遵循单一的阶段式模型的原则。

2）基于连续式表示法对组织的过程进行评估，其结果具有更好的可见性。在该表示法中可以为每个过程域定义多个能力成熟度等级，从而可以增强对过程改进中强项和弱点的认识。由于连续式表示法是对每个个别的过程域进行单独的评定，并给出个别过程域的能力成熟度等级特征图，所以更便于观察。

连续式表示法也存在两方面的不足，一是由于没有规定过程域应用的顺序，因而组织的过程改进需要软件过程改进专家的指导，以便确定组织需要改进的过程和改进的先后次序；二是尽管组织应用连续式表示法进行了过程改进，但难以与其他软件组织进行组织间过程能力的比较。

CMMI共有5个级别，分别代表软件团队能力成熟度的5个等级。数字越大，成熟度越高，表示有比较强的软件综合开发能力。

1级为执行级。在执行级水平上，软件组织对项目的目标与要做的努力很清晰，项目的目标可以实现。但是由于任务的完成带有很大的偶然性，所以软件组织无法保证在实施同类项目时仍然能够完成任务。项目实施能否成功主要取决于实施人员。

2级为管理级。在管理级水平上所有第1级的要求都已经达到；另外，软件组织在项目实施上能够遵守既定的计划与流程，有资源准备且权责到人。对项目相关的实施人员进行了相应的培训，对整个流程进行监测与控制并联合上级单位对项目与流程进行审查。该级水平的软件组织对项目有一系列管理程序，避免了软件组织完成任务的随机性，保证了软件组织实施项目的成功率。

3级为明确级。在明确级水平上，所有第2级的要求都已经达到；另外，软件组织能够根据自身的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化。这样软件组织不仅能够在同类项目上成功，也可以在其他项目上成功，科学管理成为软件组织的一种文化和财富。

4级为量化级。在量化级水平上，所有第3级的要求都已经达到；另外，软件组织的项目管理也实现了数字化。通过数字化技术来实现流程的稳定性并保证管理的精度，降低项目实施在质量上的波动。

5级为优化级。在优化级水平上，所有第4级的要求都已经达到；另外，软件组织能够充分利用信息资料，预防在项目实施的过程中可能出现的“次品”，并且能够主动地改善流程，运用新技术并实现流程的优化。

由上述的5个级别可以看出，每一个级别都是更高一级的基石，要上高层台阶必须首先踏上所有下层的台阶。应用CMMI是一个庞大的过程元模型，自发布以来在世界软件界产生了巨大的影响。CMMI等级评估已经成为业界公认的标准，其证书成为一个企业或组织能力和形象的标志。这个证书会有利于在国内、国外大型软件项目的竞标中获胜。CMMI适合企业操作，避免了某些管理体系只重理论而忽视实践的缺陷。在我国许多企业引入了CMMI咨询和认证，对于整个软件行业的管理提升及研发效率提高起到了很大的帮助作用。但也有一些企业引入CMMI体系后只留下一些形式上的开发流程和文档模板，在管理上并无实质性改进。对于CMMI，业界一直存在两种声音，有人认为CMMI执行过度，得不偿失。也有人说它过于通用，实用价值不大。但多数人还是认同它，并根据需要加以应用。

2.软件测试的成熟度模型

衡量软件企业研发和管理能力是CMM及后面推出的CMMI的目标，很多公司通过CMM的各个级别的认证为企业承接项目添加了砝码。而对于软件测试行业来说，还没有出现一个认证机构测评一个从事软件测试项目的企业具有的能力。近几年，推出的TCMM（Testing Capability Maturity Model，测试能力成熟度模型）成为了行业的标准，TCMM也分为5级。

1级Initial（初始级）。测试处于一个混乱的状态，还不能把测试与调试分开。在编码完成后才进行测试工作。测试和调试交叉在一起的目的就是发现软件中的缺陷，测试的目的是表明软件没有错。在该级别软件产品发布后没有质量保证，并且缺乏测试相应的测试资源。例如，专职测试人员和测试工具，测试人员也没有经过培训。处于这个级别的公司在测试中缺乏成熟的测试目标，测试处于可无可有的地位。

2级Phase Definition（阶段定义级）。测试与调试分开并把测试作为编码后的一个阶段。尽管将测试看作是一个有计划的行为，但是由于测试的不成熟，即仅在编码后制订测试计划，所以测试完全针对源代码。处于这个级别的公司测试的首要目的就是验证软件符合需求，并且会采用基本的测试技术和方法。由于测试处于软件生命周期的末尾环节，所以导致出现很多无法弥补的质量问题；另外，在需求和设计阶段产生的很多问题被引入到编码中，但基于源代码的测试导致产生了很多的问题无法解决。

3级Integration（集成级）。测试不再是编码后的一个阶段，而是贯穿在整个软件生命周期中。正如软件测试领域的V模型，在需求阶段软件测试开始介入。测试是建立在满足用户或客户的需求上，根据需求设计测试用例和作为测试的依据。处于这个级别的公司测试工作由独立的部门负责，测试部门与开发部门分开独立开展工作。测试部门有自己的技术培训并且有测试工具辅助进行测试工作。尽管处于这个阶段的公司认识到了评审在质量控制中的重要性，但是并没有建立有效的评审制度。所以还不能在软件生命周期的各个阶段实施评审制度，即没有建立质量控制和质量度量标准。

4级Management and Measurement（管理和度量级）。测试是一个度量和质量控制过程。在软件生命周期中评审作为测试和软件质量控制的一部分，被测试的软件产品标准包括可靠性、可用性和可维护性等。在测试项目中设计的测试用例分别保存在测试用例数据库中，以便于重用和回归测试，使用缺陷管理系统管理软件缺陷并划分缺陷的级别。但是处于这个阶段的公司还没有建立起缺陷预防机制，并且缺乏自动地对测试中产生的数据进行收集和分析的手段。

5级Optimization（优化级）。测试具有缺陷预防和质量控制的能力。建立在4级基础上的测试公司已经建立了测试规范和流程，测试是受控的和被管理的。而达到这个级别的公司坚决贯彻落实测试规范和流程且不断地进行测试过程改进，在实践中运用缺陷预防和质量控制措施。整个测试过程是被以往经验所驱动的，并且是可信任和可靠的。选择和评估测试工具存在一个既定的流程，测试工具支持测试用例的运行和管理并辅助设计用例和维护测试相关资料，缺陷收集和分析为缺陷预防和质量控制提供支持。

看了上面对于测试能力成熟度模型的分析，我们不难看出目前国内从事软件测试的公司还处于2级或3级，这与现在软件测试还是一个尚未成熟的行业有关。测试技术和测试工具还在发展之中，各个公司都在摸索阶段。从事测试外包的公司会好一些，它们为微软、IBM、Motorola等公司提供测试服务，基本上是按照委托方的要求或带领下进行测试工作。而国内做软件产品和承接软件开发的公司虽然有的建立了独立的测试团队并制订了测试规范和测试流程或者评审制度，但是测试工作还是在摸索阶段，几乎没有现成的经验可参考。所以目前急需建立软件测试的行业标准，以推动测试行业的发展，让测试有据可依。

1.5.7 选择软件测试过程模型

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

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

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