为了正常的体验网站,请在浏览器设置里面开启Javascript功能!

测试流程培训

2020-03-09 15页 doc 41KB 2阅读

用户头像

is_751406

暂无简介

举报
测试流程培训培训一:创建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及提交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系统,重新开始一个新的补丁发布流程。
/
本文档为【测试流程培训】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。 本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。 网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。

历史搜索

    清空历史搜索