2022年测试流程培训 .pdf

《2022年测试流程培训 .pdf》由会员分享，可在线阅读，更多相关《2022年测试流程培训 .pdf（11页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、1 培训一：创建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 的分析；如果是从

2、FB 直接过来的实现MR，则需详细填写验证过程、错误数据及问题的详细描述。测试 MR PW10MR-132PW10MR-131创建测试MR 时：1） MR Type 字段根据问题性质选择；2） Severity 字段需严格把握MR 等级；3） MR 中需包含问题的具体操作路径，详细的问题现象描述等。现场 FB VASFB-1245提交现场FB 时：1） Submit 时需描述问题是如何解决的，该点可以从开发submit 实现 MR 中查看到；2） Submit 时需描述补丁发布版本号；3） 若补丁通过工具发布，需说明发布路径。名师资料总结 - - -精品资料欢迎下载 - - - - - - -

3、 - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 11 页 - - - - - - - - - 2 培训二： MR 系统及 patch系统申请方法申请 MR 系统需通过邮件发信给，发信格式如下：主题：申请分支（主线）MR 系统内容：刘勇，你好！申请分支（主线）MR 系统北方 PROJECTWORKS20100128分支MRB：刘丽PM：孔悦SHORTEN NAME ： PW1020100128其他属性的请复制：北方 PROJECTWORKS需求跟踪申请 patch 系统：所属项目：新建所属项目：PROJECTWORKS 提交 patch类别

4、：dbforora client server dbmetadata dbmodel_gis dbmodel_nongis dbmodel_project dbview_gis dbview_nongis dbview_project nova_db nova_webserver webserver 申请的 MR系统名称，如果申请分支，需要在名称中体现分支版本号。如果 Severity、MR Type、Lithosphere Module 、Centrosphere Module等属性需要和某个MR系统一致，可以在此复制指定 MR系统的属性。如果申请分支MR系统，需要同时申请patch 系统，

5、 并且申请 patch系统时，需要考虑所属项目是新建还是与其他MR系统所属项目相同，并给出所属项目的英文简称。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 11 页 - - - - - - - - - 3 培训三：编译分类及编译步骤编译种类1. 日常编译作用 定期编译，由脚本自动完成,主要用来检查主线上的代码步骤 制定任务计划，每天自动定时执行编译 若发生编译错误，由Builder 发信通知相关的开发人员修改 完成编译后，将软件包提交到CVS 用新编译的软件包更新开发环

6、境2. 主线编译 (出 Load版本 ) 作用 软件开发到了一定阶段。需要对开发的新功能进行测试。 根据项目计划，由PM 发起编译步骤 根据项目计划， PM 发布主线编译通知 开发和 DB 人员根据通知，提交代码和脚本 Build 进行编译（若有编译错误，则通知相应的开发人员） 完成编译后，提交给测试人员 测试人员对主线版本进行测试（针对新功能进行测试）3. 分支编译：（发布版本）作用 项目进展到一定阶段，需要提供版本发布给客户 经过几个主线版本的测试，待版本稳定后分支 测试对分支版本进行全面的回归测试步骤 根据项目计划， PM 发布分支编译通知 开发和 DB 人员按时提交代码和脚本（分支的脚

7、本） Builder 进行编译（若有编译错误，则通知相应的开发人员） 完成编译后，提交给测试人员 测试人员对分支版本进行测试（回归测试）名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 11 页 - - - - - - - - - 4 编译步骤这里定义的是一般性的编译步骤，如有特殊的编译步骤，请在SCM 计划中详细说明。1) PM 确定，向SCM 提交 build 计划，即 “测试及对外发布子系统列表” ；2) Builder 在项目编译前一天，应通知 （E-mail ）相

8、关人员及部门编译的计划与时间等信息（如下） ：E-mail 主题为：“ XXXX 、XXXX项目 9:00 集成 build,主干 或分支 ”Build 时间： 2003/11/5(星期三 ) 9:00 Build 项目 ：Project_nameBuilder 担当 ： （ SCM 组 builder ）3) 邮件作用：a) 在指定时间前，开发和DB 人员提交代码和脚本到cvs b) 在指定时间后，开发和DB 人员停止提交代码和脚本，直到编译完成4) DB 人员在编译开始之前（收到 build 计划的 E-mail 之后），需完成数据库脚本在CVS 上的提交。如果不能及时完成提交，需通知Bu

9、ilder （如果没有类似提醒，则默认数据库脚本已经提交）。原则上Builder不会推迟编译时间点，只有在编译的过程中（中断编译时）或编译结束后，再行通知DB 人员完成脚本提交。Builder在确认 DB script 脚本提交后方可进行后续的提交工作。通常测试会在编译前5 分钟发信提醒即将编译。5) 由 Builder 执行 build 任务（参照日常编译步骤）；6) 编 译 完 毕 后 ， PM 如 有 “ 分 支 申 请 表 ”， 则 对 所 有 子 系 统 先 打 主 干tag Project_name_INT_TAG_buildno， 再 打 分 支tag 。 分 支tag的 格 式

10、 如 下 ：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 之间的关系，相关人员可以参照Builde

11、r 发出的提交ST 的“测试及对外发布子系统列表”；9) build 成功后，提交ST，并通知（ E-mail ）相关人员及部门，信息格式如下：E-mail 主题为：“XXXX 、XXXX项目主干 或分支 编译成功 ”TAG名称： Project_name_INT_TAG_buildno分支名称： BRANCH_Project_name _INT_TAG_buildno（如有分支，则也需将分支名称发出）名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 11 页 - - -

12、- - - - - - 5 培训四：软件从测试到发布流程Load1.0Load2.0,分支 20090101版本主线 MR 系统分支 MR系统生成Load：Load1.0版本Load：Load2.0版本,综合资源 20090101版本分支 MR 系统分支代码生成分支代码主线代码申请主线 MR 系统1、新增版本号Load1.02、编译 Load1.03、测试 Load1.01、新增版本号Load2.02、编译 Load2.03、验证 Load1.0中已经 submit的MR ，没有问题即可 pass。4、测试 Load2.05、直到系统相对稳定，或相对稳定的功能需要发布现场1、分支编译2、打主线

13、 TAG3、分支 TAG申请创建分支MR1、主线 MR 中新增分支版本号2、将主线 assign状态的 MR 创建关联分支MR 到分支 MR 系统3、验证主线 submit状态的 MR ，没有问题后pass ，如果有问题继续assign ，并创建关联的分支 MR 。软件发布,名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 11 页 - - - - - - - - - 6 1、申请主线MR 系统。当软件启动以后，在软件第一个load 版本生成之前要申请主线MR 系统。软件目

14、前处于主线开发阶段。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）

15、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 来决定哪些关联到分支中

16、。）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。如果没有通过则继续

17、assign 给开发，并描述问题现象。如果问题比较严重，需要在分支中修改的，同时创建关联的分支MR 到新的分支MR 系统中。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 11 页 - - - - - - - - - 7 6、分支版本发布。分支发布时除了软件介质外，还需要发布用户手册以及安装手册，具体目录为：-tosaip软件包-db数据库升级脚本-doc用户手册、安装手册-patch软件 patch 补充：分支策略以下列出了可能需要建立分支的理由：为了在对前一个开发版本

18、进行支持的同时开发下一个版本。将一部分功能的开发与主线开发隔离，待这些功能基本稳定之后，再合并回主线。为不同的客户版本产生分支，每一个分支都是主线的一个“变异（variant）”。这种方式存在致命缺点，会造成在不同的分支之间合并变更非常困难。因此，建立这样的分支必须存在特别的理由。更为合理的方式是，通过软件架构的设计，将与变异有关和与变异无关的部分分离，以定制的方式实现变异。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 11 页 - - - - - - - - - 8

19、培训五： FB 处理流程FB需求MR主线MR判断需求还是软件 bug软件 bug需求问题需求是否修改修改的，创建主线MR，同时修改测试用例，并将需求MR pass不修改的，直接submit FB，并将需求 MR pass创建分支 MR并且发布补丁PM决定该 FB是否发布是如果不发布则维持现状不变补丁发布后将FB submit操作错误submit FBFB 处理流程：当 FB 为 assign 状态时，第一处理人为测试。处理时间不能超过两天。1） 操作错误产生的问题：对于操作错误产生的问题我们不做处理，直接将FB submit 掉，并且submit 时详细描述一下正确的操作如何，以告之现场工程人

20、员。2） 软件 bug 问题：接到 FB 后，首先要判断该FB 是需求问题还是软件bug（区分时可参考FB 问题类别 ） 。若 FB 描述的是软件的问题，必须在系统中验证确实存在该问题时方可转主线实现MR。如果遇到无法重现的问题， 例如脏数据问题，需要现场协助导回现场库，在现场库上验证后方可转主线实现MR。3） 需求问题：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 11 页 - - - - - - - - - 9 若是需求问题可直接提需求MR（需求问题包括现场的新需求

21、、要求提供刷新脚本、要求软件实现某种功能等等）。需求 MR 处理方式有两种：需要实现的需求，待需求处理完将MR submit 后，测试需要即刻将需求MR 转为主线实现MR，修改测试用例，将该需求MR pass。不需要实现的需求， 带需求将需求MR submit 后， 测试需要根据需求的描述，将 FB 直接 submit掉，并且详细说明不提供原因。4） 当 PM 决定某些FB 需要发布时，方可将主线的实现MR 再转分支实现MR。5） 补丁发布后需要将对应的FB submit 掉，并且submit 时需要填写处理结果，及补丁所在patch 目录。6） 补丁发布时在gxlu-store 上做好备份，

22、然后发信给潘峥，抄送给PM 及整个测试组，由潘峥统一放到FTP 上。发信内容需包含：补丁所在gxlu-store 上的目录、需放到FTP 哪个目录下。管线 arcgis、导入导出配置平台刘风甫 陈丽SNTNDN 、备品备件Teleworks潘峥 于青凤移动、动力、工具用电量管理Teleworks屈王锁转分支 MR及补丁验证管线arcgis、导入导出配置平台发布：刘风甫SNTNDN 、备品备件、Teleworks 发布：潘峥FB刘丽将FB转：需求 MR、主线 MR移动、动力、工具用电量管理Teleworks发布：屈王锁工程支撑管理系统刘丽 张俊工程支撑管理系统发布：刘丽将所有 FB统一提给刘丽，

23、由刘丽负责将FB分配到每个测试人员，同时跟踪每个FB的处理进度作为考核项目之一。收到 FB后，需立即处理，如果确实工作繁忙，最迟不超过两天将 FB处理完毕。需求MR 当需求 submit后，测试需立即转实现 MR待PM确定要提交到现场的FB后，再将已将转主线的MR 创建关联的分支 MR由潘峥统一放到 FTP上测试发布版本或者补丁时，统一将邮件发给潘峥，抄送给PM及整个测试组，由潘峥统一出口发给现场并放到FTP上。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 11 页 -

24、 - - - - - - - - 10 补充：公司规定的FB 的整理、发布与跟踪Patch 发布、跟踪由PM 负责，执行流程如下：补丁解决问题清单（PM）验证补丁（ST）补丁发布通知（PM）通知TS安装（TS-HELP ）现场安装（TS）现场情况反馈（TS-HELP ）软件补丁发布跟踪表软件补丁发布跟踪表软件补丁发布跟踪表软件补丁发布跟踪表版本记录维护（TS-Help ）现场版本安装跟踪表全部验证通过？Yes操作（Owner ）输出、输入文档图例：No修改补丁（SW）流程说明：1、 补丁发布由PM 定期或者不定期组织进行，定期的补丁例如版本稳定之后每月的例行补丁，不定期的补丁根据现场反馈问题的

25、情况而定，在试点推广阶段一般为每周发布一次2、 由 PM 负责收集补丁发布所要解决的问题，记录到软件补丁发布跟踪表中，问题来源是FB系统或现场问题反馈表和MR。PM 填写的内容包括：问题描述、问题来源、类别、发布范围、负责人名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 11 页 - - - - - - - - - 11 3、 补丁提交测试之前，PM 将软件补丁发布跟踪表提交 ST 的测试负责人， ST 的测试负责人负责测试每一个问题，并填写以下内容：MR 编号、如何验

26、证、测试结果、发布日期4、 ST 测试补丁的标准：所有问题都验证通过，并且没有引发新的问题5、 ST 测试如果不通过则将补丁退回SW 修改，并通知PM，在 SW 修改完毕之后再次提交ST 测试；如果测试通过，ST 的测试负责人将软件补丁发布跟踪表提交PM 6、 PM 收到 ST 提交的软件补丁发布跟踪表后，当天向TSHELP 提交补丁发布通知和软件补丁发布跟踪表 （目前由ST 直接发信通知）7、 TSHELP 在接收到补丁发布通知后，24 小时之内通知各地现场的TS 进行补丁升级，并搜集各地 TS 的反馈信息，填写以下内容：现场验证完成时间、现场验证情况8、 补丁发布成功的标准：无论此次发布版

27、本或补丁解决的问题是否全部验证通过，只要无以下问题即认为安装成功：1.影响系统正常运行；2.无法正常使用功能，影响现场实施进度9、 TSHELP 根据各地补丁升级的情况维护现场版本安装跟踪表，无论升级是否成功都需如实进行记录。10、如果补丁发布成功，则TSHELP 将软件补丁发布跟踪表反馈给PM， PM 归档软件补丁发布跟踪表至文档基线库：项目名，本次补丁发布活动结束11、如果补丁发布失败，则整个流程回退到ST 测试阶段，继续第5 步，流程继续运转12、如果补丁发布成功，但是现场反馈还有个别小问题没有解决，或者补丁引发了另外的小问题，则这些问题进入FB 系统，重新开始一个新的补丁发布流程。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 11 页 - - - - - - - - -