CMM测试流程
2013-06-05 22:36阅读：
1.相关背景
CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model
for
Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
能力等级 特点
关键过程 第一级 基本级
软件过程是混乱无序的,对过程几乎没有定义,成功依靠的是个人的才能和经验,管理方式属于反应式
第二级 重复级
建立了基本的项目管理来跟踪进度.费用和功能特征,制定了必要的项目管理,能够利用以前类似的项目应用取得成功
需求管理,项目计划,项目跟踪和监控,软件子合同管理,软件配置管理,软件质量保障
第三级 确定级
已经将软件管理和过程文档化,标准化,同时综合成该组织的标准软件过程,所有的软件开发都使用该标准软件过程
组织过程定义,组织过程焦点,培训大纲,软机集成管理,软件产品工程,组织协调,专家审评 第四级
管理级
收集软件过程和产品质量的详细度量,对软件过程和产品质量有定量的理解和控制
定量的软件过程管理和产品质量管理
第五级 优化级
软件过程的量化反馈和新的思想和技术促进过程的不断改进
缺陷预防,过程变更管理和技术变更管理
1.初始级
初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证
时，那么它仍然被视为初始级。
2.可重复级
根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐进化和成熟。第二级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
3.定义级
在第二级仅定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求
制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出与项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。
4.管理级
第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正变成为一种工业生产活动。
5.优化级
第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果一个企业达到了这一级，那么表明
该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。
CMM理念
CMM主要理念之一就是加强过程控制，认为只要开发的过程按照规定动作执行，就可以很大程度上降低软件开发的质量、进度风险。而过程质量控制的主要手段就是检视。
CMM的理念之二是根据经验数据指导新的软件开发项目。CMM定义了监控软件开发过程是否规范的一系列指标，如软件生产率、检视缺陷密度、遗留缺陷密度等，并总结了同业的一些经验数据。当执行实际项目时，以这些经验数据指引开发过程，尽量使开发的关键质量指标落入经验数据区间。同时进行进一步分析总结，对质量目标进行修正，用以指导后续的新项目。通过在一个个的项目逐渐总结修正，最终得到一套适合自己的质量目标。
CMM的理念之三，也可以说是本质，是基于传统的瀑布软件开发模型的。
CMM全流程
CMM软件开发规范的流程。CMM规范基于瀑布软件开发模型，没有体现基于原型逐步求精的思想，这也是近年来在实施中为人所诟病的一个方面。下面结合IPD流程阐述一下CMM流程在公司实际的应用。
CDP-Charter
CDP即
Charter开发项目，主要的责任主体是Marketing团队和SE，目标是定义一个产品版本所要解决的主要目标和时间点，交付件是Charter。
Charter要通过BMT，即业务管理团队的批准。Charter需要回答这些问题：版本的Top
N需求和主要竞争需求，主要目标客户，完整的包需求，版本的里程碑时间点，应用的时间窗口以及在版本火车中所处的位置。
Charter-TR1
TR1即产品概念完成里程碑，主要的责任主体是SE团队，同时Marketing配合完成需求的细化、澄清和修订。这个阶段的目标是输出设计需求。相比包需求，设计需求粒度更细，能够清晰的描述每一个需求，包括每个需求的输入、输出参数，并输出低保真界面原型。
CDCP
CDCP即Concept Decision Check
Point，近年来大部分项目都裁剪，具体作用不明。
TR1-TR2
TR2即产品设计完成里程碑，主要的责任主体是SE团队。这个阶段的输出是设计规格。相比设计需求，设计规格从系统架构的角度将每个设计需求分配到每个子系统，并定义每个子系统之间新增、修改的接口。接口必须详细定义到足以指导开发人员实现的程度，可能部分没有注意到的细节可以在后续开发过程中澄清，但总体的接口设计是不允许在后续随意更改的。同时TR2还要输出高保真界面原型。
PDCP
PDCP即Plan Decision Check
Point，项目计划里程碑。虽然Charter决策时已经定出了版本代码规模、关键时间点和人力需求，但经过TR1和TR2的分析和细化，不可避免的会出现一些变更。TR2是项目从构想到实现，从混沌到清晰的一个关键时间点。相比TR2前比较不可控的的研讨、分析，TR2以后主要是执行的一个过程，因此在TR2前后有必要将版本代码规模、关键时间点和人力需求进一步明确固化下来，以便后续开发团队按照一个严格的计划来执行。除了以上提到的，PDCP时还要确定质量目标，由开发代表给各项目经理下发SOW（工作任务书）。SOW中明确了各个开发项目组在TR2-TR4之间应该完成的开发任务，是开发组完成开发任务的依据。
TR2-TR3
这个阶段开发组完成软件需求规格说明书（SRS）的写作，以及按照大瀑布模型，完成系统测试用例的写作（STC）。SRS基于软件设计需求（DS）分解细化，用描述性的语言阐述每个典型用户操作/业务流程的实现过程，包括每个子系统如何协作通讯。
TR3-TR4
这个阶段开发组依次完成软件概要设计（HLD）和集成测试用例（ITC）、软件详细设计（LLD）和单元测试用例（UTC）、编码。HLD的交付标准是定义到函数接口级别，LLD的交付标准是写出伪码。但由于瀑布模型的固有缺陷，如果花了大量的时间在文档协作上，编码时间很短，重大的风险无法提前识别，只能到编码时菜暴露，对项目进度影响大。近年来大部分项目都将HLD和LLD合二为SD——软件设计说明书，而且弱化了伪码协作。
ITC根据项目的需求而定，如果项目本省不需要专门的集成测试，就可以裁减了。如果基于xUnit进行单元测试，则UTC文档可以裁减，或至少部分裁减。
TR4-TR4A
这个阶段开发组要完成UT/IT/ST/BBIT，TR4A时开发组要向测试组交付版本进行测试。BBIT是指Building
Block Integrated Test，一般是指跨团队的子系统间的集成测试。
TR4A-TR5
这个阶段测试部会完成2+1的测试，即完成两个版本的完整测试，外加1个版本的回归测试。根据CMM的经验，2+1的测试可以达到版本功能稳定的程度。TR5结束即意味着版本开发阶段的结束。对于直接交付给客户的产品，下一阶段就是实验局阶段。对于交付给下游的中间件，产品开发基本结束，准备过TDCP。
TDCP
TDCP即 Technology Decision Check
Point。这个里程碑意味着产品主要开发活动的结束。开发代表需要邀请下游用户、测试等相关干系人员参与评审。评审的标准是产品的遗留缺陷。各域的代表会关心这些遗留缺陷是否确实影响用户的使用，有没有规避的方法。
TR5-TR6
对于直接交付给客户的产品，这个阶段就是实验局阶段。管理团队会挑选适当的客户来使用新版本，并根据暴露出来的问题进一步优化、改进。TR5-TR6之间的版本也会用于入网测试。很多新的特性本来就是应某些入网测试的需求开发的。
TR6-GA
这个阶段是维护阶段，对各种缺陷进行修改，发布新版本。这些缺陷可能是内部测试、外部测试、客户使用过程中暴露出来的。这个阶段只在控制范围内限量接收小的新需求，接收与否的依据是是否对架构影响大，是否确实紧急。
GA
GA意味着产品主要生命周期的结束。过了GA点以后，基本不会基于这个主版本在发布新版本，不接纳新需求。
