CMMI(CapabilityMaturityModelIntegration，能力成熟度模型集成)认证评估在过去的十几年中，对全球的软件产业产生了非常深远的影响。CMMI共有五个等级，分别标志着软件企业能力成熟度的五个层次，如图2-1所示。从低到高，软件开发生产计划精度逐级上升，单位工程生产周期逐级缩短，单位工程成本逐级降低。据SEI统计，通过评估的软件公司对项目的估计与控制能力提升约40%～50%，生产率提高10%～20%，软件产品出错率下降超过1/3。
图2-1CMMI模型
第一级：初始级
初始级的软件过程是未加定义的随意过程，项目的执行也是随意的，甚至是混乱的。当然有些企业可能已经制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，并且在执行过程中没有政策、资源等方面的支持，它仍然被视为初始级。
第二级：受管理级
根据多年的经验和教训，企业总结出软件开发的首要问题不是技术问题，而是管理问题。因此，CMMI发展到了第二级，更强调软件管理过程，建立一个可管理的过程是很重要的，它可以将开发的过程重复，只有可重复的过程才能逐渐改进并使其成熟。受管理级的管理过程主要包括五个方面：需求管理、项目管理、质量管理、配置管理和子合同管理;其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行且阶段可控的软件开发过程。
第三级：已定义级
在受管理级定义了管理的基本过程，但并没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中。规定所有开发的项目或产品都必须遵守该标准过程，并且按照过程执行，当然在实际过程中，可以根据具体的项目对该过程进行适当的裁剪，但过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。
第四级：定量管理级
第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品(包括工作产品和提交给用户的最终产品)的质量需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正成为一种工业生产活动。
第五级：持续优化级
持续优化级的目标是达到一个持续改善的境界。所谓持续改进，是指根据过程执行的反馈信息来改善当前已定义的开发过程，即优化已定义的执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件开发过程使开发过程达到最优。CMMI模型中包括验证(VER)和确认(VAL)两大过程域，这两大过程域与软件测试有着紧密的联系，也是规范软件测试的两大过程域。
(1)验证(VER)过程域的目的是确保所选定的工作产品符合其指定的需求。验证过程域包括验证准备、验证执行和纠正措施识别。验证的对象包括产品和中间工作产品，验证方法是将待验证的对象与选定的客户需求、产品需求和产品组件需求加以比较。验证是渐进的过程，因为它发生在产品和工作产品的整个开发过程中，从需求开始验证，历经工作产品的验证，最终为已完成产品的验证。
(2)确认(VAL)过程域的目的是展示完全置于预期环境中的产品或产品组件是否满足预期的使用需求。
所有的产品都可在其预期环境中实施确认活动，例如：操作、培训、制造、维护及支持服务。所有用于工作产品的确认方法，也能使用在对产品和产品组件的确定过程中(在所有过程域中，产品和产品组件的含义包括服务和其组件)。工作产品(例如需求、设计、原型)存在于整个产品生命周期，应及早并逐步实施确认。
确认环境必须可代表产品和产品组件的预期环境，同时该确认环境也适用于工作产品确认活动的预期环境。
当在确认过程中问题被识别出来时，需要参考需求开发、技术解决方案或项目监控过程域的实践来解决。
二、基于过程中的质量
图2-2基于过程的质量控制
而软件测试是评估产品质量的重要手段，软件测试贯穿产品开发的始终，那么在整个软件测试过程中，应该如何来度量软件测试的质量呢在整个测试过程中，质量度量主要包括以下几个方面：
(1)测试覆盖率。
测试覆盖率是指在测试过程中对被测试对象的需求、功能、代码测试的程度。主要包括对需求和代码两个方面的覆盖评估，但其实这两个方面的评估本质是一致的，都是通过测试用例来评估覆盖率。
1)基于需求的测试覆盖评估依赖于对已执行/运行的测试用例的核实和分析，其主要是通过评估测试用例覆盖率来评估，在测试过程中的目标是要求需求的覆盖率达到100%。在实际测试过程中，可以通过统计已执行的覆盖率和执行成功的覆盖率来评估需求覆盖率的值。
已经执行的测试用例覆盖率指所有测试用例中被执行用例所占百分比，公式如下：
其中，Tx表示已执行的测试用例数，Rft是测试需求的总数。成功执行的覆盖率指测试过程中执行成功的测试用例所占百分比，公式如下：
其中，Ts表示已执行并且执行状态为成功的测试用例，Rft是测试需求的总数。
2)基于代码的测试覆盖率是对被测试的程序代码语句、路径或条件的覆盖率分析。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上，主要用于白盒测试阶段。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素;数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已经定义。
基于代码的测试覆盖通过以下公式计算：
其中，Tc是指使用代码语句、条件分支、代码路径、数据状态判定点方法设计的并被执行的用例数，Tnc(Totalnumberofitemsinthecode)是指项目中总的代码数。
(2)测试执行的质量和效率。
测试执行的效率是指测试工程师每天执行的测试用例数，一般每天执行50条测试用例。测试执行的质量包括两个方面：一方面是指每个测试用例发现的缺陷数;另一方面是指软件发布后遗留的软件缺陷数占总缺陷数的百分比，一般要求低于0.5%。
故测试执行的质量和效率一般使用以下指标来统计：
(3)测试用例深度、质量和有效性。
测试用例是所有测试活动的基础，测试用例质量的好坏直接影响软件测试的质量。
测试用例的度量主要从测试用例深度(也叫测试用例密度)、质量和有效性三个方面来实现。当然如果开展了自动化测试，还可以从测试用例自动化的程度这一维度来度量。测试用例深度(TestCaseDepth，TCD)指每KLOC(千行代码)设计的测试用例数或每个功能点所设计的测试用例数，一般情况下认为每KLOC设计的用例数越多，表示测试的质量越高。当然必须考虑冗余或重复的用例数，在设计用例时应该尽量避免出现冗余或重复。
测试用例质量(TestCaseQuality，TCQ)其实是一个很复杂的指标，它包括两个方面：一方面指如何设计一个好的测试用例;另一方面指测试发现缺陷的数量。
一般情况下，一个好的测试用例应该考虑以下几个方面：
发现缺陷方面主要是指测试用例发现的缺陷数量，公式如下：
TCQ=测试用例发现的缺陷数量/总的缺陷数量总的缺陷数量除了测试用例发现的缺陷数外，还包括通过ad-hoc测试(随机、自由的测试)、集体走查(Work-through)和Fire-drill测试(类似消防训练的用户压力/验收测试)等其他手段发现的缺陷。
(4)缺陷分布分析。
缺陷是测试过程中体现工作效率和价值的重要指标之一，也是分析系统质量的重要指标。在测试过程中除了要提交缺陷外，还需要对缺陷的分布情况进行分析，这样可以作为改进系统质量的依据。在提交缺陷时，需要注意一些必需的元素项，即一个好的缺陷通常需要包含的内容，现在一些企业通常会使用缺陷管理工具来管理测试过程中所发现的缺陷。对提交的缺陷需要进行分析，这样可以进一步改进系统质量，并且可以改进测试方法和测试策略，常用的缺陷分析方法有：ODC正交缺陷分析法、Gompertz缺陷分析法、Rayleigh缺陷分析法、四象限缺陷分析法和根源缺陷分析法，具体的缺陷分析法在第7章详细介绍。
本章主要介绍了关于“软件测试在质量体系中的位置”的内容，大家觉得有用的话，记得每天来这里和小编一起学习涨薪技能。识别下方二维码，免费领取学习课件、视频哦。(笔芯)