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

测试成熟度模型集成Test Maturity Model Integration（TMMI）目录1 测试成熟度模型集成（TMMI）11.1 介绍11.2 背景和历史11.3 起源21.4 TMMI的领域31.4.1 软件和系统工程31.4.2 测试级别31.4.3 TMMI和CMMI31.4.4 评定31.4.5 改善的方法42 TMMI成熟度水平42.1 概述42.2 级别1 初始的52.3 级别2 可管理的62.4 级别3 可定义的62.5 级别4 可测量的72.6 级别5 可优化的83 TMMI的结构93.1 必需的，可预料的和提供信息的组件93.1.1 必需的组件93.1.2 期望的组件93.1.3 信息组件103.2 TMMI的组件103.2.1 成熟度级别103.2.2 过程域103.2.3 目标113.2.4 介绍性说明113.2.5 范围113.2.6 特定目标113.2.7 通用目标113.2.8 特定的实践113.2.9 典型工作产品123.2.10 子实践123.2.11 通用实践123.2.12 通用实践细节123.2.13 支持性信息组件123.3 通用目标和通用实践133.3.1 GG 2 制度化可管理过程143.3.2 GG 3 制度化已定义的过程163.4 对通用实践过程域的支持173.4.1 GP2.2计划过程173.4.2 GP2.5培训人员173.4.3 G2.6管理配置173.4.4 G2.7确定并涉及利益相关者183.4.5 GP2.8监控过程183.4.6 GP2.9坚持客观评价183.5 CMMI过程域对TMMI的支持184 TMMI过程域进阶204.1 2级TMMI过程域204.1.1 PA2.1 测试政策和策略214.1.2 PA2.2 测试计划275 TMMI通用目标和通用实践进阶385.1 GG2 制度化一个管理过程385.1.1 GP2.1 建立组织政策385.1.2 GP2.2 计划过程385.1.3 GP2.3 提供资源385.1.4 GP2.4 分配职责395.1.5 GP2.5 培训人员395.1.6 GP2.6 配置管理405.1.7 GP2.7 明确并使相关人员参与405.1.8 GP2.8 监控过程405.1.9 GP2.9 坚持客观评价415.1.10 GP2.10 与高级管理层的评审状况415.2 GG3 制度化已定义的过程415.2.1 GP3.1 建立一个已定义的过程415.2.2 GP3.2 收集改进信息411 测试成熟度模型集成（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组织软件测试方面的标准条款术语。l TMMI是TMMI组织的注册商标l CMM和CMMI是Carnegie Mellon大学的注册商标l 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.TMMIF找到。这些需求是基于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有如下过程域：l 测试组织l 测试培训程序l 测试生命周期和整合l 非功能测试l 同行评审2.5 级别4 可测量的在4级TMMI组织，测试是一个充分定义，有事实根据和可度量的过程。在4级成熟度组织和项目为产品质量和过程性能建立多个目标，并作为标准管理他们。产品质量和过程性能在统计条款上被理解，在整个生命周期被管理。测量成为组织度量库的一部分以支持基于事实策略的制定。评审和检查被视为测试的一部分并用来度量文档质量。静态和动态的测试方法被集成到一起。评审被正式的使用来控制质量关口。产品使用质量评价量化标准的属性，如可靠性，可用性和可维护性。一个组织广泛的测试度量方案提供了有关信息和能见度测试过程。测试被认为是评估，它由检测产品和相关的工作产品生命周期有关的所有活动组成。TMMI级别4有如下过程域：l 测试度量l 产品质量评估l 高级同行评审2.6 级别5 可优化的在取得之前成熟度级别所有改进目标的基础上，测试是一个完全可定义的过程，并能控制成本和测试效率。在5级TMMI中，组织在理解众多变化过程中的固有的常见原因的基础上持续改进它的过程。通过渐近和改进的过程和技术改进，提高测试过程的性能被执行。方法和技术被优化，并持续的致力于微调和测试过程提高。缺陷预防和质量控制被实践。统计抽样，信心水平度量，确实性和可信赖性驱动测试过程。除了其他，缺陷预防和质量控制被引入成为过程域。测试过程的特点是基于质量测量的抽样。存在一个详细的步骤来选择和评估测试工具。在测试设计，测试执行，衰退测试，测试用例管理等等期间尽可能的用工具来支持测试过程。在5级TMMI，支持通过一个过程资产库实践过程重用。测试是个缺陷预防为目标的过程。TMMI级别5有如下过程域：l 缺陷预防l 测试过程优化l 质量控制3 TMMI的结构图2 TMMI StructureTMMI的结构很大程度上建立在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.3 通用目标和通用实践本章描述了所有通用目标和通用实践。通用目标和通用实践很大程度上来源于CMMI。通用目标被组织成数字序列。在它们支持的通用目标下通用实践也被组织成数字序列。请注意，来自CMMI的通用目标，GG1实现特定目标没有被加入是因为它仅仅叙述CMMI的持续表示，因此没有适当的TMMI的阶段表述。否则CMMI的序列大纲可以被完全应用，以避免组织在使用CMMI和TMMI时的混淆。你的能力级别，将决定哪些通用目标和实践是适用的。当试图达到2级成熟度时，2级成熟度的过程域，通用目标2和伴随的通用实践也是适用的。通用目标3仅仅适用于当试图达到3级或者更高成熟度的时候。这就意味着当你已经达到2级成熟度的时候，为了达到3级成熟度，你必须回到2级的过程域，应用通用目标3和相关的实践。在过程改进中，制度化是重要的内容。当在通用目标和通用实践提及时，制度化意味着该过程在工作执行的方式根深蒂固，并有保证和连贯性。一个制度化的过程更像是时间压力下的保留。当过程的需求和对象发生改变时，过程的执行也需要改变以确保它仍然活动。通用实践描述的实体定位了制度化的各个方面。3.3.1 GG 2 制度化可管理过程一个可管理的过程是完成必要的工作，产生工作产品的过程；是一个有计划并按照策略执行的过程；有技能的员工有充足的资源生产可控的产出；涉及利益相关者；可监控；有评审；评估其遵守过程描述。过程能用项目，组，或者组织单元来示例。由可管理的过程提供的控件，有助于确保既定的过程是在面临压力时的保留。 GP 2.1 建立组织策略该通用实践的目的是定义过程的组织期望，并使这些期望呈现给那些在组织中受影响的人。一般而言，高级管理人员负责建立和传达指导原则，方向和负责该组织的期望。 GP 2.2 计划过程这里通用实践的目的是决定哪些是执行过程所需要的，并实现既定目标，准备执行过程中的计划，准备一个过程的描述，而且能够从利益相关者通过执行评审计划达成协议。 GP 2.3 提供资源这里通用实践的目的是要确保必要的资源来执行根据计划定义好的过程。资源包括充足的资金，适当的物理设施，熟练的人，和适当的工具。 GP 2.4 分配责任该通用实践的目的是确保有问责制来执行过程并实现整个过程生命中指定的结果。被分配的人员必须要有适当的权力来执行所分配的事。分配职责可以使用详细的工作描述或者活动的文档，例如执行过程的计划。 GP 2.5 培训人员该通用实践的目的是确保人员有必要的技能和经验来执行或者支持过程。需要提供适当的培训。概要的培训要提供给那些与执行工作有交互的人员。通过建立对过程统一理解，传授执行过程所需要的技能和知识，培训支持成功的过程性能。 GP 2.6 管理配置该通用实践的目的是建立和维护过程在有效生命周期指定工作产品的完整性。这里的工作产品特指在执行过程的计划里指出的，除了这个级别的配置管理说明，如版本控制，使用基线的正式配置管理等。配置管理实践的例子包括版本控制，更改历史记录和控制，状态识别和使用配置管理工具。更多信息关于把工作产品放到配置管理的可以参考CMMI的配置管理过程域。 GP 2.7 识别及使相关利益共享者参与该通用实践的目的是在过程执行期间建立和维护期望利益相关者的参与。利益相关者要参与的活动有计划，决定，承诺，沟通，评审，问题的解决。决定性的利益相关者包括经理和用户/客户。经理的职责包括承诺，执行活动和改进测试能力的相关任务的能力。用户的职责包括质量相关的活动，涉及到面向用户的任务。重点是征求用户/客户支持，协商一致和参与的活动，如产品风险分析，验收测试和可用性测试。根据不用的测试级别，开发人员也是利益相关者，如在测试部分，开发人员经常自己执行测试，而在验收测试阶段开发人员变成一个利益相关者来讨论事件发现，商定入口标准等。 GP 2.8 监视和控制过程该通用实践的目的是执行测试过程日常的监视和控制。在测试过程中维持适当的清晰度以便在必要的时候产用适当的行动。监控过程包括度量测试过程和它的工作产品的合适属性。更多信息关于把工作产品放到配置管理的可以参考CMMI的配置管理过程域。度量方面的更多信息可以参考CMMI的度量和分析过程域。 GP 2.9 坚持客观评估该通用目标的目的是提供可靠的保证，确保过程是按照计划执行的，并遵循它的过程描述，标准和步骤。人员不负责直接管理或者执行测试过程的活动，而是坚持评估。在许多情况下，坚持是组织内的人员评估，而不是测试过程或者项目外的。更多信息关于坚持客观评估的可以参考CMMI的过程和产品质量保证过程域。0 GP 2.10 高级管理人员的评审状态该通用实践的目的是提供高水平的管理人员在过程中的适当可视性。更高一级的管理包括在上述的管理水平直接负责组织对这一进程的管理水平。这些审查是对提供策略和过程总体指导的经理们的，而不是为那些日常直接执行监测和控制过程的人员。3.3.2 GG 3 制度化已定义的过程已定义过程是一个管理过程，它根据组织的裁剪准则从组织的一套标准过程里裁剪出来；它有已维护的过程描述；贡献工作产品，尺度，和其他过程改进信息到组织的过程资产里。一个已管理的过程和已定义的过程之间的明显差别是过程描述的适用范围，标准，和适用于特定项目，组，或者组织部门的步骤可能是不一样的。已定义过程尽可能是组织的标准，只是为了适应特殊项目或者组织部门才会在组织裁剪准则的基础上修改。 GP 3.1 建立已定义的过程该通用实践是建立和维护过程的描述，这些过程是从组织的一套标准过程里裁剪出来以满足特别示例的需要。组织应该有包含过程域的标准过程，也有指导裁剪那些标准过程的指导方针，用来满足项目或者组织部门的需要。在一个已定义的过程里，组织如何被执行的可变性被减少，过程资产，数据，知识被有效共享。关于组织的一套标准过程和裁剪准则请参考CMMI的组织过程定义过程域。 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：l 配置管理；如上所说的配置管理过程域可以充分执行项目相关的过程域和一些组织过程域的GP2.6。如上所说，过程和产品质量保证可以充分执行所有过程域的GP2.9。l 项目计划，这个过程域将给TMMI过程域“测试计划”提供支持。项目管理实践能被测试管理重用。就测试计划的利益相关者参与而言，项目计划将为通用实践GP2.7提供特定的支持。l 度量和分析，这个过程域将为TMMI过程域“测试政策和策略”的SG3“建立测试性能指标”的执行提供支持。l 需求管理，这个过程域的实施是一个派生约束管理（工作）产品，如产品风险分析和测试设计，及让他们保持最新。就保持可追溯性的实践而言有可能在“测试设计和执行”过程域被重用。l 需求开发，当在过程域“测试环境”中开发测试环境的时候，来自这个过程域的实践能被重用。l 风险管理，在过程域“测试计划”和“测试监控”中这个过程域的实践能被重用，用来识别和控制产品风险和测试计划风险。3级TMMI：l 配置管理；配置管理过程域可以充分执行项目相关的过程域和一些组织过程域的GP2.6。l 过程和产品质量保证，过程和产品质量保证可以充分执行所有过程域的GP2.9。l 项目计划，这个过程域将为TMMI过程域“测试生命周期和集成”，特别是SG3“建立一个主测试计划”的执行提供支持。l 项目管理实践能被测试管理重用。l 组织过程焦点，这个过程域将为TMMI过程域“测试组织”，特别是SG4“确定，计划和执行测试过程改进”和SG5“部署组织的测试过程吸取经验教训”的执行提供支持。l 组织过程定义，这个过程域将为TMMI过程域“测试生命周期和集成”，特别是SG1建立组织的测试过程资产的执行提供支持。l 组织培训，这个过程域将为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 建立测试政策l SP1.1 定义测试目标l SP1.2 定义测试政策l SP1.3 分配测试政策到相关人员SG2 建立测试策略l SP2.1 执行通用产品风险管理l SP2.2 定义测试策略l SP2.3 分配测试策略到相关人员SG3 定义测试性能指标l SP 3.1 定义测试性能指标l SP 3.2 实施测试性能指标目标的具体实践： SG1 建立测试政策测试政策，与企业（质量）政策一致，由利益相关者制定并一致同意。l SP 1.1 定义测试目标：在企业需要和其目标基础上定义和维护测试目标。典型工作成果如下： 研究企业需要及其目标；研究企业需要及其目标的例子包括如下：任务说明、关于产品的企业和用户需要、商业驱动、质量程序的主目标、企业（质量）政策、商业类型（如正在开发的产品的风险级别）； 为企业需要及其目标提供必要的反馈； 为企业需要及其目标定义测试目标追溯；测试目标的例子包括如下：验证产品是适合使用的、预防运作中的缺陷发生、验证符合外部标准、供有关产品质量的能见度、短期测试执行的准备时间； 相关人员评审测试目标； 在适当的时候检查并修订测试目标，例如基于年度；l SP 1.2 定义测试政策：测试政策，与企业（质量）政策一致，由利益相关者制定并一致同意。在已定义的测试目标的基础上定义测试政策，典型的工作成果如下： 测试的定义； 调试的定义（故障定位和修复）； 有关测试和测试职业的基本观点、目标，增加了的测试价值； 要实现的质量级别； 测试机构的独立程度； 高级水平测试过程的定义； 测试的主要职责； 组织的方法和测试过程改进目标； 测试政策清楚的把测试从调试中分开； 相关人员评审测试政策； 定义和建立测试政策的所有权； 在适当的时候检查并修订测试政策，例如基于年度。l SP 1.3 分配测试政策到相关人员：测试政策和测试目标被介绍和解释给测试组内组外的相关人员。典型工作成果如下： 部署计划； 演示测试政策； 分配机制的例子包括如下：记录在手册里（质量体系）、在项目或者部门会议上演示、贴海报、成为部门介绍程序的一部分、能在网站的显著位置访问到。 SG2 建立测试策略一个组织范围或者产品范围的测试策略被建立和部署；识别和定义测试级别被执行。l SP 2.1 执行一个通用的产品风险评估；一个通用的风险评估被执行来识别测试的典型临界区域。典型工作成果为通用产品风险清单，每级风险都标有类别和优先级，成果内容如下： 识别并选择那些需要做通用风险评估的人员； 使用相关人员的输入来识别通用产品风险； 记录通用产品风险的背景和潜在的结果； 对各级通用产品风险确定与之关联的相关人员； 使用预定义的参数分析已确定的通用产品风险，例如，可能性和影响； 通过已定义的风险类别，给通用产品风险分类，分组； 区分通用产品风险缓解的优先级； 评审和取得相关人员在一般产品风险的完整性，类别和优先级一致同意； 适当的修订通用产品的风险请注意，定义在“测试计划”过程域（SP1.1 定义产品风险类别和参数）的产品风险类别和参数，在这个特定的实践里被最大限度的重用。在（子）实践中执行通用产品风险评估的更多信息请参考过程域“测试计划”中SG1 “执行产品风险评估”；l SP 2.2 定义测试策略；该测试策略定义每个测试级别并确定各个级别的目标，职责，主要任务和进入/退出标准。典型的工作成果为测试策略文档，内容如下： 学习测试政策和目标； 必要时提供澄清测试政策和目标的反馈； 定义测试策略并能清晰的链接到已定义的政策和目标； 部分测试策略的实例如下：正在开发产品的一般风险；总的测试模型（V模型，增加的生命周期）作为减少风险的一个途径；测试类别（如，单元测试，集成测试，系统测试和验收测试）；各个测试类别的目标，职责和只要任务，例如单元测试（验证单元设计中制定的当前类别代码覆盖率是否被实现）、集成测试（验证全局设计中指定的一起单元操作、验证接口说明书中指定的接口操作）、系统测试（验证需求说明书中指定的系统操作、要达到当前类别的系统需求覆盖率）、验收测试（验证该系统满足验收标准、验证系统是否是适合使用、当前类别的用户需求覆盖率是否被实现）； 被用在每个测试级别的测试用例设计技术； 在每个测试级别实现的测试种类； 每个测试类别的进入/退出标准； 必须遵守的标准； 级别独立性； 执行测试的环境； 每个测试级别的自动化方法； 回归测试方法； 评审测试策略； 定义和建立测试策略的所有权； 在适当的时候重访并修订测试策略，例如基于年度。请注意，测试策略将作为项目中测试执行的起点。而且，每个项目可以调整其整体战略以满足它的需要。不需要遵守的应当明确记录在测试计划。l SP 2.3 分发测试策略到相关人员；测试策略被介绍到测试内外的相关人员，并与之讨论。典型工作成果是部署计划和演示测试策略。分配机制的例子包括如下： 记录在手册里或者质量体系中 在项目或者部门会议上演示 张贴海报 成为部门介绍程序的一部分 能在网站的显著位置访问到 SG3 建立测试性能指标建立和部署面向目标的测试过程性能指标。l SP 3.1 定义测试性能指标；测试性能指标定义在测试政策和目标基础上，包括数据收集，存储和分析的过程。典型的工作成果为测试性能指标、数据收集，存储，分析和报告程序，其内容如下： 学习测试政策和目标,如测试过程改进的目标，必要时提供澄清测试政策和目标的反馈； 定义测试性能指标并能链接到已定义的政策和目标；测试性能指标的例子如下：测试成本 测试所需的时间 缺陷的数量 缺陷检测率 测试成熟度； 评审性能指标； 定义和建立测试性能指标的所有权； 指定如何获得和储存性能指标； 指定如何分析和报告性能指标。l SP 3.2 部署测试性能指标；部署测试性能指标，提供测量结果，这些结果都可对应到已确定的测试性能指标。典型的工作成果为测试性能指标数据、测试性能指标的报告，其内容如下： 获取指定的性能指标数据； 分析和解释性能指标； 管理和存储性能指标数据和分析结果； 定期报告性能指标给相关人员； 辅助相关人员理解结果；协助理解结果的实例包括：与相关人员讨论结果、提供相关的信息，背景和解释等。4.1.2 PA2.2 测试