测试成熟度模型集成(TMMi)中文

测试成熟度模型集成 Test Maturity Model Integration

（TMMI）

目录

1 测试成熟度模型集成（TMMI） ................................................................................................ 4

1.1 介绍 .................................................................................................................................... 4 1.2 背景和历史 ........................................................................................................................ 4 1.3 起源 .................................................................................................................................... 5 1.4 TMMI的领域 ..................................................................................................................... 6

1.4.1 软件和系统工程 ..................................................................................................... 6 1.4.2 测试级别 ................................................................................................................. 6 1.4.3 TMMI和CMMI ...................................................................................................... 6 1.4.4 评定 ......................................................................................................................... 6 1.4.5 改善的方法 ............................................................................................................. 7

2 TMMI成熟度水平 ........................................................................................................................ 7

2.1 概述 .................................................................................................................................... 7 2.2 级别1 初始的 ................................................................................................................... 8 2.3 级别2 可管理的 ............................................................................................................... 9 2.4 级别3 可定义的 ............................................................................................................... 9 2.5 级别4 可测量的 ............................................................................................................. 10 2.6 级别5 可优化的 ............................................................................................................. 11 3 TMMI的结构 .............................................................................................................................. 12

3.1 必需的，可预料的和提供信息的组件 .......................................................................... 12

3.1.1 必需的组件 ........................................................................................................... 12 3.1.2 期望的组件 ........................................................................................................... 12 3.1.3 信息组件 ............................................................................................................... 13 3.2 TMMI的组件 ................................................................................................................... 13

3.2.1 成熟度级别 ........................................................................................................... 13 3.2.2 过程域 ................................................................................................................... 13 3.2.3 目标 ....................................................................................................................... 14 3.2.4 介绍性说明 ........................................................................................................... 14 3.2.5 范围 ....................................................................................................................... 14 3.2.6 特定目标 ............................................................................................................... 14 3.2.7 通用目标 ............................................................................................................... 14 3.2.8 特定的实践 ........................................................................................................... 14 3.2.9 典型工作产品 ....................................................................................................... 15 3.2.10 子实践 ................................................................................................................. 15 3.2.11 通用实践 ............................................................................................................. 15 3.2.12 通用实践细节 ..................................................................................................... 15 3.2.13 支持性信息组件 ................................................................................................. 15 3.3 通用目标和通用实践 ...................................................................................................... 16

3.3.1 GG 2 制度化可管理过程 ..................................................................................... 17 3.3.2 GG 3 制度化已定义的过程 ................................................................................. 19 3.4 对通用实践过程域的支持 .............................................................................................. 20

3.4.1 GP2.2计划过程 ..................................................................................................... 20 3.4.2 GP2.5培训人员 ..................................................................................................... 20

3.4.3 G2.6管理配置 ....................................................................................................... 20 3.4.4 G2.7确定并涉及利益相关者 ............................................................................... 21 3.4.5 GP2.8监控过程 ..................................................................................................... 21 3.4.6 GP2.9坚持客观评价 ............................................................................................. 21 3.5 CMMI过程域对TMMI的支持 ...................................................................................... 21 4 TMMI过程域进阶 ...................................................................................................................... 23

4.1 2级TMMI过程域 ........................................................................................................... 23

4.1.1 PA2.1 测试政策和策略 ........................................................................................ 24 4.1.2 PA2.2 测试计划 .................................................................................................... 30

5 TMMI通用目标和通用实践进阶 .............................................................................................. 41

5.1 GG2 制度化一个管理过程 ............................................................................................. 41

5.1.1 GP2.1 建立组织政策 ............................................................................................ 41 5.1.2 GP2.2 计划过程 .................................................................................................... 41 5.1.3 GP2.3 提供资源 .................................................................................................... 41 5.1.4 GP2.4 分配职责 .................................................................................................... 42 5.1.5 GP2.5 培训人员 .................................................................................................... 42 5.1.6 GP2.6 配置管理 .................................................................................................... 43 5.1.7 GP2.7 明确并使相关人员参与 ............................................................................ 43 5.1.8 GP2.8 监控过程 .................................................................................................... 43 5.1.9 GP2.9 坚持客观评价 ............................................................................................ 44 5.1.10 GP2.10 与高级管理层的评审状况 .................................................................... 44 5.2 GG3 制度化已定义的过程 ............................................................................................. 44

5.2.1 GP3.1 建立一个已定义的过程 ............................................................................ 44 5.2.2 GP3.2 收集改进信息 ............................................................................................ 44

1 测试成熟度模型集成（TMMI）

1.1 介绍

在过去的10年间，软件产业界花费了大量的努力用以提高它的产品质量，这无疑是个艰巨的工作，因为软件的体积和复杂度正在随着客户和最终用户越来越多的需求而飞速的增长。尽管采用了多种质量提高手段，软件产业仍然远离零缺陷。为了提高产品质量，软件产业界把重点放在了提高开发过程上，使得能力成熟度模型（CMM）被广泛使用。能力成熟度模型（CMM）和它的接替者，能力成熟度模型集成（CMMI）常常被作为软件开发过程的工业标准。尽管事实上测试至少要占到整个项目花费的30%－40%，但是在各种软件过程改进模型如CMM和CMMI，测试仍然被很少提及，为此测试社区创建了互补的改进模型来响应这个问题，本文就描述了这种模型，测试成熟度模型集成（TMMI）。TMMI是测试过程改进的详细模型并且可以实现和CMMI的互补。

1.2 背景和历史

TMMI框架由TMMI协会开发并作为准则框架用以对测试过程进行改进。TMMI也作为CMMI1.2版本的互补模型来帮助测试经理，测试工程师和软件质量专家定位某些问题的重要性。像CMMI的使用阶段一样，TMMI也使用成熟度水平概念来做过程评估和改进，此外还定义了过程域，目标和活动。TMMI成熟度标准的应用将改善测试过程，并对产品质量，测试工程的生产力，以及测试周期有着积极的影响。目前TMMI已经被开发成为可以支持组织评估和测试过程改进。通过TMMI,可以使得软件测试从一个无序混乱，缺乏资源、工具和训练有素的测试人员的弱定义过程演变成为以成熟的，可控的，并且有缺陷预防能力为主要目标的，具有完善定义的过程。实际的经验证明TMMI建立了一个更加高效的测试过程。测试成为了软件项目中的一个独立实施的阶段，并且被融入到开发过程中。软件测试德重点开始由缺陷检测转移到缺陷预防上来。

1.3 起源

TMMI的发展是以美国伊利诺伊理工学院开发的TMM框架为主要来源。除了TMM，它也借鉴了能力成熟度模型集成（CMMI），而后者是一种IT业界有着广泛应用的过程改进模型。CMMI既是分阶段的也是持续的。所谓分阶段，即为CMMI架构规定了评估过程各个阶段，评估组织必须顺序的执行它的各个阶段，以提高改进过程。所谓持续，即为CMMI没有规定通过评估的级别，一个组织选择不同的级别去做改进。

TMMI被开发成一个阶段模型，它使用预定义的多套过程域定义组织的改进过程。这种发展过程被描绘成一种模型成分，称为成熟度级别。成熟度级别又被定义成进化水平，以完成测试组织的改良过程。在后来的一个阶段TMMI的持续性才变得可用。它不会影响TMMI的内容，它仅仅提供了不用的结构和表述。促进TMMI发展的其它来源还包括Gelperin和Hetzel的测试模型的演化，它描述了过去40年间的测试过程的演化; 还有Beizer的测试模型，它描述了单个测试人员的想法的演化；有EUfunded MB-TMM项目中对TMM的研究；还有国际测试组织，如IEEE829标准中的软件测试文档[IEEE829]。在TMMI使用的测试术语来自ISTQB组织软件测试方面的标准条款术语。 ? TMMI是TMMI组织的注册商标

? CMM和CMMI是Carnegie Mellon大学的注册商标 ? TMM是Illionis理工学院的注册服务标记

至于确定成熟度等级描述，Gelperin和Hetzel的进化测试模型担任一个历史级的TMMI区别的基础。，Gelperin和Hetzel模型描述了1950年代到1990年代的阶段和测试目标。初始的时期被描述成面向调试的，在这个时期大多数的软件开发组织不清楚测试和调试的区别。测试是个模糊的活动，它跟调试一起是用来从程序中去除错误的。根据Gelperin和Hetzel的理论，测试已经进入面向预防时期，联系到最好的练习以及反映了TMMI最成熟的水平。而且，各种各样的工业界使用TMM的最佳练习和实践经验为TMMI的发展提供了必要的实验基础和实用性水平。他们阐明了当前在IT工业界最好和最差的测试实践，它也允许TMMI框架的开发者提取实际的基准以评估和改善测试实践。

1.4 TMMI的领域 1.4.1 软件和系统工程

TMMI打算在系统工程和软件工程学科方面支持测试活动和测试过程的改善。系统工程涵盖了整个系统的发展，它可以包括也可能不包括软件。软件工程涵盖了软件系统的发展。

1.4.2 测试级别

其他模型在测试过程改良方面主要致力于高级别的测试，如TPI或者仅仅定位结构测试的某一个方面，如测试机构。TMMI定位多个测试水平，包括静态测试和结构测试的各个方面。至于动态测试，低级测试和高级测试都是TMMI的目标。研究TMMI细节越多，有一个问题就必须了解，这种模型定位了结构测试的4项基石：生命周期，技能，基础结构和组织。

1.4.3 TMMI和CMMI

需要注意的是TMMI的定位是作为CMMI的互补模型。在很多情况下一个给定的TMMI级别需要它相关的CMMI级别或比它低的CMMI级别的过程域的特定支持。有些情况下甚至跟高级别CMMI有关联。在CMMI中被详尽说明的过程域和实践没有在TMMI中被重复，他们仅仅作为参考。举例来说，过程域配置管理，它当然是适合测试产品的，但是没有在TMMI中详细说明；CMMI中的实践被引用和含蓄的重用。

1.4.4 评定

许多组织发现了标准为内部的和标准为外部客户以及供应商的在测试过程改进中的价值。测试过程中的评估重点是确定改进的机会和了解该组织的立场相对于选定的模式或标准。TMMI为进行这种评估提供了一个很好的参考模型。评估小组使用TMMI指导自己的鉴定和调查结果的优先次序。用TMMI可以指导的这

些研究结果被用来为组织改进做计划。评估框架本身不是TMMI的一部分，TMMI评估需求被描述成一个单独的文件，你可以在www.TMMIFoundation.org找到。这些需求是基于ISO 15504标准的。一个特定的成熟度级别对不同的评估机构来说是一样的。确保这种一致性的规则包含在TMMI评估方法的要求中，该TMMI评估方法的要求包含了各种类别的评估，例如，准则正式的评估，快速扫描和自我评估。

1.4.5 改善的方法

TMMI提供了完整的框架作为测试过程改进的参考模型。但它并不提供测试过程改进的方法，例如IDEAL。实际经验表明测试过程改进最强有力的初始化步骤是在投资测试过程评估之前建立强有力的组织任务。给予充分的任务过程管理，建立强有力的测试小组，它描述相关的人员可以指引过程提高的方向，被证明是有效的方法。

2 TMMI成熟度水平

2.1 概述

图1 TMMI成熟度级别

TMMI是阶段架构的过程改进模型。它包含的阶段或者级别是从一个无序的，

不可管理的到可管理的，可定义的，可测量的和可优化的。图1展示了TMMI的级别从低到高的级别管理和每个级别对应的过程域。每个阶段要确保足够的改进，作为下一阶段的奠定基础。该TMMI内部结构是丰富的，在测试中可以学习和有系统地支持一个质量检测的过程，在渐进的步骤改善应用实践。TMMI有5个级别，它们遵守成熟度等级制度和演化路径来进行测试过程改进。每个级别都有一套过程域指明组织需要致力在那个级别取得成熟度。经验表明组织各尽其能一次他们专注于测试过程改进在可做到的过程域，那些域随着组织的改进需要增加混合。因为每个成熟度级别为下一个级别构成必要的基础，尽量略过一个成熟度级别通常是无益的。同时，你必须意识到测试过程改进的努力必须致力于组织在商业环境的需要，更高级别的成熟度水平上的过程域需定位在当前组织或项目的需要。例如，当组织试图从成熟度级别1升到级别2的时候经常被鼓励成立一个测试小组，它是测试组织成熟度级别3过程域中必须有的。虽然测试小组不是TMMI级别2组织所特有的，但是它是成为组织获得TMMI级别2有用的部分。图1展示了TMMI的每个成熟度级别的过程域。在接下来的章节里他们会被详细描述。下面有一个组织内各个TMMI级别的简单特征描述。这些描述将告诉读者TMMI在测试过程改进中路径演化的规定。需要注意的是TMMI并没有一个特定的过程域来指定用什么测试工具和要不要用自动化测试。在TMMI里，测试工具被作为一个辅助资源，例如应用测试设计工具是TMMI级别2测试测试和执行过程域的一个测试实践，应用性能测试工具是TMMI级别3无功能测试过程域的一个测试实践。

2.2 级别1 初始的

在TMMI级别1，测试是个混乱，无定义的过程，常常被当作调试的一部分。组织通常没有提供稳定的环境来支持这个过程。组织的成功都是依靠能力超强英雄式的人物，而不是使用被证实的过程。在代码完成之后测试被一个特别的方式展开。测试和调试被混合到一起来去除系统中的错误。这个级别的测试目标是软件运行起来后没有大的失效。关于质量和风险产品没有足够清晰的认识就被发布。实际应用时，产品经常不符合需求，不稳定或者工作太慢。测试缺少资源，工具和训练有素的人员。在TMMI级别1没有定义过程域。成熟度级别1的组织

的特征是倾向于过度承诺，危机时放弃过程，无法重复成功。产品往往不按时发布，超支，质量不可预料。

2.3 级别2 可管理的

在TMMI级别2，测试成为一个可管理的过程并被清晰地从调试中分离出来。成熟度2级反映出的过程训练能确信现有的实践仍然有时间压力。然而，很多人仍然意识到测试是编码的后一个阶段。在改善测试过程的前后，公司范围或者项目范围的策略被制定了。测试计划也被开发了。在测试计划中，测试方法被定义了，这个方法基于产品风险评估的结果。风险管理技术被用来澄清文档需求基础上的产品风险。测试也定义了那些测试需要做，什么时候做，谁来做等。根据需要委托和校验被制定了。测试被监控以确保它能按照计划执行，一旦发生背离会有相应的动作。工作产品的状态和测试服务的递交对管理来说是可见的。从详细规格说明中选择测试用例的测试设计技术被应用了。然而，在开发生命周期测试仍然开始的比较晚，比如要在设计或者在编码阶段才开始。测试分了多个标准，有单元测试，综合测试，系统测试和验收测试。对于每个确定的测试标准有指定的测试目标定义在组织范围或者项目范围的测试策略。2级TMMI组织的主要测试目标是检验产品是否符合指定的需求。还有一个目的是清楚地界定测试和调试。这个级别的TMMI有许多的质量问题是因为测试启动太晚。缺陷被引入从需求阶段，设计阶段到编码阶段。没有正式的评审程序去定位这个重要的问题。许多人认为编码过后的测试执行是主要的测试活动。 TMMI级别2有如下过程域： 1) 测试方针和策略 2) 测试计划 3) 测试监控 4) 测试设计和执行 5) 测试环境

2.4 级别3 可定义的

在TMMI级别3，测试不再是编码后的一个阶段，它被集成到整个开发生命周

期和相关的里程碑。测试计划在项目的初期就被完成，比如在需求阶段，通过一个测试总体计划。在2级TMMI测试总体计划的发展建立在测试计划技能和承诺的基础上。组织的一套标准测试过程，是3级成熟度的基础，随着时间被建立和完善。存在测试组织和明确的培训程序，测试被明确为一种职业。测试过程改进是完全制度化测试组织的一部分。在这个级别的组织明白评审在质量控制方面的重要性；正式的评审程序被实施虽然没有链接到动态测试过程。评审贯穿到整个生命周期。需求说明书指定测试职业包含评审。2级TMMI的测试设计的重点是功能性测试，测试设计和扩展测试技术，视商业目标，也包括非功能性测试，例如可用性和可靠性测试。TMMI2级和3级的本质区别是标准的范围，过程描述和步骤。2级成熟度在每个特定的实例有着完全的差别，如在一个特定的项目。3级成熟度可以从组织的一套标准过程中裁剪以适合一个特定的项目或者组织单元，因此更加一致，除了裁剪规则的不同。另外一个本质区别是在3级成熟度比2级成熟度，过程表述更加严格。因此在3级成熟度，组织必须重新访问2级成熟度的过程域。

TMMI级别3有如下过程域： ? 测试组织 ? 测试培训程序 ? 测试生命周期和整合 ? 非功能测试 ? 同行评审

2.5 级别4 可测量的

在4级TMMI组织，测试是一个充分定义，有事实根据和可度量的过程。在4级成熟度组织和项目为产品质量和过程性能建立多个目标，并作为标准管理他们。产品质量和过程性能在统计条款上被理解，在整个生命周期被管理。测量成为组织度量库的一部分以支持基于事实策略的制定。评审和检查被视为测试的一部分并用来度量文档质量。静态和动态的测试方法被集成到一起。评审被正式的使用来控制质量关口。产品使用质量评价量化标准的属性，如可靠性，可用性和可维护性。一个组织广泛的测试度量方案提供了有关信息和能见度测试过程。测

试被认为是评估，它由检测产品和相关的工作产品生命周期有关的所有活动组成。

TMMI级别4有如下过程域： ? 测试度量 ? 产品质量评估 ? 高级同行评审

2.6 级别5 可优化的

在取得之前成熟度级别所有改进目标的基础上，测试是一个完全可定义的过程，并能控制成本和测试效率。在5级TMMI中，组织在理解众多变化过程中的固有的常见原因的基础上持续改进它的过程。通过渐近和改进的过程和技术改进，提高测试过程的性能被执行。方法和技术被优化，并持续的致力于微调和测试过程提高。缺陷预防和质量控制被实践。统计抽样，信心水平度量，确实性和可信赖性驱动测试过程。除了其他，缺陷预防和质量控制被引入成为过程域。测试过程的特点是基于质量测量的抽样。存在一个详细的步骤来选择和评估测试工具。在测试设计，测试执行，衰退测试，测试用例管理等等期间尽可能的用工具来支持测试过程。在5级TMMI，支持通过一个过程资产库实践过程重用。测试是个缺陷预防为目标的过程。 TMMI级别5有如下过程域： ? 缺陷预防 ? 测试过程优化 ? 质量控制

3 TMMI的结构

图2 TMMI Structure

TMMI的结构很大程度上建立在CMMI的结构基础上。这样做的好处是因为许多人/组织已经熟悉CMMI的结构。CMMI的结构清楚的划分了必需的实践（目标）和推荐的实践（特定的实践，典型的工作产品等）。TMMI也包括这个方面，图2为目前TMMI的结构描述。在本章，讲述了TMMI的组件和结构。另外也讲述了CMMI提供给TMMI执行的支持

3.1 必需的，可预料的和提供信息的组件

各种各样的组件被组合成3个类别：必需的，可预料的、提供信息的。

3.1.1 必需的组件

必需的组件描述了一个组织必须实现的内容，以满足过程域。在组织的过程里这些执行必须是可见的。TMMI的必需组件是具体的和通用的目标。目标满足被用作评估的基础以决定是否过程域已经被实现和满足。

3.1.2 期望的组件

期望的组件描述了组织典型执行的，以实现必需的组件。期望的组件指南改

善或者执行评估。期望的组件包括具体的和通用的实践。在目标被考虑满足之前，无论是所述的实践还是可接受的替代物必须体现在组织的计划和执行过程中。

3.1.3 信息组件

信息组件提供细节以帮助组织开始考虑如何处理必需的和期望的组件。子实践，典型工作产品，记录，例子和参考都是信息模型组件。

3.2 TMMI的组件

下面的章节提供了TMMI组件的描述。需要注意的是TMMI也提供一个详尽的术语表。这些术语表很大程度上重用了国际软件测试资格委员会（ISTQB）开发的国际测试术语标准。

3.2.1 成熟度级别

TMMI的成熟度级别可以作为组织测试过程质量的度。它被定义成测试过程改进的进化平台。每个级别逐渐被发展成组织测试过程的重要部分。TMMI有5个成熟度级别。每个成熟度级别讲述了为了实现给定的级别所要实现的内容。组织的成熟度级别越高，组织的测试过程成熟度越高。为了达到指定的成熟度级别，组织必需满足这个级别和之前级别所有过程域的合适的目标（包括特定和通用）。请注意，所有组织过程，最小的TMMI级别1，不包含任何目标需要满足。

3.2.2 过程域

除了级别1，每个成熟度级别包含几个过程域用以指导组织的重点改进它的测试过程。过程域标识的问题必须被解决，以达到这个成熟度级别。每个过程域标识出一组测试相关的活动。当实践都执行了显著的改进，这些域将被制定。在TMMI中，只有那些被认为是测试过程能力的关键因素才被指明。所有成熟度级别以及比它低级别的过程域必须被实现。例如，如果组织在TMMI级别3，那么它满足所有的2级TMMI和3级TMMI的过程域。

3.2.3 目标

目标申明描述了过程域的目标，是一个信息组件。比如，测试计划过程域的目标申明是“在指定的风险和定义好的测试策略的基础上定义测试方法，建立和维护既定的测试计划来指导执行和管理测试活动”。

3.2.4 介绍性说明

过程域的过程性说明章节描述了过程域里的主要概念，是一个信息组件。

3.2.5 范围

过程域的范围章节明确的指出了过程域中的测试实践，如果有必要，过程域范围以外的测试实践也会被明确。

3.2.6 特定目标

特定目标的典型特征是必须满足过程域。特定目标是必需的模型组件，被用于评估以决定一个过程域是否被满足。

3.2.7 通用目标

通用目标出现在过程域尾部，之所以被称为“通用”是因为在多个过程域中有相同的目标申明。通用目标描述的特征是，必需存在制度化的过程来执行过程域。通用目标是一个必需模型组件，被用在评估以决定一个过程域是否被满足。

3.2.8 特定的实践

特定实践是实体描述，它在实现相关特定目标中被认为是重要的。特定实践描述的实体期望获得过程域的特定目标。特定实践是期望模型组件。

3.2.9 典型工作产品

典型工作产品章节从特定实践列出例子输出。那些例子被称为“典型工作产品”，因为经常有工作产品，也同样有效，但没有列出。典型工作产品是信息模型组件。

3.2.10 子实践

子实践是为解释和执行特定实践而提供指引的细节描述。子实践不像字面规定的那样，实际上是信息组件仅提供对测试过程改进有用的想法。

3.2.11 通用实践

通用实践出现在过程域的尾部，之所以被称为“通用”是因为相同的实践出现在多个过程域。通用实践是个实体描述，在实现相关的通用目标中被认为是重要的。通用实践是期望模型组件。

3.2.12 通用实践细节

通用实践细节出现在过程域的通用实践之后，用来提供通用实践唯一地被应用到过程域的指导。通用实践细节是信息模型组件。

3.2.13 支持性信息组件

有许多地方需要进一步的信息来描述一个概念。这些信息由下面的组件提供。

3.2.13.1 注释

注释是文本，它伴随其他模型组件。它提供细节，背景和逻辑依据。注释是信息模型组件。

3.2.13.2 实例

实例是一个组件，包括文本和一个项目清单，通常在一个盒子，可以伴随几乎任何其他组件，并提供一个或更多的例子来阐明一个概念或叙述的活动。实例是信息模型的组件。

3.2.13.3 参考

参考是一个额外的或更详细的相关过程域信息的指针，可以伴随几乎任何其他模型组件。它是信息模型组件。

3.3 通用目标和通用实践

本章描述了所有通用目标和通用实践。通用目标和通用实践很大程度上来源于CMMI。通用目标被组织成数字序列。在它们支持的通用目标下通用实践也被组织成数字序列。请注意，来自CMMI的通用目标，GG1‘实现特定目标’没有被加入是因为它仅仅叙述CMMI的持续表示，因此没有适当的TMMI的阶段表述。否则CMMI的序列大纲可以被完全应用，以避免组织在使用CMMI和TMMI时的混淆。 你的能力级别，将决定哪些通用目标和实践是适用的。当试图达到2级成熟度时，2级成熟度的过程域，通用目标2和伴随的通用实践也是适用的。通用目标3仅仅适用于当试图达到3级或者更高成熟度的时候。这就意味着当你已经达到2级成熟度的时候，为了达到3级成熟度，你必须回到2级的过程域，应用通用目标3和相关的实践。在过程改进中，制度化是重要的内容。当在通用目标和通用实践提及时，制度化意味着该过程在工作执行的方式根深蒂固，并有保证和连贯性。一个制度化的过程更像是时间压力下的保留。当过程的需求和对象发生改变时，过程的执行也需要改变以确保它仍然活动。通用实践描述的实体定位了制度化的各个方面。

3.3.1 GG 2 制度化可管理过程

一个可管理的过程是完成必要的工作，产生工作产品的过程；是一个有计划并按照策略执行的过程；有技能的员工有充足的资源生产可控的产出；涉及利益相关者；可监控；有评审；评估其遵守过程描述。过程能用项目，组，或者组织单元来示例。由可管理的过程提供的控件，有助于确保既定的过程是在面临压力时的保留。

3.3.1.1 GP 2.1 建立组织策略

该通用实践的目的是定义过程的组织期望，并使这些期望呈现给那些在组织中受影响的人。一般而言，高级管理人员负责建立和传达指导原则，方向和负责该组织的期望。

3.3.1.2 GP 2.2 计划过程

这里通用实践的目的是决定哪些是执行过程所需要的，并实现既定目标，准备执行过程中的计划，准备一个过程的描述，而且能够从利益相关者通过执行评审计划达成协议。

3.3.1.3 GP 2.3 提供资源

这里通用实践的目的是要确保必要的资源来执行根据计划定义好的过程。资源包括充足的资金，适当的物理设施，熟练的人，和适当的工具。

3.3.1.4 GP 2.4 分配责任

该通用实践的目的是确保有问责制来执行过程并实现整个过程生命中指定的结果。被分配的人员必须要有适当的权力来执行所分配的事。分配职责可以使用详细的工作描述或者活动的文档，例如执行过程的计划。

3.3.1.5 GP 2.5 培训人员

该通用实践的目的是确保人员有必要的技能和经验来执行或者支持过程。需要提供适当的培训。概要的培训要提供给那些与执行工作有交互的人员。通过建立对过程统一理解，传授执行过程所需要的技能和知识，培训支持成功的过程性能。

3.3.1.6 GP 2.6 管理配置

该通用实践的目的是建立和维护过程在有效生命周期指定工作产品的完整性。这里的工作产品特指在执行过程的计划里指出的，除了这个级别的配置管理说明，如版本控制，使用基线的正式配置管理等。配置管理实践的例子包括版本控制，更改历史记录和控制，状态识别和使用配置管理工具。更多信息关于把工作产品放到配置管理的可以参考CMMI的配置管理过程域。

3.3.1.7 GP 2.7 识别及使相关利益共享者参与

该通用实践的目的是在过程执行期间建立和维护期望利益相关者的参与。利益相关者要参与的活动有计划，决定，承诺，沟通，评审，问题的解决。决定性的利益相关者包括经理和用户/客户。经理的职责包括承诺，执行活动和改进测试能力的相关任务的能力。用户的职责包括质量相关的活动，涉及到面向用户的任务。重点是征求用户/客户支持，协商一致和参与的活动，如产品风险分析，验收测试和可用性测试。根据不用的测试级别，开发人员也是利益相关者，如在测试部分，开发人员经常自己执行测试，而在验收测试阶段开发人员变成一个利益相关者来讨论事件发现，商定入口标准等。

3.3.1.8 GP 2.8 监视和控制过程

该通用实践的目的是执行测试过程日常的监视和控制。在测试过程中维持适当的清晰度以便在必要的时候产用适当的行动。监控过程包括度量测试过程和它的工作产品的合适属性。更多信息关于把工作产品放到配置管理的可以参考

CMMI的配置管理过程域。度量方面的更多信息可以参考CMMI的度量和分析过程域。

3.3.1.9 GP 2.9 坚持客观评估

该通用目标的目的是提供可靠的保证，确保过程是按照计划执行的，并遵循它的过程描述，标准和步骤。人员不负责直接管理或者执行测试过程的活动，而是坚持评估。在许多情况下，坚持是组织内的人员评估，而不是测试过程或者项目外的。更多信息关于坚持客观评估的可以参考CMMI的过程和产品质量保证过程域。

3.3.1.10 GP 2.10 高级管理人员的评审状态

该通用实践的目的是提供高水平的管理人员在过程中的适当可视性。更高一级的管理包括在上述的管理水平直接负责组织对这一进程的管理水平。这些审查是对提供策略和过程总体指导的经理们的，而不是为那些日常直接执行监测和控制过程的人员。

3.3.2 GG 3 制度化已定义的过程

已定义过程是一个管理过程，它根据组织的裁剪准则从组织的一套标准过程里裁剪出来；它有已维护的过程描述；贡献工作产品，尺度，和其他过程改进信息到组织的过程资产里。一个已管理的过程和已定义的过程之间的明显差别是过程描述的适用范围，标准，和适用于特定项目，组，或者组织部门的步骤可能是不一样的。已定义过程尽可能是组织的标准，只是为了适应特殊项目或者组织部门才会在组织裁剪准则的基础上修改。

3.3.2.1 GP 3.1 建立已定义的过程

该通用实践是建立和维护过程的描述，这些过程是从组织的一套标准过程里裁剪出来以满足特别示例的需要。组织应该有包含过程域的标准过程，也有指导

裁剪那些标准过程的指导方针，用来满足项目或者组织部门的需要。在一个已定义的过程里，组织如何被执行的可变性被减少，过程资产，数据，知识被有效共享。关于组织的一套标准过程和裁剪准则请参考CMMI的组织过程定义过程域。

3.3.2.2 GP 3.2 收集改进信息

该通用实践的目的是收集信息，源自计划的原材料，执行过程以支持将来使用，组织过程的改进，和过程资产。信息和原材料被存储，并提供给那些正在（或者将要）计划和执行相同或类似过程的人员。

3.4 对通用实践过程域的支持

通用目标和通用实践是模型组件，它们直接定位组织过程的制度化。不论是TMMI还是CMMI的过程域都可以通过支持通用实践的执行同样的定位制度化。下面的章节提供了部分或者全部支持通用实践执行的过程域的概况，部分或者全部支持一个通用实践的执行。

3.4.1 GP2.2计划过程

测试计划：对所有项目相关的过程域（除了测试计划本身），测试计划过程能全部支持GP2.2。测试计划本身作为CMMI过程域-项目计划的一部分。

3.4.2 GP2.5培训人员

测试培训程序：通过使组织范围培训程序对那些将要执行或者支持过程的成员有效，测试培训程序支持所有过程域的GP2.5的执行。另外，测试计划过程支持通用实践，通过确定和组织被测项目中的测试和测试计划进行需要的培训。

3.4.3 G2.6管理配置

配置管理：CMMI配置管理过程可以为所有项目相关的过程域和一些组织级的过程域全面执行GP2.6，

3.4.4 G2.7确定并涉及利益相关者

测试计划：通过计划涉及标明的利益相关者和在测试计划中记录它们，测试计划过程支持这种所有项目相关过程域的通用实践。涉及利益相关者的测试计划本身可作为CMMI过程域项目计划的一部分。

3.4.5 GP2.8监控过程

测试监视和控制：测试监控过程域能全面执行所有过程域的GP2.8。

3.4.6 GP2.9坚持客观评价

过程和产品质量保证；CMMI过程和产品质量保证过程能全面执行所有过程域的GP2.9。

3.5 CMMI过程域对TMMI的支持

图3 TMMI Level and CMMI Level

虽然TMMI能被单独使用，它也当作是CMMI的辅助模型，因此在很多情况下，一个给定的TMMI级别需要来自相对应的CMMI级别或者更高CMMI级别的过程域的支持，图3为TMMI级别和CMMI级别的对应关系。在CMMI中详细说明的过程域和实践不会在TMMI中重复，它们只会被引用。下面分别介绍2级TMMI和3级TMMI所需的CMMI过程域的支持情况。 2级TMMI：

? 配置管理；如上所说的配置管理过程域可以充分执行项目相关的过程域和一

些组织过程域的GP2.6。如上所说，过程和产品质量保证可以充分执行所有过程域的GP2.9。

? 项目计划，这个过程域将给TMMI过程域“测试计划”提供支持。项目管理

实践能被测试管理重用。就测试计划的利益相关者参与而言，项目计划将为通用实践GP2.7提供特定的支持。

? 度量和分析，这个过程域将为TMMI过程域“测试政策和策略”的SG3“建立

测试性能指标”的执行提供支持。

? 需求管理，这个过程域的实施是一个派生约束管理（工作）产品，如产品风

险分析和测试设计，及让他们保持最新。就保持可追溯性的实践而言有可能在“测试设计和执行”过程域被重用。

? 需求开发，当在过程域“测试环境”中开发测试环境的时候，来自这个过程

域的实践能被重用。

? 风险管理，在过程域“测试计划”和“测试监控”中这个过程域的实践能被

重用，用来识别和控制产品风险和测试计划风险。 3级TMMI：

? 配置管理；配置管理过程域可以充分执行项目相关的过程域和一些组织过程

域的GP2.6。

? 过程和产品质量保证，过程和产品质量保证可以充分执行所有过程域的

GP2.9。

? 项目计划，这个过程域将为TMMI过程域“测试生命周期和集成”，特别是

SG3“建立一个主测试计划”的执行提供支持。 ? 项目管理实践能被测试管理重用。

? 组织过程焦点，这个过程域将为TMMI过程域“测试组织”，特别是SG4“确

定，计划和执行测试过程改进”和SG5“部署组织的测试过程吸取经验教训”的执行提供支持。

? 组织过程定义，这个过程域将为TMMI过程域“测试生命周期和集成”，特

别是SG1\建立组织的测试过程资产\的执行提供支持。

? 组织培训，这个过程域将为TMMI过程域“测试培训程序”提供支持。

验证，这个过程域的实践SG2“执行同行评审”将为TMMI过程域“同行评审”的执行提供支持。

请注意，CMMI中测试相关过程域的验证和确认没有作为TMMI里的动态测试过程的过程域支持。对于测试相关的CMMI过程域，TMMI过程域提供了支持和非常详细的说明。

4 TMMI过程域进阶

4.1 2级TMMI过程域

TMMI2级：管理级

在第2级，测试成为了管理过程，并明确地从调试中分开。由成熟度2级反射出的过程训练有助于确信在时间压力下，现行惯例被保留。然而，许多利益相关者仍然感觉它是编码过后的一个阶段。在改进测试过程的背景下，一个公司范围或者产品范围的测试策略被建立了。测试计划也被制定。在测试计划中，测试方法被定义，该方法基于这个级别的风险。风险管理技术被用来识别基于文档化需求的产品风险。测试计划将会定义需要测试什么，什么时候测试，如何测试以及有谁来测试。在利益相关者中间建立承诺，并根据需要修改。测试过程被监控以确保它按照计划执行，一旦有背离发生会有相应的动作。工作产品的状态和测试服务的递交对管理来说是可见的。从详细规格说明中选择测试用例的测试设计

技术被应用了。然而，在开发生命周期测试仍然开始的比较晚，比如要在设计或者在编码阶段才开始。测试分了多个层次，有单元测试，综合测试，系统测试和验收测试。对于每个确定的测试层次有指定的测试目标定义在组织范围或者产品范围的测试策略。2级TMMI组织的主要测试目标是检验产品是否符合指定的需求。还有一个目的是清楚地界定测试和调试。这个级别的TMMI有许多的质量问题是因为测试启动太晚。缺陷被引入从需求阶段，设计阶段到编码阶段。没有正式的评审程序去定位这个重要的问题。许多人认为编码过后的测试执行是主要的测试活动。

2级TMMI的过程域如下： 1) 测试政策和策略 2) 测试计划 3) 测试监控 4) 测试设计和执行 5) 测试环境

4.1.1 PA2.1 测试政策和策略

目标：测试政策和策略的目标是开发和建立测试策略和组织范围或者产品范围的策略，在此测试级别被明确定义。为了衡量测试性能，测试性能指标被引入。

介绍性说明：当组织想改进它的测试过程的时候，它首先应该清楚的定义测试政策。测试政策定义了组织总体测试目的，目标和测试相关的战略视图。重要的是测试政策与组织的商业（质量）政策相一致。测试政策有必要对组织所有相关人员实现一个统一的测试视图。这个统一的测试视图对于测试活动（过程改进）是必需的。测试政策必须实现新的开发，和维护测试活动。在测试政策中，测试过程改进的目标需要被说明。随后这些目标将会转成一套关键性能指标。测试政策及其相随的性能指标提供了明确的指示，沟通的方法，以期望和实现测试的性能级别。性能指示器客观的向相关人员展示了测试和测试过程改进的数值。在测试政策的基础上定义了测试策略。测试策略包含了组织或者产品（一个或多个项目）的通用测试需求。测试策略解决了通用产品风险，提出了减轻风险并与测试

政策相一致的过程。因此测试策略通过执行通用产品风险评估--研究在产品或者组织内的正在被开发的产品。一个典型的测试策略包括需要被实现的测试类别的描述，例如，单元测试，综合测试，系统测试和验收测试。对于每个测试类别中的目标，职责，主要任务和进入/退出标准进行定义。测试策略作为项目测试活动的起始点。项目依照组织范围或者产品范围建立测试策略。当测试策略被定义且被遵守的时候，测试类别只有少的重叠，且会导向一个更加有效的测试过程。此外，由于测试的目标和各个层次的做法是一致的，会导致更有效的测试过程。 范围

测试政策和策略过程域包含测试政策和测试策略的定义和部署。在测试策略中，测试级别被定义。对于每个测试级别，其中包括的测试目标，职责和主要任务被定义。为了测量测试性能和测试（改进）目标的完成度，测试性能指标被定义和部署。

具体目标和实践综述： SG1 建立测试政策 ? SP1.1 定义测试目标 ? SP1.2 定义测试政策

? SP1.3 分配测试政策到相关人员 SG2 建立测试策略

? SP2.1 执行通用产品风险管理 ? SP2.2 定义测试策略

? SP2.3 分配测试策略到相关人员 SG3 定义测试性能指标 ? SP 3.1 定义测试性能指标 ? SP 3.2 实施测试性能指标 目标的具体实践：

4.1.1.1 SG1 建立测试政策

测试政策，与企业（质量）政策一致，由利益相关者制定并一致同意。 ? SP 1.1 定义测试目标：在企业需要和其目标基础上定义和维护测试目

标。典型工作成果如下：

? 研究企业需要及其目标；研究企业需要及其目标的例子包括如下：

任务说明、关于产品的企业和用户需要、商业驱动、质量程序的主目标、企业（质量）政策、商业类型（如正在开发的产品的风险级别）；

? 为企业需要及其目标提供必要的反馈；

? 为企业需要及其目标定义测试目标追溯；测试目标的例子包括如下：

验证产品是适合使用的、预防运作中的缺陷发生、验证符合外部标准、供有关产品质量的能见度、短期测试执行的准备时间； ? 相关人员评审测试目标；

? 在适当的时候检查并修订测试目标，例如基于年度；

? SP 1.2 定义测试政策：测试政策，与企业（质量）政策一致，由利益相

关者制定并一致同意。在已定义的测试目标的基础上定义测试政策，典型的工作成果如下： ? 测试的定义；

? 调试的定义（故障定位和修复）；

? 有关测试和测试职业的基本观点、目标，增加了的测试价值； ? 要实现的质量级别； ? 测试机构的独立程度； ? 高级水平测试过程的定义； ? 测试的主要职责；

? 组织的方法和测试过程改进目标； ? 测试政策清楚的把测试从调试中分开；

? 相关人员评审测试政策； ? 定义和建立测试政策的所有权；

? 在适当的时候检查并修订测试政策，例如基于年度。

? SP 1.3 分配测试政策到相关人员：测试政策和测试目标被介绍和解释给

测试组内组外的相关人员。典型工作成果如下： ? 部署计划； ? 演示测试政策；

? 分配机制的例子包括如下：记录在手册里（质量体系）、在项目或

者部门会议上演示、贴海报、成为部门介绍程序的一部分、能在网站的显著位置访问到。

4.1.1.2 SG2 建立测试策略

一个组织范围或者产品范围的测试策略被建立和部署；识别和定义测试级别被执行。

? SP 2.1 执行一个通用的产品风险评估；一个通用的风险评估被执行来识

别测试的典型临界区域。典型工作成果为通用产品风险清单，每级风险都标有类别和优先级，成果内容如下：

? 识别并选择那些需要做通用风险评估的人员； ? 使用相关人员的输入来识别通用产品风险； ? 记录通用产品风险的背景和潜在的结果； ? 对各级通用产品风险确定与之关联的相关人员；

? 使用预定义的参数分析已确定的通用产品风险，例如，可能性和影

响；

? 通过已定义的风险类别，给通用产品风险分类，分组； ? 区分通用产品风险缓解的优先级；

? 评审和取得相关人员在一般产品风险的完整性，类别和优先级一致

同意；

? 适当的修订通用产品的风险请注意，定义在“测试计划”过程域

（SP1.1 定义产品风险类别和参数）的产品风险类别和参数，在这个特定的实践里被最大限度的重用。在（子）实践中执行通用产品风险评估的更多信息请参考过程域“测试计划”中SG1 “执行产品风险评估”；

? SP 2.2 定义测试策略；该测试策略定义每个测试级别并确定各个级别的

目标，职责，主要任务和进入/退出标准。典型的工作成果为测试策略文档，内容如下：

? 学习测试政策和目标；

? 必要时提供澄清测试政策和目标的反馈；

? 定义测试策略并能清晰的链接到已定义的政策和目标；

? 部分测试策略的实例如下：正在开发产品的一般风险；总的测试模

型（V模型，增加的生命周期）作为减少风险的一个途径；测试类别（如，单元测试，集成测试，系统测试和验收测试）；各个测试类别的目标，职责和只要任务，例如单元测试（验证单元设计中制定的当前类别代码覆盖率是否被实现）、集成测试（验证全局设计中指定的一起单元操作、验证接口说明书中指定的接口操作）、系统测试（验证需求说明书中指定的系统操作、要达到当前类别的系统需求覆盖率）、验收测试（验证该系统满足验收标准、验证系统是否是'适合使用'、当前类别的用户需求覆盖率是否被实现）； ? 被用在每个测试级别的测试用例设计技术； ? 在每个测试级别实现的测试种类； ? 每个测试类别的进入/退出标准； ? 必须遵守的标准； ? 级别独立性； ? 执行测试的环境；

? 每个测试级别的自动化方法； ? 回归测试方法；

? 评审测试策略；

? 定义和建立测试策略的所有权；

? 在适当的时候重访并修订测试策略，例如基于年度。

请注意，测试策略将作为项目中测试执行的起点。而且，每个项目可以调整其整体战略以满足它的需要。不需要遵守的应当明确记录在测试计划。

? SP 2.3 分发测试策略到相关人员；测试策略被介绍到测试内外的相关人

员，并与之讨论。典型工作成果是部署计划和演示测试策略。分配机制的例子包括如下：

? 记录在手册里或者质量体系中 ? 在项目或者部门会议上演示 ? 张贴海报

? 成为部门介绍程序的一部分 ? 能在网站的显著位置访问到

4.1.1.3 SG3 建立测试性能指标

建立和部署面向目标的测试过程性能指标。

? SP 3.1 定义测试性能指标；测试性能指标定义在测试政策和目标基础

上，包括数据收集，存储和分析的过程。典型的工作成果为测试性能指标、数据收集，存储，分析和报告程序，其内容如下：

? 学习测试政策和目标,如测试过程改进的目标，必要时提供澄清测试

政策和目标的反馈；

? 定义测试性能指标并能链接到已定义的政策和目标；测试性能指标

的例子如下：测试成本 测试所需的时间 缺陷的数量 缺陷检测率 测试成熟度； ? 评审性能指标；

? 定义和建立测试性能指标的所有权；

? 指定如何获得和储存性能指标； ? 指定如何分析和报告性能指标。

? SP 3.2 部署测试性能指标；部署测试性能指标，提供测量结果，这些结果都可对应到已确定的测试性能指标。典型的工作成果为测试性能指标数据、测试性能指标的报告，其内容如下： ? 获取指定的性能指标数据； ? 分析和解释性能指标；

? 管理和存储性能指标数据和分析结果； ? 定期报告性能指标给相关人员；

? 辅助相关人员理解结果；协助理解结果的实例包括：与相关人员讨论

结果、提供相关的信息，背景和解释等。

4.1.2 PA2.2 测试计划

目标：测试计划的目标是在已识别的风险和已定义的测试策略基础上定义测试方法，并建立和维护有依据的计划来执行和管理测试活动。

介绍性说明：在确认测试任务分配后，一个总体的学习要被执行，包括要测试的产品，项目组织，需求和开发过程。作为测试计划的一部分，来源于测试策略，并基于产品风险评估，测试方法要被定义。根据不同的水平和风险类型，它决定哪些产品需求要测试，到什么程度，如何以及何时测试，目的是给系统的最高风险级别提供最有可能的级别和覆盖类型。基于测试方法，已完成的工作要被评估，以此为结果，要提供成本清晰的建议的测试方法。产品风险，测试方法和评估被定义在相关人员的紧密合作上。测试人员不应该自己做决定。测试计划于测试策略一起，确认或者解释不遵守部分。在测试计划里，将要提供的测试交付被明确，需要的资源被确定，基础设施的相关方面被定义。另外，测试计划风险被明确。因此，测试计划将会定义测试需要什么，什么时候测，如何测以及由谁来测。最后，测试计划文档有相关人员制定和实施。测试计划为执行和控制测试活动提供了依据。测试计划通常需要加以修订，使用正式的变更控制流程，随着

项目的进展，以解决需求和承诺的变更，不准确的估计，纠正措施的变化，以及（测试）过程中的变化。

范围：测试计划过程域包括执行测试对象的产品风险评估，在已确定风险基础上定义不同的测试方法。它也包括将要执行的测试的开发评估，建立必要的承诺，定义和维护计划用以执行和管理测试。测试计划需要每个明确的测试级别。在2级TMMI，测试计划被制定在在每个测试级别上。 具体目标和实践综述

SG1 执行产品风险评估

? SP 1.1 定义产品风险类别和参数 ? SP 1.2 确定产品风险 ? SP 1.3 分析产品风险 SG2 建立测试方法

? SP 2.1 确定要测试的项目和功能 ? SP 2.2 定义测试方法 ? SP 2.3 定义进入标准 ? SP 2.4 定义退出标准 ? SP 2.5 定义中止和恢复标准 SG3 建立测试评估

? SP 3.1 建立高层工作分解结构 ? SP 3.2 定义测试生命周期

? SP 3.3 确定测试投入和费用的评估 SG4 制定测试计划

? SP 4.1 建立测试时间表 ? SP 4.2 测试人员计划

? SP 4.3 计划相关人员参与 ? SP 4.4 识别测试项目风险 ? SP 4.5 建立测试计划 SG5 获得测试计划承诺 ? SP 5.1 评审测试计划 ? SP 5.2 调和工作和资源水平 ? SP 5.3 获得测试计划承诺 目标的具体实践：

4.1.2.1 SG1 执行产品风险评估

产品风险评估被执行来明确测试的关键区域。

? SP 1.1 定义产品风险类别和参数：在风险评估期间使用的产品风险类别

和参数被定义。典型的工作成果为产品风险类别清单、产品风险评估和优先级标准，其内容为：

? 决定产品风险类别；明确产品风险类别的原因是在未来测试任务变

化时帮助进入测试计划的测试类型。产品风险类别实例包括如下：功能性风险、结构性风险、非功能性风险（如可用性，有效性，可移植性，可维护性，可靠性）、变更相关的风险（如回退）； ? 为评估和测量产品风险可能性和影响水平定义一致的标准； ? 定义每个产品风险级别的阙值；风险级别根据风险的重要性，根据

其特有影响和可能性来定义。对于每个风险级别，阈值被建立以确定产品风险的可接受或不可接受，产品风险的优先级，或管理行为的引发。

? SP 1.2 明确产品风险；产品风险被明确和记录。典型的工作成果为明确

产品风险，其内容为：

? 识别并选择参与风险评估的相关人员；

? 利用相关人员和需求文档的输入明确产品风险；产品风险识别技术

实例包括如下：风险研讨会、脑力激荡、专家访谈、检查清单、吸取的经验教训；

? 记录背景和潜在风险后果； ? 确定每个风险级别的相关人员； ? 审查测试任务已明确的产品风险。

? SP 1.3 分析产品风险；利用预定义的类别和参数对产品风险进行评估，

分类以及确定优先级。典型的工作成果为产品风险清单，并附有分配到每级风险的类别和优先级，其内容为：

? 利用预定义的参数，如可能性和影响，分析已明确的产品风险； ? 通过已定义的风险类别，对产品风险分类，分组； ? 优先考虑产品风险缓解；

? 在产品风险和需求之间建立横向的追溯，以确定产品风险的源头被

记录；

? 生成一个需求/产品风险的可追溯模型；

? 评审并获得相关人员在产品风险的完整性，类别和优先级方面的一

致同意；

? 适当的时候修订产品风险；何时需要修订产品风险包括如下：新建

或者改变需求、软件开发方法改变、项目中质量问题的经验教训。

4.1.2.2 SG2 建立测试方法

在已明确的产品风险基础上建立并商定测试方法。

? SP 2.1 确定要测试的功能和项目：基于产品风险，确定要测试和不需要

测试的功能和项目。典型的工作成果包括需要和不需要测试的项目清单、需要和不需要测试的功能清单，其内容如下：

? 细分产品风险优先级到每个需要和不需要测试的项目；

? 为每个确定要测试的项目记录风险级别和源文件（测试基础）； ? 细分产品风险优先级到每个需要和不需要测试的功能； ? 为每个确定要测试的功能记录风险级别和源文件（测试基础）； ? 与相关人员评审需要和不需要测试的项目和功能清单。

? SP 2.2 定义测试方法：测试方法被定义以减轻那些已识别和已确定优先

级的产品风险。典型的工作成果包括测试方法、其他方法，如选择一套测试设计技术，应该被详细描述用以支持后来主要测试任务的确定，并评估做每一项任务所需要的时间，其内容如下：

? 选择要使用的测试设计技术；在已定义的产品风险基础上多个测试

设计技术被定义。选择测试设计技巧的标准包括如下：系统类型、监管标准、客户或合同需求、风险级别、风险类型、现有文献、测试人员的学识、时间和预算、开发生命周期、已发现错误类型的先前经验；

? 定义评审工作产品的方法；

? 定义重新测试的方法；重新测试方法的实例如下：对于所有高风险

的测试条目，要重新执行充分测试过程；对于所有低风险的测试条目，可以用单独的工具重新测试；

? 定义回归测试的方法；回归测试方法的实例如下：回归测试的重点，

例如哪些项目和/或功能，被选中并执行测试案例，要执行测试的类型，手动测试或使用自动化测试工具； ? 确定将要被使用的支持性测试工具；

? 确定有关测试方法的重大限制；关于测试方法限制的实例如下：测

试的可用性资源、测试环境特征、项目期限；

? 测试方法与已定义的组织范围或者产品范围的测试策略保持一致； ? 明确不遵守测试策略的部分，并说明理由； ? 与相关人员评审测试方法；

? 适当的时候修订测试方法；何时需要修订测试方法的实例如下：新

建或者改变产品风险的优先级、项目中应用测试方法的经验学习。

? SP 2.3 定义进入标准：测试的进入标准被定义以防止在不允许进入测试

过程的条件下开始测试。典型的工作成果为进入标准说明，其内容如下： ? 定义一套测试过程相关的进入标准；测试过程相关的进入标准的实

例如下：来自上一个测试级别的总结报告的可用性、依据需求的测试环境的可用性、相关文档的可用性（如发布说明，用户手册，安装手册等）；

? 定义一套有关产品质量的进入标准；有关产品质量的进入标准的实

例如下：一个成功的摄入量测试没有突出的缺陷 所有悬而未决的缺陷至少要有状态分析；

? 与相关人员评审进入标准，特别是那些负责会议的进入标准。 ? SP 2.4 定义退出标准：计划何时停止测试的退出标准被定义。典型的工

作成果为推出标准说明，其内容如下：

? 定义一套有关测试过程的退出标准；有关测试过程的退出标准的例

子如下：准备被成功执行的测试百分比、每个测试条目的覆盖百分比（如代码覆盖率和需求覆盖率）、一个经批准的测试总结报告的可用性；

? 定义一套有关产品质量的退出标准；有关产品质量的退出标准的例

子如下：所有高优先级产品风险趋向缓和缺陷检测率低于某一个阙值、基于优先级的突出缺陷的数目有检查设计支持的软件模块的百分比；

? 与相关人员评审退出标准。

请注意，测试级别的退出标准应该与与之相关的测试级别的退出标准保持一致。

? SP 2.5 定义暂停和恢复标准：用于暂停所有或部分测试项目和/或功能

的测试任务的标准被定义。典型的工作成果包括暂停标准说明和恢复标准说明，其内容如下：

? 指定用于暂停所有或部分测试项目和/或功能的测试任务的暂停标

准；暂停标准的例子如下：关键缺陷的数目、没有可再生的缺陷的数目、由于测试环境，测试执行产生的问题； ? 指定用于必须被重复的测试任务的恢复标准。

4.1.2.3 SG3 建立测试评估

在讨论测试方法和计划测试活动中，好的已创立的测试评估被建立、维护使用。

? SP 3.1 建立高层工作分解结构：建立高层工作分解结构（WBS），以清

楚地定义测试评估的范围。典型的工作成果包括测试工作的产品清单、要执行的测试任务、工作分解结构，其内容如下：

? 确定基于已定义测试方法的将要被开发的测试工作产品； ? 确定被外部需要的工作产品； ? 确定将被重用的工作产品；

? 确定相关到测试工作产品的测试任务

? 确定间接测试任务，如测试管理，会议，配置管理等。

请注意，WBS也应该重视执行测试环境需求的任务，更多信息请参考“测试环境”过程域。

? SP 3.2 定义测试生命周期：定义测试生命周期，以规划计划的投入。典

型的工作成果包括测试生命周期阶段说明、测试里程碑说明，其内容如下：

? 定义测试生命周期阶段；最小程度，要有一个测试计划，测试准备

和测试执行；

? 计划测试准备阶段，以便于它在完成测试基础后立刻开始； ? 已定义的测试生命周期要与高层工作分解结构保持一致； ? 确定每个测试生命周期阶段的主要里程碑。

请注意，理解生命周期对于确定测试计划的投入，初始计划的时机，以及重新计划的时机和标准都很重要。

? SP 3.3 确定测试投入和费用的评估：对基于评估的测试工作产品和任务

评估测试投入和费用。典型的工作成果包括测试工作产品和测试任务的属性评估、测试投入评估、测试费用评估，其内容如下：

? 确定和维护测试工作产品和测试任务的属性的评估；用于评估测试

工作产品和测试任务的属性实例包括如下：大小(如测试实例的数目，页数，测试条目的数目，测试数据的容量，需求的数目等)、相关测试条目的复杂度（如轮数）、可重用水平、相关产品风险的优先级。请注意，适当的方法（如验证模型和历史数据）应该被使用，以确定将被用来做资源需求评估的测试工作产品和测试任务的属性 ? 研究能影响测试评估的（技术的）因素；影响测试评估的因数包括

如下：测试工具的使用、上一个测试级别的质量、测试基础的质量、开发环境、测试环境、来自上一个项目的测试软件的可用性、测试人员的知识和技能水平；

? 选择模型和/或历史数据，以改变测试工作产品和测试任务的属性到

评估的投入和费用；能被用来做测试评估的模型包括如下:测试要点分析、Dephi、开发投入和测试投入的比例；

? 当评估测试投入和费用时，包括一些支持性基础结构需要；支持性

基础结构需要的例子包括如下：测试环境、临界的计算机资源、办公环境、测试工具；

? 使用模型和/或历史数据评估测试投入和费用； ? 记录源自评估的假设；

? 记录测试评估数据，包括被用来重建评估的相关信息。

4.1.2.4 SG4 开发测试计划

测试计划被建立和维护，作为管理测试和与相关人员通讯的基础。

? SP 4.1 建立测试时间表：在已开发的测试评估和已定义的测试生命周期

基础上，测试时间表和预定义的可管理大小的阶段被建立和维护。典型的工作成果为测试时间表，其内容如下：

? 确定测试时间表约束条件，如任务周期，资源，必要的输入等； ? 确定测试任务依赖；

? 定义测试时间表（测试活动时间，测试生命周期阶段和测试里程碑）； ? 在定义测试时间表时记录假定条件；

? 建立矫正的行动标准，以决定什么构成源自测试计划的重大偏离，

可能需要重新计划。

? SP 4.2 测试人员计划：计划必要的拥有相关知识和技能的测试人力资

源，以执行测试工作。典型的工作成果包括所需人员编制、所需技能的详细清单、新聘用人员编制和计划、测试培训计划，其内容如下： ? 在工作分解结构，测试评估和测试时间表的基础上决定人员编制； ? 确定所需的知识和技能，以执行测试任务； ? 评估现有的知识和技能；

? 提供必需知识和技能的选择机制；选择机制的例子包括如下：内部

培训、外部培训、培训讲师、外部技能获取； ? 把选择机制合并到测试计划中。

? SP 4.3 计划参与人员：计划已明确的参与相关人员被确定，从测试生命

周期的所有阶段，通过明确人员的类型和功能需要，在测试活动的表现，描述他们的关联和与特定测试活动交互的深度。典型工作成果为相关人员参与计划。

? SP 4.4 明确测试项目任务：测试项目任务被确定，分析和存档。典型的

工作成果包括确定测试项目任务、确定测试项目任务的优先次序、测试项目风险应急，其内容如下：

? 确定测试项目风险；项目风险辨认技术包括如下：脑力激荡、专家

评审、检查单；

? 分析已确定的测试项目风险，就可能性和影响而言； ? 确定已分析的项目风险的优先级；

? 对已存档的测试项目风险的完整性和优先级进行评审并获得相关人

员的一致同意；

? 对（高优先级的）测试项目风险定义应急措施；

? 适当的时候修订测试项目风险；何时需要修订测试项目风险包括如

下：当新的测试项目风险被定义时、当测试项目风险可能改变时、当测试项目风险被撤掉时、当测试环境显著改变时。

? SP 4.5 建立测试计划：测试计划被建立和维护，作为管理测试的依据。

之前实践的结果被记录在总体的测试计划中，用合乎逻辑的方式把这些信息捆绑在一起。典型的工作成果为测试计划文档，其内容如下： ? 测试计划标识； ? 总体介绍；

? 对测试策略的违背，并列出理由；

? 需要测试和不需要测试的条目（包含优先级）； ? 需要测试和不需要测试的功能（包含优先级）； ? 测试方法（如测试设计技术）； ? 进入和退出标准； ? 暂停和恢复标准； ? 测试里程碑和工作产品； ? 测试生命周期和任务；

? 环境的需要和要求（包括办公环境）； ? 人员配置和培训需求； ? 相关人员的参与测试评估； ? 测试时间表；

? 测试项目风险和应急措施环境的需要和要求。

4.1.2.5 SG5 获得测试计划的承诺

建立和维护测试计划的承诺

? SP 5.1 评审测试计划：评审测试计划（以及其他可能的计划），以了解

测试承诺。典型的工作成果为测试计划评审记录，其内容主要包括组织相关人员的评审，让他们理解测试要求。

? SP 5.2 兼顾工作和资源水平：评审测试计划，以反映现有及估计的资源。

典型的工作成果包括修订过的测试方法和相应的评估参数、重新磋商的测试预算、修订过的测试时间表、修订过的产品风险列表、重新磋商的相关人员协议，其内容应该包括：

? 与相关人员讨论现有和估计的资源之前的差别； ? 调停现有和估计的资源之间的差别。

? 请注意，典型地要完成调停工作，可以通过降低或者延迟技术性能，

协商以获得更多资源，设法提高生产力，外包，调整员工的技能组合，或者修改日程。

? SP 5.3 获得测试计划承诺：从负责执行和支持测试计划的相关人员那里

获得承诺。典型的工作成果包括记录在案的承诺要求、记录在案的承诺、明确必需的支持，与相关人员就承诺达成协议，其内容如下： ? 记录所有的组织承诺，包括完整的和临时的； ? 适当的时候与高级经理评审内部承诺； ? 适当的时候与高级经理评审外部承诺；

? 请注意，WBS能被用作确保获得所有任务承诺的检查清单。相关人员

合作的计划应该明确各自的承诺。

5 TMMI通用目标和通用实践进阶

5.1 GG2 制度化一个管理过程 5.1.1 GP2.1 建立组织政策

建立和维护组织政策，用以计划和执行测试计划。其应该包括如下内容： ? 测试计划政策通常指定：每个项目都定义了一套测试计划，其中包括一

套测试方法，以及与之相随的测试投入和评估； ? 项目的测试方法来自于测试策略；

? 测试计划应使用一个标准的过程和模板来制定； ? 执行测试计划时应使用标准工具； ? 需求被用作测试计划活动的基础；

? 测试承诺通过与资源管理人员，企业管理人员和项目管理人员交涉以达

成一致 ；

? 在测试活动的其他受影响的组的参与是由这些组明确同意的 ； ? 管理层明确评审所有的由项目组外延到组织的测试承诺； ? 测试计划被管理和控制。

5.1.2 GP2.2 计划过程

建立和维护计划，用以执行测试计划过程。执行测试计划过程的计划被含在项目计划中，它也在CMMI项目计划过程域中被描述。

5.1.3 GP2.3 提供资源

提供适当的资源给执行测试计划过程，开发测试工作产品和提供过程的服务。其存在一份关于测试的记录在案并经批准的任务分配表，包括问题列表、关于目标和对象的期望、退出标准、需要测试和不需要测试的条目和功能、将要执行的测试类型、实行的标准、成本、进度和资源限制等。 给测试管理提供充足

的时间，用以执行测试计划活动。经验丰富的人员，有些精通于测试的应用领域，有些精通于开发过程，可以在支持测试计划的开发方面提供计划过程的工具，这些工具包括：

? 项目计划和调度工具； ? 评估工具； ? 风险评估工具； ? 测试管理工具； ? 配置管理工具。

5.1.4 GP2.4 分配职责

分配职责和权力以执行测试计划过程，开发工作产品，提供测试计划过程的服务等。测试经理通常指定为负责合同谈判和开发测试计划，并直接或委托，负责协调该项目的测试计划的过程。

5.1.5 GP2.5 培训人员

培训人员，对执行测试计划过程、参与测试计划制定的测试管理人员，其他人员或者小组，进行测试计划以及相关的过程和技术的培训。主要的培训内容应该包括：

? 计划原则； ? 测试策略；

? 产品和项目的风险评估程序和方法； ? 定义测试方法； ? 测试计划的模板和标准； ? 测试机构；

? 测试评估和测试调度； ? 测试设计技术简介； ? 支持测试计划的工具。

5.1.6 GP2.6 配置管理

放置测试计划过程中已规划的工作产品到相应级别的配置下。放置工作包括以下内容：

? 工作分解结构； ? 测试评估数据； ? 产品的风险评估数据； ? 试验计划的评审报告； ? 测试计划。

5.1.7 GP2.7 明确并使相关人员参与

根据计划明确并使相关人员参与测试计划过程。从顾客，终端用户，开发者，生产者，测试者，供应商，市场人员，维护人员，服务人员，以及其他可能受到影响的人员，还有测试过程中选择相关人员。对相关人员参与活动应该包括以下内容：

? 选择产品及产品部件进行测试；

? 通过参与产品风险评估，确定产品及产品组件的风险水平和风险类型； ? 提供测试评估的输入；

? 评审和解决测试项目风险的问题；

? 明确承诺必要的测试资源评审和批准测试计划。

5.1.8 GP2.8 监控过程

根据计划监控测试计划过程，以执行过程并采取适当的行动。度量监控测试计划过程的例子包括如下：

? 修订测试计划的数量；

? 实际的投入和交货时间与计划的投入和交货时间的比较； ? 每个修订版中测试项目改变的风险级别的数目； ? 每个修订版中的成本，进度和投入差异。

5.1.9 GP2.9 坚持客观评价

基于过程描述，标准，程序和确定的不准从，坚持对测试计划过程的客观评价。评审和/或审计客观评价的例子包括如下：

? 遵守测试策略；

? 遵守标准（程序和模板）； ? 测试计划的质量； ? 已定义的测试方法； ? 风险评估过程； ? 测试评估过程；

? 评审和作出测试承诺的活动。

5.1.10 GP2.10 与高级管理层的评审状况

与高级管理层评审测试计划过程的活动，状态和结果，并解决问题。

5.2 GG3 制度化已定义的过程

适用3级TMMI。

5.2.1 GP3.1 建立一个已定义的过程

建立和维护一个已定义测试计划过程的描述。

5.2.2 GP3.2 收集改进信息

收集工作产品，度量，度量结果和源自于计划和执行测试计划过程，以支持未来使用和组织过程和过程资产的改进的信息。度量的例子包括如下：

? 通过程序和模板建立的测试计划的百分比；

? 记录产品风险评估结果和测试方法的测试计划的百分比； ? 经管理层正式评审和批准的测试计划的百分比； ? 测试计划投入；

? 测试评估准确性

本文来源：https://www.bwwdw.com/article/a2mw.html