测试过程控制程序

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

报告版本:

页数:

测试过程控制程序

编制人:王庆

审核人:

批准人:

日期:

修改历史记录

(测试过程控制程序)

目录

1目的 (1)

2范围 (1)

3定义 (1)

4角色和职责 (1)

4.1测试经理 (1)

4.2研发经理 (1)

4.3项目经理/产品经理 (2)

4.4测试工程师 (2)

4.5研发工程师 (2)

4.6质量保证员 (3)

5活动 (3)

6研发阶段测试入场标准 (4)

7验收阶段测试入场标准 (5)

8测试暂停/终止标准 (5)

9测试停止标准 (6)

10测试程序包/更新包控制 (6)

测试过程控制程序

1目的

本文为了旨在规范项目/产品的测试流程,明确相关角色职责,定义测试入场/测试停止等测试关键点应具备的条件以及在相关环节出现问题后的整改措施。

2范围

本规程适用于公司所有项目/产品的内部测试工作。

3定义

由于软件测试是一项复杂的工程,在以往的测试工作中,测试人员都是对程序进行反复的、无休止的测试,无畏的消耗了大量的人力、物力和时间成本,为了能够提高项目/产品的质量,减少重复工作,降低项目/产品的制作成本,所以制定了如下标准:

1. 研发阶段测试入场标准:在研发阶段可以启动测试工作的标准;

2. 验收阶段测试入场标准:在验收阶段可以启动测试工作的标准;

3. 测试暂停/终止标准:当测试过程中遇到重大问题时停止本项目测试工作的标

准;

4. 测试停止标准:当产品质量达到出厂标准时,测试工作可以停止的标准。

4角色和职责

4.1测试经理

⏹参与需求、设计文档评审;

⏹制定测试计划(方案);

⏹组织测试人员编写测试用例、自动化测试场景用例、执行测试用例、发

布阶段性测试报告和验收报告;

⏹组织测试人员对系统中可自动化部分的功能确认,从测试用例中筛选

自动化场景测试用例;

⏹组织自动化测试工程师对研发人员的自动化工具培训。

⏹组织测试计划、测试用例、测试报告的评审;

4.2研发经理

⏹参与需求文档的评审及项目/产品交付清单的确认;

⏹制定研发计划;

⏹组织编写设计文档、系统安装部署手册;

⏹组织设计文档评审;

⏹组织研发人员根据设计文档完成系统开发;

⏹参与测试用例、自动化用例评审;

⏹组织研发人员在自动化测试工程师的指导下,制作自动化脚本;

⏹组织研发人员修改Bug;

⏹根据入场测试/验收测试的要求组织研发人员制作测试版本;

⏹参与验收测试评审,确认测试报告的发布;

4.3项目经理/产品经理

⏹提供项目验收清单;

⏹组织咨询顾问(业务分析师)完成需求文档;

⏹组织需求文档的评审;

⏹参与设计文档、测试用例、测试报告的评审;

⏹组织项目/产品总结会

4.4测试工程师

⏹编写测试用例并提炼出自动化测试场景用例;

⏹执行测试用例,对所发现Bug进行追踪;

⏹对研发发布的测试版本进行测试;

⏹编写测试报告;

⏹参与需求、设计评审会。

⏹在验收测试时,根据项目交付清单要求,对提交的文档进行审查;

4.5研发工程师

⏹参与需求文档评审;

⏹编写设计文档、部署文档

⏹根据设计文档开发系统功能;

⏹修改系统Bug;

⏹根据自动化场景测试用例,制作自动化脚本并维护;

4.6质量保证员

⏹签署项目开发过程相关规范推行力度的审核意见

⏹签署项目质量保证意见

5活动

验收流程图如下

功能开发

根据需求和设计文档编写测

试用例用例评审(筛选出自动

化测试用例)

制作自动化脚本

入场测试

需求/设计文档版本自测(结合自动化脚本)

验收测试(封板测试)

发布正式版本

⏹项目经理/产品经理、研发经理按照合同规定及管理要求,准备项目的产品

资料,需求文档、设计文档、部署安装文档等;

⏹研发人员在接收到经过评审的需求、设计文档后进行系统功能研发工作;

⏹测试人员在接收到经过评审的需求、设计文档后进行测试用例的编写;

⏹测试人员在编写完成测试用例后,由测试经理组织用例评审,并筛选出制作

成自动化脚本的测试用例;

⏹研发人员在完成系统功能研发后,根据测试人员提交的自动化场景测试用

例,完成自动化测试脚本;

⏹研发人员执行自动化脚本完成功能自测工作,自测通过后发布测试版本;

⏹测试人员在测试环境上部署测试版本,并进行冒烟测试,核查研发自测工作

成果;如果遇到严重问题(参见第8章测试暂停/终止标准),需要测试版本

要打回重新修改,如果遇到一般问题,则继续测试,同时研发人员要在下一

个版本发布时修改相关问题;

⏹冒烟测试通过后,进行正常测试工作,在测试版本中所发现的问题要根据

《BUG管理规范》在相应的管理工具中提出问题,并跟踪问题修改直至问题

解决;

⏹研发人员在BUG管理工具中跟踪系统当前发现的问题,并及时进行BUG修

复并按计划发布修复版本至测试部门,直至问题修复;

⏹当在测试过程中出现了需求变更、或者设计变更时,项目经理要组织咨询顾

问(业务分析师)对需求文档进行修改、研发经理要组织研发人员对设计文

档进行修改;文档修改后要进行评审,并上传至SVN中以便研发人员和测

试人员使用;

⏹研发人员和测试人员在收到更改确认后的需求和设计文档后,要进行功能

的修改和测试用例的修改;

⏹项目经理/产品经理、研发经理在确认当前版本满足验收测试(封板测试)

要求后,要召开验收测试启动会,并组织研发人员编制验收测试版本安装

包。

⏹研发人员在验收启动会后制作验收版本安装包,并结合自动化脚本进行版

本自测,自测通过后提交给测试部门。

⏹测试经理在接到验收测试版本后组织测试人员在测试环境上部署,部署完

成后进行冒烟测试检查研发人员自测成果;

⏹如果验收测试过程中发现问题,在测试停止后,需要项目经理/产品经理、

研发经理重新提交材料。

⏹验收测试通过后,测试负责人提交《验收测试报告》。

⏹项目经理/产品经理负责签署《验收完成确认单》。

⏹测试人员发布项目/产品正式版本。

6研发阶段测试入场标准

⏹测试版本中的系统功能和版本说明中的功能(包含修复功能)要一致;

相关文档
最新文档