功能测试工作规程.docx

上传人:b****3 文档编号:4938154 上传时间:2023-05-07 格式:DOCX 页数:17 大小:139.99KB
下载 相关 举报
功能测试工作规程.docx_第1页
第1页 / 共17页
功能测试工作规程.docx_第2页
第2页 / 共17页
功能测试工作规程.docx_第3页
第3页 / 共17页
功能测试工作规程.docx_第4页
第4页 / 共17页
功能测试工作规程.docx_第5页
第5页 / 共17页
功能测试工作规程.docx_第6页
第6页 / 共17页
功能测试工作规程.docx_第7页
第7页 / 共17页
功能测试工作规程.docx_第8页
第8页 / 共17页
功能测试工作规程.docx_第9页
第9页 / 共17页
功能测试工作规程.docx_第10页
第10页 / 共17页
功能测试工作规程.docx_第11页
第11页 / 共17页
功能测试工作规程.docx_第12页
第12页 / 共17页
功能测试工作规程.docx_第13页
第13页 / 共17页
功能测试工作规程.docx_第14页
第14页 / 共17页
功能测试工作规程.docx_第15页
第15页 / 共17页
功能测试工作规程.docx_第16页
第16页 / 共17页
功能测试工作规程.docx_第17页
第17页 / 共17页
亲,该文档总共17页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

功能测试工作规程.docx

《功能测试工作规程.docx》由会员分享,可在线阅读,更多相关《功能测试工作规程.docx(17页珍藏版)》请在冰点文库上搜索。

功能测试工作规程.docx

功能测试工作规程

 

测试规范文档

编号

密级

 

功能测试工作规程

 

VERSION1.1

 

信息技术管理部

2009年8月

文档修订记录

章节编号

章节名称

修订内容简述

修订日期

修订前版本号

目录

1编写目的1

2测试类型的划分1

3测试小组构成1

3.1职责2

3.2角色划分2

4工作流程及规范3

4.1工作流程3

4.2测试提交件及裁剪说明4

4.3测试计划阶段5

4.3.1成立测试小组5

4.3.2编制测试方案计划6

4.3.3设计测试案例7

4.4测试实施阶段8

4.4.1测试准入检查8

4.4.2执行测试案例9

4.4.3缺陷管理10

4.5测试收尾阶段10

4.5.1编制测试报告10

4.5.2测试工作过程改进11

4.5.3测试资产提交12

5问题处理12

1编写目的

本文档是我行信息技术项目中功能测试小组(以下简称测试小组)的日常工作规范,主要侧重测试工作流程的控制,明确软件工程的各阶段测试小组应完成的工作。

测试技术和策略等问题不在本文档描述范围内。

2测试类型的划分

项目的开发工作完成时,一般应由开发小组在完成内部测试(含单元测试和系统内部集成测试)后,再将完成件提交给测试小组进行后续测试。

按照测试的时间先后顺序,测试小组负责的测试可以分为连接测试(LinkTest,简称LT)、系统集成测试(SystemIntegrationTest,简称SIT),用户接受测试(UserAcceptanceTest,简称UAT)和版本检验测试(VerificationTest,简称VT)等四种类型。

有关的测试类型的概念如下:

1)单元测试是验证本系统的软件构件或模块的正确性,并由开发人员组织实施的测试。

因为一个构件或模块本身不是一个独立的程序,通常需要开发相应的驱动程序和桩模块。

2)系统内部集成测试是验证本系统应用处理的正确性由开发人员组织实施的内部测试。

一般采用自底向上或自顶向下的模块集成方法,逐步集成。

为消除其它周边相关系统的影响,可以采用请求方或应答方模拟器来模拟周边系统,比如网银模拟器或CCBS模拟器等。

3)连接测试是在跨系统的测试环境中,为消除跨系统间环境和报文接口的一般性技术缺陷而进行的短期测试,可以视为SIT阶段开始前的绿灯测试,实际工作中可根据项目实际情况将其内容纳入SIT测试阶段。

4)系统集成测试是为验证需求规格说明所定义的所有系统功能和业务功能,并且与关联系统能够正确的集成交互所进行的测试,是对整体系统功能进行全面测试和验证的过程。

系统集成测试也被称为“跨系统集成测试”。

5)用户接受测试是为验证软件实现的业务功能是否满足业务需求、是否满足业务人员的实际使用需求而由业务部门组织的测试。

用户接受测试通常由业务部门组织进行测试,此过程中本规程及相关规范只作为建议,不作为强制约束要求。

6)版本检验测试按照类似投产的版本管理要求,将待投产的版本在类似的生产环境中安装,并作回归测试,以检验投产版本质量的过程。

实际测试中可以将此阶段纳入UAT测试的最后一轮。

3测试小组构成

职责

功能测试是软件过程中的重要组成部分,肩负着如下责任:

Ø尽可能早地参与项目的需求工作和必要的应用设计工作,参与需求、设计、单元测试、系统内部集成测试等阶段的审核工作,跟踪业务需求的变更,全面理解和熟悉系统的功能需求和应用设计,从用户体验和测试的角度提出自己的看法。

Ø编写合理的测试方案和计划,并与项目整体计划有机地结合在一起。

Ø编写合理有效测试案例,保证对被测应用的覆盖。

Ø针对测试需要选择相应测试技术及策略。

Ø认真仔细地实施测试工作,进行缺陷登记与跟踪,做好复测工作,并提交测试报告。

角色划分

下面是一般情况下测试小组的角色构成,在人力资源有限的情况下,一人可以同时承担多个角色。

角色名称

相关主要责任

测试经理

●组建测试小组

●协调测试小组内外部的沟通

●编制测试方案和计划

●组织测试准入检查

●测试过程中的进度控制、风险管理

●测试过程报告

●编写测试报告

●召集测试评审

测试人员

●识别测试需求

●设计测试案例

●协助编制测试方案和计划

●协助测试准入检查

●执行测试案例,测试结果记录

●测试缺陷登记与跟踪

●协助测试评审

技术支持人员

●为测试工作提供技术支持,比如环境安装、版本布署、测试工具支持等

备注:

该角色可选,可根据项目实际情况设置

4工作流程及规范

工作流程

每项功能测试(SIT、UAT等)任务都可划分为三个阶段,每个阶段由不同的活动组成。

测试提交件及裁剪说明

下面是对各测试阶段主要工作提交件要求及裁剪说明的一览表。

部分提交件是必须的,部分提交件允许在一定条件下省略。

部分模板要求必须采用全行统一的模板(即本规范所要求的),部分模板允许各开发中心结合自身情况进行定制,部分模板允许各项目组根据情况自由决定。

阶段

提交件

必须提交

模板定义

裁剪条件说明

测试计划

QC项目创建申清单

全行统一

在不引起混淆的情况下,可与QC原有项目进行复用,不用再提交QC项目创建清单

测试方案

开发中心

1各开发中心根据测试任务的规模可自定义模板

测试计划

项目组

如果测试方案中已包括了测试计划的内容,则本文档可省略

测试方案计划评审检查表

开发中心

测试案例执行周期在3工作日以内的测试任务可省略

测试案例

开发中心

数据线有关测试任务可采用其它自定义模板

测试数据需求

项目组

各项目酌情选用

测试案例评审检查表

开发中心

测试案例执行周期在3工作日以内的测试任务可省略

测试实施

功能测试准入检查表

开发中心

测试案例执行周期在3工作日以内的测试任务可省略

QC中的测试案例执行记录

全行统一

按QC的规范进行管理

QC中的测试缺陷记录

全行统一

按QC的规范进行管理

测试日报

项目组

各项目酌情选用

测试收尾

测试报告

开发中心

可以采用各开发中心统一规定的模板代替

测试报告评审检查表

开发中心

测试案例执行周期在3工作日以内的测试任务可省略

测试工作改进报告

项目组

各项目酌情选用

测试资产清单

项目组

各项目酌情选用

测试计划阶段

成立测试小组

过程要点

详细说明

启动条件

测试任务明确,前期工作启动

工作内容

●为测试小组任命一名测试经理,同时确定测试小组的其它构成人选

●小组内进行必要的培训

●对于跨系统的测试,测试人员往往来自于多个项目或部门,工作地点可能不在一起,更需要明确小组的人员组成、职责及配合方式

●测试经理按照有关流程申请创建QC的项目和用户,并通知各方

●QC项目的创建应按照项目群的方式,把相关项目组和人员都纳入,这样才能便于测试过程中的协同和统一管理

结束条件

测试小组成立

输出产物

QC项目创建申请单

相关模板

QC项目创建申请单(含在测试管理工具(QC)使用手册中)

相关指南

测试管理工具(QC)使用手册

例外

●若以前的测试任务已成立过测试小组,则可以复用以前的组织人员和形式

●在不引起混淆的情况下,可与QC原有项目进行复用,不用再提交QC项目创建清单

责任人

项目经理

参与人

测试经理

编制测试方案计划

过程要点

详细说明

启动条件

项目计划确定

测试目标、范围等已确定

工作内容

对于有多次投产版本的项目,须按照每次不同的待测版本编写相应的测试方案和计划。

测试方案至少包括以下关键内容:

●测试目标――对本次测试的要求和要达到的目标

●测试范围――需要测试小组测试的范围,和各个测试需求的测试优先级

●工作分工——明确测试小组内部及外部配合方的相关责任和工作关系

●测试环境――使用什么样的测试环境进行本次测试

●测试策略——整体测试的总体测试策略、方法和工具等

●版本管理――测试过程中版本如何管理、不同系统间的版本更新协同方式

●完成标准――达到何种条件可以认为测试完成

●交付物——测试完成时应提交的工作产物,比如测试方案、测试案例、测试报告等等

●风险管理——分析测试过程中可能出现的风险及对策

测试计划至少应包括以下关键内容:

●主要任务—每项任务的时间计划、前置条件及资源

●主要里程碑——关键任务及完成时间点

测试计划可以采用project或excel等形式来编制

结束标准

测试方案计划评审通过或得到相关各方的书面认可

输出产物

测试方案、测试计划、测试方案计划评审检查表

相关模板

测试方案、测试方案计划评审检查表

相关规范

功能测试评审管理规范

例外

●对于多个系统参与的同一个测试任务,可由主项目组或牵头方统一编制测试方案和计划,不用每个系统单独编制和出具

●测试计划可以在测试方案中直接详细列明,而不用单独编制

责任人

测试经理

参与人

项目经理、测试人员

设计测试案例

在需求分析说明书确立基线以后,测试小组需要针对项目的测试范围编写测试案例。

在实际测试过程中,测试案例可根据实际需要进行更新和调整。

在案例的编写过程中,具体的任务和责任人如下:

过程要点

详细说明

启动条件

本次测试范围、业务需求已经明确

需求分析说明书已通过评审

工作内容

●准备本次测试的测试案例

⏹测试案例可以新编或复用以前积累的案例

⏹每个测试案例须包括案例编号、测试概述、测试数据、必要的操作步骤、预期结果等要素

⏹测试案例全部编制完成后,根据测试数据描述梳理出本次全部案例所需的测试数据需求

⏹案例须覆盖所有的测试需求和功能点

⏹采用统一的模板进行案例设计

●根据测试案例,整理提出完整清晰的测试数据需求,并及时着手准备测试数据

●案例全部导入QC中进行管理,便于统计、分析及跟踪

结束标准

测试案例需要覆盖所有的待测试需求或功能点,并且评审通过

输出产物

测试案例、测试数据需求、测试案例评审检查表

相关模板

功能测试案例设计、测试案例评审检查表、测试数据需求

相关指南

功能测试案例设计指南、功能异常测试案例设计参考、测试管理工具(QC)使用手册

相关规范

功能测试评审管理规范

例外

对于数据线的测试任务,可另外制定其测试案例模板

责任人

测试人员

参与人

测试经理、开发人员、项目经理

测试实施阶段

测试准入检查

过程要点

详细描述

启动条件

测试实施准备工作完成

工作内容

●测试经理根据本项目的特点,事先确定测试准入标准中哪些条目可以进行裁剪,并与项目经理或开发人员事先沟通

●准入标准中“计划准入标准”是指编制测试计划和案例设计时就需要具备的前提条件,应提前进行检查;“执行准入标准”是指在执行案例之前需要进行的检查。

以上两类检查应分两次进行

●测试经理和测试人员根据测试准入标准,逐项进行检查,并填制功能测试准入检查表

●对于不满足条件的检查项,要求相关方面进行解决,解决后重新进行检查

●对于必须要通过的检查项,而没检查通过的,视为准入检查不通过,不能进入下一阶段工作

结束条件

测试准入检查通过

输出产物

功能测试准入检查表

相关模板

功能测试准入检查表

责任人

测试经理

参与人

测试人员、项目经理、开发人员、技术支持人员

执行测试案例

过程要点

详细描述

启动条件

测试执行阶段准入检查通过

工作内容

●测试人员根据计划,执行相应的测试案例,并及时在QC中更新案例的“运行结果”状态

●测试人员进行缺陷登记,并跟踪解决情况,及时复测,关闭缺陷

●测试经理跟踪案例执行情况,了解影响案例执行的因素,及时跟进有关的协调、报告测试状态

●测试经理根据项目的情况,选择有关的报告形式,将测试进展情况及时通报给有关各方

结束条件

测试案例执行完成

输出产物

QC中的测试案例执行记录、测试日报

相关指南

测试管理工具(QC)使用手册

责任人

测试人员、测试经理

参与人

开发人员、项目经理

缺陷管理

过程要点

详细描述

启动条件

测试案例开始执行

工作内容

●测试人员在测试过程中,登记被测系统缺陷,跟踪缺陷的分析、解决过程

●开发人员及时分析处理缺陷,并按要求记录缺陷的分析处理信息,更新缺陷状态,填制缺陷起源;对需要其它人员参与分析处理的时候,需及时将缺陷分配给下一环节人员

●测试人员对待验证的缺陷需及时进行复测,测试通过后关闭缺陷

结束条件

测试案例执行完成,并且缺陷跟踪完成

输出产物

QC中的测试缺陷记录

相关规范

功能测试缺陷管理规范

相关指南

测试管理工具(QC)使用手册

责任人

测试人员、开发人员、测试经理

参与人

项目经理

测试收尾阶段

测试实施阶段结束或即将结束时,测试小组可以开始着手准备进行总结报告及收尾工作。

编制测试报告

在测试实施完成之后,测试经理需根据实施测试情况,编制测试报告。

过程要点

详细描述

启动条件

测试小组完成了所有的测试实施工作或测试时间已结束

工作内容

测试经理根据测试的结果,按照测试报告的文档模板编写测试报告,测试报告必须包含以下重要内容:

●案例执行情况分析――测试阶段案例执行的数量、轮次、通过率等

●测试过程中已发现缺陷分析――分析缺陷的数量、分布、起源等

●未执行案例的风险分析――分析未执行的案例对系统形成的风险

●未关闭缺陷的风险分析――分析未关闭的缺陷对系统形成的风险

●测试结论――评价测试方案中定义的测试完成标准是否达到,被测系统的质量评价,存在的风险,以及有关建议

结束条件

功能测试报告评审通过,发送给相关人员

输出产物

测试报告、测试报告评审检查表

相关模板

功能测试报告模板(或用户测试报告模板)、测试报告评审检查表

相关规范

功能测试评审管理规范

例外

●用户测试报告模板仅供有关用户测试时参考

责任人

测试经理

参与人

测试人员、开发人员、项目经理

测试工作过程改进

测试过程改进在测试实施阶段工作全部结束以后进行。

它的目的是评估本次测试工作,总结经验,使下一次的工作做得更好。

本项工作不是一个必须的过程,各项目可根据情况采用。

过程要点

详细描述

启动条件

测试实施阶段结束

工作内容

●测试经理召集测试参与人员,讨论本次测试过程得与失,总结经验,提出改进方法和意见

●编写测试工作过程改进报告

结束条件

测试工作过程改进报告编制完成

输出产物

测试工作改进报告

例外

可根据项目情况,裁剪本过程

责任人

测试经理

参与人

测试人员

测试资产提交

测试资产提交在测试实施阶段工作结束以后进行,对测试过程中涉及到各种标准文档进行归类,存档。

过程要点

详细描述

启动条件

测试实施阶段结束

工作内容

提交本次测试过程产生的,能为其它项目或本项目后续测试提供借鉴的,与投产版本配套的测试案例、测试脚本等

结束条件

全部资产归档完毕

输出产物

测试资产清单

例外

如果资产内容不多,结构清楚,则可以省略测试资产清单

责任人

测试经理

参与人

测试人员

5问题处理

对于测试过程中出现的争议或问题,分别提请项目经理、牵头项目组项目经理、开发中心及信息技术管理部相关条线帮助协调解决。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 解决方案 > 学习计划

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2