培训一:创建MR及提交FB时注意事项
需求MR VASFB-1245
? 新建需求任务跟踪MR时:
1) MR type字段应选择Requirement fix:需求改正,或Requirement enhancement:需求增强;
2) Severity 字段需严格把握MR等级;
3) MR中需包含与现场沟通内容
或需求描述等。
实现MR VASFB-1245
? 创建实现任务跟踪MR时:
1) MR type字段需根据问
性质选择;
2) Severity 字段需严格把握MR等级;
3) 如果是从需求过来的实现MR,则需填写完整的需求描述,比对需求MR以及相关T3的
;如果是从FB直接过来的实现MR,则需详细填写验证过程、错误数据及问题的详细描述。
测试MR PW10MR-132 PW10MR-131
? 创建测试MR时:
1) MR Type字段根据问题性质选择;
2) Severity 字段需严格把握MR等级;
3) MR中需包含问题的具体操作路径,详细的问题现象描述等。
现场FB VASFB-1245
? 提交现场FB时:
1) Submit时需描述问题是如何解决的,该点可以从开发submit实现MR中查看到;
2) Submit时需描述补丁发布版本号;
3) 若补丁通过工具发布,需说明发布路径。
培训二:MR系统及patch系统申请方法
申请MR系统需通过邮件发信给ssg@gxlu.com.cn,发信格式如下:
主题:申请分支(主线)MR系统
内容:
刘勇,你好!
申请分支(主线)MR系统
北方PROJECTWORKS20100128分支
MRB:刘丽
PM:孔悦
SHORTEN NAME:PW1020100128
其他属性的请复制:北方PROJECTWORKS需求跟踪
申请patch系统:
所属项目:新建所属项目:PROJECTWORKS
提交patch类别:
dbforora
client
server
dbmetadata
dbmodel_gis
dbmodel_nongis
dbmodel_project
dbview_gis
dbview_nongis
dbview_project
nova_db
nova_webserver
webserver
培训三:编译分类及编译步骤
● 编译种类
1. 日常编译
? 作用
l 定期编译,由脚本自动完成,主要用来检查主线上的代码
? 步骤
l 制定任务
,每天自动定时执行编译
l 若发生编译错误,由Builder发信通知相关的开发人员修改
l 完成编译后,将软件包提交到CVS
l 用新编译的软件包更新开发环境
2. 主线编译(出Load版本)
? 作用
l 软件开发到了一定阶段。需要对开发的新功能进行测试。
l 根据项目计划,由PM发起编译
? 步骤
l 根据项目计划,PM发布主线编译通知
l 开发和DB人员根据通知,提交代码和脚本
l Build进行编译(若有编译错误,则通知相应的开发人员)
l 完成编译后,提交给测试人员
l 测试人员对主线版本进行测试(针对新功能进行测试)
3. 分支编译:(发布版本)
? 作用
l 项目进展到一定阶段,需要提供版本发布给客户
l 经过几个主线版本的测试,待版本稳定后分支
l 测试对分支版本进行全面的回归测试
? 步骤
l 根据项目计划,PM发布分支编译通知
l 开发和DB人员按时提交代码和脚本(分支的脚本)
l Builder进行编译(若有编译错误,则通知相应的开发人员)
l 完成编译后,提交给测试人员
l 测试人员对分支版本进行测试(回归测试)
● 编译步骤
这里定义的是一般性的编译步骤,如有特殊的编译步骤,请在SCM计划中详细说明。
1) PM确定,向SCM提交build计划,即“测试及对外发布子系统列表”;
2) Builder在项目编译前一天,应通知(E-mail)相关人员及部门编译的计划与时间等信息(如下):
E-mail主题为:“XXXX、XXXX项目9:00集成build,主干[或分支]”
Build时间:2003/11/5(星期三) 9:00Build项目: Project_nameBuilder担当:(SCM组builder)
3) 邮件作用:
a) 在指定时间前,开发和DB人员提交代码和脚本到cvs
b) 在指定时间后,开发和DB人员停止提交代码和脚本,直到编译完成
4) DB 人员在编译开始之前(收到build计划的E-mail之后),需完成数据库脚本在CVS上的提交。如果不能及时完成提交,需通知Builder(如果没有类似提醒,则默认数据库脚本已经提交)。原则上Builder不会推迟编译时间点,只有在编译的过程中(中断编译时)或编译结束后,再行通知DB 人员完成脚本提交。Builder 在确认DB script脚本提交后方可进行后续的提交工作。通常测试会在编译前5分钟发信提醒即将编译。
5) 由Builder执行build任务(参照日常编译步骤);
6) 编译完毕后,PM如有“分支申请表”,则对所有子系统先打主干tag [Project_name]_INT_TAG_[buildno],再打分支tag。分支tag的格式如下:BRANCH_[Project_name] _INT_TAG_[buildno],[buildno]由Builder填写;
7) 根据PM的“分支申请表”如果没有分支请求,应对所有子系统打上主干tag,tag的格式如下:[Project_name]_INT_TAG_[buildno],[buildno]由Builder填写;
8) PM负责或指定相关人员提交release letter(一般由开发teamleader提交),ST从相关人员处获取release letter的提交确认。release letter中应反映出Load与buildno之间的关系,相关人员可以参照Builder发出的提交ST的“测试及对外发布子系统列表”;
9) build成功后,提交ST,并通知(E-mail)相关人员及部门,信息格式如下:
E-mail主题为:“XXXX、XXXX项目主干[或分支]编译成功”
TAG名称:[Project_name]_INT_TAG_[buildno]
分支名称:BRANCH_[Project_name] _INT_TAG_[buildno](如有分支,则也需将分支名称发出)
培训四:软件从测试到发布流程
1、 申请主线MR系统。
当软件启动以后,在软件第一个load版本生成之前要申请主线MR系统。软件目前处于主线开发阶段。
2、 Load1.0版本编译。
当软件发开完毕,提交测试时,软件进入第一个版本测试阶段。此时需要在主线MR系统中的新增项目的版本号,即在MR系统的Load中增加第一个版本号,例如“Load1.0版本”。编译第一个版本Load1.0,开始接收测试。Load1.0中的所有的问题都提到新建的Load1.0版本中。
3、 Load2.0版本编译。
当Load1.0版本测试基本结束后,同时待开发将MR基本修改完毕时,开始编译第二个版本Load2.0。
测试Load2.0版本时注意事项:
1) 在MR系统的Load中增加第二个版本号,例如“Load2.0版本”。
2) Load2.0开始测试前,首先验证上一个版本,即Load1.0所有已经submit的MR,验证通过的直接pass。如果没有通过则继续assign给开发,并描述问题现象。
3) 将Load2.0版本测试出来的问题都统一提到Load:Load2.0版本。
4、 后续版本编译。
如若还有后续编译版本,则重复第3步操作。
5、 分支版本编译。
当软件版本趋于稳定后可以产生分支版本。
注意事项:
1) 编译分支版本前需要首先申请分支MR系统和patch系统。
2) 将主线MR系统中处于assign状态的MR创建关联的MR到新的分支MR系统中。(根据项目需要由PM来决定哪些关联到分支中。)
3) 在主线MR系统的Load中增加分支版本号,例如“综合资源20090101版本”。后续分支所有的问题都提到主线MR系统该版本中。
4) 分支编译完毕需要在CVS上先创建主线TAG,再创建分支TAG。主线TAG的格式如下[Project_name]_INT_TAG_[buildno],分支TAG的格式如下BRANCH_[Project_name] _INT_TAG_[buildno]。创建好TAG和分支后将主线TAG和分支TAG名称发信给整个项目组。
5) 分支版本开始测试前,首先验证上几个版本中所有已经submit的MR,验证通过的直接pass。如果没有通过则继续assign给开发,并描述问题现象。如果问题比较严重,需要在分支中修改的,同时创建关联的分支MR到新的分支MR系统中。
6、 分支版本发布。
分支发布时除了软件介质外,还需要发布用户手册以及安装手册,具体目录为:
-tosaip 软件包
-db 数据库升级脚本
-doc 用户手册、安装手册
-patch 软件patch
补充:
● 分支策略
以下列出了可能需要建立分支的理由:
? 为了在对前一个开发版本进行支持的同时开发下一个版本。
? 将一部分功能的开发与主线开发隔离,待这些功能基本稳定之后,再合并回主线。
? 为不同的客户版本产生分支,每一个分支都是主线的一个“变异(variant)”。这种方式存在致命缺点,会造成在不同的分支之间合并变更非常困难。因此,建立这样的分支必须存在特别的理由。更为合理的方式是,通过软件架构的设计,将与变异有关和与变异无关的部分分离,以定制的方式实现变异。
培训五:FB处理流程
FB处理流程:
当FB为assign状态时,第一处理人为测试。处理时间不能超过两天。
1) 操作错误产生的问题:
对于操作错误产生的问题我们不做处理,直接将FB submit掉,并且submit时详细描述一下正确的操作如何,以告之现场工程人员。
2) 软件bug问题:
接到FB后,首先要判断该FB是需求问题还是软件bug(区分时可参考FB问题类别)。
若FB描述的是软件的问题,必须在系统中验证确实存在该问题时方可转主线实现MR。如果遇到无法重现的问题,例如脏数据问题,需要现场协助导回现场库,在现场库上验证后方可转主线实现MR。
3) 需求问题:
若是需求问题可直接提需求MR(需求问题包括现场的新需求、要求提供刷新脚本、要求软件实现某种功能等等)。
需求MR处理方式有两种:
? 需要实现的需求,待需求处理完将MR submit后,测试需要即刻将需求MR转为主线实现MR,修改测试用例,将该需求MR pass。
? 不需要实现的需求,带需求将需求MR submit后,测试需要根据需求的描述,将FB直接submit掉,并且详细说明不提供原因。
4) 当PM决定某些FB需要发布时,方可将主线的实现MR再转分支实现MR。
5) 补丁发布后需要将对应的FB submit掉,并且submit时需要填写处理结果,及补丁所在patch目录。
6) 补丁发布时在gxlu-store上做好备份,然后发信给潘峥,抄送给PM及整个测试组,由潘峥统一放到FTP上。发信内容需包含:补丁所在gxlu-store上的目录、需放到FTP哪个目录下。
补充:
● 公司规定的FB的整理、发布与跟踪
Patch发布、跟踪由PM负责,执行流程如下:
流程说明:
1、 补丁发布由PM定期或者不定期组织进行,定期的补丁例如版本稳定之后每月的例行补丁,不定期的补丁根据现场反馈问题的情况而定,在试点推广阶段一般为每周发布一次
2、 由PM负责收集补丁发布所要解决的问题,记录到《软件补丁发布跟踪表》中,问题来源是FB系统或《现场问题反馈表》和MR。PM填写的内容包括:问题描述、问题来源、类别、发布范围、负责人
3、 补丁提交测试之前,PM将《软件补丁发布跟踪表》提交ST的测试负责人,ST的测试负责人负责测试每一个问题,并填写以下内容:MR编号、如何验证、测试结果、发布日期
4、 ST测试补丁的
:所有问题都验证通过,并且没有引发新的问题
5、 ST测试如果不通过则将补丁退回SW修改,并通知PM,在SW修改完毕之后再次提交ST测试;如果测试通过,ST的测试负责人将《软件补丁发布跟踪表》提交PM
6、 PM收到ST提交的《软件补丁发布跟踪表》后,当天向TSHELP提交补丁发布通知和《软件补丁发布跟踪表》(目前由ST直接发信通知)
7、 TSHELP在接收到补丁发布通知后,24小时之内通知各地现场的TS进行补丁升级,并搜集各地TS的反馈信息,填写以下内容:现场验证完成时间、现场验证情况
8、 补丁发布成功的标准:无论此次发布版本或补丁解决的问题是否全部验证通过,只要无以下问题即认为安装成功:1.影响系统正常运行;2.无法正常使用功能,影响现场实施进度
9、 TSHELP根据各地补丁升级的情况维护《现场版本安装跟踪表》,无论升级是否成功都需如实进行记录。
10、 如果补丁发布成功,则TSHELP将《软件补丁发布跟踪表》反馈给PM,PM归档《软件补丁发布跟踪表》至文档基线库:项目名\Project_Management\Project_Tracking\,本次补丁发布活动结束
11、 如果补丁发布失败,则整个流程回退到ST测试阶段,继续第5步,流程继续运转
12、 如果补丁发布成功,但是现场反馈还有个别小问题没有解决,或者补丁引发了另外的小问题,则这些问题进入FB系统,重新开始一个新的补丁发布流程。