度量是改进过程的有效途径之一。通过对测试过程的度量，可以使测试过程规范化、可视化;对度量数据的分析，可以测量出测试过程的有效性及存在的问题，明确测试过程的改进方向，从而保证软件的质量。因此，对软件测试过程的度量研究具有十分重要的意义。
CMMI与软件测试
CMMI是美国卡耐基梅隆大学的软件工程研究所针对软件质量保证的核心—软件过程改进所提出的，它是一个成功的、广泛使用的过程改进模型。
众所周知，软件测试是软件过程不可分割的一部分，所以CMMI实际上也为软件测试过程改进提供了一系列的指导方针和关键原则。在CMMI连续表示中，验证(VER)和确认(VAL)过程域紧密的与软件测试联系在一起;而诸如配置管理(CM)、风险分析(RSKM)、量化项目管理(QPM)等过程域也同样包含了对测试过程改进的有力支持。
CMMI与度量
CMMI提供了度量和分析(MA)过程域，其目的是开发和维持用于支持管理信息需要的度量能力。MA实际包含了度量和分析两个步骤，度量在前，是为获得过程或产品的表征数据;分析在后，是对数据进行分析，发现不一致、发现趋势和发现问题。
CMMI的度量和分析流程主要分为3个部分:计划、收集和分析。在计划阶段，主要任务是度量目标的确定和目标的细化;在收集阶段，主要任务是按数据采集和存储规程进行数据的收集、数据完整检查;在分析阶段，主要任务是按分析规程进行数据分析、存储数据和结果，以及报告结果。MA过程域定义严格，流程清楚，目标明确，可以用它来指导软件测试过程的度量活动。
软件测试过程
按照MA的指导，任何对过程的度量都是建立在清晰的过程定义上的，因此，必须对软件测试过程有一个准确的定义。传统的软件测试过程包括:测试计划、测试设计、测试开发和测试执行等阶段，每个阶段都有一系列的任务。但是传统的软件测试过程定义无论是从测试范围还是测试工作方式上都存在着明显的不足，不利于进行过程度量，而CMMI则对传统的软件测试过程进行了扩充。因此，我们提出了一个基于CMMI的软件测试过程模型(software test process model，STPM)，如图1所示。
STPM有如下几点改进:
(1)软件测试不再只是对程序代码的测试工作，而是包含了所有在软件开发过程阶段产出物的测试工作，这扩展了测试工作的范围，更有利于发现软件开发中的缺陷;
(2)测试过程与整个软件开发过程是并行的，扩展了测试过程的工作方式;
(3)清晰的定义了过程的输入输出流，为整个过程的度量奠定了基础;
(4)将测试的结果纳入到了软件开发的缺陷管理机制中，扩展了测试的作用。
度量目标
通过对STPM的分析 ，可以确定3类度量目标:①对测试产品的度量，这主要是对应STPM的输入，包括需求规格说明、详细设计说明、系统设计说明以及程序代码等的度量;②对测试过程产品的度量，这主要是对应STPM的输出，包括测试用例、测试报告等的度量;③对测试过程本身的度量，主要是对应STPM的执行状态，包括时间状态、环境状态等的度量。
度量元的选取和细化
CMMI为过程改进提供了足够多的实践指导，但是，它只阐述了该做什么，而没有阐述该如何做，这一点也在MA中体现了出来。所以，在CMMI提供的要求和原则下，具体的度量和分析工作需要我们自己来定义。在此，我们引入GQM方法来保证度量元选取和细化的有效性。GQM(goal-question-metric)方法源于软件行业，是一种系统地对软件及其开发过程实施定量化的度量方法。GQM引入了目标驱动的度量概念，在软件开发过程中已经取得了很好的效果。GQM的基本思想是:先确定一组目标:再针对各个目标，提出可能会遇到的问题，来定义这个目标;最后，针对每一个问题再给出一组测量方法，并用这一组测量方法测量出来的数据(度量元)就是对这个问题的回答。
GQM方法在实施过程中最重要的就是要保证G、Q、M之间问题转化的完整性和匹配性。而对CMMI的一个单独的过程域而言，可以这样来描述:首先，对该过程域定义一个目的;然后，为了达到这个目的，给出了一系列的关键目标(包含特定目标和共性目标);最后，针对每一个目标，细分关键实践来实现，而每个关键实践又可再分为具体的子实践。即是说，CMMI的过程域从定义到实践是一个严格意义上的完整性和匹配性转化。如果从每个过程域的角度来进行软件测试过程的度量研究，那么就可以建立起CMMI模型与GQM方法的映射关系，如图2所示。
上面的映射关系分为目的层、问题层和度量层，这样，CMMI也是目标驱动的。由于GQM方法是一套已经被证明成功的度量元选取方法，所以在生成了CMMI到GQM的映射后，由CMMI导出度量元是可行的。将CMMI与GQM的映射关系定义为C—G模型，并将应用到C—G模型中的CMMI相关软件测试过程域定义为STPA(software test process area)，C-G模型和STPA为度量元选取和细化提供了理论依据。
CMMI不是专门为改进软件测试过程而出现的，所以将STPA引入进入C—G模型中时，需要有一定的剪裁和适用的选取原则，才能保证度量元的有效性。本文从过程域、实践、文档、公共特性和相似结果5个方面，根据STPM，提出度量元的选取和细化遵循原则。
原则1 过程域剪裁。每个STPA都有几个相关过程域，如果几个STPA同时都包含一个确定的过程域，那么该过程域应该保留并合并;如果STPA涉及的相关过程域与软件测试相关性不强，那么该过程域应该完全删除不予考虑。这样既可以保证STPA引申出来的软件测试实践的完整，又可以抓住STPA的核心。
原则2 实践剪裁。CMMI面向的是整个软件过程改进，所以在分析STPA时:①某些关注整个软件过程的实践，关注重点都要置换成软件测试过程，并要以特定的测试输入输出作为基础;②某些与软件测试无关的实践，或者是涉及到过程域的定义、维护以及审查等实践，都可以被剪裁掉;③对某些零散的实践，如果表示的都是同一个目标，那么应该将其合并;④对子实践，如果直接度量元仍然无法确定，应允许再进行拆分。
原则3 文档剪裁。每个STPA都包含了大量繁琐的文档，不利于管理和维护。因此，应该只保留与测试输入输出有关的计划、规程、标准和报告等文档，这也是将整个度量和分析过程开发成自动化系统时所期望得到的文档数据。在保留的文档中，还应该注意相关文档的合并消除，降低文档之间的冗余关系。
原则4 公共特性剪裁。每个STPA都有许多执行能力公共特性，这些内容在企业进行全面过程改进时或许有用，但是在进行软件测试过程度量时，有些显得无关和没有必要。对此，可以采取以下3种方法:①纳入到相关STPA中，例如人员、工具等资源的管理，可以在配置管理中统一度量;②直接作为该过程域的度量目标，例如过程状态管理、维护，可以作为对测试过程本身的度量;③完全放弃，例如人员培训、角色分配等。
原则5 相似结果的合并。通过对不同的STPA分析，可能会对软件测试过程的某个属性重复度量，这时就必须涉及到相似度量元的合并。主要原则有3点:①如果度量元完全重复，那么应该只保留一个;②如果度量元属于同一度量目标，那么两者都应该保留并归为一类;③如果这个度量元是直接度量和间接度量的关系，那么应该将间接度量置于直接度量之下，并与该直接度量的其它间接度量进行合并。
应用案例
现以STPA中与软件测试联系最为紧密的确认(VAL)过程域为例，分析软件测试过程的度量。VAL的目的是证实产品或产品构件置于预期的环境时满足预期的用途。在STPM中，产品或产品构件就是被测试的产品，预期的环境是搭建的测试平台，而用途则是产品的需求。因此，VAL在C-G模型的目的层是:证实被测试的产品置于搭建好的测试平台下是否满足产品预期的需求。
按照原则1和原则2，集中分析VAL的两个特定目标:确认准备和确认产品。确认准备在STPM 中对应的是测试计划和测试设计部分，输入主要有测试产品和产品需求等，输出主要有需求确认计划和产品确认计划等。确认产品在STPM中对应的是测试执行和结果分析部分，输入主要来源与确认准备目标的输出，而输出主要有确认结果、确认报告和对查表等。因此，VAL在C-G模型的问题层是:01是否准备好了确认产品和确认环境？02确认的过程和结果是否有效？在明确了VAL的目标以及输入输出后，可以根据VAL的具体实践以及实践说明展开其在C-G模型中的问题层，结合原则2、原则3和原则4，将上述的VAL目标映射到C-G模型的度量层:M1产品规模度量;M2需求规模度量;M3测试用例规模度量;M4测试用例的有效性度量;M5测试结果的度量;M6测试工具使用度量;M7测试过程进度度量;M8测试充分性度量;M9测试平台稳定性度量。
其中M1和M2属于对测试产品的度量，M3、M4、M5和M6属于对对测试过程产品的度量，M7、M8和M9属于对测试过程本身的度量。进一步分析可以得到VAL对于STPM 的直接度量元，如表1所示。
表1所呈现的都是直接度量元，事实上，在VAL的分析过程中，一些直接度量元的导出是以间接度量元为基础的，这些信息应该与度量元的数据收集方法、数据单位等一起写入度量元的属性定义中。
通过对软件测试过程的度量和分析能够提高软件测试的有效性，保证软件的质量。本文在清晰的软件测试过程定义下，以CMMI这个成功的过程改进模型为基础，对度量目标和度量元的有效选取进行了研究。下一步的工作重点，是定义数据采集和存储规程进行度量数据的收集，以及定义分析规程来分析数据，提供度量结果和改进措施。最终，还需要开发一个自动化系统来支持整个度量和分析过程。而所有研究的基础，则是对软件测试过程度量元的选取，这也是本文研究的意义所在。
图1 软件测试过程模型
图2 CMMI与GQM的映射关系模型
文章来源于领测软件测试网 https://www.ltesting.net/
