爱华网本科毕业论文
（题目：基于CMMI的项目级软件测试的研究）
姓学专院名：号：业：系：************计算机科学与技术信息工程学院2013
年5月20日指导老师：职称学历：完成时间：
教务处制
安徽新华学院本科毕业生毕业论文（设计）承诺书
本人按照毕业论文进度计划积极开展实验（调查）研究活动，实事求是地做好实验（调查）记录，所呈交的毕业论文（设计）是我个人在导师指导下进行的研究工作及取得的研究成果。据我所知，除文中特别加以标注引用参考文献资料外，论文中所有数据均为自己研究成果，不包含其他人已经发表或撰写过的研究成果。与我一同工作的同志对本研究所做的工作已在论文中作了明确说明并表示谢意。毕业论文作者签名：日期：
基于CMMI的项目级软件测试的研究
摘要
在信息化越来越重要的今天，软件产品变得愈发重要，逐渐融入到日常生活中。随着软件规模的扩大，技术、结构越来越复杂，软件测试的流程变得越来越重要，其成熟度对于提高软件开发的质量和生产效率起到了至关重要的作用。为了更好地解决这些问题我们引入了CMMI。
CMMI的目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。CMMI的思想是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。
本文对CMMI以及与软件测试相关的关键过程域进行分析和研究，并对传统的软件测试理论模型（Ｘ模型，V模型）进行分析和比较。我们在这两种模型已经研究的基础上，对CMMI的软件测试流程进行探索和研究，并设计了一种基于CMMI的软件测试流程的测试管理系统，用来提高软件开发的质量和提升软件开发的效率。并结合实际软件项目案例——“国信国瑞终端销售管理系统”，将提出的双V模型应用在该项目的开发过程，进行本模型的效果分析和实例验证。关键词:CMMI；软件测试；V模型；X模型；过程域；软件测试流程
I
CMMI-basedproject-levelsoftwaretesting
Abstract
Nowadays,informationtechnologyisbecomingmoreandmoreimportant,softwareproductshasbecomeincreasinglyimportant,graduallyintegratedintothedailylife.Withtheexpansionofsoftware,technologyandstructurebecomemoreandmorecomplex,softwaretestingprocesshasbecomeincreasinglyimportant,softwarecapabilitymaturityforimprovingqualityandproductionefficiencyofsoftwaredevelopmenthasplayedavitalrole.Inordertobettersolvetheseproblem,weintroducedtheCMMI.
CMMIisdesignedtohelpsoftwareenterprisetoimprovethesoftwareengineeringprocess,enhancethedevelopmentandimprovementability,thuscanontimeandwithinbudgettodevelophighqualitysoftware.CMMIthoughtisaslongasyoufocusonthesustainedefforttoestablishaneffectiveinfrastructuresoftwareengineeringprocess,ongoingmanagementpracticesandprocessimprovement,youcanovercomedifficultiesinsoftwaredevelopment.
Inthispaper,wetotheCMMIandsoftwaretestingrelatedkeyprocessareasforanalysisandresearch,thetraditionalsoftwaretestingtheorymodel(Vmodel,Xmodel)wasanalyzedandcompared.Onthebasisoftheresearchoftwomodels,toexploreandresearchofCMMIsoftwaretestingprocess,wedesignatestmanagementsystembasedonCMMIsoftwaretestingprocess,usedtoimprovethequalityofsoftwaredevelopmentandimprovetheefficiencyofsoftwaredevelopment.Combiningwiththeactualsoftwareprojectcases--“GuosenGuoruitheterminalsalesmanagementsystem”,wewillthedoubleVmodelappliedintheprojectdevelopmentprocess,andwewillanalyzethemodelandexampleverification.KeyWords：CMMI;softwaretesting;Vmodel;Xmodel;processareas;softwaretestingprocess
II
目录
1CMMI概述.................................................................................................1
1.1CMMI简介............................................................................................1
1.2CMMI的起源........................................................................................1
1.3过程域..................................................................................................2
1.4CMMI的实施方法................................................................................5
1.5CMMI的实施流程................................................................................52软件测试关键过程域.............................................................................7
2.1CMMI过程域的四个种类....................................................................7
2.2过程管理..............................................................................................7
2.2.1组织过程聚焦(OPF).......................................................................8
2.2.2组织过程定义(OPD).......................................................................8
2.2.3组织培训(OT).................................................................................9
2.2.4组织过程性能（OPP）...................................................................9
2.2.5组织性能管理（OPM）...................................................................9
2.3项目管理..............................................................................................9
2.3.1项目策划（PP）...........................................................................10
2.3.2项目监督和控制（PMC）.............................................................10
2.3.3供方协定管理(SAM).....................................................................10
2.3.4集成项目管理（IPM）.................................................................11
2.3.5风险管理（RSKM）........................................................................11
2.3.6定量项目管理（QPM）..................................................................11
2.4工程....................................................................................................11
2.4.1需求管理（RM）............................................................................12
2.4.2需求开发（RD）............................................................................12
2.4.3技术解决（TS）............................................................................13
2.4.4产品集成（PI）............................................................................13
2.4.5验证（VER）..................................................................................13
2.4.6确认（VAL）..................................................................................13
2.5支持....................................................................................................13
2.5.1过程和产品质量保证（PPQA）....................................................14
2.5.2配置管理（CM）............................................................................14
2.5.3测试与分析（MA）........................................................................14
2.5.4决策分析和解决方案（DAR）......................................................15
2.5.5原因分析及解决方案（CAR）......................................................153软件测试理论模型...............................................................................16
3.1V模型.................................................................................................16
3.2X模型.................................................................................................17
3.3两种模型的比较...............................................................................19
3.4基于CMMI软件测试流程的研究.....................................................19
3.4.1CMMI的优点..................................................................................19
3.4.2基于CMMI的软件测试过程改进的研究.....................................204基于CMMI软件测试流程的测试管理系统的设计与案例分析验证22
4.1设计背景介绍...................................................................................22
4.1.1关于产品流程领域的确认和验证...............................................22
4.1.2测试管理工具现状分析...............................................................22
4.2设计和导入.......................................................................................23
4.3产品整合流程与测试管理工具.......................................................24
4.4测试管理系统设计...........................................................................26
4.5模型分析与案例验证.......................................................................29
4.5.1案例——“国信国瑞终端销售管理系统”项目概述..............29
4.5.2基于CMMI软件测试的项目案例理论分析与验证....................305总结与展望...........................................................................................34致谢......................................................................................................35参考文献....................................................................................................36
1CMMI概述
1.1CMMI简介
CMMI的英文全称是CapabilityMaturityModelIntegration，中文翻译过来即软件能力成熟度模型集成。它是由美国国防部、美国国防工业协会与卡内基-梅隆大学一起开发完成的。
CMMI是CMM模型的最新版本，最早的CMMI1.02版本主要运用在软件项目的管理方法。随着SEI在全世界范围内的普及推广，CMMI演变成一种被广泛运用的综合性模型。
1994年，SEI发布了CMM软件模型，之后的几年又开发出人力资源管理、集成产品、软件采购以及各种过程开发的能力成熟度模型。经过长期的实践过程，这些模型在各个软件企业得到了充分的利用，然而对一些大型软件公司而言，一种单一的模型已经不能满足企业发展的需要。随后整合不同模型的CMM应运而生。
CMMI主要用于提高各个软件公司的开发能力，改善软件工程的开发进程，按照其开发思想的要求，只要集中时间精力，持续不断地建立有效的软件工程过程的基础结构和对管理实践过程不断进行完善，最终我们将克服软件开发的种种难题。
1.2CMMI的起源
随着企业规模的发展和壮大，人们对软件产品的要求越来越高，这就促使我们需要对CMM的研究工作不断深入下去，开始陆续推出CMM模型。例如，企业管理成熟度模型、集成产品成熟度模型等等：
（1）SW-CMM(SoftwareCMM)软件CMM
（2）SE-CMM(SystemEngineeringCMM)系统工程CMM
（3）SA-CMM(SoftwareAcquisitionCMM)软件采购CMM
（4）IPT-CMM(IntegratedProductTeamCMM)集成产品群组CMM
（5）P-CMM(PeopleCMM)人力资源能力成熟度模型
[1]
为了跟其他模型区分开来，国内外很多资料把CMM叫做SW-CMM。按照SEI原先的计划，CMM的改进版本2.0应该在1997年11月完成，然后在取得版本2.0的实践反馈意见之后，在1999年完成准CMM2.0版本。但是，美国国防部办公室要求SEI推迟发布CMM2.0版本，而要先完成一个更为紧迫的项目CMMI。
CMMI开发者最初设想把现在已有的和即将被开发出来的能力成熟度模型集中放到一个框架中。根据这个思想，CMMI吸收SW-CMM2.0版本和SPA中的优点，最终CMM完成到CMMI的过度。
[2]
1.3过程域
我们一般将能力成熟度模型分为5个等级、22个过程域。5个成熟度等级分别为：初始级，可重复级，已定义级，量化管理级，优化级。这5个等级为软件过程能力的评价提供依据，最重要的是为软件开发工程遇到的问题指明了方向，进而循序渐进完成开发任务。
除此之外，我们还要提到一个重要的概念，即过程域（ProcessArea）。简单来讲，过程域就是指软件开发中，做好软件开发过程的一个方面。过程域提出我们想要达到某一个成熟度必须要解决的问题。按照设定，每个成熟度等级都有一个或者一个以上的过程域，初始级除外。
下面我们将依次讲解这5个能力成熟度模型和22个过程域（如表1-1所示）。（1）初始级
在软件开发过程中，初始级是及其混乱，没有规律可循。初始级是不存在过程域的。（2）可重复级
可重复级又叫做受管理级（Repeatable）。这一级别主要任务是建立基本的项目管理过程，功能特点等等。可重复级一共有7个过程域：●需求管理（REQM）
[4]
[3]
●项目规划（PP）●项目跟踪和控制（PMC）●供应商协议管理（SAM）●度量与分析（MA）
●过程与产品质量保证（PPQA）●配置管理（CM）（3）已定义级
已定义级的主要任务是将软件进程和管理的过程进行系统化，标准化，形成一套完善的标准软件工程。一经批准，所有开发项目将使用统一的开发过程和标准软件。
已定义级一共有11个过程域：●需求开发（RD）●技术解决方案（TS）●产品集成（PI）●验证（VER）●确认（VAL）●组织过程焦点（OPF）●组织过程定义（OPD）●组织培训（OT）●集成项目管理（IPM）●风险管理（RSKM）●决策分析和解决（DAR）（4）量化管理级
量化管理级主要是针对软件过程和产品质量进行分析考量。量化管理级一共有2个过程域：●组织过程性能（OPP）●量化项目管理（QCM）（5）优化管理级
优化管理级主要是量化过程和持续不断的改进开发过程，并提出更好的解
决方案和新思想。
优化管理级一共有2个过程域：●组织创新及部署（OID）●原因分析与决策（CAR）
表1-1成熟度等级、过程域及类别对照图
成熟度等级、过程域以及类别
过程域
英文名字
成熟度1级（初始化，Initial）所需要完成的过程域成熟度2级（项目管理，Managed）所需要完成的过程域
类别
项目策划（PP）
项目监督和控制（PMC）需求管理（RM）测量和分析（MA）
过程和产品质量保证（PPQA）
配置管理（CM）
ProjectPlanning
ProjectMonitorandControlRequirementsManagementMeasurementandAnalysis
ProcessandProductQualityAssuranceConfigurationManagementSupplierAgreementManagement
项目管理类项目管理类项目管理类工程类工程类支持类支持类
供方协定管理（SAM）
成熟度3级（过程管理，Defined）所需要完成的过程域
组织过程聚焦(OPF)组织过程定义(OPD)组织培训(OT)
集成项目管理（IPM）风险管理（RSKM）需求开发（RD）技术解决（TS）产品集成（PI）验证（VER）确认（VAL）
OrganizationalProcessFocusOrganizationalProcessDefinitionOrganizationalTrainingIntegratedProjectManagementRiskManagement
RequirementsDevelopmentTechnicalSolutionProductIntegrationVerificationValidation
过程类过程类过程类项目管理类项目管理类工程类工程类工程类工程类工程类支持类
决策分析和解决方案（DAR）DecisionAnalysisandResolution
成熟度4级（定量管理，QuantitativelyManaged）所需要完成的过程域
组织过程性能（OPP）定量项目管理（QPM）
OrganizationalProcessPerformanceQuantitativeProjectManagement
过程类项目管理类
成熟度5级（过程优化，Optimized）所需要完成的过程域
组织性能管理（OPM）原因分析及解决方案（CAR）
OrganizationalPerformanceManagementCausalAnalysisandResolution
过程类支持类
1.4CMMI的实施方法
大体上说，一般企业想做CMMI，大致有如下几个步骤：（1）项目需求，决定使用CMMI；
（2）EPG[5]（过程改进小组）开始接受系统培训，深入掌握CMMI；
（3）EPG根据自己学习的情况和具体在软件开发过程中遇到的困难写出自己的解决方案；
（4）将所学的记录下来，运用到实践中；
CMMI有两种不同的实施方法，方法不同所代表的级别自然就不同。CMMI两种实施方法：连续式和阶段式[6]。
（1）连续式：这种方法主要用于衡量一个公司或企业的项目能力，任何一个企业在选择一个项目的时候，根据自己的任务需求，它的评估通过的的概率就很大，然而它在反应问题上面就相对要窄。
（2）阶段式：这种方法主要是衡量一个公司或企业在项目实施上的综合能力，即企业的成熟度。具体说就是，一个企业在进行项目评估的时候，需要专业的评估师对企业的每个项目进行细致的研究。一般来说，绝大多数的企业项目要达到三级，少数达到二级以上，不允许出现一级项目，这样企业在评估中才有可能达到三级。
1.5CMMI的实施流程
（1）CMMI项目启动会
确切了解企业实施CMMI实施的商业目标，建立一个完善的CMMI项目实施沟通机制；
（2）建立CMMI基础培训和过程改进小组
进行CMMI的基础概念培训，辅导企业建立核心过程改进小组；（3）发现问题、及时诊断
深入企业了解企业现状，及时发现企业现阶段存在的弊端，提交错误报告，并对企业成熟度级别有一定的了解。（4）过程域培训和文件定义
了解企业现状之后，利用CMMI过程域培训成果，通过一系列的分析报告，最终确定需求报告；
（5）项目试点
从所有项目中选出一个能够代表公司的项目作为试点，并依此来完善过程文件；
（6）组织推广
组织团结企业自身的力量参与CMMI；
（7）预评估
验证组织推广的结果，再次发现企业中的弊端，进行二次改进；
（8）正式评估
通过SEI权威授权评估师进行评估，采用目前最先进的SCAMPI评估方法，对企业的能力成熟的进行评估，一旦通过，颁发荣誉证书。[7]
2软件测试关键过程域
2.1CMMI过程域的四个种类
从第一章表1-1可以看出，我们把软件测试22个过程域划分为四个类别：过程管理类、项目管理类、工程类、支持类。这样划分为四个类别为我们对软件测试过程域的分析研究提供了方便。
过程管理类：组织过程聚焦(OPF)、组织过程定义(OPD)、组织培训(OT)、组织过
程性能（OPP）、组织性能管理（OPM）
项目管理类：项目策划（PP）、项目监督和控制（PMC）、供方协定管理(SAM)、集
成项目管理（IPM）、风险管理（RSKM）、定量项目管理（QPM）
工程类：需求管理（REQM）、需求开发（RD）、技术解决（TS）、产品集成（PI）、
验证（VER）、确认（VAL）
支持类：过程和产品质量保证（PPQA）、配置管理（CM）、测试与分析（MA）、决
策分析和解决方案（DAR）、原因分析及解决方案（CAR）[8]
2.2过程管理
过程管理PA内容包括定义、计划、部署、资源支持、配置、控制、评估、改进等各种项目。过程管理分为：组织过程聚焦(OPF)、组织过程定义(OPD)、组织培训(OT)、组织过程性能（OPP）、组织性能管理（OPM）[9]。
过程管理过程域，如图2.1所示：
图2.1基本过程管理过程域
2.2.1组织过程聚焦(OPF)
OPF是软件能力成熟度为3级的过程域，包括的内容有充分掌握组织过程中软件进程的状况，对软件进行评估、检测、完善。其主要目的是为提高整体软件过程能力打下基础，建立软件活动过程责任。
OPF过程域实现步骤如下：
确认过程改进机会
筹划并完成过程改进项目
部署标准过程及将经验归入过程财富
2.2.2组织过程定义(OPD)
OPD指的就是在组织层上SEPG定义软件的过程，内容有组织维护标准软件过程，保护软件过程相关财富。
这里我们提到组织标准软件过程，具体包括以下方面：描述软件过程体系结构、描述过程元素。
OPD目标有两点：
组织维护标准软件过程
查找、评估和完善相关使用组织标准软件过程的资料。
2.2.3组织培训(OT)
OT的目的是为使组织达到软件能力成熟度的第三级提供资源保障。
OT主要有两个目标：
（1）为各种软件管理技术相关知识提供专业系统的培训
（2）为软件管理技术的相关工作成员提供组织责任上的培训
2.2.4组织过程性能（OPP）
OPP是软件能力成熟度达到4级的过程域，主要目标任务是建立性能基线和模型。
2.2.5组织性能管理（OPM）
OPM是软件能力成熟度达到5级的过程域，主要目标和步骤是维护商业目标、分析性能数据、收集改进意见、完成部署。
2.3项目管理
项目管理类指包含跟项目计划相关的项目管理活动。项目管理类分为：项目策划（PP）、项目监督和控制（PMC）、需求管理（RM）、集成项目管理（IPM）、风险管理（RSKM）、定量项目管理（QPM）。
项目管理过程域如图2.2所示：
图2.2基本项目管理过程域
2.3.1项目策划（PP）
PP是软件能力成熟度为2级的过程域，其实现目标为：
（1）估计项目生命周期、工作量和工作成本
（2）初步预测项目进度并确定项目计划
（3）最终获取计划承诺
2.3.2项目监督和控制（PMC）
PMC是软件能力成熟度为2级的过程域，其实现目标为：
（1）分析项目计划参数和项目风险
（2）一旦出现风险立即纠正
2.3.3供方协定管理(SAM)
SAM是软件能力成熟度为2级的过程域，其实现目标为：
（1）签订供应协议
（2）执行协议并提交产品
2.3.4集成项目管理（IPM）
IPM是软件能力成熟度为3级的过程域，其实现目标为：
（1）完善项目定义过程，建立一个良好环境
（2）平衡各种利益关系
2.3.5风险管理（RSKM）
RSKM是软件能力成熟度为3级的过程域，其实现目标为：
（1）分析制定风险管理策略
（2）风险识别
（3）解决风险
2.3.6定量项目管理（QPM）
QPM是软件能力成熟度为4级的过程域，其实现目标为：
（1）制定管理准备
（2）对项目进行管理、分析原因
2.4工程
工程类包括：需求管理（REQM）、需求开发（RD）、技术解决（TS）、产品集成（PI）、验证（VER）、确认（VAL）。
工程管理过程域如图2.3所示：
图2.3工程管理过程域
2.4.1需求管理（RM）
根据以往的经验，在软件开发过程中，在需求阶段出现错误的概率远远大于在编码阶段出现错误的概率。因而需求管理在软件测试过程中处于一个极为重要的地位。
RM简言之，就是对分配需求进行管理。主要任务是为软件过程建立基线，保持软件与软件活动的一致性，尽最大可能满足客户对软件功能的需要。
RM实现步骤有如下：
（1）确认完善分配需求
（2）随时根据需要对分配需求进行更改
2.4.2需求开发（RD）
RD是软件能力成熟度为3级的过程域，实现目标有：
（1）获取客户需求
（2）建立产品需求
（3）确认需求
2.4.3技术解决（TS）
TS是软件能力成熟度为3级的过程域，实现目标有：
（1）提前准备问题解决方案
（2）开始设计
（3）完成设计
2.4.4产品集成（PI）
PI是软件能力成熟度为3级的过程域，实现目标有：
（1）建立产品集成环境
（2）检查接口是否完整
（3）交付产品组件
2.4.5验证（VER）
VER是软件能力成熟度为3级的过程域，实现目标有：
（1）建立验证环境，开始验证
（2）分析同行评审数据
（3）分析验证结果
2.4.6确认（VAL）
验证完成之后我们进行确认，VAL是软件能力成熟度为3级的过程域，实现目标有：
（1）建立确认环境，开始确认
（2）分析确认结果
2.5支持
支持类包括：过程和产品质量保证（PPQA）、配置管理（CM）、测试与分析（MA）、决策分析和解决方案（DAR）、原因分析及解决方案（CAR）。支持类主要目的在于产品的开发与维护[10]。
基本支持过程域如图2.4所示：
图2.4基本支持过程域支持过程域涵盖了支持产品开发、维护、产出等方面的活动。他们通过CMMI过程域来提供一些经使用的重要的过程，并在执行其他的过程中代表性的使用这些过程[11]。
2.5.1过程和产品质量保证（PPQA）
PPQA是软件能力成熟度为2级的过程域，实现目标有：
（1）准确评价工作过程
（2）出现问题，找出对应的解决方案
2.5.2配置管理（CM）
CM是软件能力成熟度为2级的过程域，实现目标有：
（1）建立配置管理系统
（2）追踪控制请求
（3）完善管理记录
2.5.3测试与分析（MA）
MA是软件能力成熟度为2级的过程域，实现目标有：
（1）建立测量目标并采集数据
（2）分析测试数据
2.5.4决策分析和解决方案（DAR）
DAR是软件能力成熟度为3级的过程域，实现目标有：
（1）建立决策方案
（2）评价决策方案
（3）确定决策方案
2.5.5原因分析及解决方案（CAR）
CAR是软件能力成熟度为5级的过程域，实现目标有：
（1）找出缺陷所在
（2）分析出现问题的原因
（3）提出解决方案
（4）记录解决结果
3软件测试理论模型
3.1V模型
当前在软件项目开发过程中有两种最常见的测试模型：V模型和X模型。首先，我们对V模型[12]进行详细的介绍。
V模型是软件测试中最被广泛使用的一种测试模型，如图3.1
所示。
图3.1V模型
看上图，这种形似英文字母V的软件测试流程我们称为V模型。从左到右，V模型详细地描述了软件测试的流程的测试行为。软件测试流程依次顺序为：需求分析，概要设计，详细设计，编码，单元测试，集成测试，系统测试，验收测试。V模型的右半段，即单元测试，集成测试，系统测试，验收测试称之为测试阶段。其中后一个开发阶段的输入由前一个阶段提供[13]。
在V模型中，单元测试是在代码的基础上进行测试，主要用来验证可执行程序的代码能否达到预期的功能需求；
集成测试用来验证单元与单元之间集成的正确性，并对详细设计中定义的单元接口进行检查；
系统测试验证系统是不是达到了概要设计中定义的功能和性能；
最后，验收测试阶段由评测小组进行评估和验收，保证产品满足客户的需求。V模型的优点及其价值：
V模型非常明确地告诉我们测试过程中存在的不同级别，同时详细的描述了这些测试阶段和开发过程期间各阶段的对应关系。
从上面V模型图可以看出，测试跟开发过程是平等的，也就是说两者在软件测试过程是同样重要的。
V模型的缺陷：
我们容易误解把测试过程当做需求分析，概要设计，详细设计及编码之后的一个阶段，这样我们很容易忽视对需求分析和系统设计的验证，甚至有些错误一直到验收测试阶段才被发现，这样我们反复改变需求设计，修改代码困难极重，返工量极大[14]。
适用范围：小型项目，规模比较小的公司。
3.2X模型
前面提到V模型，还有一种比较常见的测试模型：X模型，相较于V模型，X模型运用不是十分广泛，但也是我们必须掌握的一种测试模型。X模型如图
3.2所示。
图3.2X模型
如图3.2所示，这种形似英文字母X的测试模型称之为X模型。X模型左半部分描述的是针对单独程序片段所进行的相互分离的编码和测试，然后通过反复地交接，集成为能够执行的程序，最后对这些可以的执行的程序进行测试[15]。
从上面的X模型图还可以看出，X模型还定义了探索性测试，这一过程是X模型软件测试中非常重要的一环，通过这一步骤软件测试人员可以发现更多的错误信息，有利于节约软件开发的成本。
X模型的优点及强项：
X模型的优点我们可以参照V模型的缺点进行分析，不难发现，X模型解决了V模型中存在的大量返工这一难题，不会出现直到验收测试发现有错误而重新更改需求分析的问题，解决软件产品交互、反复冗余的集成等等问题，减少软件开发的周期，从而在保证软件质量的前提下，大大提高软件测试的效率。
X模型的缺陷：
显而易见，X模型没有遵守软件开发的常规步骤，在软件测试开始时，没有对需求分析进行细致的分析和编写工作，造成软件成熟能力较低，使得测试和软件开发结合不是十分紧密，为后面测试阶段的进行埋下了隐患。
3.3两种模型的比较
前面两节我们介绍了V模型和X模型，接下来我们对这两种模型进行一个简单的比较。
从使用频率来看，X模型虽然在一定程度上缩短软件开发的周期，提高了软件开发的效率，但V模型将测试与软件开发紧密结合起来，得到更多企业的认可，因而被广泛适用。
从适用范围来看，V模型适用于中小项目、一般的小型企业，X模型适用范围相对较广。
3.4基于CMMI软件测试流程的研究
纵观基于CMMI的测试流程，我们在具体操作过程中，主要是针对两种理论模型中的V模型进行研究，详细按照V模型的流程，需求分析，系统设计，编码，单元测试，集成测试，系统测试，验收测试，每一个步骤都不能颠倒或遗漏。具体到每一个测试环节我们按照另外一种理论模型-X模型进行。
3.4.1CMMI的优点
能力成熟度模型最早是由美国卡内基梅隆大学软件工程研究所提出的。前面提到，CMMI模型主要有两种表现形式，连续型和阶梯型，其中连续型指的是软件测试的能力等级，阶梯型指的是成熟能力等级。这两种模型在某种程度极大促使软件测试的发展。
具体CMMI在软件测试改进过程中发挥了哪些作用？
（1）CMMI极大地扩展了软件测试的周期
在进行软件生命周期测试的每一个阶段，我们都要对软件开发的各个阶段的每个产品进行验证。这样极大地保证在软件开发过程中尽量出现差错，进而大大降低软件开发过程的风险，缩短了软件测试的周期。这样我们可以极大避免出现等到编码完成之后出现错误而造成大量返工的问题[16]。
（2）CMMI极大地提高了软件测试在开发中的地位
与我们所了解的瀑布模型相比而言，CMMI模型指出软件测试和整个软件开
发过程是同时进行的，并不存在主次之分。CMMI模型把软件测试当做软件开发过程的一种辅助管理手段，从而实现了定性到定量的转化。
（3）CMMI使软件测试成为防止缺陷的有效手段
CMMI出现后，软件测试由原来的事后测试行为转变成为一种全称测试和分析行为，这种根据对数据测试的统计分析，以此来预测未来软件产品，相信这不是一种事后弥补的质量管理方式。这种软件测试方式与传统的测试相比，极大缩短了项目开发的周期，降低了软件产品出现质量问题的风险。
3.4.2基于CMMI的软件测试过程改进的研究
研究软件测试过程模型，在两种理论模型（V模型和X模型）的基础上下面我们提出一种新模型，这种模型不同于前面两种模型，我们加以改善，出现的一种新型模型，我们称之为双V模型。双V模型如下图3.3
所示：
图3.3双V模型
如上图所示，我们称之为双V模型，我们知道CMMI最适合于迭代模型中软件开发的改进，但是迭代模型在某种意义上我们可以当做瀑布模型，每经历依次迭代看做依次软件生命周期，所以双V模型也适用于迭代模型的开发。
双V模型中，模型的左半部分表示软件的验证测试，依次有系统规格验证，
需求验证，总体设计验证和详细设计验证，主要是对软件设计阶段代码和规格说明的。而模型的右半部分则代表软件的确认测试，包括系统确认，验收确认，集成确认，单元确认等四个阶段。这四个阶段对应开发周期的测试阶段，验证测试一旦完成将进行确认测试。在每个设计阶段完成后，我们不仅要完成设计工作，还要完成对应的确认测试，从图中画出的虚线可以看出这一点[17]。
从下面的图3.4可以看出，软件测试与软件开发不再是两个相互独立的阶
段，而是两个平行发生，同等重要的阶段。
图3.4（上面是开发周期，下面为测试周期）
4基于CMMI软件测试流程的测试管理系统的设计与
案例分析验证
4.1设计背景介绍
为了让软件测试具体落实在软件开发过程中，我们通过软件测试的验证与确认，参考能力成熟度整合模型中的产品整合流程，设计出一套测试管理系统。利用差异分析、流程定义、流程部署等等一系列的流程分析过程，设计测试管理系统，详细定义测试相关流程，从而开展相关的测试活动，严格按照CMMI软件测试流程和过程域，改善软件测试管理工作。
4.1.1关于产品流程领域的确认和验证
在CMMI中，工程流程领域主要有过程管理、产品集成、需求开发、需求管理、技术解决方案、确认、验证这6个流程管理。产品集成领域包含三个具体的目标，从而在尽可能最好的集成度，产品组件的集成，以及客户的产品交付顺序。在整合过程中，产品一体化进程的核查和验证的具体实施方法，集成配套产品，组件的产品组合，以确保集成产品的正常运作，并提供产品的实施。在现场确认过程中的主要作用，逐步验证是否符合客户的需求，以减少出错的概率。在操作环境中的或模拟的环境，这可以进行，协调与客户所确定的需要，在此过程中的一个重要组成部分。验证过程中的主要作用是要确保选定的工作产品满足他们的特定需求。验证通常是一个渐进的过程验证，产品成分，并最终完全组装的产品的验证。
4.1.2测试管理工具现状分析
测试管理工具指的是使用特定的工具对软件测试的过程和结果进行管理。利用测试管理工具的优点有很多，例如：缩短测试时间、提升软件测试的质量、明确测试的结果。下面简单介绍市场主要的几种测试管理工具。
（1）ClearQuest:
ClearQuest是由IBM公司生产的一款测试管理工具。主要作用是对软件测
试中产品缺陷和功能提供管理记录和流程跟踪。它可以对管理流程提供查询和定制功能。它可以使用客户端服务器结构和浏览器和服务器结构进行架构，不过浏览器和服务器结构必须要建立一个web服务器，用户才能使用ClearQuest系统进行登录。
（2）QACenter
QA中心是康普柯伟迅软件服务公司开发的一个测试管理工具。QA中心测试帮助测试应用系统，这样软件的质量可以得到保证。开发和测试团队的测试平台环境是从一个单一的控制点到一个环境平台。它还可以建立一个共享测试资源，这样测试人员和管理人员可以利用资源对测试结果进行存储和查询。需求主导项目来开发应用软件，以及驱动器的测试计划。项目组通过该文件，需求管理和需求规划和测试，以确保应用系统，以满足用户的需求。该项目需要通过需求管理界面，存储在一个集中的数据库，你可以使用微软的Word，查看和浏览需求和审核（审计）报告，或在网络的变化。
（3）TestDirector：
TestDirector测试管理工具是由MercuryInteractive公司生产研发的一种测试管理工具。它可以在世界范围内，不仅在公司内部，在公司外部也可以进行管理测试。TestDirector是基于web应用软件的测试管理工具，它将软件测试过程系统化，可以让测试人员和开发人员共享一个数据仓库，从测试需求管理一直到测试结果，只需要通过web浏览器就可以完成，极大方便了软件测试流程。
4.2设计和导入
系统设计和导入过程可分为三个主要阶段:
（1）差异分析的主要目的，了解本组织的现状，能力成熟度模型集成过程所需区域的差异程度。在这个阶段，在分析差异的程度上，以改善该问题的计划必须建立，以此为基础进行作为后续执行。
（2）流程定义起着非常重要的作用，在ML3过程领域的需求中。ML3主要的工作就是要明确企业的流程定义，业务流程标准化，企业经营程序的组件，流程组件的必须是独立的，每个组件中等大小，用来支持量化管理。定义的流程，必须进行评估和修正，才能真正满足实际工作的要求。
（3）流程部署实施和系统的分析，包括实作与导入，通过系统分析的方法，把定义的流程，设计和实施信息系统，选择一个经验丰富的团队进行评估使用成果。
4.3产品整合流程与测试管理工具
CPMS产品集成过程主要讨论操作程序的产品在符合CMMI的CPMS要求的一体化进程，并把它转换成一个测试管理工具的要求规范，打造符合的CMMI规范的支持管理工具。基于CMMI的项目管理系统（CPMS）是特有的工作案管理和研发作业程序。CPMS产品一体化流程是由CMMI产品流程领域特定目标和特定实务延伸而来。为了满足CMMI的需求，我们已经定义出了一种流程组件，并确定实施步骤，以满足特定的目标和具体做法，规范的流程组件[18]。PI-100运行程序的过程组件的作业流程一共有五个步骤，涵盖SP1.1SP1.2，SP1.3，SP2.1，SP2.2规范要求。如图4.1
所示：
图4.1PI-100流程
CPMS产品集成领域的四个主要流程组件，如图4.2所示，在运作程序过程
中，验证（VER）和确认（VAL）的整合过程领域工作是至关重要的。例如，在PISG2确保接口的兼容性要求，SP2.1审查界面说明的完整性，要达到操作的要求，在执行PI-100系统测试计划产品整合流程组件时，必须参照验证流程组件，辅助工作案完成PI-100建立系统测试计划流程组件，最终输出系统测试计划书。其他流程领域的实施PI，CPMS产品整合流程的输出文件的测试文件有：系统测试计划书，系统测试规范书，集成测试报告书，运行报告书，测试和验收测试报告书。
汇整产品规格一体化进程,，CPMS流程组件和系统要求如表4-1所示。基于规范的的CPMS产品的整合流程规范，我们提出了一个测试管理信息系统必须包含文本文档管理，需求管理，测试执行，异常跟踪，统计报表和文档管理等功能模块，辅助测试单位和开发单位测试。例如，CMMI产品的整合进程的首要工作是做好SG1准备产品的整合。对应CPMSPI-100创建一个系统测试计划和PI-200开发系统的测试程序，在工作案管理功能模块进行实践，使系统建立和控制测试案例的版本及其他相关信息，以帮助用户产生操作或验收测试程序和案件[19]
。
图4.2CMPS流程组件
表4-1CPMS
流程组件与系统需求
4.4测试管理系统设计
我们提出了一个测试管理信息系统，主要包含有：工作案管理，需求管理，
测试执行，异常跟踪，统计报表和文档管理等功能模块。本节介绍了测试管理系统的流程和结构,如图4.3所示。通过需求分析，测试管理系统和辅助组织来实现的CPMS[20]产品整合过程,如表4.1,CPMSPI-100创建一个系统测试计划，PI-200的测试程序开发的系统，其目的：设计出系统测试计划书作为未来系统测试的基础;生成系统的测试规范书，定义测试方法和评价标准来作为实施系统或系统组件的验证和确认的基础。测试管理系统的需求有：该系统可以创建一个测试案例和版本信息，以帮助用户产生操作或验收测试的测试程序和案例，以做好测试引线工作。
图4.3测试管理系统流程和结构
根据需求分析的结果，我们设计测试管理系统模块如图4.4所示，在开始建
立情况和系统要求的测试单元，然后创建一个测试案例，然后选择测试用例，执
行测试。测试结束后由开发商提出异常反应，试验单位负责跟踪校正异常情况。开发单位和检验单位交换了意见，讨论细节或提出相关建议的工作文本，并最终输出测试报告。
图4.4测试管理系统模型
系统分为6个功能模块如图4.4所示,包含:
(1)工作案管理。测试工作案主要是以版本为测试的单位,一个工作案可依测试次数有多个版本。在一个版本异常结果皆被解决之后,才可再开新版本进行测试。在工作案版本管理内,提供了增加、删除和修改版本的功能。测试工作案可分别建立、删除和修改所属的测试案例。并让测试工作案的各版本选择测试案例进行测试。
(2)系统需求管理。测试工作案可根据系统需求规格书建立、删除和修改工作案的系统需求。测试案例建立时会与系统需求做关联,确定测试案例符合系统需求规格书的系统需求。当开发单位修改程序时只需提供修改的部分与哪些系统需求有关,系统便可经由系统需求追溯矩阵自动筛选所需测试的测试案例。
(3)测试执行。测试单位可利用执行测试填写测试结果和测试概况,并将测试案例的执行测试结果,归类为正常、严重异常、异常、轻微异常和建议5类,且必须针对异常情形进行说明。
(4)异常追踪。当测试案例的测试结果为严重异常、异常或轻微异常时,开发单位可依据测试单位所提出的异常说明进行修正系统的动作。修正完成后,即可利用异常回复功能,回复异常的原因和修正的情形。测试人员可根据异常追踪的功能,追踪异常发生的原因及开发单位是否已解决异常,达到测试人员和开发单位沟通的目的。另外,开发单位与测试单位可在此交流各版本的意见,增加彼此间的互动。
(5)统计报表。统计报表内包含异常数、异常分类及工作案或版本的各项统计信息,且依权限的不同,能看到不同的信息,也可设定显示字段及筛选数据内容客制化产生报表。
(6)文档管理器。系统可协助使用者产生测试报告和运转测试记录表,减少使用者撰写文件的时间。
4.5模型分析与案例验证
4.5.1案例——“国信国瑞终端销售管理系统”项目概述
1、项目概述
安徽国信通信有限责任公司是一家从事电信通讯终端设备销售的企业，下设
多个销售中心，和多家供应商、分销商存在密切的业务往来。随着业务规模的不断扩大，管理者发现原有的管理模式信息反馈慢，数据不准确，无法给管理者、决策者提供有效的支持，迫切需要建设一套综合进销存、财务管理于一体的计算机信息管理系统，实现对资金流、物流、信息流的全面管理。
2、项目目标
项目名称：国信国瑞终端销售管理系统
用户：安徽国信通信有限责任公司
开发者：安徽和信科技发展有限责任公司软件研发部
项目目标：实现基于计算机网络的仓储管理系统、销售管理系统，采购管理系统、应收应付管理系统、基础数据管理系统，并且提供各种查询和报表。
3、交付的产品,产品表如下：
表4-2交付产品图
4、约束与假设
约束：此项目根据实际的启动时间。
假设：用户需求可能会发生变化，将导致返工，加大工作量。
5、项目组织
项目组织结构图如下4.5所示：
项目经理
需求分析工程师
设计工程师开发工程师测试工程师配置管理员
图4.5项目组织结构图
4.5.2基于CMMI软件测试的项目案例理论分析与验证
1、基于双V模型的项目测试分析
项目开发方式：由于用户对项目需求表达的比较明确，且用户需求比较稳定，项目周期比较长，所以选择瀑布型生命周期模型，每次经历一次迭代可以看做一次软件生命周期。
项目阶段划分及主要工作产品如下：
表4-3项目阶段与工作产品图
项目进度计划甘特图如4.6所示：
图4.6项目进度计划甘特图
项目进度
1、前期准备阶段2、需求分析阶段3、基础数据收集4、需求确认5、系统设计
系统规划阶段
双V模型
制定系统确认计划
需求分析阶段制定验收测试计划
总体设计阶段制定集成测试计划
6、系统功能开发6、系统功能开发
详细设计阶段制定单元测试计划
编码阶段制定代码测试任务
7、系统测试
测试期
制定测试期任务
项目部署
图4.7双V模型的案例应用
如上图4.7，我们将双V模型应用在“国信国瑞终端销售管理系统”项目中，阶段1是前期准备阶段，我们进行系统规划阶段。阶段2、3、4分别为需求分析阶段，基础数据采集和需求确认，对应双V模型的需求分析阶段。阶段5进行系统设
计，对应总体设计阶段。阶段6进行的是系统功能开发，对应详细设计阶段和编码阶段。阶段7对应进行系统测试，对应的是测试周期。根据双V模型的测试计划，我们每个设计阶段完成后，不仅要完成设计工作，还必须完成相应的确认测试。阶段1制定系统确认计划，阶段2、3、4制定系统验收测试计划，阶段5制定集成测试计划，阶段6根据上一阶段制定的单元测试计划执行代码测试任务，阶段7根据前一阶段制定的集成测试计划和验收测试计划执行测试期任务，最后进入项目部署期。
这样通过双V模型的提前测试计划干预，可以尽早在开发周期中合理高效地安排测试工作，通过分阶段、分力度的测试任务的执行，进一步提高测试效率，达到了项目级的软件测试效果。
2、基于“测试管理系统模型”的理论分析验证
软件测试是为了发现错误而执行程序的过程，其目的在于在产品投入生产运行之前，尽可能地发现并排除软件中隐藏的错误，从而提高软件的质量。因此我们要想提高项目的开发效率，就必须要提高软件测试的效率。
针对测试管理系统的用户角色，在原有的角色上我们增加一项PPQA角色。PPQA是把对过程及其相关工作产品的客观的洞察结果提供给项目的开发人员和管理人员。增加PPQA人员这一使用角色，我们可以按照所用的过程描述、标准和规程客观地评价执行的过程、工作产品、以及服务标识并记录问题，将质量保证活动结果反馈给项目人员和管理者，确保CMMI度量标准的贯彻执行。
“国信国瑞终端销售管理系统”中我们使用LDAP权限分配管理，LDAP即轻量目录访问协议，它是一种特殊的数据库，是一个比关系数据库抽象层次更高的存储概念。在进行项目管理时，LDAP对查询进行了优化，在大数据量的情况下效果很明显。
个性化服务的作用主要是为了不同的角色的人员提供具体的不同分工的工作支持。
本测试管理系统的6大功能模块协作运行流程如下：“工作案管理”模块以版本为测试单位，工作案版本管理内进行增加、删除和修改功能，测试工作案的各版本选择测试案例进行测试，随后进行“执行测试”模块，最终产出测试结果，并将测试结果归类。“系统需求管理”模块建立系统需求规格书，确认测试案例
符合系统需求规格书的系统需求，紧接着进行“异常追踪”模块，对测试结果的不同情形进行分析。“统计报表”模块包含工作案和版本的统计信息，我们使用“文档管理器”模块产生测试报告和测试记录表，减少文档的撰写时间。
5总结与展望
随着上个世纪90年代美国联邦航空管理局开发出CMM模型以来，随后的十几年时间里，软件测试这项技术逐渐走向成熟，在计算机软件测试领域大放异彩，相信在不久的未来，这门技术将得到更为广泛的普及和发展。
基于CMMI的项目及软件测试的研究，在计算机领域非常重要的一项技术。要想深入了解和掌握掌门技术，首先，我们必须了解什么是CMMI？CMMI的来源和介绍，CMMI的5个等级和22个过程域，接着我们了解在软件测试过程中遇到的一些专业术语，最后我们还要重点掌握CMMI的实施方法和实施流程，这是掌握CMMI的关键所在。
第二章重点介绍到软件测试的过程域，我们不仅要知道软件能力度的等级和过程域，还要深入理解其中重要的过程域，比如，需求管理，配置管理，产品的集成，验证和确认等等。这些只有清楚地了解这些过程域的特点和目标，才能彻底掌握软件测试过程域。
第三章引入两种理论模型——V模型和X模型。学完之后，分析了两种模型各自的优点和缺点，并对两者做一个比较，在不同的项目中采取哪一种更合理。
第四章基于CMMI软件测试流程的测试管理系统的设计。我们设计出一套测试完善的测试管理系统，严格执行CMMI软件测试流程和相关过程域，让软件测试应用于具体的软件开发过程中。
这篇论文主要阐述了CMMI详细内容及过程域和目前的测试流程V模型和X模型，并在此设计出一套测试管理系统，主要工作是开发这个系统，验证其效率。并结合实际软件项目案例——“国信国瑞终端销售管理系统”，将提出的双V模型应用到该项目的开发过程，进行本模型的效果分析和实例验证。
致谢
至此，我以基于CMMI的项目级软件测试的研究为题的毕业论文全部完成。首先，我感谢指导老师沈老师在工作繁忙的情况下，抽出时间对我的毕业论文进行指导和帮助，我相信没有沈老师的耐心指导，我很难在这么短的时间内顺利完成毕业论文。我记得当初选题的时候，我由于自身的原因，没有找到合适自己的选题方向，沈老师及时伸出援手，为我指明了方向。至此，我对所有给予论文帮助的指导老师表示崇高的敬意。
其次，我要感谢几位大学校友的，临近毕业之际，由于自身工作的缘故，论文申请报告和中期检查报告没来得及完成，好在在校友的帮助下，顺利交到指导老师手中。对此，我表示衷心的感谢，没有你们的帮助我不能够及时顺利地完成毕业论文。
最后，感谢审阅和参加论文答辩的每位老师，由于时间的原因，毕业论文完成有些仓促，希望你们给予批评和指正，再次表示感谢。
参考文献
[1]六西格玛和CMMI集成软件过程改进应用研究，张哲，天津大学，2006.
[2]在中国外资企业实施CMMI过程改进的研究，江伟桥著，华南理工大学，2006.
[3]CMMI精粹（第三版），王辉青、战晓苏著，清华大学出版社，2009.
[4]基于CMMI的软件测试流程；朱瑞志，张忠能，田小鹏；计算机工程，2004年第S1期.
[5]基于CMMI过程框架的企业应用研究，郭红霞著，同济大学软件学院，2009.
[6]基于CMMI的敏捷软件改进过程研究，陈斌著，中国海洋大学，2009.
[7]笑傲测试——软件测试流程方法与实施，魏伟著，清华大学出版社，2007.
[8]软件测试：跨越整个软件开发生命周期，郭耀著，清华大学出版社，2008.
[9]企业信息化能力成熟度的研究，杨一平著，首都经济贸易大学，2009.
[10]从测不准原理看软件测试的不充分性，吉向东著，自动化技术与应用，2008.
[11]软件生产能力成熟度模型（SW-CMM）的研究，王永军等著，沈阳师范学院学报，2002.
[12]一种基于V模型的嵌入式软件测试方案，奚雪峰著，信息技术，2004.
[13]基于CMMI的软件测试研究与实践,朱瑞志著，上海交通大学，2004.
[14]军事代表系统采用CMMI控制军用软件质量的研究，姜河著，四川大学著，2006.
[15]CMMI+敏捷整合开发：更快改进性能的案例与实用技术，PaulE.McMahon著，清华大学出版社，2012.
[16]ISO9000与CMM模型的比较，徐欣威著，计算机应用研究，2002.
[17]V模型及CMMI模型中的软件测试分析；李晓琳，刘晖；计算机工程与科学,2006年第12期.
[18]一个基于web的软件过程评估工具，廖力著，东南大学，2004.
[19]CMMI精粹（第三版），王辉青、战晓苏著，清华大学出版社，2009.
[20]软件工程导论（第五版），张海藩编著，清华大学出版社，2008.
百度搜索“爱华网”,专业资料,生活学习,尽在爱华网
