软件测试配置管理计划案例.docx
- 文档编号:7695469
- 上传时间:2023-05-11
- 格式:DOCX
- 页数:18
- 大小:80.23KB
软件测试配置管理计划案例.docx
《软件测试配置管理计划案例.docx》由会员分享,可在线阅读,更多相关《软件测试配置管理计划案例.docx(18页珍藏版)》请在冰点文库上搜索。
软件测试配置管理计划案例
卷号
卷内编号
密级
酒店管理系统
分类:
专题计划
使用者:
项目经理、配置变更控制经理、集成员、项目组成员
配置管理计划
Version1.0
项目承担部门:
配置管理部门
撰写人(签名):
完成日期:
2010/7/18
本文档使用部门:
□主管领导■项目组
□客户(市场)□维护人员□用户
评审负责人(签名):
评审日期:
文档信息
标题:
配置管理计划
作者:
创建日期:
2010/7/18
上次更新日期:
2010/7/18
版本:
Version1.0
部门名称:
swjtu-Java-02
修订文档历史记录
日期
版本
说明
作者
2010/7/18
Version1.0
创建文档
2010/7/22
Version1.1
修改文档
配置管理计划
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简单,功能强大。
2.CM环境和基础设施
1)产品数据量的预期大小:
我们期望本项目至少有150个文件,50M的磁盘空间。
2)产品团队的分配:
角色
成员名单
角色说明
PM
项目经理
SA
需求分析师
SE
设计分析师
TE
测试工程师
CM
配置管理员
PPQA
产品和质量保证
服务器和客户机的实际位置:
1台。
2G内存、160G硬盘。
Win7。
服务器位置在C2-6,客户端在C2-1.3.4.5.7.8.9.10
3.配置管理活动
3.1配置标识
标识方法
最终的工件的命名方式是大写字母+缩写+编号+名称例:
HMS-CM-101-配置管理计划
相应的工件的中间版本命名方式是以对应的阶段大写字母缩写加类别大写缩写加版本编号命名
发布标志为产品缩写加版本号,阶段发布为阶段号加版本号
工件存储目录及分类
项目开发过程产生的工件由相应的负责人及时上传至SVN服务器,由配置管理员统一管理。
SVN服务器文件存放目录分类如下图
文件上传管理
所有模块负责人必须与每日工作结束之前上传当日工作内容上传至SVN服务器。
所有上传工件必须符合标识方法中的命名方式。
3.1.3项目基线
基线名称
基线标识
产出时机
计划基线
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复审会议,或立即打开变更请求以将其放入解决队列中。
已指定
然后由项目经理负责已打开的变更请求,他应根据变更请求的类型分配工作;如果需要,还应更新时间表。
已解决
表示该变更请求已解决完毕,现在可以进行核实了。
如果提交者是QE部门的成员,则拥有者将自动变成执行提交的QE成员。
否则,拥有者将变成QE经理,以重新进行人工分配。
测试已失败
在测试工作版本或发布工作版本中进行测试时失败的变更请求将置于此状态中。
拥有者自动变成解决变更请求的角色。
已核实
处于此状态的变更请求已经在测试工作版本中得到了核实,并且可以进行发布了。
已关闭
变更请求不再引人注意。
这是可以指定给变更请求的最后一个状态。
只有CCB复审管理员有权关闭变更请求。
变更请求被关闭后,提交者将收到一份有关对变更请求的最终处理结果的电子邮件通知。
在下列情况中可能关闭变更请求:
1)其已核实的解决结果在发布工作版本中得到确认之后;2)其拒绝状态得到确认时;或3)被确认为对现有变更请求的重复。
在后一种情况中,会将重复变更请求通知给提交者,并将提交者添加到该变更请求中,以便以后通知他们(详情请参见状态“拒绝”和“重复”的定义)。
如果提交者希望对关闭变更请求有异议,则必须更新变更请求并且重新将其提交供CCB复审。
变更过程的变更请求状态(状态图):
3.2.1.2保存变更历史记录
如果工件为Word文档,则在文档的修订文档历史记录。
如果工件为其他工件,必须在相应的记录中保存变更历史纪录。
3.2.1.3变更请求中受影响配置项的变更
在变更请求中受影响配置项需要变更时,首先由CCB协调员通知受影响配置项的变更人员,其次被通知人员按照标准变更流程进行变更。
3.2.2变更控制委员会(CCB)
1.职责:
CCB的基本任务是明确产品的基线、复审对基线的变更、最后批准、否决变更或延期执行。
2.选择成员标准:
从用户、开发人员、测试小组、项目管理中选择。
3.项目的CCB成员为:
4.CCB主席:
5.处理变更请求和确认的过程:
CCB以事触发为主要工作方式,必须定期(每个阶段结束时)按需召开会议。
确保变更提议及时得到了复审和处理。
拟定变更复审通知协议。
确保变更请求提交后,各有关人员都得到了通知,决定由谁复审各种工件。
传达给同事和团队负责人,以及变更提议的接受者,并让他们有机会复审并参与意见。
人员
角色
职责
施皓
CCB主席
协调组织
复审员
需求复审
复审员
需求复审、架构复审
复审员
架构复审、代码复审
复审员
代码复审
复审员
测试复审
协调员
负责通知由谁进行复审
3.3配置状态统计
3.3.1项目介质存储和发布进程
3.3.1.1项目介质保留策略、备份计划、事故处理计划、恢复计划
1.备份机制及保留策略:
1)每天实验结束时将主服务器的数据备份到ftp服务器中。
2)ftp服务器只保留最近一周的备份。
2.事故处理和恢复机制:
如果出现事故(如:
主服务器当机、遭病毒、硬件损坏等),采用ftp服务器上的数据进行恢复。
3.防病毒/杀毒机制:
1)杀毒/防病毒软件:
Antivir
2)频率:
每日杀毒。
3)负责人:
系统管理员(施皓)。
3.3.1.2介质保留方式:
介质保留方式:
联机。
类型:
移动硬盘。
格式:
Windows的文件。
3.3.2报告和审计
目的:
让项目经理确定需要报告哪些产品的相关变更数据,以及报告人和报告频率。
频率:
每日/每个阶段结束时进行报告。
报告人:
配置管理经理。
1.基于变更请求的报告。
1)龄期:
基于时间的报告。
内容和格式如下:
缺陷(Bug)名称
打开时间
修复时刻
滞后时间(天)
备注
2)分布:
基于计数的报告。
内容和格式如下:
3)
拥有者
Bug个数
修复状态
Bug个数
优先级
Bug个数
4)趋势:
与时间和计数有关的报告。
内容和格式如下:
发现Bug个数
修复Bug个数
Bug发现频率
(天)
Bug修复频率
(天)
就打开的缺陷和关闭的缺陷而言,它们之间的“质量差距”有多大?
解决缺陷所用的平均时间
(天)
2.工作版本报告。
工作版本报告中列出了构成软件某一特定版本的一个工作版本的所有文件、它们的位置以及已并入的变更。
3.审计。
包含功能审计和物理审计。
1)功能审计:
核实软件配置项的实际性能是否符合它的需求。
2)物理审计:
验证在配置管理系统中建立基线的工件是否为“正确”版本。
4.配置状态报告(参见附录2)
4.里程碑
在每一次迭代完成时,设立一个里程碑。
CM计划:
在先启阶段创建,精化阶段各迭代中进行CM计划更新,精化阶段完成时CM计划完成。
5.培训和资源
培训:
角色
人员
培训内容
配置管理经理
相关知识基础培训
项目经理
相关知识基础培训
数据库设计
数据库相关知识及应用
界面设计
图形设计及制作相关知识
6.附录配置管理报表及其格式
附录1
基线发布表
型目编号
项目名称
酒店管理系统
基线号
本基线配置项路径
基线包含工作名称
版本号
路径
负责人
备注
附录2
ConfigurationStateAccounting
1、配置项状态
分类
配置项
配置项版本
路径
负责人
创建时间
最后更新时间
当前状态
2、变更请求概要列表
请求编号
请求主题
提出者
创建时间
完成时间
当前状态
备注
3、版本发布信息
发布版本
计划发布时间
实际发布时间
备注
4、备份历史信息
备份序号
备份时间
备份位置
负责人
备注
5、CM环境状态
5.1、主服务器状态
服务器名称
服务器状态
SCM库规模(MB)
SCM可用空间(MB)
5.2、备份服务器状态
备份服务器名称
备份服务器状态
SCM库规模(MB)
SCM可用空间(MB)
6、度量
配置项数量
变更请求数量
SCM缺陷数量
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 配置管理 计划 案例