【教学课件】第6章软件测试项目管理.ppt

第 6 章 软件测试项目管理,6.1 测试项目管理概述6.2 测 试 文 档6.3 软件测试计划6.4 测试的组织与人员管理6.5 软件测试过程管理,6.1 测试项目管理概述,6.1.1 测试项目与测试项目管理1测试项目 测试项目是在一定的组织机构内，利用有限的人力和财力等资源，在指定的环境和要求下，对特定软件完成特定测试目标的阶段性任务。该任务应满足一定质量、数量和技术指标等要求。,测试项目一般具有如下一些基本特性。（1）项目的独特性（2）项目的组织性（3）测试项目的生命期（4）测试项目的资源消耗特性（5）测试项目目标冲突性（6）测试项目结果的不确定因素,2测试项目管理 测试项目管理就是以测试项目为管理对象，通过一个临时性的专门的测试组织，运用专门的软件测试知识、技能、工具和方法，对测试项目进行计划、组织、执行和控制，并在时间成本、软件测试质量等方面进行分析和管理活动。（一种高级管理方法）测试项目管理贯穿整个测试项目的生命周期，是对测试项目的全过程进行管理。,测试项目管理有以下基本特征。（1）系统工程的思想贯穿测试项目管理的全过程。（2）测试项目管理的组织有一定的特殊性。,（3）测试项目管理的要点是创造和保持一个使测试工作顺利进行的环境，使置身于这个环境中的人员能在集体中协调工作以完成预定的目标。（4）测试项目管理的方法、工具和技术手段具有先进性。,6.1.2 测试项目的范围管理 测试项目范围管理就是界定项目所必须包含且只需包含的全部工作，并对其他的测试项目管理工作起指导作用，以确保测试工作顺利完成。,项目目标确定后，下一步过程就是确定需要执行哪些工作，或者活动来完成项目的目标，这就是要确定一个包含项目所有活动在内的一览表。准备这样的一览表通常有两种方法：一种是让测试小组利用“头脑风暴法”根据经验，集思广益来形成。这种方法比较适合小型测试项目。,另一种是对更大更复杂的项目建立一个工作分解结构WBS和任务的一览表。工作分解结构是将一个软件测试项目分解成易于管理的更多部分或细目，所有这些细目构成了整个软件测试项目的工作范围。工作分解结构是进行范围规划时所使用的重要工具和技术之一，它是测试项目团队在项目期间要完成或生产出的最终细目的等级树，它组织并定义了整个测试项目的范围，未列入工作分解结构的工作将排除在项目范围之外。,进行工作分解是非常重要的工作，它在很大程度上决定项目能否成功。对于细分的所有项目要素需要统一编码，并按规范化进行要求。这样，WBS的应用将给所有的项目管理人员提供一个一致的基准，即使项目人员变动时，也有一个互相可以理解和交流沟通的平台。,6.2 测 试 文 档,测试文档是对要执行的软件测试及测试的结果进行描述、定义、规定和报告的任何书面或图示信息。由于软件测试是一个很复杂的过程，同时也涉及到软件开发中其他一些阶段的工作，因此，必须把对软件测试的要求、规划、测试过程等有关信息和测试的结果，以及对测试结果的分析、评价，以正式的文档形式给出。,测试文档对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时还会用到测试文档。测试文档的编写是测试管理的一个重要组成部分。,6.2.1 测试文档的作用测试文档的重要作用可从以下几个方面看出。1促进项目组成员之间的交流沟通2便于对测试项目的管理,3决定测试的有效性4检验测试资源5明确任务的风险6评价测试结果7方便再测试8验证需求的正确性,6.2.2 测试文档的类型 根据测试文档所起的不同作用，通常把它分成两类，即前置作业文档和后置作业文档。测试计划及测试用例的文档属于前置作业文档。后置作业文档是在测试完成后提交的，主要包括软件缺陷报告和分析总结报告。,6.2.3 主要软件测试文档1软件测试文档给出了软件测试主要文档的类型。,2软件测试计划 主要对软件测试项目、所需要进行的测试工作、测试人员所应该负责的测试工作、测试过程、测试所需的时间和资源，以及测试风险等做出预先的计划和安排。,3测试设计规格说明 用于每个测试等级，以指定测试集的体系结构和覆盖跟踪。,4软件测试用例规格说明文档用于描述测试用例。,5测试规程 用于指定执行一个测试用例集的步骤。6测试日志 由于记录测试的执行情况不同，可根据需要选用。,7软件缺陷报告 用来描述出现在测试过程或软件中的异常情况，这些异常情况可能存在于需求、设计、代码、文档或测试用例中。8测试总结报告 用于报告某个测试完成情况。,6.3 软件测试计划,测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。,6.3.1 制定测试计划的目的 一个计划一定是为了某种目的而产生的，对于软件质量管理而言，制定测试计划的目的主要有3个。1使软件测试工作进行更顺利2促进项目参加人员彼此的沟通3使软件测试工作更易于管理,6.3.2 制定测试计划的原则 制定测试计划是软件测试中最有挑战性的一个工作。以下原则将有助于制定测试计划工作。1制定测试计划应尽早开始2保持测试计划的灵活性3保持测试计划简洁和易读4尽量争取多渠道评审测试计划5计算测试计划的投入,6.3.3 制定测试计划时面对的问题 制定测试计划时，测试人员可能面对以下问题，必须认真对待，并妥善予以处理。1与开发者意见不一致 2缺乏测试工具 3培训不够,4管理部门缺乏对测试工作的理解和支持5缺乏用户的参与6测试时间不足7过分依赖测试人员8测试人员处于进退两难的状态9不得不说“不”,6.3.4 制定测试计划 制定测试计划时，由于各软件公司的背景不同，测试计划文档也略有差异。实践表明，制定测试计划时，使用正规化文档通常比较好。为了使用方便，在这里给出IEEE软件测试计划文档模板。,根据IEEE8291998软件测试文档编制标准的建议，测试计划包含了16个大纲要项，简要说明如下。1测试计划标识符 一个测试计划标识符是一个由公司生成的惟一值，它用于标识测试计划的版本、等级，以及与该测试计划相关的软件版本。,2介绍 在测试计划的介绍部分主要是测试软件基本情况的介绍和测试范围的概括性描述。,3测试项 测试项部分主要是纲领性描述在测试范围内对哪些具体内容进行测试，确定一个包含所有测试项在内的一览表。具体要点如下。功能的测试 设计的测试 整体测试,IEEE标准中指出，可以参考下面的文档来完成测试项：需求规格说明 用户指南 操作指南 安装指南 与测试项相关的事件报告,4需要测试的功能 测试计划中这一部分列出了待测的功能。5方法（策略）这部分内容是测试计划的核心所在，所以有些软件公司更愿意将其标记为“策略”，而不是“方法”。,测试策略描述测试小组用于测试整体和每个阶段的方法。要描述如何公正、客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响，要尽可能地考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备。测试记录具体说明如下。,公正性声明 测试用例 特殊考虑 经验判断 设想,6不需要测试的功能 测试计划中这一部分列出了不需要测试的功能。7测试项通过/失败的标准 测试计划中这一部分给出了“测试项”中描述的每一个测试项通过/失败的标准。正如每个测试用例都需要一个预期的结果一样，每个测试项同样都需要一个预期的结果。,下面是通过/失败的标准的一些例子：通过测试用例所占的百分比；缺陷的数量、严重程度和分布情况；测试用例覆盖；用户测试的成功结论；文档的完整性；性能标准。,8测试中断和恢复的规定测试计划中这一部分给出了测试中断和恢复的标准。常用的测试中断标准如下：关键路径上的未完成任务 大量的缺陷 严重的缺陷 不完整的测试环境 资源短缺,9测试完成所提交的材料 测试完成所提交的材料包含了测试工作开发设计的所有文档、工具等。例如，测试计划、测试设计规格说明、测试用例、测试日志、测试数据、自定义工具、测试缺陷报告和测试总结报告等。,10测试任务 测试计划中这一部分给出了测试工作所需完成的一系列任务。在这里还列举了所有任务之间的依赖关系和可能需要的特殊技能。,11环境需求 环境需求是确定实现测试策略必备条件的过程。例如：人员人数、经验和专长。他们是全职、兼职、业余还是学生？设备计算机、测试硬件、打印机、测试工具等。,办公室和实验室空间在哪里？空间有多大？怎样排列？软件字处理程序、数据库程序和自定义工具等。其他资源软盘、电话、参考书、培训资料等。,12测试人员的工作职责 测试人员的工作职责是明确指出了测试任务和测试人员的工作责任。有时测试需要定义的任务类型不容易分清，不像程序员所编写的程序那样明确。复杂的任务可能有多个执行者，或者由多人共同负责。,13人员安排与培训需求 前面讨论的测试人员的工作职责是指哪类人员（管理、测试和程序员等）负责哪些任务。人员安排与培训需求是指明确测试人员具体负责软件测试的哪些部分、哪些可测试性能，以及他们需要掌握的技能等。实际责任表会更加详细，确保软件的每一部分都有人进行测试。每一个测试员都会清楚地知道自己应该负责什么，而且有足够的信息开始设计测试用例。,培训需求通常包括学习如何使用某个工具、测试方法、缺陷跟踪系统、配置管理，或者与被测试系统相关的业务基础知识。培训需求各个测试项目会各不相同，它取决于具体项目的情况。,14进度表 测试进度是围绕着包含在项目计划中的主要事件（如文档、模块的交付日期，接口的可用性等）来构造的。作为测试计划的一部分，完成测试进度计划安排，可以为项目管理员提供信息，以便更好地安排整个项目的进度。,表6-4给出了一个例子。,进度安排会使测试过程容易管理。通常，项目管理员或者测试管理员最终负责进度安排，而测试人员参与安排自己的具体任务。,15潜在的问题和风险 软件测试人员要明确地指出计划过程中的风险，并与测试管理员和项目管理员交换意见。这些风险应该在测试计划中明确指出，在进度中予以考虑。有些风险是真正存在的，而有些最终证实是无所谓的，重要的是尽早明确指出，以免在项目晚期发现时感到惊慌。,一般而言，大多数测试小组都会发现自己的资源有限，不可能穷尽测试软件所有方面。如果能勾画出风险的轮廓，将有助于测试人员排定待测试项的优先顺序，并且有助于集中精力去关注那些极有可能发生失效的领域。下面是一些潜在的问题和风险的例子：,不现实的交付日期 与其他系统的接口 处理巨额现金的特征 极其复杂的软件 有过缺陷历史的模块 发生过许多或者复杂变更的模块 安全性、性能和可靠性问题 难于变更或测试的特征,风险分析是一项十分艰巨的工作，尤其是第一次尝试进行时更是如此，但是以后会好起来，而且也值得这样做。,16审批 审批人应该是有权宣布已经为转入下一个阶段做好准备的某个人或某几个人。测试计划审批部分一个重要的部件是签名页。审批人除了在适当的位置签署自己的名字和日期外，还应该签署表明他们是否建议通过评审的意见。,6.4 测试的组织与人员管理,6.4.1 测试的组织与人员管理概述 测试项目成功完成的关键因素之一就是要有高素质的软件测试人员，并将他们有效地组织起来，分工合作，形成一支精干的队伍，使他们发挥出最大的工作效率。,测试的组织与人员管理就是对测试项目相关人员在组织形式、人员组成与职责方面所做的规划和安排。测试的组织与人员管理的任务是：（1）为测试项目选择合适的组织结构模式；（2）确定项目组内部的组织形式；（3）合理配备人员，明确分工和责任；（4）对项目成员的思想、心理和行为进行有效地管理，充分发挥他们的主观能动性，密切配合实现项目的目标。,测试的组织与人员管理应注意的原则是：（1）尽快落实责任 从软件的生存周期看，测试往往指对程序的测试，但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。实际上，测试的准备工作在分析和设计阶段就开始了，在软件项目的开始就要尽早指定专人负责，让他有权去落实与测试有关的各项事宜。,（2）减少接口 要尽可能地减少项目组内人与人之间的层次关系，缩短通信的路径，方便人员之间的沟通，提高工作效率。（3）责任明确、均衡 项目组成员都必须明确自己在项目组中的地位、角色和职责，各成员所负的责任不应比委任的权力大，反之亦然。,6.4.2 测试人员的组织结构 组织结构是指用一定的模式对责任、权威和关系进行安排，直至通过这种结构发挥功能。测试组织结构设计时主要考虑以下因素。垂直还是平缓 集中还是分散 分级还是分散 专业人员还是工作人员 功能还是项目,选择合理高效的测试组织结构方案的准则是：（1）提供软件测试的快速决策能力；（2）利于合作，尤其是产品开发与测试开发之间的合作；（3）能够独立、规范、不带偏见地运作并具有精干的人员配置；,（4）有利于满足软件测试与质量管理的关系；（5）有利于满足软件测试过程管理要求；（6）有利于为测试技术提供专有技术；（7）充分利用现有测试资源，特别是人；（8）对测试者的职业道德和事业产生积极的影响。,进行软件测试的测试组织结构形式很多，目前常见的测试组织结构有独立的测试小组和集成的测试小组两种形式。,1独立测试小组 独立的测试小组，即主要工作是进行测试的小组，他们专门从事软件的测试工作。测试组设组长一名，负责整个测试的计划、组织工作。测试组的其他成员由具有一定的分析、设计和测试经验的专业人员组成，人数根据具体情况可多可少，一般35人为宜。测试组长与开发组长在项目中的地位是同级、平等的关系。,2集成测试小组 集成测试小组是将测试与基本设计因素组合起来，构成的测试组织结构。这是与独立测试有关的一种集成测试组织形式，即集成测试小组是由需要向同一个项目经理汇报工作的测试人员和开发人员组成。,6.4.3 测试人员 测试人员的能力应包括以下几项。（1）一般能力：包括表达、交流、协调、管理、质量意识、过程方法、软件工程等；（2）测试技能及方法：包括测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等；,（3）测试规划能力：包括风险分析及防范、软件放行/接收准则制定、测试目标及计划、测试计划和设计的评审方法等；（4）测试执行能力：包括测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具；（5）测试分析、报告和改进能力：包括测试度量、统计技术、测试报告、过程监测及持续改进。,测试组织管理者的工作能力在很大程度上决定测试工作的成功与否，测试管理是很困难的，测试组织的管理者必须具备：（1）了解与评价软件测试政策、标准、过程、工具、培训和度量的能力；（2）领导一个测试组织的能力，该组织必须坚强有力、独立自主、办事规范且没有偏见；,（3）吸引并留住杰出测试专业人才的能力；（4）领导、沟通、支持和控制的能力；（5）有提出解决问题方案的能力；（6）测试时间、质量和成本控制的能力。,6.4.4 人员的通信方式 人员的沟通、交流方式主要有：（1）正式非个人方式，如正式会议等；（2）正式个人之间交流，如成员之间的正式讨论等（一般不形成决议）；（3）非正式个人之间交流，如个人之间的自由交流等；,（4）电子通信，如E-mail（电子邮件）、BBS（电子公告板系统）等；（5）成员网络，如成员与小组之外或公司之外有经验的相关人员进行交流；在实践中发现，（5）的通信效率最高，其次是（1）。,6.4.5 测试人员管理的激励机制 激励，简单地说就是调动人的工作积极性，把潜力充分发挥出来。在管理学中，激励是指管理者促进、诱导下属形成动机，并引导其行为指向特定目标的活动过程。激励机制在测试组织建设中十分重要，测试组织的管理者不仅把测试人员组织在一起，团结在一起工作，更重要的是要善于调动测试人员的工作热情，激励每个成员都努力工作，实现项目的目标。测试人员管理的激励机制的关键点是：,管理者习惯用对自己有效的因素激励测试人员，很可能发现无效；过多行使权力、资金或处罚手段很可能导致项目失败；注意采取卓有成效的非货币形式的激励措施；在项目进行过程中，而不仅是在项目结果时实施激励措施；,奖励应该在工作获得认同后尽快兑现；对项目成员的工作表现出真诚的兴趣，是对他们最好的奖励；已经满足的需要很可能不再成为激励因素。激励因素是影响个人行为的东西，是因人而异、因时而异的。因此，管理者必须明确各种激励的方式，并合理使用。,作为测试人员，测试工件的7条效率原则是：主动思考，积极行动；一开始就牢记目标，不迷失方向；重要的事情放在首位（但常常把紧急的事情放在首位）；先理解人，后被人理解；寻求双赢；互相合作，追求1+12；终生学习，自我更新，不断进步。,6.4.6 测试人员的培训 如今，计算机软、硬件技术发展十分迅速，测试人员必须有足够的能力来适应这些变化。而另一方面，测试工作本身是一门需要技术的学问，它包含了众多的理论和实践。缺乏这些知识和经验，测试的深度和广度就不够，测试的质量就无法保证。从测试管理的角度来说，为了高效地实现测试工作的目标，需要不断地帮助他们进行知识的更新和技术能力的提升，这些就需要通过培训来达到。,1软件测试培训内容2制定测试人员培训计划,6.4.7 测试的组织与人员管理中的风险管理 在进行测试的组织与人员管理时，我们往往重视招聘、培训、考评、薪资等各个具体内容的操作，而忽视了其中的风险管理问题。,其实，每个公司在人事管理中都可能遇到风险，如招聘失败、新政策引起员工不满、技术骨干突然离职等等，这些事件会影响公司的正常运转，甚至会对公司造成致命的打击。如何防范这些风险的发生，是我们应该研究的问题。特别是高新技术企业，由于对人的依赖更大，所以更需要重视测试的组织与人员管理中的风险管理。,6.5 软件测试过程管理,6.5.1 测试项目的跟踪与监控软件测试和软件开发一样，都遵循软件工程的原理，有它自己的生命周期。软件的测试过程管理基于广泛采用的“V”模型。“V”模型支持系统测试周期的任何阶段。,基于“V”模型，在开发周期中的每个阶段都 有相关的测试阶段相对应，测试可以在需求分析阶段就及早开始，创建测试的准则。每个阶段都存在质量控制点，对每个阶段的任务、输入和输出都有明确的规定，以便对整个测试过程进行质量控制和配置管理。,根据质量管理中PDCA质量环的思想，需要对软件测试过程进行跟踪、检查，并与测试计划进行对比。测试计划中描述了如何实施和管理软件的测试过程，测试计划经批准生效后，将被用来作为对测试过程跟踪与监控的依据。测试项目的跟踪与监控的基础是软件测试计划。,在具体的测试项目的跟踪与监控过程中，可以采用周报、日报、例会，以及里程碑评审会等方式来了解测试项目的进展情况，建立、收集和分析项目的实际状态数据，对项目进行跟踪与监控，达到项目管理的目的。基于可靠的信息，明智的和有意义的决策可以很好地管理测试过程，在测试过程的每个阶段，测试项目管理人员应特别注意需要弄清楚以下问题：,系统现在是否做好测试准备？如果系统开始测试会有什么样的风险？当前测试所达到的覆盖率是怎样的？到目前为止取得了哪些成功？还要哪些测试要做？怎么证明系统已经经过了有效的测试？有哪些变更，哪些必须重新测试？,6.5.2 测试的配置管理 配置管理的目的是建立和维护在软件生命周期中软件产品的完整性和一致性。一般来说，软件测试配置管理包括4个最基本的活动：（1）配置标识；（2）变更控制；（3）配置状态报告；（4）配置审计。,1配置标识 配置标识是配置管理的基础。所有配置项的操作权限都应当严格管理，其基本原则是：所有基线配置项向测试人员开放读取权限；而非基线配置项向测试组长、项目经理及相关人员开放。,配置标识主要是标识测试样品、测试标准、测试工具、测试文档（包括测试用例）、测试报告等配置项的名称和类型。所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定部分记录对象的标识信息，标识各配置项的所有者及储存位置，指出何时基准化配置项（置于基线控制之下），这样使得测试相关人员能方便地知道每个配置项的内容和状态。,2变更控制 变更控制的目的并不是控制和限制变更的发生，而是对变更进行有效的管理，确保变更有序地进行。,变更控制主要包括以下内容。（1）规定测试基线，对每个基线必须描述下列内容：每个基线的项（包括文档、样品和工具等）；与每个基线有关的评审、批准事项以及验收标准。,（2）规定何时何人创立新的基线，如何创立；（3）确定变更请求的处理程序和终止条件；（4）确定变更请求的处理过程中各测试人员执行变更的职能；（5）确定变更请求和所产生结果的对应机制；（6）确定配置项提取和存入的控制机制与方式。,3配置状态报告 配置状态报告就是根据配置项操作数据库中的记录，来向管理者报告软件测试工作的进展情况。配置状态报告应该包括以下主要内容：（1）定义配置状态报告形式、内容和提交方式；（2）确认过程记录和跟踪问题报告，更改请求，更改次序等；（3）确定测试报告提交的时间与方式。,4配置审计配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实地执行和实现。配置审计包括以下主要内容：（1）确定审计执行人员和执行时机；（2）确定审计的内容与方式；（3）确定发现问题的处理方法。,6.5.3 软件测试风险管理1风险的基本概念 风险可定义为“伤害、损坏或损失的可能性；一种危险的可能或一种冒险事件。”风险涉及到一个事件发生的可能性，涉及到该事件产生的不良后果或影响。软件风险是指开发不成功引起损失的可能性，这种不成功事件会导致公司商业上的失败。风险分析是对软件中潜在的问题进行识别、估计和评价的过程。软件测试中的风险分析是根据测试软件将出现的风险，制定软件测试计划，并排列优先等级。,软件风险分析的目的是确定测试对象、测试优先级，以及测试的深度。有时还包括确定可以忽略的测试对象。通过风险分析，测试人员识别软件中高风险的部分，并进行严格彻底地测试；确定潜在的隐患软件构件，对其进行重点测试。在制定测试计划的过程中，可以将风险分析的结果用来确定软件测试的优先级与测试深度。,2软件测试与商业风险 软件测试是一种用来尽可能降低软件风险的控制措施。软件测试是检测软件开发是否符合计划，是否达到预期的结果的测试。如果检测表明软件的实现没有按照计划执行，或与预期目标不符，就要采取必要的改进行动。因此，公司的管理者应该依靠软件测试之类的措施来帮助自己实现商业目标。,3软件风险分析 风险分析是一个对潜在问题识别和评估的过程，即对测试的对象进行优先级划分。风险分析包括以下两个部分。发生的可能性：发生问题的可能性有多大。影响的严重性：如果问题发生了会有什么后果。,通常风险分析采用两种方法：表格分析法和矩阵分析法。通用的风险分析表包括以下几项内容。（1）风险标识：表示风险事件的惟一标识；（2）风险问题：风险问题发生现象的简单描述；（3）发生可能性：风险发生可能性的级别（110）；,（4）影响的严重性：风险影响的严重性的级别（110）；（5）风险预测值：风险发生可能性与风险影响的严重性的乘积；（6）风险优先级：风险预测值从高向低的排序。,综上所述，软件风险分析的目的是：确定测试对象、确定优先级，以及测试深度。在测试计划阶段，可以用风险分析的结果来确定软件测试的优先级。对每个测试项和测试用例赋予优先代码，将测试分为高、中和低的优先级类型，这样可以在有限的资源和时间条件下，合理安排测试的覆盖度与深度。,4软件测试风险 软件测试的风险是指软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，造成测试的补充以及结果不准确。测试的不成功导致软件交付潜藏着问题，一旦在运行时爆发，会带来很大的商业风险。,主要是对测试计划执行的风险分析与制定要采取的应急措施，降低软件测试产生的风险造成的危害。测试计划的风险一般指测试进度滞后或出现非计划事件，就是针对计划好的测试工作造成消极影响的所有因素，对于计划风险分析的工作是制定计划风险发生时应采取的应急措施。,其中，交付日期的风险是主要风险之一。测试未按计划完成，发布日期推迟，影响对客户提交产品的承诺，管理的可信度和公司的信誉都要受到考验，同时也受到竞争对手的威胁。交付日期的滞后，也可能是已经耗尽了所有的资源。计划风险分析所做的工作重点不在于分析风险产生的原因，重点应放在提前制定应急措施来应对风险发生。当测试计划风险发生时，可能采用的应急措施有：缩小范围、增加资源、减少过程等措施。,将采用的应急措施如下。应急措施1：增加资源。请求用户团队为测试工作提供更多的用户支持。应急措施2：缩小范围。决定在后续的发布中，实现较低优先级的特性。应急措施3：减少质量过程。在风险分析过程中，确定某些风险级别低的特征测试，或少测试。,上述列举的应急措施要涉及到有关方面的妥协，如果没有测试计划风险分析和应急措施处理风险，开发者和测试人员采取的措施就比较匆忙，将不利于将风险的损失控制到最小。因此，软件风险分析和测试计划风险分析与应急措施是相辅相成的。,由上面分析可以看出，计划风险、软件风险、重点测试、不测试，甚至整个软件的测试与应急措施都是围绕“用风险来确定测试工作优先级”这样的原则来构造的。软件测试存在着风险，如果提前重视风险，并且有所防范，就可以最大限度减少风险的发生。在项目过程中，风险管理的成功取决于如何计划、执行与检验每一个步骤。遗漏任何一点，风险管理都不会成功。,6.5.4 软件测试的成本管理对于一般项目，项目的成本主要由项目直接成本、管理费用和期间费用等构成。,当一个测试项目开始后，就会发生一些不确定的事件。测试项目的管理者一般都在一种不能够完全确定的环境下管理项目，项目的成本费用可能出现难以预料的情况，因此，必须有一些可行的措施和办法，来帮助测试项目的管理者进行项目成本管理，即依据实际预算制定项目计划，实施整个项目生命周期内的成本度量和控制。,1测试费用有效性 风险承受的确定，从经济学的角度考虑就是确定需要完成多少测试，以及进行什么类型的测试。经济学所做的判断，确定了软件存在的缺陷是否可以接受，如果可以，能承受多少。测试的策略不再主要由软件人员和测试人员来确定，而是由商业的经济利益来决定的。,“太少的测试是犯罪，而太多的测试是浪费。”对风险测试得过少，会造成软件的缺陷和系统的瘫痪；而对风险测试得过多，就会使本来没有缺陷的系统进行没有必要的测试，或者是对轻微缺陷的系统所花费的测试费用远远大于它们给系统造成的损失。,测试费用的有效性，可以用测试费用的质量曲线来表示，如图6-1所示。随着测试费用的增加，发现的缺陷也会越多，两线相交的地方是过多测试开始的地方，这时，排除缺陷的测试费用超过了缺陷给系统造成的损失费用。,图6-1 测试费用的质量曲线,2测试成本控制 测试成本控制也称为项目费用控制，就是在整个测试项目的实施过程中，定期收集项目的实际成本数据，与成本的计划值进行对比分析，并进行成本预测，及时发现并纠正偏差，使项目的成本目标尽可能好地实现。,测试工作的主要目标是使测试产能最大化，也就是，要使通过测试找出错误的能力最大化，而检测次数最小化。测试的成本控制目标是使测试开发成本、测试实施成本和测试维护成本最小化。在软件产品测试过程中，测试实施成本主要包括：测试准备成本、测试执行成本和测试结束成本。,（1）测试准备成本控制（2）测试执行成本控制,对部分重新测试进行合理的选择，将风险降至最低，而成本同样会很高，必须将其与测试执行成本进行比较，权衡利弊。利用测试自动化，进行重新测试，其成本效益是较好的。部分重新测试选择方法有两种：对由于程序变化而受到影响的每一部分进行重新测试；对与变化有密切和直接关系的部分进行重新测试。,（3）测试结束成本控制（4）降低测试实施成本（5）降低测试维护成本 降低测试维护成本，与软件开发过程一样，加强软件测试的配置管理，所有测试的软件样品、测试文档（测试计划、测试说明、测试用例、测试记录、测试报告）都应置于配置管理系统控制之下。降低测试维护工作成本主要考虑：,对于测试中出现的偏差要增加测试；采用渐进式测试，以适应新变化的测试；定期检查维护所有测试用例，以获得测试效果的连续性。,保持测试用例效果的连续性是重要的措施，有以下几个方面：每一个测试用例都是可执行的，即被测产品功能上不应有任何变化；基于需求和功能的测试都应是适合的，若产品需求和功能发生小的变化，不应使测试用例无效；每一个测试用例不断增加使用价值，即每一个测试用例不应是完全冗余的，连续使用，应是成本效益高的。,3质量成本 测试是一种带有风险性的管理活动，可以使企业减少因为软件产品质量低劣，而花费不必要的成本。,（1）质量成本要素质量成本要素主要包括一致性成本和非一致性成本。一致性成本是指用于保证软件质量的支出，包括预防成本和测试预算，如测试计划、测试开发、测试实施费用。,非一致性成本是由出现的软件错误和测试过程故障（如延期、劣质的发布）引起的。这些问题会导致返工、补测、延迟。追加测试时间和资金就是一种由于内部故障引起的非一致性成本。非一致性成本还包括外部故障（软件遗留错误影响客户）引起部分。一般情况下，外部故障非一致性成本要大于一致性成本与内部故障非一致性成本之和。,（2）质量成本计算质量成本一般按下式计算：质量成本=一致性成本+非一致性成本,4缺陷探测率缺陷探测率是另一个衡量测试工作效率的软件质量成本的指标。缺陷探测率=测试发现的软件缺陷数/(测试发现的软件缺陷数+客户发现并反馈技术支持人员进行修复的软件缺陷数),测试投资回报率可按下式计算：投资回报率=(节约的成本 利润)/测试投资100%,