16.测试项目管理

16.1软件测试配置管理

16.1.1软件测试配置管理的概念

配置管理(Configuration Management，CM)是对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。软件测试配置管理一般应用过程方法和系统方法来建立软件测试管理体系，也就是把软件测试管理作为一个系统，对组成这个系统的各个过程加以识别和管理，以实现设定的系统目标。同时要使这些过程协同作用、互相促进，从而使它们的总体作用大于各个过程之和。软件测试配置管理的主要目标是在设定的条件限制下，尽可能发现和找出软件缺陷。测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象包括软件测试计划、测试方案(用例)、测试版本、测试工具及环境、测试结果等。

16.1.2软件配置管理中的相关概念

软件配置管理中有如下相关概念：

16.1.2.1软件配置项(Software Configuration Item，SCI) 

软件配置项为了配置管理的目的而作为一个基本的独立单位来看待的软件成分或它们的集合体，如外部提交的软件产品、项目成果(代码、文档和数据)以及项目内部使用的支持工具(如文档测试用例软件工具)等。在多数的软件配置管理系统中，最基本的软件配置项是以磁盘文件的形式存放和管理的。 

16.1.2.2基线(Baseline)

已经通过正式评审和认可，作为下一步开发的基础，并且只有通过正式的更改控制规程才能进行更改的配置项。  

16.1.2.3软件配置控制委员会(Software Configuration Control Board，SCCB) 

它是软件配置控制委员会 

16.1.2.4配置管理库 

分为开发库、测试库、基线库(受控库)和产品库。 

(1)开发库 

在软件生命周期的某一阶段期间，存放与该开发活动相关的配置项及相关信息的库。

(2)测试库 

存放单元测试之后、系统测试结束之前的，与测试相关的配置项。 

(3)基线库(受控库) 

在软件生命周期的某一阶段结束时，存放作为阶段成果而释放的、与开发活动相关的配置项及相关信息的库。纳入基线库的配置项的更改必须遵照《变更过程指导》进行。 

(4)产品库 

项目成果正式提交用户前，SCM在项目经理的指导下从基线库中提取构成最终产品配置项。 

16.1.2.5软件配置管理(Software Configuration Management，SCM) 

它是软件配置管理 

16.1.2.6软件工作产品(Software Workproduct)

作为定义、维护或使用软件过程的一部分所生成的任何人工制品。它包括过程描述、计划、规程、计算机程序和相联的文档。 

16.1.2.7同行评审(Peer Review)

由一个软件工作产品生成者的同行遵循已定义的规程对产品作的评审，目的在于标识出缺陷和改进之处

16.1.3软件配置管理的主要过程和活动

软件配置管理的主要过程和活动如下

(1)配置项识别

(2)工作空间管理

(3)版本控制

(4)变更控制

(5)状态统计和报告

(6)配置审计和审查

(7)产品生成

(8)过程管理

软件配置管理的主要过程和活动如下图所示：

16.1.4软件配置管理的主要任务

软件配置管理的主要任务如下：

(1)制定项目的配置计划

(2)配置项标识与配置库管理

(3)版本控制

(4)变更控制

(5)定期进行配置审计

(6)向相关人员报告配置状态

16.1.5软件配置管理计划

软件配置管理计划的内容如下：

(1)配置管理软件资源和硬件资源

(2)配置库结构

(3)人员、角色以及配置管理规范

(4)基线计划

(5)配置库备份计划

16.1.6配置管理系统的主要功能

配置管理系统的主要功能如下：

(1)并行开发支持

(2)修订版管理

(3)版本控制

(4)产品发布管理

(5)构建管理

(6)过程控制

(7)变更请求管理

(8)代码共享

16.2缺陷(Bug)管理流程

16.2.1缺陷的分类

从不同角度，Bug可以分为软件错误、软件缺陷、软件故障和软件失效

(1)软件错误

软件错误指的是软件产品中存在的导致期望的运行结果和实际运行结果间出现差异的一系列的问题。

(2)软件缺陷

软件缺陷是存在于软件之中的那些不希望或不可接受的偏差。

(3)软件故障

软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。

(4)软件失效

软件失效是指软件运行时产生的一种不可接受的外部行为结果。

16.2.2软件缺陷的相关概念

16.2.2.1软件缺陷的范畴

符合下边5个规则的才能叫做软件缺陷：

(1)软件未达到产品说明书标明的功能。

(2)软件出现了产品说明书指明不会出现的错误。

(3)软件功能超出产品说明书指明范围。

(4)软件未达到产品说明书虽未指出但应达到的目标。

(5)软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

16.2.2.2软件缺陷的分类

软件缺陷的分类如下：

(1)功能不正常

(2)软件在使用上不方便

(3)软件的结构未做良好规划

(4)功能不充分

(5)与软件操作者的互动不良

(6)使用性能不佳

(7)未做好错误处理

(8)边界错误

(9)计算错误

(10)使用一段时间所产生的错误

(11)控制流程的错误

(12)在大数据量压力之下所产生的错误

(13)在不同硬件环境下产生的错误

(14)版本控制不良所产生的错误

(15)软件文档的错误

16.2.2.3软件缺陷的严重级

软件缺陷的严重级可分为：

(1)致命(Fatal)

功能完全丧失、系统崩溃、死机、数据丢失或损坏

(2)严重(Critical)

部分主要功能丧失、结果错误、功能遗漏以及数据不能保存

(3)一般(Major)

次要功能没有实现，但不影响正常使用，如界面布局、提示不正确及小故障

(4)较小(Minor)

不影响使用的瑕疵或小建议

16.2.2.4软件缺陷的优先级

软件缺陷的优先级可分为：

(1)最高优先级(P1)：系统几乎不能使用或测试不能继续，需要立即修复

(2)次高优先级(P2)：产品发布之前必须修复

(3)中等优先级(P3)：如果时间允许应该修复

(4)一般优先级(P4)：可以修复，但不影响发布

16.2.2.5软件缺陷跟踪状态

软件缺陷在Bugzilla中的状态描述如下：

(1)NEW

测试人员将Bug提交给任务分发人员(研发模块负责人)，此时Bug状态为NEW，开始Bug的生命周期，如果测试人员知道具体负责的研发人员，也可以直接指定，在Assign To项目中输入具体负责的研发人员Email

(2)ASSI

任务分发人员将Bug分发给指定研发人员时，将Bug置为ASSI状态，解决Bug的工作就开始了

(3)RESO DUPL

研发人员接收分配给自己的Bug后，在当前项目的Bug List中查看该Bug是否与之前的Bug重复，若重复，将新Bug置为RESO DUPL状态，并在Commnet中注明与哪个Bug重复(部分研发人员将旧Bug置为RESO DUPL是错误的)

(4)RESO INVA

研发人员对于没有重复的Bug进行修复，经过分析，如果Bug是因为在错误的环境下产生或由于错误操作导致或由于测试人员错误理解而产生，属于无效Bug，将Bug置为RESO INVA状态，并在Commnet中注明置为无效的原因

(5)RESO LATE

研发人员对于没有重复的有效Bug进行修复，经过分析，如果当前版本无法修复，但在以后项目中或条件成熟时会修复，将Bug置为RESO LATE状态，并在Commnet中注明置为LATE的原因(部分研发人员将此类Bug误置为RESO INVA是错误的)

(6)RESO WONT

研发人员对于没有重复的有效Bug进行修复，经过分析，不在产品需求范围内，而且在可预见的未来内也不会提供该功能，将Bug置为RESO WONT状态，并在Commnet中注明置为WONT的原因

(7)RESO WORK

研发人员对于没有重复的有效Bug进行修复，按照Bug的步骤，多次验证，却无法重现该Bug，需要测试人员再次发现该Bug时告知自己，以便查找原因时，将Bug置为RESO WORK状态

(8)RESO FIXE

研发人员对于没有重复的有效Bug进行修复，发现了产生Bug的原因，经过修改代码，能够消除该Bug，将Bug置为RESO FIXE状态，并在Commnet中注明问题的原因、修复的方法和将在哪个版本中修复，以便测试人员准确及时验证(部分研发人员只注明修复了Bug，但没有说明版本，或说明版本错误)

(9)VERI FIXE 

测试人员在处理RESO FIXE时，在指定的版本及以后的版本中进行验证，如果发现该Bug已经不存在，将Bug置为VERI FIXE状态，并在Commnet中注明验证通过的版本

(10)REOP

测试人员在处理RESO FIXE时，在指定的版本及以后的版本中进行验证，如果发现该Bug仍存在，将Bug置为REOP状态，并在Commnet中注明重现该Bug的版本，补充必要的信息，需要研发人员继续查找原因，进一步修复Bug，测试人员在测试过程中，发现状态为VERI FIXE的Bug重现了，将Bug置为REOP状态，并在Commnet中注明重现该Bug的版本，补充必要的信息，需要研发人员继续查找原因，进一步修复Bug，测试人员在测试过程中，发现状态为CLOS的Bug重现了，操作同上

(11)CLOS

测试人员在回归测试时，再次验证VERI FIXE状态的Bug，如果该Bug仍未重现，将该Bug置为CLOS状态，并在Commnet中注明最后验证的版本，至此Bug的生命周期结束，如果该项目后续版本中再出现该Bug时，需要REOP，以上的操作只在同一个项目中进行处理，不同项目的Bug不存在重复问题。测试人员在提交Bug时，如果希望其他人也了解Bug的进展，可以在CC项中输入他们的Email，bug已经提交后，如果希望其他人也了解Bug的进展，可以在CC List项中点击edit，添加他们的Email

在Bugzilla中的Bug状态转换图如下

16.3质量成本的相关应用

质量成本是指企业为了保证和提高产品或服务质量而支出的一切费用，以及因未达到产品质量标准，不能满足用户和消费者需要而产生的一切损失。

质量成本一般包括：

(1)一致成本

为确保与要求一致而作的所有工作叫做一致成本

(2)非一致成本

由于不符合要求而引起的全部工作叫做非一致成本

这些工作引起的成本主要包括：预防成本、鉴定成本、内部损失成本和外部损失成本。其中预防成本和鉴定成本属于一致成本，而内部损失成本和外部损失成本，又统称为故障成本，属于非一致成本。

下面用一张表说明一致成本和非一致成本的计算

表16-2  测试成本构成表

16.4软件测试项目管理

16.4.1软件测试管理的范畴

(1)测试过程管理

(2)测试人员与组织

(3)测试计划与测试进度

(4)测试风险管理

(5)测试成本管理

(6)测试产出物的管理

16.4.2测试质量控制的过程

测试质量控制，可以从如下几个方面进行：

(1)制定质量保证计划

(2)评审测试文档

(3)审核测试活动

全国计算机技术与软件专业技术资格（水平）考试【软件评测师】-考试内容总结（十六）测试项目管理