企业级软件产品系统测试的敏捷方法研究和实践硕士学位论文.doc

企业级软件产品系统测试 的敏捷方法研究和实践浙江大学硕士学位论文 摘要摘要系统测试属于软件产品对外发布前的产品验收测试，其目的是验证软件产品是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。在传统的瀑布开发模型下，系统测试通常要等到代码开发阶段结束后开始。独立的系统测试阶段有利于测试工作的顺利进行，但缺点也显而易见不能尽早消除系统层面的软件缺陷导致测试和修复缺陷的成本居高不下，同时也增加了软件开发生命周期的时间。敏捷测试是遵守敏捷宣言的软件测试实践方法，是敏捷开发的关键组成部分。敏捷系统测试的引入加快了软件开发生命周期并提高了软件产品的整体质量，但不可避免的增加了系统测试过程的难度。如何发挥敏捷系统测试的优势，并降低其带来的影响是本论文主要分析和讨论的内容。软件测试成熟度模型（TMM）是基于CMM产生的，TMM的目标是帮助组织提高软件测试成熟度，它能够用于分析软件测试机构运作过程中最优秀或最混乱的区域，并辅助软件测试机构进行测试过程的评估与改进。作者将在论文中运用TMM模型与敏捷系统测试过程模型的基本思想，提出基于TMM模型的敏捷系统测试具体过程实现模型、软件缺陷管理方案、企业级软件系统测试用例设计，并通过作者在黑莓公司实习期间参与的敏捷系统测试项目加以论证运用TMM模型可以改进敏捷系统测试过程。关键词：系统测试，敏捷测试，系统测试过程模型，系统测试具体过程实现模型，软件测试成熟度模型i浙江大学硕士学位论文 AbstractAbstractSystem testing belongs to acceptance testing of software product before its official release to the customers. It aims to verify whether the software product meets the definition of its specification requirement, and specify the places inside the software that violate the requirement. In traditional water-fall development model, system testing is always started after code development completion. While independent phase of system testing makes the testing process progress smoothly, the shortcomings of it are also obvious. Traditional system testing process is hard to eliminate system level software defects in the early phase of testing, which results in making the testing overhead at the high level. Besides, in order to fully achieve testing goals, independent system testing process tends to prolong time usage of software development lifecycle.Agile testing is one kind of software testing practice which follows agile manifesto, and its one of indispensable parts of agile development. Incorporating agile method into system testing can accelerate the software release process and highly improve the quality of software product. However, there do exist difficulties in agile system testing process. In the following paragraphs of the main body of thesis, the author will explain how to take advantage of the agile system testing, and minimize the impact of the its agile process.Software Testing Maturity Model(abbr. TMM) is derived from Capacity Maturity Model(abbr. CMM), and it aims to help testing organization improve the level of testing maturity. It is used to find out the strength and weakness of the software testing organization, as well as to coordinate the evaluation and improvement of it. In the thesis, the author will combine the TMM and agile system testing process model together to come up with the agile system testing process implementation model, software defect management solution, design method of system testing cases of enterprise software. A case study will be provided after all those theoretical explanations. Key Words：System Testing, Agile Testing, System Testing Process Model, System Testing Process Implementation Model, Software Testing Maturity Modelii浙江大学硕士学位论文 目录目录摘要iAbstractii目录I图目录IV表目录V第1章 绪论11.1 课题背景11.1.1 敏捷开发与敏捷测试概述11.1.2 系统测试概述31.2 研究目标41.3 论文组织架构4第2章 软件测试成熟度模型理论分析62.1 软件测试能力成熟度模型概述62.2 软件测试能力成熟度模型等级划分62.2.1 初始级概述72.2.2 阶段定义级概述72.2.3 集成级概述82.2.4 管理和度量级概述102.2.5 优化、缺陷预防和质量控制级概述102.3 软件测试能力成熟度模型度量评估122.4 软件测试能力成熟度模型实践122.5 本章小结13第3章 系统测试理论分析143.1 系统测试和敏捷系统测试概述143.1.1 系统测试概述143.1.2 敏捷的系统测试概述153.2 系统测试过程模型163.2.1 里程碑模型163.2.2 软件产品发布生命周期模型173.2.3 里程碑模型和敏捷迭代开发模型相结合的模型193.3 基于TMM的系统测试过程具体实现模型203.3.1 系统测试开始前的准备工作计划203.3.2 第一个里程碑阶段测试过程223.3.3 第二个里程碑阶段测试过程243.3.4 第三个里程碑阶段测试过程253.3.5 第四个里程碑阶段测试过程263.4 本章小结26第4章 软件缺陷管理概述274.1 软件缺陷管理概述274.2 软件缺陷管理系统特点分析274.2.1 软件缺陷管理系统局的方便性284.2.2 软件缺陷管理系统的追踪性294.3 软件缺陷管理系统局限性分析294.4 软件缺陷管理系统使用的必要性分析304.5 本章小结30第5章 企业级软件产品概述315.1 企业级软件概述315.2 通用软件产品概述315.3 企业级软件系统测试用例分析325.3.1 黑莓手机管理平台解决方案概述325.3.2 系统测试用例设计举例345.4 本章小结35第6章 案例分析366.1 项目背景及测试结果分析366.1.1 系统测团队架构分析366.1.2 项目系统测试过程实现模型分析386.1.3 项目软件缺陷管理方案分析396.1.4 系统测试测试结果分析396.2 项目改进成果466.3 本章小结47第7章 总结与展望487.1 论文总结487.2 今后展望48参考文献49作者简历50致谢51II浙江大学硕士学位论文 图目录图目录图 1.1 敏捷开发模型示例2图 1.2 传统瀑布开发模型示例3图 2.1 软件测试能力成熟度模型具体内容6图 2.2 软件测试能力成熟度模型等级划分7图 3.1 系统测试过程具体实现过程示例14图 3.2 里程碑模型示例17图 3.3 软件产品发布生命周期示例18图 3.4 里程碑模型和敏捷迭代模型相结合的系统测试过程示例19图 5.1 黑莓手机管理平台解决方案产品线32图 5.2 软件测试类型示例34图 5.3 系统完整系测试示例35图 6.1 TC项目的时间表37图 6.2 TC项目的敏捷系统测试过程模型38图 6.3 第一个迭代系统部署测试执行中发现的软件缺陷示例42图 6.4 第二阶段系统部署测试中发现的软件缺陷示例45III浙江大学硕士学位论文 表目录表目录表 3.1 采用里程碑模型下各个阶段里程碑目标示例17表 3.2 四里程碑系统测试过程示例20表 3.3 系统测试开始前准备工作示例20表 3.4 第一个里程碑系统测试具体过程22表 3.5 第二个里程碑系统测试具体过程24表 3.6 第三个里程碑系统测试具体过程25表 3.7 第四个里程碑系统测试具体过26表 6.1 操作系统和数据库兼容性信息40表 6.2 第一阶段设计的测试用例分布41表 6.3 第一阶段测试执行结果41表 6.4 第一阶段确定的缺陷里程碑分类43表 6.5 第二阶段设计的测试会话分布44表 6.6 第二阶段测试执行结果44表 6.7 第二阶段确定的缺陷里程碑分类46表 6.8 第三阶段设计的测试用例分布46IV浙江大学硕士学位论文第1章 绪论第1章 绪论1.1 课题背景1.1.1 敏捷开发与敏捷测试概述 敏捷开发是以团队为核心，具有迭代性和增量性的开发方法1，图1.1是经典的敏捷开发模型示例。敏捷开发是针对传统的瀑布开发模型的弊端而产生，目的是提高软件开发效率和响应能力。敏捷开发过程中，软件功能以持续整合的方式不断集成到软件产品中，在整个开发过程中都强调高效沟通和及时反馈。敏捷软件开发关注保持简洁的代码，经常性测试和及时地交付应用的功能模块。敏捷思想的出现是为了替代传统的瀑布模型开发流程。 敏捷开发遵循敏捷宣言，其正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法2。 敏捷宣言强调的敏捷软件开发的四个核心价值是：（1）个人和互动高于流程和工具（2）工作软件高于理解文档（3）客户协作高于合同协商（4）变化响应高于计划遵循 敏捷宣言提出的十二条原则包括：（1）最重要的目标是通过持续不断地及早交付有价值的软件使客户满意。（2）欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。（3）经常地交付可工作的软件，倾向于采取较短的周期。（4）业务人员和开发人员必须相互合作，项目中的每一天都不例外。（5）激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。（6）不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。（7）可工作的软件是进度的首要度量标准。（8）敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。（9）坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。（10）以简洁为本，它是极力减少不必要工作量的艺术。（11）最好的架构、需求和设计出自自组织团队。（12）团队定期地反思如何能提高成效，并依此调整自身的举止表现图 1.1 敏捷开发模型示例 敏捷测试是遵守敏捷宣言的软件测试实践方法，是敏捷模型的关键组成部分3。敏捷思想的广泛传播使人们开始关注如何有效测试，同时敏捷项目也进一步改变了测试人员在团队中的角色。把质量构建进产品的思想是敏捷团队的中心任务。敏捷团队在迭代中工作高度协作以确保产品的质量状态。敏捷团队是高度跨职能的，开发人员，测试人员和其他人在整个迭代中紧密协作，以确保产品质量。敏捷团队中的几个核心概念都与测试有关。在测试驱动开发中，程序员为自己编写的代码进行单元测试。此外，开发人员也会编写测试代码进行集成测试以保证代码单元之间按要求协同工作，驱动测试开发（TDD）能够从代码层面深入思考软件设计并防止缺陷4。作者将单元测试和单元集成测试归于传统瀑布模型的开发阶段，主要由开发工程师负责。下文将阐述的敏捷测试主要指“面向业务”的测试，也称为“面向客户”的测试，测试定义了软件产品设计期望的特性和功能。测试工程师在敏捷开发过程中所进行的工作包括验证产品功能的测试和发现最终产品可能存在的缺陷以及缺陷改进后的测试。 瀑布模型一般会明确定义软件开发生命周期的各个阶段，即以需求分析和设计文档开始，代码编写和软件开发其次，以测试阶段结束（瀑布模型在该阶段通常会出现无法按时完成项目而匆忙进行测试，甚至延迟软件交付等情况）5，图1.2是经典的瀑布开发模型示例。瀑布模型的优点在于各个阶段目的明确、团队角色分工清晰、管理简单。但缺点也十分明显：需求固定，开发效率较低，软件质量无法提高等。在使用瀑布开发模型的开发团队中，测试人员虽被视为软件产品的质量守护者，但在由于测试阶段在代码交付和开发完成后开始，测试人员不能通控制代码如何编写提高软件质量，甚至不能控制开发人员是否进行单元测试。同时，由于需求冻结，测试人员无法直接通过改变产品需求改善软件质量。敏捷模型针对瀑布模型存在的缺陷提出改进。在敏捷团队中，开发人员、测试人员、产品经理、项目架构师等相互协作，及时反馈信息，此外团队在工作中密切接触业务，详细了解需求。在敏捷模型中，测试人员不再等待开发完成才开始工作，而是从设计阶段就开始寻找整个开发周期中可以贡献价值的地方，并且测试人员可以在迭代过程中与产品经理和项目负责人及时沟通，变更产品需求，甚至可以在需求分析阶段，从提高软件质量等角度提出产品需求。敏捷团队是以整体团队方式运行。整体团队运行方式要求每个人都对测试任务负责。架构师和项目经理需要参与敏捷测试计划的制定，参与软件缺陷生命周期的管理，而开发人员通过使用测试驱动开发，来编写高效高质量的代码。传统开发模型中的测试人员在敏捷开发过程中所进行的工作包括验证产品功能的测试和发现最终产品可能存在的缺陷以及缺陷改进后的测试。敏捷测试的优点之一就是可以快速从测试中得到反馈，它驱动项目前进，每个迭代里程碑都需要达到既定的测试目标。由于敏捷项目开发和测试在一定程度上并行，因此相对于传统瀑布模型开发，项目整体进展时间较快。图 1.2 传统瀑布开发模型示例 软件缺陷生命周期管理在敏捷测试中也具有高度迭代性。在一个迭代周期中，当发现软件缺陷之后，测试人员将与开发人员、产品经理或软件架构师沟通交流，在得到反馈和确认之后将提交软件缺陷报告。敏捷团队负责人和架构师将判断该软件缺陷的优先程度，并将其设定为此迭代或在未来迭代周期中需解决的缺陷，而当开发人员在某个迭代周期中修复此软件缺陷之后，测试人员会得到反馈并进行回归测试验证。1.1.2 系统测试概述 系统测试是将经过集成测试的软件，作为系统计算机的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行6。它是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试。它是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试是软件产品发布前的最终产品验收测试。 由于系统测试属于最终产品对外发布前的验收测试，在传统的瀑布开发模式下，为了版本稳定性，通常要等到代码开发阶段、对代码的单元测试和对产品功能的集成测试完成之后开始系统测试。在所有开发代码的活动全部完成后，开发人员开始参与到系统测试活动中来，他们的工作将转向协助测试人员修复发现的软件缺陷。1.2 研究目标作者将在下文引入软件测试成熟度模型（TMM），软件测试成熟度模型（TMM）是基于CMM产生的，TMM的目标是帮助组织提高软件测试成熟度，它能够用于分析软件测试机构运作过程中最优秀或最混乱的区域，并辅助软件测试机构进行测试过程的评估与改进。作者将在论文中运用TMM模型与敏捷系统测试过程模型的基本思想，提出基于TMM模型的敏捷系统测试具体过程实现模型，阐述如何发挥敏捷系统测试的优势，并减少其带来的测试难度；分析软件缺陷管理方案、企业级软件系统测试用例设计；并提供案例分析以论证运用TMM模型可以改进敏捷系统测试过程。作者对论文的主要贡献包括：(1) 总结了适用于系统测试过程的模型。(2) 结合TMM和敏捷系统测试过程模型，提出了适用于敏捷系统测试过程的敏捷系统测试过程实现模型。1.3 论文组织架构根据上述研究目标，文章其余部分内如组织如下：第二章： 作者将在第二章重点阐述了软件测试成熟度模型（TMM），软件测试成熟度模型是基于CMM产生的，TMM的目标是帮助组织提高软件测试成熟度，并辅助软件测试机构进行测试过程的评估与改进。作者将在下文对敏捷系统测试运用测试成熟度模型的改进和度量评估方法。 第三章： 第三章将介绍系统测试和敏捷系统测试的一般特点，并分析了系统测试过程的具体实现模型和系统测试过程模型。此外，作者将在3.3节提出基于软件测试能力成熟度模型（TMM）分析的系统测试具体过程实现模型，它是里程碑模型和敏捷迭代开发的系统测试过程模型的具体实现，并结合了TMM对如何提高软件测试成熟度的分析。第四章： 作者在第四章通过对软件缺陷、软件缺陷管理的概述介绍了基于TMM第四级管理和度量级别所要求的软件缺陷度量和管理，并将举例说明如何实现敏捷的软件缺陷管理。 第五章： 作者在第五章将介绍企业级软件的主要特点，并根据第二章TMM分析结合黑莓企业手机管理平台解决方案，提出了企业级软件系统测试用例设计方案。 第六章：第六章中，作者将根据TC项目系统测试测试过程，对该项目运用文中在3.3节中提出敏捷系统测试具体过程实现模型。该章将对TC项目的敏捷系统测试迭代阶段进行了案例分析，并给出了测试结果和结果分析。 第七章： 第七章将对全文内容进行总括，展望敏捷系统测试未来可继续改进的方面。5浙江大学硕士学位论文第2章 软件测试成熟度模型理论分析第2章 软件测试成熟度模型理论分析2.1 软件测试能力成熟度模型概述 能力成熟度模型（Capability Maturity Model）简称CMM7，其基本思想是：由于问题是由管理软件开发过程的方法引起的，所以新技术的运用不会自动提高生产率和利润率。能力成熟度模型主要包括五个等级：初始级（Initial）、可重复级(Repeatable)、定义级（Defined）、管理级（Managed）、优化级（Optimizing）。软件测试成熟度模型(Testing Maturity Model)简称TMM8，是基于CMM产生的。其基本思想是提出一个与CMM类似的框架，来评估组织团队测试过程的成熟度,目标是帮助组织提高测试成熟度。作为一类等级递增模型，它能够用于分析软件测试机构运作过程中最优秀或最混乱的区域，并辅助软件测试机构进行测试过程的评估与改进。软件测试成熟度模型具有如下优点：(1) 等级水平结构、关键活动和角色的定义精细。(2) 测试相关因素覆盖全面。(3) 支持测试过程成熟度增长。(4) 有定义良好的评估模型的支持。2.2 软件测试能力成熟度模型等级划分TMM制定了五个成熟度等级：初始级，阶段定义级，集成级，管理和度量级，优化、缺陷预防和质量控制级9。如图2.1，各级成熟度水平包含了一组成熟度目标和子目标，以及支持它们的任务、职责和活动。图2.2为软件测试能力成熟度模型的等级划分。图 2.1 软件测试能力成熟度模型具体内容图 2.2 软件测试能力成熟度模型等级划分2.2.1 初始级概述 TMM初始级软件测试过程的特点是测试过程无序，有时甚至是混乱的，几乎没有妥善定义的。初始级中软件的测试与调试常常被混为一谈，软件开发过程中缺乏测试资源，工具以及训练有素的测试人员。初始级的软件测试过程没有定义成熟度目标。2.2.2 阶段定义级概述 TMM的定义级中，测试己具备基本的测试技术和方法，软件的测试与调试己经明确地被区分开。测试被定义为软件生命周期中的一个阶段，紧随代码开发阶段之后。TMM的定义级中需实现3个成熟度目标:制订测试与调试目标，启动测试计划过程，制度化基本的测试技术和方法。 软件组织必须清晰地区分软件开发的测试过程与调试过程，识别各自的目标，任务和活动。正确区分这两个过程是提高软件组织测试能力的基础。与调试工作不同，测试工作是一种有计划的活动，可以进行管理和控制。这种管理和控制活动需要制订相应的策略和政策，以确定和协调这两个过程。制订测试与调试目标包含5个子成熟度目标: (1) 分别形成测试组织和调试组织，并有经费支持。(2) 规划并记录测试目标；规划并记录调试目标。(3) 将测试和调试目标形成文档，分发至项目涉及的所有管理和开发人员。 (4) 将测试目标反映在测试计划中。 制订计划是使一个过程可重复，可定义和可管理的基础。测试计划应包括测试目的，风险分析，测试策略以及测试设计规格说明和测试用例。此外，测试计划还应说明如何分配测试资源，如何划分单元测试、集成测试、系统测试等。启动测试计划过程包含5个子目标: (1) 建立组织内的测试计划组织并予以经费支持。 (2) 建立组织内的测试计划政策框架并予以管理上的支持。(3) 开发测试计划模板并分发至项目的管理者和开发者。 (4) 建立一种机制，使用户需求成为测试计划的依据之一。 (5) 评价，推荐和获得基本的计划工具并从管理上支持工具的使用。 为改进测试过程能力，组织中需应用基本的测试技术和方法，并说明何时和怎样使用这些技术，方法和支持工具。基本测试技术和方法制度化有2个子目标: (1) 在组织范围内成立测试技术组，研究，评价和推荐基本的测试技术和测试方法，推荐支持这些技术与方法的基本工具。(2) 制订管理方针以保证在全组织范围内一致使用所推荐的技术和方法。2.2.3 集成级概述 在TMM的定义级，测试过程中引入计划能力，在TMM的集成级，测试过程引入控制和监视活动。两者均为测试过程提供了可见性，为测试过程持续进行提供保证。在集成级，测试不仅仅是跟随在编码阶段之后的一个阶段，它已被扩展成与软件生命周期融为一体的一组已定义的活动。测试活动遵循软件生命周期的V字模型。测试人员在需求分析阶段便开始着手制订测试计划，并根据用户或客户需求建立测试目标，同时设计测试用例并制订测试通过准则。在集成级上，应成立软件测试组织，提供测试技术培训，关键的测试活动应有相应的测试工具予以支持。在该测试成熟度等级上，没有正式的评审程序，没有建立质量过程和产品属性的测试度量。集成级要实现4个成熟度目标，它们分别是:建立软件测试组织，制订技术培训计划，软件全生命周期测试，控制和监视测试过程。软件测试的过程及质量对软件产品质量有直接影响。由于测试往往是在时间紧，压力大的情况下所完成的一系列复杂的活动，因此应由训练有素的专业人员组成测试组。测试组要完成与测试有关的多种活动，包括负责制订测试计划，实施测试执行，记录测试结果，制订与测试有关的标准和测试度量，建立铡试数据库，测试重用，测试跟踪以及测试评价等。建立软件测试组织要现4个子目标: (1) 建立全组织范围内的测试组(2) 定义测试组的作用和职责。(3) 由训练有素的人员组成测试组。 (4) 建立与用户或客户的联系，收集他们对测试的需求和建议。 为高效率地完成好测试工作，测试人员必须经过适当的培训。制订技术培训规划有3个子目标: (1) 制订组织的培训计划，并在管理上提供包括经费在内的支持。(2) 制订培训目标和具体的培训计划。(3) 成立培训组，配备相应的工具，设备和教材 提高测试成熟度和改善软件产品质量都要求将测试工作与软件生命周期中的各个阶段联系起来。该目标有4个子目标: (1) 将测试阶段划分为子阶段，并与软件生命周期的各阶段相联系。(2) 基于已定义的测试子阶段，采用软件生命周期V字模型。(3) 制订与渊试相关的工作产品的标准。(4) 建立测试人员与开发人员共同工作的机制。这种机制有利于促进将测试活动集成于软件生命周期中 为控制和监视测试过程，软件组织需采取相应措施，如:制订测试产品的标准，制订与测试相关的偶发事件的处理预案，确定测试里程碑，确定评估测试效率的度量，建立测试日志等。控制和监视测试过程有3个子目标: (1) 制订控制和监视测试过程的机制和政策。(2) 定义，记录并分配一组与测试过程相关的基本测量。(3) 开发，记录并文档化一组纠偏措施和偶发事件处理预案，以备实际测试严重偏离计划时使用。2.2.4 管理和度量级概述 在管理和测量级，测试活动除测试被测程序外，还包括软件生命周期中各个阶段的评审，审查和追查，使测试活动涵盖了软件验证和软件确认活动。根据管理和测量级的要求，软件工作产品以及与测试相关的工作产品，如测试计划，测试设计和测试步骤都要经过评审。因为测试是一个可以量化并度量的过程。为了测量测试过程，测试人员应建立测试数据库。收集和记录各软件工程项目中使用的测试用例，记录缺陷并按缺陷的严重程度划分等级。所建立的测试规程应能够支持软件组终对测试过程的控制和测量。管理和测量级有3个要实现的成熟度目标:建立组织范围内的评审程序，建立测试过程的测量程序和软件质量评价。 软件组织应在软件生命周期的各阶段实施评审，以便尽早有效地识别，分类和消除软件中的缺陷。建立评审程序有4个子目标: (1) 管理层要制订评审政策支持评审过程。 (2) 测试组和软件质量保证组要确定并文档化整个软件生命周期中的评审目标，评审计划，评审步骤以及评审记录机制。(3) 评审项由上层组织指定。通过培训参加评审的人员，使他们理解和遵循相牢的评审政策，评审步骤。 测试过程的侧量程序是评价测试过程质量，改进测试过程的基础，对监视和控制测试过程至关重要。测量包括测试进展，测试费用，软件错误和缺陷数据以及产品渊量等。建立渊试测量程序有3个子目标: (1) 定义组织范围内的测试过程测量政策和目标。(2) 制订测试过程测量计划。(3) 应用测量结果制订测试过程改进计划。 软件质量评价内容包括定义可测量的软件质量属性，定义评价软件工作产品的质量目标等项工作。软件质量评价有2个子目标: (1) 管理层，测试组和软件质量保证组要制订与质量有关的政策，质量目标和软件产品质量属性。(2) 测试过程应是结构化，己测量和己评价的，以保证达到质量目标。2.2.5 优化、缺陷预防和质量控制级概述 由于本级的测试过程是可重复，已定义，已管理和己测量的，因此软件组织能够优化调整和持续改进测试过程。测试过程的管理为持续改进产品质量和过程质量提供指导，并提供必要的基础设施。优化，预防缺陷和质量控制级有3个要实现的成熟度目标: 应用过程数据预防缺陷，质量控制，测试过程优化。 这时的软件组织能够记录软件缺陷，分析缺陷模式，识别错误根源，制订防止缺陷再次发生的计划，提供跟踪这种括动的办法，并将这些活动贯穿于全组织的各个项目中。应用过程数据预防缺陷有礴个成熟度子目标: (1) 成立缺陷预防组。(2) 识别和记录在软件生命周期各阶段引入的软件缺陷和消除的缺陷。 (3) 建立缺陷原因分析机制，确定缺陷原因。 (4) 管理，开发和测试人员互相配合制订缺陷预防计划，防止已识别的缺陷再次发生。缺陷预防计划要具有可跟踪性。 在本级，软件组织通过采用统计采样技术，测量组织的自信度，测量用户对组织的信赖度以及设定软件可靠性目标来推进测试过程。为了加强软件质量控制，测试组和质量保证组要有负责质量的人员参加，他们应掌握能减少软件缺陷和改进软件质量的技术和工具。支持统计质量控制的子目标有: (1) 软件测试组和软件质量保证组建立软件产品的质量目标，如:产品的缺陷密度，组织的自信度以及可信赖度等。 (2) 测试管理者要将这些质量目标纳入测试计划中。 (3) 培训测试组学习和使用统计学方法。 (4) 收集用户需求以建立使用模型 优化测试过程在测试成熟度的最高级，己能够量化测试过程。这样就可以依据量化结果来调整测试过程，不断提高测试过程能力，并且软件组织具有支持这种能力持续增长的基础设施。基础设施包括政策，标准，培训，设备，工具以及组织结构等。优化测试过程包含:(1) 识别需要改进的测试括动 (2) 实施改进。 (3) 跟踪改进进程。 (4) 不断评估所采用的与测试相关的新工具和新方法。 (5) 支持技术更新。2.3 软件测试能力成熟度模型度量评估虽然TMM在管理和度量级才明确提出了正式的度量以及评估计划，但定义度量对象与度量方法的工作则可以在四级以下进行，因为度量本身就是支持更高成熟度目标的实现以及当前能进行的最佳测试活动的实施。软件测试机构可从低级、粗略的度量做起，随着成熟度等级的提高,度量逐步深入和细化。与成熟度的等级关系相似，高等级的度量包含了低等级的度量10。下面讨论在各成熟度等级上，可应用于软件测试机构的度量对象和度量方法:(1) 规模度量 规模对于测试项目，测试计划，成本工作量预测，风险评估，效率度量而言，是一项非常重要的度量因素，它包括：软件产品规模、测试对象数量、测试用例编写数量、测试用例执行数量11。(2) 缺陷度量、软件异常数量、缺陷率 测试机构在此级开始收集缺陷信息的目的是：在实际测试中对发现的各类问题有着文档化的记录。缺陷信息有助于评价软件质量，支持软件开发和测试过程的改进，同时对软件缺陷数据库的建立提供了基础。(3) 成本工作量、测试项目总体成本、测试执行小时数、测试工作量成本成本度量则有助于测试成本预测，通过收集成本工作量度量信息，软件测试机构就可以开始着手建立成本数据库，为将来的测试项目提供成本预测支持。(4) 代码走查、系统测试的计划时间、系统测试的执行时间 代码走查和系统测试是软件测试机构被授权的测试类型。如果有其它测试类型，则同样要搜集其设计和执行时间12。有助于制定，评估和改进测试计划的度量包括：1) 计划生成的测试用例数量2) 实际生成的测试用例数量3) 计划的测试覆盖率4) 实际的测试覆盖率5) 成本性能指数（CPI，指计划的测试时间与实际测试时间之间的比例）2.4 软件测试能力成熟度模型实践作者将在论文中运用TMM模型与敏捷系统测试过程模型的基本思想，提出基于TMM模型的敏捷系统测试具体过程实现模型，阐述如何发挥敏捷系统测试的优势，并减少其带来的测试难度；分析软件缺陷管理方案、企业级软件系统测试用例设计；并提供案例分析以论证运用TMM模型可以改进敏捷系统测试过程。2.5 本章小结作者在本章重点阐述了软件测试成熟度模型（TMM），软件测试成熟度模型是基于CMM产生的，TMM的目标是帮助组织提高软件测试成熟度，并辅助软件测试机构进行测试过程的评估与改进。作者将在下文对敏捷系统测试运用测试成熟度模型的改进和度量评估方法。13浙江大学硕士学位论文第3章 系统测试理论分析第3章 系统测试理论分析3.1 系统测试和敏捷系统测试概述3.1.1 系统测试概述正如绪论所描述，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。由于系统测试属于最终软件产品对外发布前的产品验收测试，在传统的瀑布开发模式下，为了交付系统测试的版本稳定性，系统测试属于产品开发的较后阶段，通常要等到代码开发阶段、对代码的单元测试和对产品功能的集成测试完成之后。在所有开发代码的活动全部完成后，开发人员开始参与到系统测试活动中来，他们的工作将转向协助测试人员修复发现的软件缺陷。系统测试是对整个产品系统进行的测试，目的是验证系统是否满足需求规格定义，找出与需求规格不符或与之矛盾的地方。系统测试属于最终产品验收测试，其执行一般基于开发团队交付的可运行版本。图3.1为系统测试具体实现的一般过程，主要针对传统瀑布模型下的系统测试，而敏捷的系统测试也会经历图上的各个过程，区别在于敏捷的测试也是迭代的、增量的，即敏捷模型下系统测试过程并不是单一过程，而是基于敏捷迭代而进行多个系统测试迭代，并且每个系统测试迭代都会加入敏捷因素，例如不断的沟通和反馈，并且上图中过程之间会不断的交互，各个过程的界限也变得模糊。系统测试的一般过程包括：图 3.1 系统测试过程具体实现过程示例 (1) 版本交付系统测试，测试团队分析测试策略 在瀑布模型下，系统测试开始于开发阶段完全结束之后。系统测试团队根据产品功能需求说明书和设计文档分析系统测试策略。 (2) 设计测试用例，制定测试计划 系统测试团队根据系统测试策略的分析结果设计测试用例，并制定测试计划。测试计划的详细程度和覆盖程度也基于测试策略。 (3) 执行测试用例，验证缺陷修复 软件测试过程就是发现缺陷的过程，测试团队发现的缺陷将由开发团队进行修复，并由测试团队进行回归验证。 (4) 完成测试计划，分析并交付测试结果 系统测试团队将测试交付测试结果，并对测试中发现的软件缺陷进行再分析，收集缺陷数据报告并根据缺陷趋势曲线识别和预防缺陷的频繁发生。3.1.2 敏捷的系统测试概述 独立的系统测试阶段有利于测试工作的顺利进行，但缺点也显而易见不能尽早消除系统层面的软件缺陷导致测试和修复所发现缺陷的成本居高不下，同时也不可避免的增加整个软件产品发布的时间。在敏捷模型下，系统测试活动将采用“有条件”的敏捷迭代过程13。所谓条件是指系统测试的敏捷实现过程将基于开发团队交付的alpha版本软件产品，最初交付的产品仅包含部分功能，当进入功能开发整合和系统测试并行阶段后，后续功能会在敏捷迭代中不断逐步整合到软件产品中。敏捷的系统测试强调从客户的角度出发，即从使用系统的用户出发来测试系统，重点关注持续迭代整合进系统的新功能和迭代周期需回归测试已修复的软件缺陷。敏捷的系统测试强调以人为中心，测试过程的进行依靠团队的高效沟通和持续反馈。3.1.2.1 敏捷系统测试的优点引入敏捷系统测试的优点显而易见：（1）尽早发现与系统测试相关的软件缺陷。许多系统层面的软件缺陷只有在基于复杂用户故事设计的测试用例中才会被发现，因此系统测试提早介入可以提早发现此类缺陷的时间。尽早发现软件缺陷可以有效降低软件测试的成本，并提高软件产品的质量。（2）使系统测试工程师更好的融入整个敏捷团队。 敏捷测试的采用使得系统测试团队和其他角色之间更频繁且更深入的交流，系统测试团队可以在交流中不断修改和完善测试计划，并更加高效的进行缺陷跟踪。更密切交流的另一个重要好处是，当新的功能整合到软件版本中时，系统测试团队可以立即注意到，并增加相应的测试计划。（3）允许系统测试工程师提出需求变更。 传统的系统测试在代码开发完成后开始，由于需求的冻结，使得系统系统测试工程师可以从用户使用系统的角度出发，对产品的需求提出变更，提高产品的质量或用户使用的友好程度。（4）加快软件产品发布周期。系统测试和功能开发整合并行使得系统测试可以提早介入到产品开发生命周期中，系统测试工程师可以有更多的时间进行测试，这使测试人员可以在迭代的早期熟悉并理解产品的架构特点和运行方式，从而加快后续阶段的测试效率。3.1.2.2 敏捷系统测试的挑战 敏捷系统测试的引入加快了软件产品发布的周期，但也不可避免的增加了系统测试过程进行的难度，敏捷系统测试主要的挑战包括：(1) 易引入新的系统层次软件缺陷。(2) 增加了测试用例设计的难度。(3) 完成测试计划的工作量变得难以估计。(4) 敏捷的测试过程对系统测试工程师提出了更高的要求。(5) 测试和开发并行增加了开发工程师的工作难度。3.2 系统测试过程模型 作者在3.1节中介绍了系统测试过程具体实现的一般模型，该模型主要描述的是在一个系统测试过程中，系统测试团队所参与的与测试过程相关的活动。与具体实现模型不同，本节作者所描述的系统过程模型主要阐述的是系统测试的渐进过程，即系统测试过程可以分为多个子过程，每个过程是包含了系统测试的一个具体实现。3.2.1 里程碑模型 由于系统测试是在将软件产品交付给客户使用之前完成的最终产品测试，一般在完成开发和功能验证测试之后进行，因此采用里程碑模型的系统测试过程为产品发布之前的测试建立了时间表，时间表上的各个节点称里程碑。测试团队会对里程碑完成提出阶段性目标，并且每个里程碑达到时都会产生阶段可交付物，例如可对外交付或对Beta用户交付的软件版本。里程碑模型有利于测试团队不断加深对所测试软件产品的理解，同时提出阶段性目标有利于跟进整个系统测试过程所处状态，随着阶段的深入，完成里程碑的标准将变得越来越苛刻，最终目标是达到产品发布的质量要求。图3.2里程碑模型基本过程的示例。里程碑模型并不是简单的时间表概念，更重要的是制定达到里程碑的目标。如表3-1所示，里程碑目标的内容一般包括：计划验证修复的软件缺陷、计划覆盖的测试计划内容。图 3.2 里程碑模型示例表 3.1 采用里程碑模型下各个阶段里程碑目标示例里程碑目标M1M2M3Release测试用例覆盖进行优先级最高的测试用例覆盖优先级最高的测试用例覆盖优先级最高，次高的用例完成所有测试用例修复软件缺陷修复30%被确定为M1里程碑目标的缺陷修复50%被确定为M2里程碑目标的缺陷修复70%被确定为M3里程碑目标的缺陷修复所有软件缺陷3.2.2 软件产品发布生命周期模型 采用软件发布生命周期模型的系统测试过程是基于里程碑模型的衍生，其里程碑时间点以对Alpha/Beta用户发布或对外正式发布软件版本为主要里程碑目标，同时每一个里程碑目标都包含了对之前发布版本的缺陷修复和质量提高。里程碑时间表从最初Alpha版本交付测试开始到软件产品最终对外发布。软件发布生命周期模型适用于企业级软件的测试，庞大复杂的测试计划可以分解为多个阶段计划，通过阶段性目标的检验完成大型的系统测试项目。图3.3为软件发布生命周期示例： (1) Pre-Alpha里程碑 该阶段主要指传统瀑布模型下的需求分析、设计、开发、单元测试环节。 (2) Alpha里程碑 该阶段的目标通常是最终交付的版本软件通过所有测试，并完成缺陷修复。所有测试工作将在该里程碑达到前完成。 (3) Beta里程碑 Beta测试阶段将根据设计用户故事、用户场景设计测试用例，进行测试。通常Beta阶段开始前开发团队将完成所有功能的开发，因此该阶段将开始完成的系统测试过程。Beta里程碑可以分解为多个里程碑，每个阶段将设置相应的里程碑目标，随着阶段的深入，完成里程碑的标准将变得越来越苛刻。 (4) 软件对外发布候选版本里程碑 该阶段里程碑目标主要是验收交付的Alpha版本产品质量，并修复发现的缺陷，使得该里程碑达到时交付可运行的软件产品。图 3.3 软件产品发布生命周期示例3.2.3 里程碑模型和敏捷迭代开发模