下载文档原格式
软件过程改进模型的设计与实现软件开发过程中，质量始终是关键问题。
软件工程的发展经历了不断的实践和总结，逐渐形成了一整套软件开发过程模型。
然而，作为开发软件的团队却常常面临着软件质量问题，如过程不规范、项目管理混乱、频繁抽样测试等问题。
而软件过程改进模型正是为了解决这些问题而产生的。
一、软件过程改进模型的概念软件过程改进模型是一系列帮助软件企业实现高效、规范、纪律化开发所需过程和方案的理论体系，用于对现有软件开发过程进行量化和分析，帮助企业掌握和改进自己的软件开发过程。
软件开发团队通过实施软件过程改进模型，能够实现提高产品质量、减少开发成本、缩短开发周期、提高用户满意度等目标。
软件过程改进模型的设计和实现，需要建立在软件企业的实际情况之上。
软件过程改进模型不是简单的复制某个成功的过程模型，更不是一时半刻就能完成的事情。
它需要考虑到企业的发展阶段、开发团队的文化背景，以及制定适合企业实际情况的软件开发过程和规范标准。
二、软件过程改进模型的实施步骤1.确定改进目标企业实施软件过程改进模型的首要任务就是确立改进的目标。
具体而言，企业应该围绕着产品质量、开发效率、组织管理等方面来确定改进目标，明确需要改进的问题点和阶段目标。
2.识别当前软件过程水平只有对软件开发过程中的每个环节进行细致的分析，才能找出潜在的问题和风险。
因此，企业需要对自己的软件开发过程进行全面、深入的分析，包括流程、导航、协作等方面。
有了深入的诊断分析，企业可以对现有模式中的弱点和不足进行针对性的改进。
3.选择适合自己的改进模型企业对自己的现状进行了全面的分析之后，需要选择一种适合自己发展的软件过程改进模型。
在选择过程中，需要综合考虑团队规模、开发阶段、业务目标等因素，并根据企业实际情况进行微调和融合。
4.部署和实施改进模型如果企业选择的改进模型能够针对实际问题进行有效、可行的改进，那么就需要进入部署和实施阶段。
在实施过程中，需要注意过程控制、风险管理、需求跟踪等方面的技术难点。
软件测试模型及其改进方向探讨随着信息技术的快速发展和应用的普及，软件已经成为现代信息产业的核心。
因为软件的复杂性、不确定性、变动性和不可复制性等困难，软件测试一直是软件工程中最具挑战性的部分之一。
在这样的背景下，各种软件测试模型应运而生。
本文将探讨常见的软件测试模型及其改进方向。
一、软件测试模型介绍1. 瀑布模型瀑布模型是最早期的软件生命周期模型之一，也是最常用的测试模型之一。
它是一个线性的模型，包括需求分析、设计、编码、测试和维护阶段，每个阶段都有自己的输出和输入，阶段之间是顺序紧密耦合的。
2. 增量模型增量模型是一个渐进式的模型，它强调在软件生命周期的早期和长期的测试和集成测试之间进行软件部分测试和集成测试。
这个模型使生命周期能够分为多个阶段，每一阶段可以演示完整的软件系。
3. V模型V模型通常用于整个软件生命周期，强调开发和测试是相互依赖的。
它强调在不同阶段间有相应的测试活动，每个阶段的测试活动使用跟踪矩阵进行记录，该技术可以对测试活动和需求文档和产品文档之间的要求进行追踪。
4. 敏捷模型敏捷模型是当今最流行的软件测试模型之一，它强调需求在生命周期中的动态性、第一次尝试和积极性的响应，这个模型允许提供实时反馈和交流，便于在开发期间进行测试。
二、软件测试模型的改进方向1. 瀑布模型在瀑布模型中，每个阶段之间是完全线性的，限制了生命周期的交互性和灵活性。
因此，软件团队可以采用敏捷方法，以便在更早的阶段接受有意义的反馈，并在更快的速度下加入更多的需求变更和改进。
2. 增量模型虽然增量模型在测试和集成测试之间进行了软件的部分测试和集成测试，但它缺乏足够的重视和积极性来处理测试数据和测试用例的质量控制。
因此，团队可以通过更加关注数据和质量控制来改进这个模型。
3. V模型V模型强调了测试和开发的相互依赖性，但它忽略了测试人员在需求和设计阶段所起的重要作用。
因此，技术人员可以采取适当的步骤来改进该模型，包括改进对测试团队和测试资源的意识，及将测试人员纳入需求，设计，代码和测试文档的编写过程中。
软件开发过程质量评价模型一、软件开发过程概述软件开发过程是将用户需求转化为软件产品的过程，它涉及到需求分析、设计、编码、测试、部署和维护等多个阶段。
这个过程不仅需要技术能力，还需要良好的管理策略和质量保证措施。
软件开发过程的质量评价模型是评估软件开发过程中各个环节质量的一种工具，它可以帮助开发团队识别问题、优化流程和提高产品质量。
1.1 软件开发过程的核心阶段软件开发过程的核心阶段主要包括以下几个方面：- 需求分析：这是软件开发的起点，开发团队需要与用户沟通，明确用户需求，并将其转化为软件需求规格说明书。
- 设计阶段：在这个阶段，开发团队根据需求规格说明书设计软件的架构和详细设计，包括软件的模块划分、接口设计等。
- 编码阶段：开发人员根据设计文档进行编码，实现软件的功能。
- 测试阶段：测试团队对软件进行测试，包括单元测试、集成测试、系统测试和验收测试等，以确保软件质量。
- 部署阶段：软件经过测试后，部署到生产环境中供用户使用。
- 维护阶段：软件部署后，需要进行持续的维护和升级，以适应用户需求的变化和技术的发展。
1.2 软件开发过程的质量评价指标软件开发过程的质量评价指标是衡量软件开发质量的一系列标准，包括但不限于：- 需求满足度：软件是否满足了用户的需求和期望。
- 设计合理性：软件的设计是否合理，是否易于扩展和维护。
- 代码质量：代码是否规范、清晰、易于理解。
- 测试覆盖率：测试是否全面，是否覆盖了所有重要的功能和场景。
- 缺陷密度：软件中缺陷的数量与软件规模的比例。
- 用户满意度：用户对软件的使用体验和反馈。
二、软件开发过程质量评价模型的构建软件开发过程质量评价模型的构建是一个系统工程，需要综合考虑软件开发的各个阶段和质量评价指标。
2.1 质量评价模型的构成要素质量评价模型的构成要素主要包括以下几个方面：- 过程模型：选择适合项目特点的软件开发过程模型，如瀑布模型、迭代模型、敏捷模型等。
- 质量标准：定义软件开发过程中各个阶段的质量标准和评价指标。
第2章软件测试过程模型及标准第一节回顾1.软件过程模型：软件开发全部过程、活动和任务的结构框架也称软件开发模型或软件生存周期模型2.典型的软件过程模型：瀑布模型，演化模型，增量模型，原型模型，螺旋模型，喷泉模型，基于构件的开发模型，形式方法模型3.瀑布模型（包含计算机系统工程）（如图所示）将软件放在计算机系统工程中，考察软件在计算机系统扮演什么角色，软件做什么，区分哪些事情由硬件完成，哪些事情软件完成，哪些事情由人完成。
4.瀑布模型（不包含计算机系统工程）（如图所示）第二节软件测试过程模型1.模型：描述软件测试全部过程、活动和任务的结构框架2.典型的软件测试模型：2.1V模型2.2W模型2.3H模型2.4TMap模型第三节V模型1.V模型描述软件开发各阶段与软件测试类别的关系2.V模型的左分支展示了软件开发的活动（和传统瀑布模型的开发步骤相一致），右分支展示了软件测试的类别特点：3.可根据V模型确定各软件测试阶段的测试要求4.可针对开发活动的不同特点为不同的测试类别设计不同的测试用例5.体现测试人员参与开发的全过程6.V模型（含计算机系统工程）（如图所示）7.V模型（不含计算机系统工程）（如图所示）8.V模型右侧的测试级别随软件开发程度的加深而对应不同级别的测试阶段a)单元测试：主要针对详细设计和编码的测试b)集成测试：主要针对概要设计的测试c)系统测试：主要针对软件系统或计算机系统的测试d)验收测试：主要由用户进行的测试缺点：V模型把测试过程作为在需求定义、需求分析、系统概要设计、系统详细设计及编码之后的一个阶段。
容易使人理解为测试是软件开发的最后阶段，测试主要针对程序进行，而需求定义、需求分析、系统概要设计、详细设计阶段隐藏的问题一直到后期的系统测试和验收测试才被发现。
第四节W模型1.V模型中增加各开发阶段应同步进行的验证和确认活动，演化成W模型2.W模型由两个V组成，一个V代表开发过程，另一个V代表测试过程优点：3.体现了尽早地、不断地进行软件测试4.体现了测试对象不仅是程序代码，还包括需求分析、设计等阶段的工作产品，测试与开发同步进行。
软件过程改进相关模型研究软件过程模型是指在软件开发过程中所采用的一套标准化的方法论，目的是减少开发过程中的风险，同时提高软件质量和开发效率。
软件过程改进模型则是通过对软件开发过程中的各个环节进行改进，不断优化软件开发过程，以提高软件质量和成本效益。
本文将就软件过程改进相关模型的研究进行探讨。
一、软件过程改进模型概述软件过程改进模型目的是通过在软件开发过程中定义一套标准的软件开发过程规范，以保证开发的软件质量。
其核心任务是在软件开发过程中持续地对开发流程进行改进，迭代式地完善软件的开发流程，提升软件开发的效率和质量。
二、软件过程改进模型的类型1. 能力成熟度模型（CMM）。
CMM 是软件工程领域的一种成熟度模型，被广泛应用于软件过程改进和评估。
CMM 强调了软件开发过程的标准化和管理，具有很强的实践性和可操作性。
2. 能力成熟度模型集成（CMMI）。
CMMI 是 CMM 的改进和升级版，提供了一种集成的成熟度模型，包括了系统工程、软件工程和硬件工程。
CMMI 通过评估模型来评估组织的软件过程能力，对于组织实现过程改进和过程管理具有很大的帮助。
3. SPICE 模型（软件过程改进和能力测量）。
SPICE 是一种软件过程改进和能力测量模型，它是从 ISO/IEC 15504 标准评估模型中发展而来的。
SPICE 主要用于软件组织的过程评估和改进，可用于 ISO9001 认证。
三、软件过程改进模型的优点1. 具有较高的可操作性。
软件过程改进模型通常具有一定的可操作性，可以对软件开发过程中的各种流程进行规范化管理，提高软件开发的效率。
2. 改善软件开发的质量和效率。
通过对软件开发过程中的各个环节进行标准化管理和评估，可以不断改善软件开发的质量和效率。
3. 有利于软件开发成本控制。
通过改进软件开发过程，减少软件缺陷和重复的工作，可以降低软件开发的成本。
四、软件过程改进模型的局限性1. 需要大量资源投入。
软件过程改进模型的实施需要投入大量的人力、物力和财力，对于小规模软件组织或开发人员较少的团队来说，难以承受。
软件测试中的模型和理论分析在软件开发中，测试是一个至关重要的环节，它能够帮助开发人员发现和修复软件中的缺陷和错误，确保软件的质量和可靠性。
为了有效地进行软件测试，测试人员通常会使用不同的模型和理论来指导和支持测试过程。
本文将对软件测试中常用的模型和理论进行分析和讨论。
一、瀑布模型瀑布模型是软件开发中最早提出的一种常用模型，它将软件开发过程划分为不同的阶段，如需求分析、设计、编码、测试和维护。
在瀑布模型中，测试通常在开发完成后进行，以验证软件是否符合设计规范和用户需求。
这种模型适用于需求较为明确、稳定的项目，但缺点是测试阶段较晚，容易导致发现问题的时间延迟。
二、迭代模型迭代模型是一种较为灵活的软件开发模型，它将软件开发过程划分为多个迭代周期，每个周期包括需求分析、设计、编码和测试等阶段。
与瀑布模型不同的是，迭代模型在每个迭代周期中都会进行测试，并且可以根据测试结果进行反馈和调整。
这种模型适用于需求不稳定、变化频繁的项目，能够及时发现和解决问题。
三、V模型V模型是一种基于瀑布模型的测试模型，它将软件开发过程和测试过程进行了对应。
在V模型中，测试与开发是并行进行的，测试人员可以在每个开发阶段中进行相应的测试活动。
V模型强调了测试与开发的密切关联，能够提前发现和修复问题。
然而，V模型在应对需求变更和交付时间紧迫的项目时可能不够灵活。
四、敏捷测试敏捷测试是一种基于敏捷开发方法的测试方法论，它注重快速、反馈和迭代。
敏捷测试强调测试人员与开发人员之间的密切合作和沟通，测试活动贯穿整个开发过程。
敏捷测试适用于需求频繁变更和交付迅速的项目，能够及时发现问题并进行调整和修复。
除了以上提到的模型，软件测试还涉及到一些重要的理论和技术，如黑盒测试和白盒测试。
黑盒测试是一种测试方法，它根据软件的输入和输出来判断和评估软件的功能和性能。
而白盒测试则是一种测试方法，它通过对软件的内部结构和代码进行分析和测试来评估软件的逻辑和正确性。
软件过程改进模型（如CMMI）的应用与效果评价软件过程改进模型是一种用于评估和改进软件开发过程的方法。
其中最为著名的就是CMMI（Capability Maturity Model Integration）模型。
CMMI模型是一种成熟度模型，它能够帮助企业评估自己的软件开发过程，确定改进方向，并提供一个评估标准，以便与其他企业进行比较。
CMMI模型包括五个成熟度级别，从初始级别到优化级别。
每个级别都有一组特定的目标和实践，以帮助企业达到该级别的要求。
CMMI模型还包括一组通用实践，这些实践适用于所有级别。
CMMI模型的应用可以帮助企业实现以下目标：1. 提高软件开发过程的效率和质量。
2. 减少软件开发过程中的错误和重复工作。
3. 提高软件开发团队的合作和沟通能力。
4. 提高客户满意度，增加市场竞争力。
5. 降低软件开发成本和风险。
CMMI模型的应用需要企业进行以下步骤：1. 评估现有软件开发过程的成熟度级别。
2. 确定改进方向和目标。
3. 制定改进计划和实施方案。
4. 实施改进计划，并监控和评估效果。
CMMI模型的应用需要企业付出一定的努力和成本，但是它能够带来显著的效果。
以下是一些实施CMMI模型后的效果评价：1. 提高软件开发过程的效率和质量。
通过实施CMMI模型中的最佳实践，企业能够减少错误和重复工作，提高代码质量和可维护性，从而提高软件开发过程的效率和质量。
2. 提高客户满意度。
通过提高软件开发过程的质量和可靠性，企业能够提高客户满意度，增加市场竞争力。
3. 减少软件开发成本和风险。
通过减少错误和重复工作，企业能够降低软件开发成本和风险。
4. 提高软件开发团队的合作和沟通能力。
通过实施CMMI模型中的团队合作和沟通实践，企业能够提高团队合作和沟通能力，从而提高软件开发团队的效率和质量。
5. 促进企业文化变革。
通过实施CMMI模型中的最佳实践，企业能够促进企业文化变革，从而逐步形成一种以质量为导向、以客户为中心、以持续改进为目标的企业文化。
软件测试过程改进模型入门介绍转自51testing摘要：测试常被看作是一个昂贵且不可控的过程。
测试花费太多的时间，耗费的比计划投入的多，无法提供充分的关于测试过程本身的质量情况。
因此，信息系统的质量和商务风险难以判断。
很多组织意识到改进测试过程可以解决这些问题。
但是，实际上为了改进和控制测试过程到底应该采取什么步骤以及什么次序是困难的。
基于实践知识和测试过程开发经验，测试过程改进模型（以下简称TPI）被开发出来。
TPI提出了一个组织内测试过程成熟度的观点。
在这份文件里将介绍TPI的内容和结构。
同时，测试过程改进的一些方面及面临的挑战也将做些讨论。
1、概述测试常被看作是一个昂贵且不可控的过程。
测试花费太多的时间，耗费的比计划投入的多，无法提供充分的关于测试过程本身的质量情况。
因此，信息系统的质量和商务风险难以判断。
很多组织意识到改进测试过程可以解决这些问题。
但是，实际上为了改进和控制测试过程到底应该采取什么步骤以及什么次序是困难的。
基于实践知识和测试过程开发经验，测试过程改进模型（以下简称TPI）被开发出来。
TPI提出了一个组织内测试过程成熟度的观点。
在这份文件里将介绍TPI的内容和结构。
同时，测试过程改进的一些方面及面临的挑战也将做些讨论。
2、软件测试的目的一个信息系统开发阶段的测试活动可以这样来加以说明：测试活动是从测试计划、测试准备到测试执行、测试分析这样一个过程，测试的目标是对信息系统（泛指软件）的特性进行确认，以发现该系统应有状态与实际状态的差异。
测试计划和测试准备活动用以定义测试过程何时开始。
在任何测试方法应用前（即测试执行阶段前），测试过程要求有明确的计划和准备阶段。
测试可以降低系统质量的不确定度级别，但是测试效果的好坏依赖于系统发布所带来的风险，还有我们愿意花费在降低不确定度等级上的时间和资金。
3、测试等级为了有效地组织测试，不同的测试等级需要加以应用。
每一个测试等级对应某一组需求、功能或者技术说明。
软件测试过程改进模型入门介绍转自51testing摘要：测试常被看作是一个昂贵且不可控的过程。
测试花费太多的时间，耗费的比计划投入的多，无法提供充分的关于测试过程本身的质量情况。
因此，信息系统的质量和商务风险难以判断。
很多组织意识到改进测试过程可以解决这些问题。
但是，实际上为了改进和控制测试过程到底应该采取什么步骤以及什么次序是困难的。
基于实践知识和测试过程开发经验，测试过程改进模型（以下简称TPI）被开发出来。
TPI提出了一个组织内测试过程成熟度的观点。
在这份文件里将介绍TPI的内容和结构。
同时，测试过程改进的一些方面及面临的挑战也将做些讨论。
1、概述测试常被看作是一个昂贵且不可控的过程。
测试花费太多的时间，耗费的比计划投入的多，无法提供充分的关于测试过程本身的质量情况。
因此，信息系统的质量和商务风险难以判断。
很多组织意识到改进测试过程可以解决这些问题。
但是，实际上为了改进和控制测试过程到底应该采取什么步骤以及什么次序是困难的。
基于实践知识和测试过程开发经验，测试过程改进模型（以下简称TPI）被开发出来。
TPI提出了一个组织内测试过程成熟度的观点。
在这份文件里将介绍TPI的内容和结构。
同时，测试过程改进的一些方面及面临的挑战也将做些讨论。
2、软件测试的目的一个信息系统开发阶段的测试活动可以这样来加以说明：测试活动是从测试计划、测试准备到测试执行、测试分析这样一个过程，测试的目标是对信息系统（泛指软件）的特性进行确认，以发现该系统应有状态与实际状态的差异。
测试计划和测试准备活动用以定义测试过程何时开始。
在任何测试方法应用前（即测试执行阶段前），测试过程要求有明确的计划和准备阶段。
测试可以降低系统质量的不确定度级别，但是测试效果的好坏依赖于系统发布所带来的风险，还有我们愿意花费在降低不确定度等级上的时间和资金。
3、测试等级为了有效地组织测试，不同的测试等级需要加以应用。
每一个测试等级对应某一组需求、功能或者技术说明。
本章内容主要基于[KoP99]和[ISEO4]。
3.1 低级测试低级测试陷于系统的各个组成部分的测试中，例如程序单元，单独的或者关联的。
从系统开发开始，即开始单元，程序和模块的测试。
如上面所述这种分离性依赖于程序下部结构和所使用的编程语言。
这类测试的执行者多数时候是开发人员。
当众多的系统基本单元确认已经符合他们的技术规格时，作为系统构成的稍大些的模块在集成测试中进行测试。
集成测试主要关注与数据流和程序间的接口部分。
3.2 高级测试高级测试全面、彻底的测试产品。
在低级测试已经完成并且缺陷已得到纠正后，要进行系统测试以检验系统是否满足了功能和技术规格说明书中定义的要求。
系统测试完成后，向客户提交产品进行验收。
验收测试需要模拟搭建一个产品环境。
高级测试尤其应该被作为一个单独的过程来执行。
过去的经验显示高级测试过程的设计远比低级测试过程的设计更重要。
4、关于测试的几个问题本章指出测试中的一些常见问题以及测试过程改进的一些必要方面，本章内容基于[KoP99]。
4.1 测试的原始形式在系统进入产品阶段即将被发布前，测试工作短暂的开展一段时间，并且执行测试工作的人员是非专业的，而是随机的，谁有空闲谁来做。
这就是测试的最初形式和状态。
这类测试往往在系统进入产品发布阶段后或者近期没有发现新的缺陷即宣告终止，结果就是系统带着一些隐含的缺陷即被发布，导致在后续的因为这些缺陷而引发的软件重做、重测上付出高昂的代价。
4.2 当前情势现在，在很多单位或者组织中间对于一个可管理的测试过程的重要性已经有了越来越多的共识。
测试在执行前应首先进行计划制定和准备工作，计划和准备的内容应该建立于开发文档上。
组织内应该清楚地知道哪些测试过，哪些未被测试过。
但是，不管怎样，测试始终面要面对时间短、人员少、资源短缺以及技术支持度低等现状。
测试处在开发周期的末端，并且往往陷入一个反复开发、反复测试的无休止的死循环中。
即便测试停止之后，对于系统的质量等级依然是一个不确定的答案。
4.3 最新发展要想能够面对当前市场的激烈竞争，组织必须要缩短新产品投向市场的时间。
尽管开发过程正在不断加快，但是在开发过程的任何一环节都有可能引入的错误却没有丝毫迹象显示正在减少。
相关经验的缺乏和不断上升的技术复杂度佐证了上述现象是正常的。
即使现在的测试过程对于当前情势来说看起来是相当令人满意的，但是有一点很明显这不是软件测试的未来模式。
5、改进测试过程5.1 测试过程改进的必要性前一章提及的那些问题的产生原因可以归结于不可控的或者准备不足的测试过程。
消除这些原因就是测试过程改进的原动力。
参考Koomen和Pol关于测试过程改进的论述，TPI可以定义如下：从信息服务整体出发，统筹与优化测试过程的质量、成本和周期的过程。
这里的质量是指测试过程关于被测对象质量方面的度量程度，即测试质量，系统或者程序等具体测试对象的质量不在此范畴。
当然，一个质量上改良的测试过程并不能给被测系统带来更好的质量。
测试本身不会提高系统的质量。
事实上，它能做到的是确认系统已具有的质量特征，并试图通过所提供的这些质量信息驱使组织去改善产品质量。
在整个信息服务来看，测试过程并不是孤立的。
低成本、高效率的追求，不是测试的本质目的，测试应该为信息服务更高的效能（信息服务的整体水平）做出更多贡献。
测试过程改进的一个目标应该是尽可能多地发现缺陷、降低改正成本、更早的报告系统质量情况。
所有的评测标准要谨慎地相互兼容，以此取得一个能够尽可能早的发现更过重要缺陷的总体策略。
测试要朝着更加专业化的方向发展，提高专业测试技能，职能分工细化，如测试管理、测试技术专家、测试工程师。
整个测试过程的进步和质量可以被度量，其度量结果在将来可以作为测试过程改进的输入项加以利用。
5.2 测试过程改进步骤改进测试过程类似于任何其他过程的改进。
测试过程的改进，通常遵循以下步骤：1. 确定目标和需要考虑的域。
要确定测试的质量特性：是使测试速度更快、费用更低还是覆盖率更高？什么样的测试过程最需要改进，改进过程需要持续多长时间，具有什么效果？2. 确定当前的条件。
评估当前情势的优缺点。
3. 确定需要的条件。
基于对当前条件的分析结果和改进目标，确定需要的条件和行动步骤。
4. 实施改革。
根据预先拟制的改进计划，按照建议的改进操作步骤实施改革，同时跟踪改进信息，填写条件检查项，用以验证是否达到了改进目标。
5. 通过一个参照系，使测试过程的优缺点呈现出来。
这个参照系可以是测试方法论或者是一个测试过程改进模型。
依照Koomen和Pol的通用软件过程改进模型（如SPICE和CMM），它为测试过程的逐步改进提供了一个不是很充分的参照体系。
因为是个更高层次的抽象，在这个参照体系中测试过程的改进往往是作为一个步骤来处理。
当然，有些专门针对测试过程改进而设计的模型，如测试能力度量模型，测试改进模型以及测试度量模型等，这些模型都不包含足够的可应用的改进步骤、详细的描述和使用说明。
6、TPI模型6.1 TPI模型综述测试过程改进模型必须从多个视角观测测试过程，例如测试工具的使用，测试技术以及报告。
在TPI 模型中，这些观测点叫作关键域。
每一个关键域可以归类到成熟度中。
对于整个测试过程的效能来说，并不是所有的关键域都是同等的，在不同的关键域和等级之间存在着一些关系。
确认在各个层级上的归类是客观的，在每个层级上设置一个或多个检查点。
一个检查点是一个需求。
如果一个测试过程符合某个层级的所有检查点，那么这个过程就属于这个层级。
除了评估测试过程的当前情势外，关键域和层级同样可以用于定义需要的条件和为达到这些条件而需要实施的中间步骤。
在这个模型中附有改进建议，给出了如何达到某一特定水平的说明和建议。
6.2 TMap模型TMap，组织测试的方法体系以及第5.2章中所提到的模型的其他方面构成TPI模型的基础。
TMap方法体系包括4个环节，这四个环节组成开发周期中所有测试活动的一个生命周期，好的组织体系，正确的测试框架和测试工具以及为执行测试活动可用的技术。
这些环节是通用的，并且在每一个测试过程中必须给予每一个环节一定的关注度。
要有一个和谐的测试过程，则这些环节上的测试开发应该要保持和谐。
6.3 关键域和等级通过查看一个结构化测试过程的每一环节的不同方面，总计20个关键域在TPI模型中得到公认。
通过测试过程中关键域的应用来判断过程的成熟度。
但是无论如何，每一个关键域在使用期间不会是均等的彻底的，因为每个测试过程有它自己的优势和弱势。
为了能够更深入的观察这些关键域的状态，模型给每个关键域设置了一个上升的等级（通常为从A到D）。
一般地说，每个关键域有3至4级。
每个高一点的等级在效率、成本和（或）质量方面要优于它前面的层级。
每个层级由适用于这个关键域的一定的需求组成。
这些一定层级的要求（即检查点）同样包含低层的需求：一个B级的测试过程应该同时完全满足A级和B级的要求。
如果一个B级的测试过程不能够满足A级的要求，那么它应该被视作在低一级的层级上或者是针对那个特别的关键域尚未定义的层级上。
不同层级的关键域的描述详见表1。
表1中关键域的不同级别中都包含里程碑，例如，测试过程每周报一次，周报包含发现的缺陷和花费的小时数的概述。
因为缺陷没有指出优先级，测试进度也未在报告中提及，所以这个过程应在这个关键域中归类为A级。
6.4 检查点我们要使用检查点以确定某一层级的要求。
这些要求以问题的形式加以定义，它们是为了判断是否达到某一层级而必须要严肃回答的。
基于这些检查点，我们能够评估一个测试过程，并为每一个关键域建立正确的所处层级。
每个关键域的下一个层级对应一个改进。
这些检查点也是累积的：为了给等级B归类，测试过程需要同时满足等级B和等级A两个等级的检查点。
例子：测试工具这个关键域的检查点规划和控制工具（等级A）检查点：● 在缺陷管理和至少其他两项规划、控制活动中应用自动化工具（字处理等办公类软件不算）执行和分析工具（等级B）检查点：至少两类自动化工具应用于测试执行阶段，如录制回放工具、测试覆盖率分析工具等。
测试团队借助于这些工具对于测试的费效比有个大概的了解。
测试过程的自动化扩展（等级C）检查点：自动化工具（标准字处理软件除外）应用在测试计划阶段（主要是活动评估、计划编制、进度追踪、配置管理和缺陷管理）、测试准备、方案和执行（总计不少于5种工具得到应用）。
6.5 测试成熟度矩阵在各个关键域的层级确定后，注意力应集中在采取哪一个改进步骤上，因为不是所有的关键域和层级都是同等重要的。
举例来说，一个好的测试策略（测试策略关键域的A级）就比测试技术应用的描述更加重要（方法适用范围关键域的A级）。
除了上述的优先级外，在不同关键域的层级之间也存在着依赖性。
