软件测试配置管理计划案例.docx
《软件测试配置管理计划案例.docx》由会员分享，可在线阅读，更多相关《软件测试配置管理计划案例.docx（18页珍藏版）》请在冰豆网上搜索。
软件测试配置管理计划案例
本页仅作为文档页封面，使用时可以删除
Thisdocumentisforreferenceonly-rar21year.March
软件测试配置管理计划案例
卷号
卷内编号
密级
酒店管理系统
分类:
专题计划
使用者:
项目经理、配置变更控制经理、集成员、项目组成员
配置管理计划
Version
项目承担部门：
配置管理部门
撰写人（签名）：
完成日期：
2010/7/18
本文档使用部门：
□主管领导■项目组
□客户（市场）□维护人员□用户
评审负责人（签名）：
评审日期：
文档信息
标题:
配置管理计划
作者:
创建日期:
2010/7/18
上次更新日期:
2010/7/18
版本:
Version
部门名称:
swjtu-Java-02
修订文档历史记录
日期
版本
说明
作者
2010/7/18
Version
创建文档
2010/7/22
Version
修改文档
配置管理计划
1.简介
项目CM计划说明在产品生命周期中将执行的所有与CM相关的活动。
它详细说明了活动时间表、分配的职责以及必需的资源（包括人员、工具和计算机设备）。
1.1目的
CM计划的目的在于，定义或参考那些描述要在软件产品开发中执行配置和变更控制管理（CM）方式的步骤和活动。
1.2范围
本规范规定了在制订软件配置管理计划时应该遵循的统一的基本要求。
本规范适用于软件特别是重要软件的配置管理计划的制订工作。
对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。
1.3定义、首字母缩写词和缩略语
CCB-configurationcontrolboard变更（或配置）控制委员会
CI-configurationitem配置项
CM-configurationmanagement配置管理
Baseline：
基线。
PCA：
物理审计，在配置管理系统中建立基线的工件是否为“正确”版本。
FCA：
功能审计，是核实软件配置项的实际性能是否符合它的需求。
CMP-configurationmanagementplan配置管理计划
CR-changerequest变更请求
SCM-softwareconfigurationmanagement软件配置管理
任意角色–项目中所有角色
1.4参考资料
《RationalUnifiedProcess2000》
《SDPPlan》
《DevelopCase》
2.软件配置管理
组织、职责和接口
相关人员
职责
接口
CCB
该委员会监督变更流程，由开发人员和用户的代表组成。
与任意角色：
任意角色提出变更请求，需提交给CCB，对变更请求进行处理后，将结果通知给提出者。
配置经理
配置经理负责为产品开发团队提供全面的配置管理（CM）基础设施和环境。
CM的作用是支持产品开发行为，使开发人员和集成员有适当工作区来构建和测试其工件，并且使所有工件均可根据需要包含在部署单元中。
配置经理还必须确保CM环境有利于进行产品复审、更改和缺陷跟踪等活动。
配置经理还负责撰写CM计划并汇报基于“变更请求”的进度统计信息。
发布基线
与项目经理：
CM计划需要参照SDP计划，而且SDP又参照CM计划。
SCM经理每周/每阶段都要提供系统的配置状态报告给项目经理。
与集成员：
CM经理创建配置管理库，而集成员创建集成工作区。
集成员创建基线和提升基线，由SCM经理管理基线。
与部署经理：
SCM经理创建部署单元，需要部署计划。
与架构设计师：
SCM经理创建CM环境，需要实施模型。
与任意角色：
任意角色创建开发工作区，需要配置库。
与系统管理员：
创建CM环境时，需要系统管理员提供硬件和网络基础设施。
与组织SCM管理员：
在每一阶段基线完成后提交基线工件。
与评审协调员：
接收评审协调员提交的评审结果工件和评审表。
与SQA人员：
配合SQA人员活动。
任意角色
项目组所有成员
任何角色均可以“检入”和“检出”任何与产品相关的工件，以便在配置控制系统中进行维护。
此外，任意角色都可以提交变更请求，并且对它们所拥有的变更请求进行更新。
2.1工具、环境和基础设施
1.工具
类型
使用时期
工具
原因
配置管理
产品开发全程
Svn
Svn简单，功能强大。
环境和基础设施
1）产品数据量的预期大小：
我们期望本项目至少有150个文件，50M的磁盘空间。
2）产品团队的分配：
角色
成员名单
角色说明
PM
项目经理
SA
需求分析师
SE
设计分析师
TE
测试工程师
CM
配置管理员
PPQA
产品和质量保证
服务器和客户机的实际位置：
1台。
2G内存、160G硬盘。
Win7。
服务器位置在C2-6,客户端在C2-.
3.配置管理活动
3.1配置标识
标识方法
最终的工件的命名方式是大写字母+缩写+编号+名称例：
HMS-CM-101-配置管理计划
相应的工件的中间版本命名方式是以对应的阶段大写字母缩写加类别大写缩写加版本编号命名
发布标志为产品缩写加版本号,阶段发布为阶段号加版本号
工件存储目录及分类
项目开发过程产生的工件由相应的负责人及时上传至SVN服务器，由配置管理员统一管理。
SVN服务器文件存放目录分类如下图
文件上传管理
所有模块负责人必须与每日工作结束之前上传当日工作内容上传至SVN服务器。
所有上传工件必须符合标识方法中的命名方式。
项目基线
基线名称
基线标识
产出时机
计划基线
JH-01
计划阶段结束
需求基线
XQ-01
需求分析阶段结束
设计基线
SJ-02
设计阶段结束
产品基线
CP-03
实现部署阶段结束
基线创建
非代码类基线：
由配置经理根据《开发案例》创建
代码类基线：
由集成员根据产品架构文档创建
3.2配置和变更控制
3.2.1变更请求的处理和审批
软件配置的变更管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。
变更请求表单是一个正式提交的工件，用于在整个项目的生命周期内跟踪所有的请求（包括新特性、扩展请求、缺陷、变更的需求等）与相关的状态信息。
所有变更历史记录，包括所有状态变更及变更的日期和原因，都将随CR一起保存。
进行多次复审和结束项目时都可使用此信息。
变更过程中的活动
活动
角色
内容
提交变更请求
提交者
项目的任何涉众均可提交变更请求（CR）。
通过将变更请求状态设置为已提交，变更请求被记录到变更请求追踪系统中（例如ClearQuest）并放置到CCB复审队列中。
复审变更请求
CCB
此活动的作用是复审已提交的变更请求。
在CCB复审会议中对变更请求的内容进行初始复审，以确定它是否为有效请求。
如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重性以及其他任何相关的标准，判定该变更是在当前发布版的范围之内还是范围之外。
确认重复或拒绝
CCB代表
如果怀疑某个变更请求为重复的请求或已拒绝的无效请求（例如，由于操作符错误、无法重现、工作方式等），将指定一个CCB代表来确认重复或已拒绝的变更请求。
如果需要的话，该代表还从提交者处收集更多信息。
更新变更请求
提交者
如果评估变更请求时需要更多的信息（详细信息），或者如果变更请求在流程中的某个时刻遭到拒绝（例如，被确认为是重复、已拒绝等），那么将通知提交者，并用新信息更新变更请求。
然后将已更新的变更请求重新提交给CCB复审队列，以考虑新的数据。
分配工作与安排工作时间
项目经理
一旦变更请求被置为已打开，项目经理就将根据请求的类型（例如，扩展请求、缺陷、文档变更、测试缺陷等）把工作分配给合适的角色，并对项目时间表做必要的更新。
进行变更
指定的角色
指定的角色执行在流程的有关部分中指定的活动集（例如，需求、分析设计、实施、制作用户支持材料、设计测试等），以进行所请求的变更。
这些活动将包括常规开发流程中所述的所有常规复审活动和单元测试活动。
然后，变更请求将标记为已解决。
核实测试工作版本中的变更
测试员
指定的角色（分析员、开发人员、测试员、技术文档编写员等）解决变更后，变更将放置在要分配给测试员的测试队列中，并在产品工作版本中加以核实。
核实发布工作版本中的变更
系统集成员
已确定的变更一旦在产品的测试工作版本中得到了核实，就将变更请求放置在发布队列中，以便在产品的发布工作版本予以核实、生成发布版本说明等，然后关闭该变更请求。
3.2.1.1变更过程中的变更请求状态
状态
定义
已提交
出现此状态的原因为：
1）提交新的变更请求；2）更新现有的变更请求；或3）考虑在新的发布周期中使用已推迟的变更请求。
变更请求放置在CCB复审队列中。
本操作的结果不会指定拥有者。
已推迟
变更请确定为有效，但对于当前发布版来说属于“超出范围”。
处于已推迟状态的变更请求将得以保留，并在以后的发布版中被重新考虑并加以使用。
可以指定一个目标发布版，以表明可以提交变更请求（以重新进入CCB复审队列）的时间范围。
重复
处于此状态的变更请求被视作对已提交的另一个变更请求的重复。
变更请求可由CCB复审管理员或被指定解决它的角色置于该状态中。
将变更请求置于重复状态中时，将（在ClearQuest的“附件”选项卡上）记录它所重复的那个变更请求的编号。
在提交变更请求之前，提交者应首先查询变更请求数据库，看是否已有与之相重复的变更请求。
这将省去复审流程中的若干步骤，从而节省大量的时间。
应将重复变更请求的提交者添加到原始变更请求的通知列表中，以便以后将有关解决事宜通知他们。
已拒绝
CCB复审会议或指定的角色确定此状态中的变更请求为无效请求，或者需要提交者提供更为详细的信息。
如果已经指定（提出）变更请求，则它将从解决队列中删除并重新复审。
这将由CCB所指定的权威来予以确认。
除非有必要，否则提交者无需进行任何操作。
在此情况下变更请求状态将变为详细信息。
考虑到可能会有新的信息，在CCB复审会议中将重新复审该变更请求。
如果变更请求确认为无效，将被CCB关闭并且通知提交者。
详细信息
数据不足以确认已拒绝或重复的变更请求是否有效。
拥有者自动变成提交者，将通知提交者提供更多数据。
已打开
对于当前发布版来说，处于此状态的变更请求已被确定为属于“范围之内”，并且亟待解决。
它已定于在即将来临的目标里程碑之前得以解决。
它被确定在“指定队列”中。
与会者是提出变更请求并将其放入解决队列中的唯一权威。
如果发现优先级为第二或更高的变更请求，应立即通知QE经理或开发经理。
此时，他们可以决定召开紧急CCB复审会议，或立即打开变更请求以将其放入解决队列中。
已指定
然后由项目经理负责已打开的变更请求，他应根据变更请求的类型分配工作；如果需要,还应更新时间表。
已解决
表示该变更请求已解决完毕，现在可以进行核实了。
如果提交者是Q
升级会员 