【文档说明】软件测试技术第七章软件测试管理课件.pptx，共(100)页，553.644 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-50390.html

以下为本文档部分文字说明：

第七章软件测试管理第1页/共100页第1页，共100页。目录•7.1软件质量管理•7.2软件评审•7.3软件测试计划•7.4测试文档管理•7.5软件配置管理•7.6测试结束的原则第2页/共100页第2

页，共100页。7.1软件质量管理7.1.1软件质量特性软件质量的定义：不同的标准化组织在不同的时期都给出过多种对软件质量的定义，能够被普遍接受的观点是：软件质量是与软件系统或软件产品满足明确或隐含需求的能力有关的特征和特性的集合。第3页/共100页第3页，共100页。

软件质量的特征•软件需求是度量软件质量的基础。•软件质量既要保证明确的用户需求，也要保证隐含的用户需求。•软件质量反映的是软件的综合特征与用户期望。第4页/共100页第4页，共100页。软件测试管理质量模型•McCall质量模型McCall模型是提出

最早的一种质量模型，由McCall等人于1979年在改进更为早期的Boehm质量模型的基础上提出。McCall模型的价值在于对影响软件质量的众多因素进行了归纳与分类，便于使用者从全局角度理解和控制软件质量。第5页/共100页第5页，共100页。McCall质量模型示意图图7-1McC

all质量模型软件运行软件转移软件修正可维护性可测试性灵活性可移植性可复用性互连性正确性可靠性效率完整性可用性第6页/共100页第6页，共100页。•ISO/IEC9126质量模型ISO/IEC9126质量模型是一种评价软件质量的通用模型。最初于1991年发布，主要面向软件质量特性和产品评

价，1997年之后经过修订提出了新的面向产品质量度量和质量模型的ISO9126系列标准，ISO9126系列标准描述了软件评估过程的模型，定义了6种主要质量特性。第7页/共100页第7页，共100页。•IS

O/IEC9126从以下3个方面来评价软件产品的质量：•内部质量。指软件产品在规定条件下使用时满足明确的和隐含的需求的能力•外部质量。是从软件产品外部角度出发所观察到的软件总体特性(并不涉及软件内部)•使用质量。是从用户的角度出发所观察到的软件在特定使用

环境下满足需求的程度第8页/共100页第8页，共100页。ISO9126标准：•ISO9126-1：质量模型图7-2ISO/IEC9126软件质量模型内部质量外部质量使用质量影响依赖依赖影响软件产品质量内部度量外部度量使用质量度量使用环境第9页/共100页第9页，共

100页。•ISO9126-2：外部质量度量。•ISO9126-3：内部质量度量。ISO9126的主要部分是外部和内部质量模型，如图7-3所示。由6个质量特性和27个质量子特性构成。第10页/共100页第10页，共100页。

图7-3ISO9126内部和外部质量的质量模型内部质量和外部质量可移植性可维护性效率易用性可靠性功能性1、适合性2、准确性3、互操作性4、安全保密性5、功能性的依从性1、成熟性2、容错性3、易恢复性4、可靠性的依从性1、易理解性2、易学性3、易操作性4、吸引性

5、易用性的依从性1、时间特性2、资源利用性3、效率依从性1、易分析性2、易改变性3、稳定性4、易测试性5、维护性的依从性1、适应性2、易安装性3、共存性4、易替换性5、可移植性的依从性第11页/共100页第11页，共100页。•ISO

9126-4：使用质量度量。软件使用质量包含以下4个质量特征：有效性：软件在特定环境下达到准确性和完备性目标的能力。生产性：用户为达到有效性而消耗适当数量的资源的能力，例如完成任务的时间、工作量、材料、财务费用等。安全性：软件

可能造成损害的可接受的风险级别。满意度：用户对软件产品的满意程度，包括对软件产品的意见。第12页/共100页第12页，共100页。7.1.2软件质量标准与管理体系1、软件质量标准的层次软件质量标准一般分为如下5个层次：国际标准

：由国际机构制定和公布的标准。典型的软件质量国际标准包括ISO/IEC12119，ISO/IEC9126，ISO/IEC14598，ISO/IECSQuaRE系列标准。第13页/共100页第13页，共100页。•国家标准：由国家机构制定或批准，只适用于本国范围的标准。如我国标准简称

为“国标GB”。•行业标准：由行业协会、学术团体或国防机构制定的适用于某个业务领域的标准，例如电子和电气工程师协会IEEE等。•企业规范：一些大型企业或公司单独或联合制定的规范。•项目规范：专门为特定软件项目制定的操作规范。第14页/共100页第1

4页，共100页。2、主要的软件质量管理体系国内软件企业所采用的软件质量管理体系主要是ISO9000和CMM/CMMI两种。常见的质量管理体系如表7-1所示。第15页/共100页第15页，共100页。名称制定者适用领域简要说明ISO9000国际标准，ISO/TC

所有行业其中ISO9000-3是针对软件开发行业的标准实施指南CMM软件行业标准，卡耐基-梅隆大学制定并管理软件行业分为5个等级，CMMI是CMM的新版本，选择CMM/CMMI认证的美国软件企业较多ISO

15504（SPICE）国际标准，ISO/TC所有行业软件过程评估标准，起源于软件过程改进和能力测定（SPICE，SoftwareProcessImprovementandCapabilityDeterminat

ion）项目六西格玛（SixSigma）行业标准，最早由摩托罗拉公司提出所有行业不只关注质量，还关注成本、进度等，面向全面管理。以质量为主线，以客户需求为中心，利用对事实和数据的分析改进业务流程TickIT软件行业标准，由英国工贸部DTI发起软件行业目的是推动IT企业通过ISO9000质量认证，

TickIT基于ISO9001，选择ISO9001/TickIT认证的欧洲软件企业较多表7-1常见的质量管理体系第16页/共100页第16页，共100页。•ISO9000ISO9000是一个质量管理系列标准，为了应用于软件开发行业，ISO专门制

定出ISO9000-3标准，也就是将ISO9000-3作为软件企业实施ISO9001的指南。ISO的核心内容主要包括合同评审、需求规格说明、开发计划、质量计划、设计和实现、测试和确认、验收、复制、交付与安装以及维护的相关标准。第17页/共100页第17页，共100页。•CMM（

CapabilityMaturityMode）能力成熟度模型CMM的实用性在于将软件过程改进步骤划分为逐步成熟的、阶梯式的5个等级（如图7-4所示），以便于软件企业根据阶段目标不断对软件开发和维护进行

过程监控和研究，使其更加科学化、标准化。图7-4CMM过程成熟度级别初始级可重复级优化级基本的管理控制已管理级已定义级过程定义过程度量过程控制第18页/共100页第18页，共100页。CMM的5个等级的基本特征•初始级（Initial）：只有少量过程经过了严格

定义。•可重复级（Repeatable）：初步实现了标准化。第19页/共100页第19页，共100页。•已定义级（Defined）：已实现标准化、文档化。•已管理级（Managed）：产品和过程已经建立了定量的质量目标。•优化级（Optimizing）：已具备持续不断地改进软件开发过程的

能力。第20页/共100页第20页，共100页。•CMM的五个等级与软件产品潜在缺陷密度和缺陷清除率的关系如表7-2.CMM等级潜在缺陷密度缺陷清除率（%）被交付的缺陷15.00850.7524.00890.4433.

00910.2742.00930.1451.00950.05表7-2CMM级别、潜在缺陷密度与缺陷清除率第21页/共100页第21页，共100页。除了CMM1之外，CMM的每一个等级都给出了若干关键过程域KPA，用以达到相应的过程改进目标。

CMM2的KPA：软件质量保证（SQA，SoftwareQualityAssurance）方法。CMM3的KPA：同行评审（PR，PeerReviews）方法。CMM4的KPA：软件质量管理（SQM，SoftwareQuality

Management）方法。CMM5的KPA：缺陷预防（DP，DefectPrevention）方法。第22页/共100页第22页，共100页。3、主要软件质量管理体系的区别与联系ISO9001与CMM的联系：•都以全面质量管理为理论基础，以提高软件质量管理水平为目标，强调管理过程的规范化和文

档化。•都强调“该说的要说到，说到就要做到”，即对每个重要过程都要形成文件，并检查交付物的质量水平。第23页/共100页第23页，共100页。•ISO9001和CMM的不同之处•基础不同：ISO9001确定了一个合格质量管理体系的最低

可接受水平，而CMM更为强调持续过程改进。•范围有所区别：ISO9001的范围包括软硬件、流程性材料和服务，CMM严格聚焦于软件。第24页/共100页第24页，共100页。•不能简单替代：一些ISO9001质量要求在CMM中不存在，反之亦然，另外一些要求是分散对应的。•层次不同：ISO9000认

证的结果只有“通过”和“不通过”两种，而CMM的评价分为5级第25页/共100页第25页，共100页。CMM和CMMI的主要不同之处：•CMMI更为适用于硬件开发、系统集成的大型软件企业。对于规模不大，业务集中于软件开发的企业来讲CMM

比较适用。•CMMI有阶段式和连续式的表现方法，而CMM只有阶段式的表现方法。第26页/共100页第26页，共100页。•CMMI对原有CMM的关键过程区域KPA进行了更为详细的拆分和扩充，并结合常见的软件生命周期模型进行了映射。•CMM在软件

方面的要求比CMMI略低，实施难度和过程改进的费用也要小一些。第27页/共100页第27页，共100页。7.2软件评审1、软件评审的重要性软件评审的作用软件评审是为了验证软件开发和软件测试各个阶段的工作是否已经阶段性地

达到了规定的技术和质量要求，然后决定能否转入下一阶段的工作。因此，通过软件评审可以建立软件项目管理过程中的重要里程碑，是软件质量控制和保障的重要手段之一。第28页/共100页第28页，共100页。软件评审的阶段划分•根据软件开发和测试阶段划分评审阶段

可以分为软件需求评审、设计评审、测试计划评审、编码和单元测试评审、集成测试评审、系统测试评审、验收测试评审等。•根据评审的对象划分根据评审的对象划分为管理评审、技术评审、文档评审和流程评审。第29页/共100页第29页，共100页。软件评审对缺陷分布的影响图7-

5软件评审对缺陷分布的影响据统计软件评审可以找出4/5的软件缺陷，软件评审能够尽早发现软件缺陷，避免将大量软件缺陷遗留到测试执行阶段才去发现与修复。缺陷数量软件发布时间需求分析阶段设计阶段执行测试阶段编码阶段具有阶段性软件评审缺乏软件评审第30页/共100页第

30页，共100页。尽早发现软件缺陷的作用（1）减少软件缺陷的数量软件缺陷具有“弥漫和放大”效应。软件研发由一系列阶段组成，前期阶段的某一软件缺陷会造成后期阶段更多数量的缺陷，尽早发现软件缺陷将缺陷的数量尽可能控制在最小范围之内，避免后期阶段缺陷数量的膨胀。第31页/共100页第31页，共100

页。（2）降低修复软件缺陷的成本如图7-6所示，不同软件研发阶段修复软件缺陷的成本差异很大。图7-6研发各个阶段软件缺陷修复成本对比缺陷修复成本软件研发阶段需求分析总体设计详细设计程序编码单元测试集成测试系统

测试软件发布后1361015225040~1000第32页/共100页第32页，共100页。2、软件评审的方法软件评审在各个软件企业的形式不同，不同的形式之间并没有本质的区别，只存在以下正式和非正式的差别。•正式的软件评审：以评审会议的形式进行，由评审组长

和相关开发与测试人员组成，通过会议准备、设定评审原则、召开会议、评审分析、给出过程改进意见、形成正式的问题总结与记录等环节完成软件评审。第33页/共100页第33页，共100页。•非正式软件评审:相关的评审人员通过邮件接收评审内容，分散阅

读并提出书面意见，或者是以非正式会议的形式对评审对象进行检查。非正式评审仍然需要形成评审记录，由评审人员签字以体现各自责任。第34页/共100页第34页，共100页。软件评审的评审技术（1）缺陷检查表缺陷

检查表是最为常用的评审工具，根据经验列出了最有可能发生的软件缺陷。通过缺陷检查表驱动评审过程可以更为准确地确定评审范围，提高评审的质量和效率。第35页/共100页第35页，共100页。（2）场景分析场景分析法多在需求评审时应用，在评审过程中采用分层评审、分

类评审和分阶段评审的方法。分层评审。从评审对象的高层内容向低层细节内容逐步推进进行评审。分类评审。对评审对象的各类主要内容分别进行评审，适用于对大多数软件开发阶段的评审。分阶段评审。即进行多次评审，以降低评审的难度，提高评审的质量。第36页/共100页

第36页，共100页。7.3软件测试计划7.3.1对于测试计划的基本认识1、测试计划的目的与作用测试计划是为了确定各个测试阶段的目标和策略，明确需要完成的测试活动，合理安排测试所需要的时间和资源，说明完成测试的组织结构和岗位职责，确定对测试过程及其结果进行控制和测量所需要的方法和活动，

识别测试风险。第37页/共100页第37页，共100页。制定测试计划的主要作用：•体现软件测试管理的主要目标。•便于进行测试管理。•建立对测试结果的客观评价标准。•有利于及早发现软件需求方面的问题。•便于软件项目人员的沟通与理解。第38页/共100页第38页，共100页。2、编写测试计

划的注意事项（1）根据软件项目的规模与特点确定单独编写测试计划还是为每个测试阶段分别编写测试计划（2）做好测试需求分析（3）增强测试计划的实用性（4）在测试计划中体现What、Why、When、Where、Who、How的“5W1H

”规则。第39页/共100页第39页，共100页。7.3.2测试计划的主要内容完整测试计划的主要内容应该包括界定测试范围、确定具体的测试策略、分析测试风险、规划测试资源、制定测试进度等。表7-3所示IEE

E829-2008标准规定的测试计划大纲来制定测试计划。第40页/共100页第40页，共100页。表7-3IEEE829-2008软件测试计划大纲主测试计划纲要阶段测试计划纲要MasterTestPlanOutline1.Introduction1.1.Documentident

ifier1.2.Scope1.3.References1.4.Systemoverviewandkeyfeatures1.5.Testoverview1.5.1Organization1.5.2Mastertestschedule1.5.3Integritylevelschema1.5.4Res

ourcessummary1.5.5Responsibilities1.5.6Tools，techniques，methods，andmetrics2.DetailsoftheMasterTestPl

an2.1.Testprocessesincludingdefinitionoftestlevels2.1.1Process:Management2.1.1.1Activity:Managementoftesteffort2.1.2Process:AcquisitionLevelTestPlanO

utline1.Introduction1.1.Documentidentifier1.2.Scope1.3.References1.4.Levelintheoverallsequence1.5.Testclassesandoveralltestconditions2.Detai

lsforthisleveloftestplan2.1Testitemsandtheiridentifiers2.2TestTraceabilityMatrix2.3Featurestobeteste

d2.4Featuresnottobetested2.5Approach2.6Itempass/failcriteria2.7Suspensioncriteriaandresumptionrequirements2

.8Testdeliverables3.Testmanagement3.1Plannedactivitiesandtasks；testprogression第41页/共100页第41页，共100页。1.5.5Responsibilities1

.5.6Tools，techniques，methods，andmetrics2.DetailsoftheMasterTestPlan2.1.Testprocessesincludingdefinitionoftestle

vels2.1.1Process:Management2.1.1.1Activity:Managementoftesteffort2.1.2Process:Acquisition2.1.2.1:Activity:Acquis

itionsupporttest2.1.3Process:Supply2.1.3.1Activity:Planningtest2.1.4Process:Development2.1.4.1Activity:Concept2.1.4.2Activity:Requiremen

ts2.1.4.3Activity:Design2.1.4.4Activity:Implementation2.1.4.5Activity:Test2.1.4.6Activity:Installation/checkout2.1.5P

rocess:Operation2.1.5.1Activity:Operationaltest2.1.6Process:Maintenance2.1.6.1Activity:Maintenancetest2.2.Testdocumentationrequirements2.3.Testadmini

strationrequirements2.4.Testreportingrequirements3.General3.1.Glossary3.2.Documentchangeproceduresandhistory2.4Featuresnottobetested2.5Approach2.6Ite

mpass/failcriteria2.7Suspensioncriteriaandresumptionrequirements2.8Testdeliverables3.Testmanagement3.1Plannedactivitiesandtasks；testprog

ression3.2Environment/infrastructure3.3Responsibilitiesandauthority3.4Interfacesamongthepartiesinvolved3.5Resourcesandtheiralloca

tion3.6Training3.7Schedules，estimates，andcosts3.8Risk(s)andcontingency(s)4.General4.1Qualityassuranceprocedures4.2Met

rics4.3Testcoverage4.4Glossary4.5Documentchangeproceduresandhistory续表7-3IEEE829-2008软件测试计划大纲第42页/共100页第42页，共100页。测试计划的概要说明（1）测

试计划概要：概况性地描述被测软件的基本情况。（2）测试目标：对整体测试目标、各阶段的测试目标、测试对象以及约束进行简要说明。（3）测试范围：说明软件的哪些功能和性能需要被测试到，重点列出需要测试的主要功能和软件关键特性，与测试用例的设计相对应并互相检查。第43页/共1

00页第43页，共100页。（4）测试策略：测试策略是测试计划中最为核心的内容，规定了对测试对象进行测试的推荐方法。测试策略的作用:①确保测试根据测试任务的特点选择合适的测试方法和手段。第44页/共100页第44页，共100页。④测试策略规定了判定测试有

效性的准则。⑤测试策略考虑了何时采用手工测试、何时采用自动化测试以及采用什么测试工具，因此可以提高测试的效率。⑥通过制定测试策略可以使项目组成员对如何完成测试达成一致意见。第45页/共100页第45页，

共100页。测试策略制定的主要步骤：①分析测试输入。②确定测试需求。③确定测试优先级。④制定具体策略。常见的测试策略有基于测试技术的测试策略、基于测试方案的测试策略和基于缺陷分析的测试策略等。第46页/共100页第46页，共100页。（

5）测试阶段定义与完成标准：描述测试的各个阶段，例如单元测试、集成测试和系统测试，并说明计划中所针对的测试类型，例如功能测试或性能测试，描述测试通过或失败的标准，确定中断测试或恢复测试的判断准则。（6）

测试完成所提交的材料：包括测试过程中所涉及到的所有测试文档以及自定义测试工具。第47页/共100页第47页，共100页。（7）测试配置：在测试之前，制定出完成测试目标所必需的软硬件资源、必备的测试工具以及相关的技术资源和培训需求。（8）人员组织与职责：说明测试项目中

的人力资源安排情况，确定测试人员的工作职责划分及其管理权限。第48页/共100页第48页，共100页。（9）测试进度：进度控制是测试计划的主要内容之一，需要分析主要测试阶段和测试任务所需要的时间，给出相应的时间进度表。制定测

试进度计划时一般需要考虑以下一些问题：①软件项目的整体研发周期限制。②已有的软件开发阶段进度计划第49页/共100页第49页，共100页。③测试内容和测试任务的特点。例如，对具有复杂业务流程或高技术复杂性的关键模块进行测试，以及稳定性、

可靠性、安全性和性能等方面的测试需要更多的时间。测试风险的严重程度、数量、原因及其应对难度。④测试人员状况。可供调配的测试人员数量及其个人测试能力。⑤搭建测试平台所需要的软硬件资源状况。⑥被测软件部分的测试用例数量第50页/共100页第50页，共100页。（

10）风险分析：列出所有可能会影响测试设计、开发或实施的风险或意外事件，并且给出避免和应对的措施。常见的测试风险及其预防和处理措施：缺乏详细的需求与设计文档，软件质量标准不清晰，项目计划频繁变更等等测试风险。除了上述列出的测试风险之外，实际测试工作

中还会遇到很多其它的风险因素。因此，风险分析是一项十分艰巨的工作。第51页/共100页第51页，共100页。7.4测试文档管理测试文档管理的内容。测试文档的编写与管理是整个测试管理工作的一个重要组成部分。测试文档管

理包括了对文档的分类管理、文档的格式和模板管理、文档的一致性管理和文档的存储管理等内容。第52页/共100页第52页，共100页。测试文档的类型测试文档主要分为前置测试文档和后置测试文档两种类型，以执行测试前后

进行划分。IEEE829-2008“IEEEStandardforSoftwareandSystemTestDocumentation”给出了一个测试项目所应当编写的测试文档及其相互关系，如图7-7和图7-8所示。第

53页/共100页第53页，共100页。图7-7IEEE829-2008中规定的前置测试文档主测试计划（MTP）测试完整性等级方案整体测试过程、活动和任务确定测试包含的阶段和测试文档单元测试计划（LTP）集成测试计划（L

TP）系统测试计划（LTP）验收测试计划（LTP）阶段测试范围测试资源测试方法验收测试设计（LTD）更多的测试方法细节验收测试用例（LTC）验收测试过程（LTPr）输入输出测试设置与执行说明注意：这里的测试阶

段仅是测试过程示意，可以有不同类型和数量的测试阶段。图中只给出验收测试后续文档，其它阶段后续文档类同。执行测试第54页/共100页第54页，共100页。图7-8IEEE829-2008中规定的后置测试文档异常报告（AR）阶段测试日志（LTL）验收测试报告（LTR）总体通过或失败的测

试总体测试结果执行测试阶段期中测试状态报告（LITSR）测试过程和结果概要不正确或不希望出现的结果单元测试报告（LTR）集成测试报告（LTR）系统测试报告（LTR）主测试报告（MTR）所有详细结果第55页/共100页第55页，共100页。IEEE829-200

8中规定了如下测试文档：•主测试计划（MTP，MasterTestPlan）：总体测试计划和测试管理文档，是针对软件需求和项目质量保障的计划。•阶段测试计划（LTP，LevelTestPlan）：说明特定测试阶段的测试范围、方法、资源和测试活动进度安排，识别和说明测试项

、测试特性、所需执行的测试任务、针对每项任务的人员职责和相关风险。第56页/共100页第56页，共100页。•阶段测试设计（LTD，LevelTestDesign）：说明需要测试的软件特性及其测试通过或失败的度量指标，进一步详细说明计划中给

出的测试方法。•阶段测试用例（LTC，LevelTestCase）：给出本阶段的所有测试用例。•阶段测试过程（LTPr，LevelTestProcedure）：说明测试用例的执行步骤，或者是为了评估软件产品或基于

软件的系统的一系列特性所需执行的操作步骤。第57页/共100页第57页，共100页。•阶段测试日志（LTL，LevelTestLog）：有关测试执行情况的细节记录。•异常报告（AR，AnomalyReport）：说明在测试过程中发生的任何需要调查研究的异常或错误事件。•阶段期中测试状

态报告（LITSR，LevelInterimTestStatusReport）：这一报告的目的是为了总结特定测试活动的结果，根据结果有选择性地给出测试评价和建议，说明测试计划的变化情况。第58页/共100页第58页，共100页。•阶段测试

报告（LTR，LevelTestReport）。每一个测试阶段都有一个相应的阶段测试报告，用于对阶段测试活动进行总结，根据测试结果给出评价与建议。•主测试报告（MTR，MasterTestReport）

。主测试报告与主测试计划相对应，只要制定和实施了一个主测试计划，就必须编写一个对应的主测试报告来描述计划的实施结果，对整个测试活动的结果进行总结和评价。第59页/共100页第59页，共100页。测试完整性等级•测试完整性等级用于区别测试的重要程度，决定了测试的广度和深度。可

以基于功能、性能、安全性或者其它软件特性，对需求、单个功能、一组功能、软件单元和子系统的完整性等级进行设置。第60页/共100页第60页，共100页。完整性等级计划表7-4测试完整性等级计划完整性等级说明4、极端重要必须能够正确执行，否则会造成

系统崩溃、系统无法正常使用、重要数据遭到破坏并且无法修复等严重问题3、重要必须能够正确执行，否则会造成系统部分主要功能无法使用、部分系统功能缺失，可能会引起系统崩溃，引发严重的安全性问题2、一般测试结果的正确与否影响到用户能否有效地使用

软件系统，该测试部分出现缺陷会造成系统功能不正确、性能低下、系统不稳定等问题1、可以忽略软件中可能存在一些微小的造成用户使用不便的问题，但并不影响用户的最终使用第61页/共100页第61页，共100页。每一个等级

所需要的测试文档如表7-5所示。表7-5完整性等级所对应的测试文档完整性等级选择的测试文档4MTP，LTP，LTD，LTC，LTPr，LTL，AR，LITSR，LTR，MTR3MTP，LTP，LTD，LTC，LTPr，L

TL，AR，LITSR，LTR，MTR2LTP，LTD，LTC，LTPr，LTR，LTL，AR，LITSR，LTR1LTP，LTD，LTC，LTPr，LTL，AR，LTR第62页/共100页第62页，共1

00页。针对一个测试项目中会产生很多测试文档，需要采用专门的文档管理工具对其进行分类管理，以便于进行查阅、修改和权限控制。测试文档是前后依赖的，因此对编制好的测试文档一定要进行必要的审核，做好文档的一致性检查，避

免测试对象、测试度量指标等内容在多个文档中不一致的情况发生。第63页/共100页第63页，共100页。7.5软件配置管理7.5.1软件配置管理的作用软件配置管理（SoftwareConfigurationManagement，SCM）是一种标

识、组织和控制软件变更的技术。目的:为了建立和维护软件产品的完整性和一致性。第64页/共100页第64页，共100页。缺乏配置管理会产生的问题：•缺陷只在测试环境出现，但是在开发环境中无法重现。•已经修复的缺陷在进行新版本软

件测试时又再次出现。•程序发布前已经通过了内部测试，但是发布时却出现软件运行失效的问题。第65页/共100页第65页，共100页。软件配置管理的作用主要体现•支持并行开发。能够实现开发人员同时对同一个程序进行开发和修改，解决多个用户对同一程序进行开发和修改所引起的版本不一致问题。•资源共享。

提供良好的软件资源存储和访问机制，开发人员可以共享开发资源，解决了多个用户对同一文件同时修改所引起的资源冲突问题。第66页/共100页第66页，共100页。•变更请求管理。跟踪和管理开发过程中出现的缺陷、功能变

更请求或者任务，加强软件研发人员之间的沟通和协作，使他们能够及时了解变更的状态。•版本控制。跟踪每一个软件版本变更的创造者、时间和原因，从而提高发现软件缺陷的效率。能够重现软件的任何一个历史版本。第67页/共100页第67页，共100页。•软件发布管理。软

件项目经理能够及时和清晰地了解项目的当前状态，管理和计划软件的变更，与软件的发布计划和质量保证计划保持一致。•软件Build管理。通过配置管理系统实现自动化的软件Build过程。•软件过程控制。贯彻实施正规化的开发规范，避免过

程混乱。第68页/共100页第68页，共100页。7.5.2软件配置管理的重点工作软件配置管理包括以下5项最为重要的活动：•配置项识别•变更控制•版本管理•配置状态报告•配置审计第69页/共100页第69页，共100页

。（1）配置项识别•重要性：配置标识是配置管理的基础，所有配置项的操作权限都应当严格管理。•基本原则：所有基线配置项向测试人员开放读取权限；而非基线配置项向测试组长、项目经理及相关人员开放。第70页/共100页第70页，共100页。配置项识别就是将软件配置项按规定统一编号，将配置项划分为基线配置

项和非基线配置项，并且将其存储在配置库中以便于所有人员了解每个配置项的内容和状态，为不同人员设定配置项使用权限。所有基线配置项只向开发和测试人员开放读取权限，不能随意改变；而非基线配置项向项目管理人员

和相关人员开放。第71页/共100页第71页，共100页。配置管理中的配置项软件配置项就是配置管理的对象。软件开发过程所产生的所有程序、数据、文档等都是软件的组成部分，都需要作为配置项进行管理。此外，配置项还包括操作系统、开发工具、数据

库等软件环境和工具。软件特定版本的配置项之间需要相互匹配以保持软件整体的一致性。第72页/共100页第72页，共100页。配置管理中的基线基线是已经正式通过审核批准的一个配置项或一组配置项的集合，因此可以作为进一步开发的基础，并且只能通过正式的变化控制过

程来改变。基线通常与项目开发过程中的里程碑相对应，经过评审批准的阶段性成果的统一标识就标志着项目的不同基线。常见的基线有需求规格说明、设计说明、特定版本的源程序、测试计划等。第73页/共100页第73页，共100页。（2）变更控制•目的：变更控制的目的并不是控制和限制变更的发生，而是对

变更进行有效的管理，确保变更有序地进行。第74页/共100页第74页，共100页。变更控制的主要内容①规定测试基线，对每个基线必须描述下列内容：每个基线的项（包括文档、样品和工具等）；与每个基线有关的评审、批准事项以及验收标准。第75页/共1

00页第75页，共100页。②规定何时何人创立新的基线，如何创立；③确定变更请求的处理程序和终止条件；④确定变更请求的处理过程中各测试人员执行变更的职能；⑤确定变更请求和所产生结果的对应机制；⑥确定配置项提取和存入的

控制机制与方式。第76页/共100页第76页，共100页。变更控制的典型流程图7-9软件变更控制的典型流程验证基线阶段里程碑基线确认变更实现变更授权变更批准变更更新基线建立基线申请变更变更第77页/共100页第77页，共100页。（3）版本管理

版本管理包括对文档、程序等配置项的各种版本进行存储、登记、索引、权限分配等一系列管理活动，目的是按照一定的命名规则保存配置项的所有版本，避免发生版本丢失或混乱，并且确保能快速和准确地查找到特定版本下的配置项。第78页/共100页第78页，共100页。（4）配置状态报告根据配置库中的记录，通

过CASE工具可以生成不同的配置状态报告，例如配置项的状态、基线之间的差别描述、变更日志、变更结果记录等。配置状态报告着重反映了当前基线配置项的状态，同时也反映了变更对软件项目进展的影响，可以作为项目进度管理的参考依据。第79页/共100页第79页，

共100页。（5）配置审计•评估基线的完整性，确认所有配置项已入库保存。•检查配置记录是否正确反映了配置项的配置情况。•审核配置项的结构完整性。•对配置项进行技术评审，防止不完善的软件实现。•验证配置项的正确性、完备性和一致

性。•验证软件是否符合配置管理标准和规范。•确认记录和文档保持可追溯性。第80页/共100页第80页，共100页。7.5.3配置管理的流程图7-10软件配置管理的流程1、制定配置管理计划开始结束2、创建配置管理环境3、标识配置项4、建立基线6、配置审计7、变更

控制管理5、生成配置状态报告第81页/共100页第81页，共100页。（1）制定配置管理计划及时制定配置管理计划是整个软件项目成功的重要保证。配置管理计划的主要内容是制定配置管理策略，确定变更控制策略并对计划内容进行评审。第8

2页/共100页第82页，共100页。制定配置管理计划的主要工作流程•配置控制委员会（ConfigurationControlBoard，CCB）根据项目开发计划确定软件各阶段里程碑和开发策略。•配置管理员（ConfigurationManagementoff

icer，CMO）根据CCB的规划，制定详细的配置管理计划，递交CCB审核。•配置管理计划经CCB审核通过后，交项目经理批准和发布实施。第83页/共100页第83页，共100页。（2）创建配置管理系统创建配置管理系统的主要工作包括确定软件和硬件环境，安装配置管理工具，建立一个

配置管理库，储存在配置计划中已经定义好的配置项，设定配置项使用权限。第84页/共100页第84页，共100页。（3）配置管理计划的实施执行阶段的配置管理活动主要分为以下三个方面：•由配置管理员完成配置库的日常管

理和维护工作。•由开发和测试人员具体执行配置管理策略。•软件项目人员按照规定完成变更控制。第85页/共100页第85页，共100页。配置管理活动的执行流程•配置控制委员会负责设定研发活动的初始基线。•配置管理

员根据配置计划设立配置库和工作空间，为执行配置管理做好准备。•开发和测试人员按照统一的配置管理策略，对授权的软件资源进行开发和测试。•配置控制委员会在软件开发过程中审核各种变更请求，并适时地设立新的基线，保证开发、测试和维护工作的有序进行。第86页/

共100页第86页，共100页。4）软件配置管理的误区•误区一：配置管理就是解决软件版本控制的问题版本控制只是配置管理中最基本的内容，产生这一认识误区的根本原因在于一些软件企业对软件开发流程的管理不重视，另外一个原因是由于开发资源不足，例如缺乏必要的配置管理软硬件环境，缺乏专业的配置管理人员，因

此难以实施系统化的配置管理。第87页/共100页第87页，共100页。•误区二：由开发水平最差的人员担任配置管理员。配置管理的计划、流程和制度只是配置管理实施的基础，而配置管理员是配置管理的具体实施者，决定了配

置管理能否有效地实施。国外软件企业一般都由具备丰富开发经验的人员担任配置管理人员，部分配置管理工作甚至直接由开发经理担任。第88页/共100页第88页，共100页。•误区三：采用了先进的配置管理工具就能完成有效的配置管理。不能盲目迷信和依赖工具，认为只要部署了

专业的配置管理工具就自然建立了配置管理体系。工具不能代替管理，工具的成功使用依赖于规范的配置管理流程以及合格的配置管理人员。第89页/共100页第89页，共100页。7.6测试结束的原则（1）基于“测试阶段”的原则测试一般都要经过单元测试、集成测试和系统测试这几个阶段，可以分别针对各个测试阶段

制定详细的测试结束标准。每个测试阶段符合结束标准后，再进行下一个阶段的测试。第90页/共100页第90页，共100页。相关的测试都需要设定一些结束标准。例如单元测试则需要设定以下标准：•核心代码、测试用例都100%经过了评审。•按单元测试计划完

成了所有规定的测试任务。•功能覆盖率达到100%，代码覆盖率不低于85%。•发现的软件缺陷都已修复，各级缺陷修复率达到标准。第91页/共100页第91页，共100页。（2）基于“验收测试”的原则对于项目类软件，当内部测试达到或接近测试指定的标准后，就将软件递交给用户做最后的验收测试。如

果测试验收通过，就可以停止测试；如果发现了一些缺陷，在有针对性地修复并经过用户认可后就可以结束测试。第92页/共100页第92页，共100页。（3）基于“测试用例”的原则测试用例设计完成并且评审通过后，其执行情况可以作为测试结束的一个参考标准。如

果测试过程中发现测试用例通过率太低，可以暂停测试，待开发人员全面改进软件后再继续测试。当功能测试用例通过率达到100%、非功能测试用例通过率达到95%以上时，可以结束测试。但是使用该原则作为测试结束标准时，需要

严格控制好测试用例的质量。第93页/共100页第93页，共100页。（4）基于“缺陷收敛趋势”的原则通过缺陷分析得到缺陷数量变化的趋势图，当趋势曲线逐渐收敛并且趋近于零时代表很难再发现缺陷，可以以此作为判定测试结束的标准。第94页/

共100页第94页，共100页。（5）基于“缺陷修复率”的原则软件缺陷的严重性等级可以分为致命、严重、重要和较小。在决定测试结束时间时，可以设定致命和严重级别缺陷的修复率必须达到100%；重要缺陷的修复率必须达到95%以上，但不允许存在功能性的错误；较小问题的缺陷可以暂时不做修复。第95页/共

100页第95页，共100页。（6）基于“覆盖率”的原则当需求覆盖率达到100%，代码覆盖率达到测试计划要求的比例后，基本上就可以结束测试。可以通过“抽样测试”和“随机测试”进行补充性检查。第96页/共100页第96页，共100页。（7）基于“缺陷度量”的原则通过缺陷分析技术和缺陷分析工具对

缺陷进行度量，将缺陷主要属性的分布情况、缺陷密度、缺陷清除率等作为判断测试结束的依据。第97页/共100页第97页，共100页。（8）基于“项目计划”的原则项目计划规定了主要测试活动及其进度安排，如果完成了所有规定的测试内容和回归

测试，就可以作为结束测试的一个参考标准。但是，此项原则不能机械使用，因为开发环节的延迟会压缩测试时间，需要结合整体软件质量标准来判断是否可以结束测试。第98页/共100页第98页，共100页。（9）基于“质量成本”的原则软件项目都需要对质量、成本和进度这三个因素进

行平衡，“太少的测试是犯罪，而太多的测试是浪费”。当发现缺陷的测试费用超过了缺陷给系统造成的损失费用时，可以终止测试。第99页/共100页第99页，共100页。（10）基于“测试和行业经验”的原则测试

人员的测试能力和对目标用户业务的熟悉程度会影响到测试效率和测试质量，因此测试人员的经验也应当作为判断何时结束测试的一个依据。第100页/共100页第100页，共100页。