测试成熟度模型集成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 评估需求被描述成一个单独的文件，你可以在https://www.doczj.com/doc/455983587.html,找到。这些需求是基于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，
由TMMi 基金会编写 测试成熟度模型集成专业人士资格认证测试成熟度模型培训大纲 发布V1.1 版本 编辑: Erik van Veenendaal 版权通告 受限于版权条款的不限制分发 爱尔兰TMMi 基金会版权所有
本TMMi基金会资料按照现有的状况来提供。 TMMi基金会未就任何事项作出任何形式的担保，无论明示的或暗示的，包括但不限于适用性或适销性担保、排他性担保、或使用本资料所获得结果的担保。TMMi基金会未就不存在专利、商标或版权侵权作出任何形式的担保。 本文档中对任何商标的使用，并非有意以任何方式侵犯商标所有人的权利。允许为内部使用而复制本文档及制作本文档的衍生品，但所有复制品及衍生品中需包含版权及“非担保”声明。为外部及商业使用而复制本文档或制作本文档衍生品的，应向TMMi基金会请求允许。 下列注册商标和服务标志在 TMMi 基金会的文档中被用到：CMMI?, TMMi?. CMMI 是由卡内基梅隆大学在美国专利与商标局注册。 TMMi?是 TMMi 基金会的注册商标。 贡献者 Andrew Goslin (UK) Klaus Olsen (Denmark) Meile Posthuma (The Netherlands) Geoff Thompson (UK) Erik van Veenendaal (The Netherlands) Brian Wells (UK)
版本修改 这一节仅供参考
Table of Contents 1 简介 (4) 1.1文档目的 (4) 1.2测试成熟度模型集成专业人士资格认证 (4) 1.3 TMMi 评估师 (4) 1.4 业务价值 (5) 1.5详细程度 (5) 1.6资料来源 (5) 2.学习目标 (6) 2.1学习认知级别 (6) 2.2 学习目标 (7) 2.2.1 测试改进的背景 (7) 2.2.2 TMMi模型概述 (7) 2.2.3 TMMi成熟度级别 (8) 2.2.4 TMMi的结构 (8) 2.2.5 TMMi模型 (8) 2.2.6 TMMi的评估 (9) 2.2.7 TMMi的实施 (9) 3. 认证考试 (11) 3.1 考试结构 (11) 3.2 考题分布 (11) 4. 培训机构 (12)
针对XXXX内存溢出问题 性能测试报告 (仅供内部使用) 拟制:日期： 审核:日期： 审核:日期： 批准:日期：
修订记录
目录 1概述 ........................................................ 错误!未定义书签。2测试目的..................................................... 错误!未定义书签。3测试设计..................................................... 错误!未定义书签。 对象分析.................................................... 错误!未定义书签。 测试策略.................................................... 错误!未定义书签。 测试模型.................................................... 错误!未定义书签。 测试环境描述............................................ 错误!未定义书签。 详细测试方法................................................ 错误!未定义书签。 测试方法综述............................................ 错误!未定义书签。 并发用户计算及启动...................................... 错误!未定义书签。 监视统计数据............................................ 错误!未定义书签。 业务模型................................................ 错误!未定义书签。4测试结果..................................................... 错误!未定义书签。 CPU使用情况................................................. 错误!未定义书签。 内存使用情况................................................ 错误!未定义书签。 页面分解.................................................... 错误!未定义书签。5测试结论..................................................... 错误!未定义书签。
测试综合 性能测试 容量测试建模篇
目录 修订记录 ...................................................................................................................... 错误！未定义书签。目录 (2) 1前言 (3) 1.1目标 (3) 1.2用途 (3) 1.3阅读对象 (3) 1.4内容简介............................................................................................................ 错误！未定义书签。 1.5编制背景 (3) 2术语及定义........................................................................................................... 错误！未定义书签。3容量建模.. (3) 3.1方法简述 (3) 3.2实例展示 (4) 3.3建模优点 (5)
1前言 1.1目标 为了对性能测试中容量建模方法形成统一的标准，使各项目组在性能测试过程中的容量建模环节做到有据可循、有方法做指导。 1.2用途 本文为光大银行质量中心性能测试组在实施性能测试过程中提供容量测试建模方法，并指导各项目组的性能测试工作。 1.3阅读对象 本文的阅读对象是我行测试经理、项目经理、测试人员及其他关注性能测试的技术及管理人员。 1.4编制背景 目前，质量中心性能测试项目组在容量测试建模过程中，各项目组虽然使用相同的方法，但需要经过很多次繁琐的调整，才能满足预期的测试模型，且调试的过程中存在差异性，没有统一的标准；通过现有的建模方法运行的测试结果得出的交易配比与预期的比存在差距。所以在此背景下，经过项目组的讨论决定，提供给大家一个统一的容量测试建模方法。 2容量建模 2.1方法简述 在容量测试执行之前，我们需要为每一个测试场景建模。建模是根据业务模型（即各交易间的交易量配比关系）来构建，因此业务模型的确立很重要。业务模型的确立主要来源于
测试成熟度模型集成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)
容器安全成熟度模型 虽然越来越多的企业开始采用容器化的云原生应用，但传统的安全措施却无力应对新技术发展带来的挑战。当下云原生虽说异常火热，却没有一个清晰的路线图，能够指明在容器化过程中，各个阶段该如何做好安全。由于容器化的每个阶段都会带来新的安全挑战，企业必须在做好基础架构的同时，确保每个阶段的安全。可以预见，从第一个容器化应用开发到管理数千个容器过程中，安全需求也在不断变化。 容器安全成熟度模型，旨在帮助企业在采用容器和容器扩容过程中能够更好理解并成功应对所产生的各类安全挑战。 01 一、引言
无论应用是在容器中运行，还是在虚拟机、主机上运行，发生安全事件的后果都是相同的。此外，在安全事件发生后，无论打多少补丁，也无法挽回已泄露的敏感数据。据调查报告《2020年容器与Kubernetes安全状况》显示，94％的受访者表示，在过去12个月中发生了容器安全事件。 在过去12个月中遭遇过容器安全问题类型和比例 在很多情况下，企业并不完全了解容器化架构所面临的安全挑战，更不用说如何主动应对这些挑战。这时，常见的做法就是将之前的安全策略应用到容器中来，但这并不一定适合新的应用体系架构和开发工作流程。总得来说，就是容器使用率不断提高，但安全总是落后一步。 下文将针对容器安全成熟度模型进行详细解释，旨在帮助企业更好了解需要部署哪些重要工具，采取哪些措施，来满足当前和未来容器安全需求。 二、容器安全成熟度模型
第1阶段：实验学习 在这个阶段，主要是开发人员自己学习如何在机器上使用容器。例如，通过一些不进入生产系统的项目做练习。在这一阶段，所涉及的应用大多是一些基本应用。 这阶段可能持续数月之久。由于只有个别开发人员在学习和测试容器，因此只要项目不是用于生产，就不需要专用的安全工具，也不需要改变以往安全策略。与往常一样，开发人员只需确保安全编码。但是，这个阶段安全也是声明式的和自动化的，是开发工作流程的一部分，而不是在完成应用构建后才解决安全问题。 虽说，在该阶段安全并不太重要，也不会犯什么错误。但是，如果组织机构打算扩展容器化项目，则需要确保让每个人都了解，安全风险和复杂性会在扩展后迅速增加。在第1阶段和第2阶段之间的安全挑战存在巨大差异的，这会让许多组织机构措手不及。 第2阶段：正式启动 在这个阶段，容器化已不再是个别开发人员的业余项目，而是由团队或业务部门开展一部分正式项目。这时，开发团队会用容器创建一个用于生产的新应用或将现有应用容器化。 大多数组织机构在开发其第一个容器化应用时，可能会使用下列其中一种方法： ?将现有应用容器化 ?将现有应用的一部分内容容器化 ?从头开始在容器中开发新应用
性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数据量测试，网络性能测试，服务器性能测试五大部分，具体编写测试用例时要根据实际情况进行裁减，在项目应用中遵守低成本，策略为中心，裁减，完善模型，具体化等原则；一、WEB 全面性能测试模型 Web 性能测试模型提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，这些类型的性能测试的实施是有着相似之处的； 1. 预期指标的性能测试 系统在需求分析和设计阶段都会提出一些性能指标，完成这些指标的相关的测试是性能测试的首要工作之一，这些指标主要诸于“系统可以支持并发用户200个；”系统响应时间不得超过20秒等，对这种预先承诺的性能要求，需要首先进行测试验证； 2. 独立业务性能测试 独立业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。 用户并发测试是核心业务模块的重点测试内容，并发的主要内容是指模拟一定数量的用户同时使用某一核心的相同或者不同的功能，并且持续一段时间。对相同的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作。另外一类是在同一时刻使用完全一样的功能。 3. 组合业务性能测试 通常不会所有的用户只使用一个或者几个核心业务模块，一个应用系统的每个功能模块都可能被使用到；所以WEB性能测试既要模拟多用户的相同操作，又要模拟多用户的不同操作；组合业务性能测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模版的组合并发情况；组合性能测试是最能反映用户使用情况的测试往往和服务器性能测试结合起来，在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息进而全面分析系统瓶颈。 用户并发测试是组合业务性能测试的核心内容。组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来匹配； 4. 疲劳强度性能测试 疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试，其主要目的是确定系统长时间处理较大业务量时的性能，通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定； 5. 大数据量性能测试 一种是针对某些系统存储，传输，统计查询等业务进行大数据量时的性能测试，主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试； 第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者常用的组合业务。 第三种大数据量测试结合了前面两种的测试，两种测试同时运行产生较大数据量的系统性能测试；大数据量测试通常在投产环境下进行，并独立出来和疲劳强度测试放在一起，在整个性能测试的后期进行；大数据量的测试可以理解为特定条件下的核心业务或者组合业务测试； 6. 网络性能测试 主要是为了准确展示带宽，延迟，负载和端口的变化是如何影响用户的响应时间的，在实际的软件项目中 主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成； 7. 服务器（操作系统，WEB服务器，数据库服务器）性能测试 初级服务器性能测试主要是指在业务系统工作或者进行前面其他种类性能测试的时候，监控服务器的一些计数器信息，通过这些计数器对服务器进行综合性能分析，为调优或提高系
1.术语解释 (1)过程域 过程域是一个业务域中一束相关的实践，当它们一起得以实现时，就满足被认为对 该过程域的改善具有重要作用的一组条件。 (2)过程改善 是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这 一程序的结果 (3)专用目标 每一个过程域中都有一个或多个“专用目标”，用于描述满足该过程域必须呈现的 一些独有特征 (4)共用目标 每一个过程域中都有一个或多个“共用目标”，用于描述实现制度化的该过程必须 呈现的特征 (5)专用实践 每一个过程域中都有一个或多个“专用实践”，这些专用实践被被认为对于达到该 过程域的专用目标是重要的活动，即期望以专用实践所描述的活动，会导致达到一 个过程域的专用目标。 (6)共用实践 每一个过程域中都有一个或多个“共用实践”，被认为对于要达到该过程域相关的 共用目标的重要的活动。 (7)能力等级 是指遵循一个过程可达到的预期结果的程度。所谓能力等级，是指在单一过程域中 已达到的过程改善。换句话说，能力等级是为了管理，对过程改善程度所设定的几 个“台阶”。 (8)成熟度模型：是指达到预先定义的一组过程域所有目标的一种过程改善等级 2.简答题 (1)CMMI提出所基于的基本思想 CMMI提出所基于的基本思想是过程路径思想，通过过程把软件质量的3个支撑点 ---受训的人员、规程和方法、工具和设计进行集成，以开发所期望的系统\产品。 为此，CMMI紧紧围绕开发、维护和运行，把经过证明的“最佳实践”放在一个结 构中。该结构有乃至于指导组织确定其过程的发送优先次序；有乃至于指导这些改 善的实施，以提高其过程能力和成熟度，并且还支持其他领域（如获取和服务）能 力成熟度模型开发。 (2)什么是过程制度化？在CMMI中把过程制度化分为几个等级？简要回答每一个等 级的主要特征。 所谓的过程制度化，是指过程被渗透在执行工作的方式中，执行的工作有一定的承 诺，并且在组织范围内是一致的。 已执行过程、已管理过程、已定义过程、已定量管理过程、持续优化过程 (3)简述CMMI模型的模型部件及部件间的关系 过程域、专用目标、专用实践、共用目标、共用实践、典型工作产品、子实践、共 用实践的精华、意图陈述、简介性注释、相关过程域 CMMI是有一些过程域组成；过程域有自己的确定专用目标和共用目标。过程域及
5.1.2性能测试需求提取 复习了一些常见的理论概念后，我们开始性能测试需求的提取。这个过程是非常重要的，往往测试失败，就是因为在这个过程中不知道如何得到确切的性能指标，而导致测试无法正常开展。性能测试需求提取一般的流程如图5- 1所示。 图5- 1性能测试需求提取流程 分析提取指标 在用户需求规格说明书中，会给出系统的功能、界面与性能的要求。规范的需求规格说明书都会给出明确的性能指标，比如单位时间内访问量要达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，这些指标都会以可量化的数据进行说明。如果，实际项目并没有这些正规的文档时，项目经理部署测试任务给测试组长时，一般就会说明是否要对项目的哪些业务模块进行性能测试，以及测试的要求是什么的。最麻烦的就是项目经理或者客户要求给出一个测试部门认为可以的数据，这样非常难做的。可是“甲方”往往都是提要求的，“乙方”只能“无条件”接受！ 表5- 1需求规格说明书中的性能要求 表5- 1给出的指标非常明确，在测试过程中，我们只需收集用户登录模块的响应时间、登录成功率、并发数、CPU使用率、内存使用率的数据，然后与表5- 1的指标进行比较即可，通过的，就认为达到了客户要求的性能，未达到就分析原因，并给出测试报告及解决建议。 大多数是没有明确的需求，需要我们自己根据各种资料、使用各种方法去采集测试指标。以OA系统为例，假设《OA系统需求规格说明书》中并未指明系统的性能测试要求，需要测试工程师自己分析被测系统及采集性能衡量指标。 分析OA系统的结构，所有功能中仅有考勤模块可能是被测系统最终用户经常使用的业务点，那么我们的重点应该在放在该模块上。一般我们可以从下面三个方面来确定性能测试点： 第一、用户常用的功能。常用的功能一旦性能无法满足，比如登录功能，从输入用户名与密码点击登录按钮到显示成功登录信息，花了5分钟，这样的速度是 人无法忍受的。而对于用户不常用的，比如年度报表汇总功能，三个季度甚 至是一年才使用，等个10分钟也是正常的，这些是跟用户的主观感受相关 的，得根据实际情况区分。
PCMM（人员能力成熟度模型）介绍 PCMM（People Capability Maturity Model，人员能力成熟度模型）是美国宾州大学SEI（软件工程学院）沿用CMM（Capability Maturity Model，软件开发能力成熟度模型）的框架所开发出的一套指导企业持续提升人力资源管理能力的方法论和知识体系。 一、5个成熟度层级 PCMM将企业的人力资源管理能力分为5个层级。 1）初始级 在初始级，组织人力资源管理工作仅仅是事务性的，诸如基本的人事管理和工资奖金发放等。人力资源管理部门可能象征性地提供了一些表格，如绩效评估或职位描述，却没有为这些文件的合理使用提供指导或培训。 各级管理者缺乏基本的人力资源管理培训，在管理下属的能力是建立在以往的经验及其个人的“管人技巧”上。甚至一些管理者们并不接受开发组织人力资源是他们个人的主要职责。他们从事人员管理活动，比如，面试应征者，在没有准备的情况下作绩效评估，其结果是使应征者败兴而归或不合理的人事决策。 在初始级，组织的员工能力是未知的，因为组织没有为测试或提高这些能力作任何努力。员工们只是积极努力地完成自己的工作任务，因为没有任何激励措施来使他们的动机与组织的业务指标相一致。当员工们觉得其他企业有着更好的工作环境以及更好的职业发展前景时，就会离职，因此组织的员工流动率相当高。由于有经验的员工不断流失，组织始终是一些新手，因此，组织的知识和技术水平并不随时间的推移而提高，因为组织必须为那些有见识的已经离开组织的职员替补新职员。 2）可重复级 主要目标是消除妨碍员工正常工作的主要障碍，为持续改进开发人力资源的
XX系统性能测试方案 (仅供内部使用) 拟制: 日期：yyyy-mm-dd 审核: 日期：yyyy-mm-dd 审核: 日期：yyyy-mm-dd 批准: 日期：yyyy-mm-dd 博为峰教育科技(北京)有限公司 版权所有侵权必究
修订记录
目录 1概述 (6) 1.1被测试系统简介 (6) 1.2性能测试目的 (6) 2性能需求分析 (6) 3系统角色行为分析 (7) 3.1用户行为分析 (7) 3.2运营行为分析 (8) 3.3系统后台行为分析 (8) 4系统结构分析 (8) 4.1系统组成分析 (8) 4.2压力传递分析 (8) 4.3潜在瓶颈分析 (9) 4.4系统资源分析 (9) 4.5系统监测及其评价标准分析 (9) 5性能测试方案的确定 (10) 5.1基本流程的确定 (10) 5.2异常流程分析 (10) 5.3混合流程分析 (10) 5.4测试项的确定 (11) 5.5数据模型分析及数据规划 (11) 5.6妨碍性能测试持续开展的问题及其解决办法 (11) 5.7测试接口分析 (11) 5.8被测系统配置及其组网图 (11) 5.9测试工具的选定 (12) 5.10测试数据的准备 (12) 5.11测试用例设计建议 (12) 6附录 (12)
表目录List of Tables 表1 需求跟踪矩阵表........................................................................................ 错误！未定义书签。
图目录List of Figures 错误！未找到目录项。
总第255期2011年第1期 计算机与数字工程 Computer&D ig ital Eng ineer ing V o l.39No.1 71软件审查能力成熟度模型* 曹悦1)张靖2) (华中科技大学电子与信息工程系1)武汉430074)(海军工程大学计算机系2)武汉430033) 摘要软件审查是提高软件过程质量和生产率的一种方法。文章介绍了审查能力成熟度模型,该模型用于评估一个组织软件审查实践的层次,为审查改进提供框架。 关键词审查;能力成熟度;质量 中图分类号T P393 I nspection Capability Maturity Model Cao Y ue1)Z hang Jing2) (Department of Electronics and Infor mation Eng ineering,H uazho ng U niversity of Science and Technology1),Wuhan430074) (Department of Com puter Science,N aval U niversit y of Eng ineer ing2),W uhan430033) A bstract Softw are inspect ion is an important method of improv ing qua lity and pr oductiv ity of softw are pro cess.T his paper int rodues inspect ion capability matur ity mo del(ICM M).T his model can be used to assess t he lev el of softw ar e inspec-t ion in an o rg anizat ion and to be a fr amew or k for inspection impr ovement. Key Words inspection,capabilit y maturit y model,quality Class Nu mber T P393 1引言 软件审查是提高软件过程质量和生产率的一种有效方法[1]。其基本目标是在软件工程的早期,通过协助软件开发人员标识和修复工作中的错误以改进软件质量。它以温伯格的/非自我程序设计0的概念为基础,在开发和维护过程的每一个环节进行审查。在很多问题的发现上,审查不仅比测试更有效,而且还可以在纠正成本较小的前提下尽早更正错误。表1给出了审查和测试发现错误的概率。 但是软件审查还没有在大多数组织中广泛应用,其自身还需要改进。本文介绍审查能力成熟度模型(ICM M),该模型可以评价组织的软件审查实践等级并提出审查改进的框架。ICM M与SM mm[2]、T MM[3]模型类似均用于软件相关过程评估和改进,在参考集成能力成熟度模型(CM-M I)[4]的基础上对软件审查进行建模,是CMM I模型的有益补充。审查能力成熟度的基础源于CM-M I并采纳其思想拓展到审查领域。 表1检测错误的概率(%) 阶段发现错误概率 设计审查57.7 代码审查62.7 单元测试72.9 算法测试8.3 集成测试46.1 需求测试45.7 ICM M延续CM MI的成熟度等级思想,从初始级到最优级共分为5个等级。每个成熟度等级都包含若干子过程,所有定义的需求均满足时才达到该等级。ICM M并不专注于特定类型的审查,例如需求或代码审查。它也不试图定义一种理想的审查过程,因为在不同情况下过程会变化。模型涵盖所有类型审查中普遍存在的最重要的元素。同 *收稿日期:2010年7月13日,修回日期:2010年8月20日 作者简介:曹悦,女,研究方向:电子与信息工程。张靖,女,讲师,研究方向:软件测试。
企业信息化成熟度阶段分类模型分析 从企业信息化基础条件和信息系统应用水平两个方面提出了企业信息化成熟度的13个评价指标，根据对66家企业的调研结果，采用主成分分析方法对13个评价指标进行了降维分析，得出了企业信息化成熟度综合评价指标。根据这些综合指标对66家企业的数据进行了聚类分析，提出了企业信息化成熟度阶段分类模型，得出企业信息化的五个发展阶段：即信息化准备阶段、信息系统引入阶段、信息系统集成共享阶段、信息系统企业外延伸阶段、信息系统决策支持阶段。 研究企业信息化成熟度等级模型就是研究企业信息化从不成熟到成熟的过程演变规律，为企业评估其目前的信息化发展阶段，制定信息化发展战略提供帮助。20世纪60年代以来，在信息系统的研究中，信息化成熟过程引起了广泛关注。国外提出了很多信息化成熟度模型，例如：Nolan模型、Synnott模型、Mische 模型、Hanna模型、Edgar Schein模型、Boar模型、业务-IT联盟成熟度模型等，其中Nolan模型最著名。在20世纪70年代，Nolan通过对200多个公司、部门信息系统实践的总结，分别以计算机在组织中的应用规模以及组织在IT应用上的资源投入大小为横纵坐标，提出了信息系统进化的4阶段模型：初始、传播、控制和成熟阶段。随着信息技术的发展，Nolan在4阶段模型的基础上又提出了6阶段模型，增加了“集成”和“数据管理”两个阶段。不同的国家，信息化起点不同，信息化的路径也不可能完全一样。为此，国内很多学者尝试研究适合中国企业的信息化成熟度模型。文献[2]提出4阶段模型：引入、集成、流程变革、战略变革。文献[3]提出6阶段模型：企业进入、数字化生存、单点数字化、联合自动化、决策支持自动化、敏捷一虚拟化的企业。文献[7]提出5阶段模型：技术支撑级、资源集成级、管理优化级、战略支持级和持续改善级。文献[8]提出了6阶段模型：原始信息化、信息化初级、单个信息系统、信息系统集成、信息网络化集成决策和网上企业。文献[9]提出了5阶段模型：引入、渗透、膨胀、调整、集成。但这些研究对模型提出过程的阐述都比较笼统，没有具体说明模型是如何提出的。为此，作者通过对66家企业的问卷调查，采用主成分分析和聚类分析方法，提出了信息化成熟度模型。 1 企业信息化成熟度评价指标体系 计算机及所构成的硬件环境是企业进行信息化的基础条件，各种信息系统的应用则体现了企业信息化的应用水平。因此，企业信息化成熟度评价指标体系包括企业信息化基础条件建设和信息系统应用水平两个方面的指标，具体指标体系如图1所示。
常用的性能测试方法(策略)和测试要点 1.明确测试目标，测试目标尽可能能够有量化的标准 1）上线前验证性的性能测试，针对银行系统一般的性能指标为TPS、响应时间是否满足业务需求； 2）容量测试，测试系统在特定系统环境下的处理能力，关注的性能指标是TPS、响应时间、并发用户数等； 3）稳定性测试，银行系统对系统7×24小时的稳定性要求还是很高的； 4）异常测试，指系统出现异常或故障的情况下，系统能否在最短的时间内恢复，保证在线交易的正常进行； 2、明确测试范围，测试系统有哪些，测试交易的路径覆盖范围； 3、业务模型分析，选择日常交易量比较大，路径覆盖范围广的典型交易，建立性能测试的业务模型，确定各支交易的占比； 4、测试需求分析，测试环境（软硬件），人力，测试工具的选择，测试基础数据等需求； 5、测试内容及测试策略，一般包含以下几个方面： 1）基准测试，单用户单交易的测试，主要用于调试测试脚本的正确性，以及查看每只交易在无压力下的响应时间，为下面的测试建立基准； 2）单交易负载测试，获取每只交易的最大负载，主要考察单只
交易和系统处理能力的影响； 3）混合场景的测试，按照业务及测试模型梯度加压，以获取系统的最大处理能力，及在各种压力下每只交易的响应时间情况； 4）稳定性测试，按照混合测试模型，考察在一定的压力下持续执行24小时的系统运行情况，主要关注系统是否稳定，系统是否存在内存泄漏问题等； 5）异常测试，服务中断、网络终端、硬件故障等异常情况下系统对在线交易的影响； 6、设计测试案例； 7、执行测试，监控系统资源、应用、数据库相关指标，记录测试结果； 8、测试结果收集和分析； 9、测试报告编写； 10、测试总结； --以上是个人的一点概括性的总结，供大家参考，总之，测试目标决定测试策略和测试方法，明确测试目标是关键。来源:考试大
软件能力成熟度模型:CMM 五个级别介绍 CMM 为企业的软件过程能力提供了一个阶梯式的进化框架, 阶梯共有五级。第一级只是一个起点,任何准备按 CMM 体系进化的企业都自然处于这个起点上,并通过它向第二级迈进。除第一级外,每一级都设定了一组目标, 如果达到了这组目标,则表明达到了这个成熟级别,可以向下一级别迈进。 从纯粹的个人行为发展到有计划有步骤的组织行为… 第一级:初始级 (Initial; 第二级:可重复级 (Repeatable; 第三级:已定义级 (Defined; 第四级:受管理级 (Managed; 第五级:优化级 (Optimizing。 初始级 初始级的软件过程是未加定义的随意过程, 项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范, 但若这些规范未能覆盖基本的关键过程要求, 且执行没有政策、资源等方面的保证时,那么它仍然被视为初始级。 关注点: 工作方式处于救火状态,不断的应对突如其来的危机; 工作组:软件开发组、工程组; 提高: 需要建立项目过程管理,建立各种计划,开展 QA 活动。
可重复级 根据多年的经验和教训,人们总结出软件开发的首要问题不是技术问题而是管理问题。因此, 第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程, 可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面; 其中项目管理过程又分为计划过程和跟踪与监控过程。 通过实施这些过程,从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。 关注点: 规则化 引入需求管理、项目管理、质量管理、配置管理、子合同管理等; 引入工作组:测试组、评估组、质量保证组、配置管理组、合同组、文档支持组、培训组; 提高: SEPG 、建立软件过程库和文档库 已定义级 在可重复级定义了管理的基本过程, 而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准, 并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程, 裁剪出与项目适宜的过程, 并且按照过程执行。过程的裁剪不是随意的,在使用前必须经过企业有关人员的批准。 关注点: 文档化,标准的一致的;
最新版LoadRunner性能测试实战 内容介绍： 很多使用LoadRunner的测试人员经常面临两个难题：脚本开发与性能测试分析。本书就是基于帮助测试人员解决这两个问题而编写，致力于使读者学精LoadRunnner这一强大的性能测试工具。 全书共分为四部分：入门篇、基础篇、探索篇、实战篇。第一篇入门篇的内容包括第1章和第2章，着重于讲解性能测试与LoadRunner的基础理论知识。第二篇基础篇的内容包括第3章至第5章，是LoadRunner 的基本使用部分，着重讲解Virtual User Generator、Controller、Analysis的使用方法。第三篇探索篇的... 第1部分入门篇.. (1) 第1章性能测试基础知识.. 3 1.1 性能测试基本概念 (4) 1.1.1 什么是性能测试 (4) 1.1.2 性能测试应用领域 (6) 1.1.3 性能测试常见术语 (8) 1.2 全面性能测试模型 (11) 1.2.1 性能测试策略模型 (14) 1.2.2 性能测试用例模型 (17) 1.2.3 模型的使用方法 (20) 1.3 性能测试调整基础 (21) 1.4 如何做好性能测试 (24) 1.5 本章小结 (28) 第2章LoadRunner基础知识.. 29 2.1 LoadRunner简介 (29) 2.1.1 LoadRunner主要特点 (29) 2.1.2 LoadRunner常用术语 (31) 2.2 LoadRunner工作原理 (32) 2.3 LoadRunner测试流程 (33) 2.4 LoadRunner的部署与安装 (35) 2.5 本章小结 (41) 第2部分基础篇 (43) 第3章脚本的录制与开发.. 45
工业互联网成熟度评估模型 本文出自工业互联网产业联盟发布的《工业互联网成熟度评估白皮书》。 本白皮书旨在为企业提供一套评价自身实践的方法论，为企业找到工业互联网实施中的主要问题、改进方向和建设路径。与此同时，业界各方力量的应用和反馈也将不断促进联盟修正该方法论中存在的问题，为工业互联网发展提供更科学更准确的指导。 一、工业互联网成熟度评估提出的原因 （一）工业互联网应用浪潮来袭 随着工业互联网概念兴起，美德先导应用不断涌现，目前德国工业4.0平台已有140多个应用案例，美国IIC有接近50 个应用案例，主要聚焦在生产管理优化、物流仓储优化、质量管理优化、产线柔性部署、产品服务价值化等领域。与此同时，我国产业界也加快了面向各类场景的工业互联网应用探索。2016 年，工信部相关部门组织实施了10 个工业互联网试点示范项目，AII 联盟也评选出了首批12 个工业互联网优秀案例。然而，目前我国工业互联网应用与发达国家相比还存在总体发展水平较低、行业间企业间基础差异较大、大规模推广难度巨大、缺乏工业互联网评估体系和实施指南等问题。 （二）联盟需构建先导性的标准化模型 从国内外已有的主要成熟度模型来看，德国构建了工业4.0 成熟度评级模型，但因两国发展基础不同，建设水平不同，并不能直接用于我国工业互联网成熟度评估。AII 联盟作为推进我国工业互联网政产学研用协同发展的公共平台，需要率先开展研究，针对我国自身特点，制定一套评估模型和方法，推进工业互联网理论与实践。 （三）为企业提供一个便利的自我评价工具 当前产业界对工业互联网的理解不统一，企业对自身工业互联网发展的定位、现状和发展路径不明确，缺乏一致的方法论来评判具体实践。联盟希望通过工业互联网成熟度评估体系的制定助力企业了解自身建设水平，发现存在的问题，并获取相关的诊断建议。该评估模型并不是为了创造一套复杂的理论，而是希望以提供互联网服务的方式为企业提供一个便利的自我评价工具。 （四）为政产研用搭建一个持续透明的信息窗口 工业互联网成熟度评估模型的制定并不是一蹴而就的，当前的 1.0 版本主要是结合现阶段工业互联网发展的特点和先进实践而得出的，将来还有持续发展、反复迭代的过程，需要借助产业界各类主体的意见和建议深化模型，并结合企业对模型的应用结果和反馈，不断更替或补充更符合不同阶段实际情况的评估因素，不断修正完善评估指标、权重和评估问卷设置等。这个过程不仅能助力政府部门了解我国工业互联网的最佳实践，也能帮助应用企业和解决方案服务商建立透明的信息窗口，促进产学研结合。
流程再造新工具：PEMM框架 作者：迈克尔·哈默 翻译：陈桂华为什么流程再造屡屡失败，主要原因就在于企业能力与流程不匹配。本文介绍的新工具能帮助企业解决这个问题。 “流程管理”早已成为企业日常运作的一部分。17年前，我在《哈佛商业评论》 (参见Reengineering Work：Don't Automate，Obliterate，1990年7／8月号) 上首次提出这一全新概念，引发了颇多争议。而如今，世界各地的企业都在通过业务流程再造来推行企业变革。所谓业务流程是指从原材料进入企业到产品流出企业这一运营链条上的所有工作。企业进行业务流程再造，不仅能够大幅提高绩效，还能为客户提供更大的价值，为股东创造更多的利润。很少有企业高管会质疑这一点。事实上，各行各业的企业，无论其规模大小，几乎都因为关注、衡量和重新设计了面向内部和外
部客户的流程，而在成本、质量、速度和赢利能力等关键指标上取得了显著改善。 不过遗憾的是，失败的例子也比比皆是。2000年以来，我亲历了数百家企业为了重获生机而建立或再造业务流程的过程。尽管有良好的意愿和必要的投资，但许多企业不是进展缓慢，就是成效甚微。即使是那些成功变革的企业，也是历经千辛万苦才“守得云开见月明”。不可否认，所有的变革项目推行起来都困难重重，然而流程变革则更为艰难。一般人都以为，设计新的业务流程就是重新安排工作流程，只需要确定谁来做什么事，在哪里做，按照什么顺序来做就行了。然而情况并没有这么简单。要让新流程发挥作用，企业必须从更广层面上重新界定工作，提供更多培训以支持这些工作，并培养一线员工的决策能力：还要调整奖励制度，不仅关注结果，也要考虑过程。除此之外，企业必须重塑组织文化，强调团队合作、个人责任感以及客户重要性，重新界定管理者的职责，鼓励他们监管流程，而不是监督具体活动，培养员工而不是监督员工，最后，企业需要协调信息系统，以确保跨部门流程的运行顺畅，而不只是支持单个部门。 在我研究的多数企业中，高管们常常为了流程重组而绞尽脑汁。他们知道，要发挥流程的作用，就得改变很多东西．但究竟需要改变什么，改变多少、何时改变，他们又不清楚。他们的迷茫引发了种种混乱：决策犹豫不决、计划杂乱不清，争辩无休无止、讨论无果而终，无端的自满和绝望，再三失误和重复劳动，一再延期和半途而废。他们不停地相互询问：我们是否一开头就做错了?我们怎么才能知道事情有没有进展?完成变革后，企业会呈现什么样的面貌?另外，对于哪些因素有助于推动基于流程的变革，高管们往往意
性能测试方案
修订记录
目录 目录 (3) 1概述 (4) 2测试目标 (4) 3测试设计 (5) 3.1对象分析 (5) 3.2测试策略 (5) 3.3测试模型 (5) 3.4测试环境描述 (6) 3.5详细测试方法 (7) 4统计测试数据 (9) 5性能测试报告输出 (12) 6性能调优与回归 (12)
性能测试方案 1概述 ：首页、注册、登录、站内交流、站内搜索、测试技术资料上传与下载等模块的性能测试工作。本文主要描述了上述模块的性能参考指标及测试方法，以便于性能测试实施人员与客户对系统从技术层面指导测试人员验证相关功能模块的负载能力，根据实际的性能监控数据考察系统最大的负载及相关指标情况，以便于客户对系统实施相关的调优工作，使其达到预期期望的压力和性能要求。 2测试目标 本次性能测试工作验证系统：首页、注册、登录、信息检索、普通用户资料上传、在线观看视频等模块的性能需满足下表指标（场景指标）： 表1性能指标列表 并发数=业务量/（时间段(小时单位)3600秒/每人每笔业务的处理时间）
3测试设计 3.1对象分析 系统采用B/S（Browser/Server）模式设计。基于LAMP开发平台开发。 操作系统：Red Hat Enterprise Linux 4 Web服务器：apache 2.0 数据库服务器：mysql 5.0 开发语言：PHP 3.2测试策略 使用HP商用性能测试工具LoadRunner 9.1，模拟用户并发操作。测试系统首页、注册、登录、站内交流、站内搜索、测试技术资料上传与下载等模块在多用户并发操作下是否能够稳定正常运行。支持的最大并发数，各项指标是否能够达到预期的指标标准，并为后期系统调优提供指标数据支持。 3.3测试模型 3.3.1系统组网图（需客户提供） 图1系统组网图
CMMI CMMI 早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI 在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。 目录
展开 简介 CMMI 的全称为：Capability Maturity Model Integration，即能力成熟度模型集成。 CMMI家族包括CMMI for Development, CMMI for Service和CMMI for Acquisition三个套装产品。 CMMI是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型 自从1994 年SEI 正式发布软件CMM 以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题，其中主要问题体现在：n 不能集中其不同过程改进的能力以取得更大成绩； n 要进行一些重复的培训、评估和改进活动，因而增加了许多成本； n 遇到不同模型中有一些对相同事物说法不一致，或活动不协调，甚至相抵触。 于是，希望整合不同CMM 模型的需求产生了。1997 年，美国联邦航空管理局（FAA）开发了FAA-iCMMSM（联邦航空管理局的集成CMM），该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM和软件的SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。 CMMI 与CMM 最大的不同点在于：CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即：系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分。 CMMI 有两种表示方法，一种是大家很熟悉的，和软件CMM 一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5 个成熟度级别，帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续