项目测试规范流程讲解.docx
- 文档编号:24326705
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:19
- 大小:63.77KB
项目测试规范流程讲解.docx
《项目测试规范流程讲解.docx》由会员分享,可在线阅读,更多相关《项目测试规范流程讲解.docx(19页珍藏版)》请在冰豆网上搜索。
项目测试规范流程讲解
软件项目测试规范流程
奥尊公司测试部
2012年9月
修订历史记录
日期
变更版本
变更描述
作者
2012/9/13
新增
王志芳
1.概述4
1.1软件测试的目的4
1.2软件测试的原则4
1.3对软件测试的错误认识4
2.软件测试过程6
2.1测试过程6
2.2角色与职责9
3.关键活动定义11
3.1测试准备11
3.2测试方法设计11
3.3测试计划11
3.4计划评审12
3.5文档评审12
3.6测试用例及评审12
3.7环境准备12
3.8测试执行13
3.9缺陷汇报/分析13
3.10回归测试13
3.11随机/异常测试14
3.12阶段报告14
3.13测试报告14
4.测试文档简述14
4.1开发转测试确认表15
4.2需求变更控制文档15
4.3问题修复清单16
4.4测试计划16
4.5测试脚本(用例)16
4.6问题报告16
4.7缺陷分析文档16
4.8测试报告文档16
1.概述
1.1软件测试的目的
•软件测试是为了发现错误而执行程序的过程
•测试是为了证明程序有错误,而不是证明程序无错误
•一个好的测试用例是在于它能发现至今未发现的错误
•一个成功的测试是发现了至今未发现的错误的测试
1.2软件测试的原则
•软件测试的原则之一:
GoodEnough这是一种权衡投入/产出比的原则,测试既不要不充分,也不要过分。
不充分和过分都是一种不负责任的表现。
Zero-bug是一种理想,Good-enough是我们的原则。
•软件测试的原则之二:
EarlyBest越早发现错误,因错误而导致的损失就越小;所以测试工作必须贯穿软件开发的整个生命周期,以期尽早发现软件中的错误。
那些认为只需在软件开发完成后再进行系统测试的观点是错误的。
•软件测试的原则之三:
bug的80%原则
一般情况下,在分析、设计、实验阶段的复审和测试工作能够发现和避免80%的bug,
而系统的软件测试能够找出其余bug中的80%。
最后约5%的bug只有在用户大范围、长时间的使用后才会暴露出来。
因此测试只能保证尽可能多地发现错误,不能保证发现所有的错误。
1.3对软件测试的错误认识
•对测试的错误认识
(一):
完整的测试是可能的——在实际操作中,完整的测试是不可能的。
——从理论上说,完整的测试也是不可能的。
•对测试的错误认识
(二):
存在一个可以定义的测试终结点
——测试通常是在时间用完时结束
测试是一份令人厌倦的工作
•对测试的错误认识(三):
测试和调试没有什么区别,除了支持调试外,测试没有别的目的
——测试是查找潜在的错误,调试是定位已知的错误
——测试贯穿于整个软件生存期,调试主要是在软件开发过程中
——测试是发现问题,调试解决问题
——测试与调试不能相互替代,但可相互支持,相辅相成
•对测试的错误认识(四):
测试是件很简单的工作,无需设计——测试是一项具有很大创造性的工作,其工作量一点也不比代码设计小——测试是需要设计的,一个好的测试计划或方案往往能达到事半功倍的效果——测试设计可以是自动的,半自动的或手工编写
2.软件测试过程
2.1测试过程
对需要测试的任何产品,都需要有一个测试的进入标准、测试执行的开始标准、测试执行的结束标准以及测试执行好坏的评价标准。
本文所定义的测试流程,也遵循这么一条基本主线,其过程主要包括测试的进入、执行、报告、分析、结束。
测试的进入往往是在需求分析即将结束时进行的,这样测试过程与开发过程基本同步,有助于尽早发现系统设计的问题;这样做的另一好处还在于测试准备充分,开发结束可立即进入测试阶段,有助于缩短项目进度。
测试执行前的准备工作对于测试来说是至关重要的,这些准备工作主要包括从系统需求分析报告和概要设计文档里面获取产品信息及产品功能特点,并对此进行相关的分析、总结,然后进行测试设计:
包括选择测试方法,确定测试内容、测试工具,结合产品特点确定是否进行性能、负载、压力、安全等方面内容的测试;制定测试计划;制定详细测试执行计划及设计测试案例。
下图是测试过程的结构层次图,通过这个图,我们可以看到整个产品从需求到产品交付的过程中,测试和开发之间的关系以及对应的测试过程。
开发过程
需求分析
系统设计
编码
需求分析
测试过程
报告
系统设计说明
测试准备
单元测试
集成测试
产品转测试
修复/新版产品
单元测试
报告
集成测试
报告
问题修复清单
测试方法设计
测试计划
计划评审
文档评审
测试用例及评审
环境准备
测试计划
测试用例
文档评审
记录
测试执行
回归测试
缺陷汇报/分析
问题报告
随机/异常测试缺陷汇报/分析
问题报告
阶段报告
阶段测试报告
从上图我们可以看出测试任务的具体工作流程:
1、系统设计阶段测试经理开始确认测试项目,熟悉和了解用户需求,配合开发做相关资源准备。
2、编码、单元测试和集成测试阶段根据系统设计,制定和设计大体的测试框架,包括可能用到的测试方法,测试工具,确定测试人员,熟悉测试产品的功能设计,储备对应的测试需求的技术知识,进行必要的测前技术培训,对测试任务进行大致的时间计划和人员安排。
在完成上述相关准备之后,开始进行详细的测试设计,编写测试计划和测试用例,并对此进行评审。
对有性能需求测试的进行性能测试设计。
即:
组建测试项目组,确定测试项目经理和组员熟悉产品功能设计分析可能实施的测试方法
考虑可能需要的测试工具支持
分析测试人员具备的技术需求
完成初步的产品测试进度分析按照功能模块进行人员分工进行必要的测前技术培训
编写测试计划,并进行项目内评审编写测试脚本(用例),并进行开发参与的项目评审。
对有性能测试、负载测试及安全测试需求的,设计专门的测试方法和用例。
3、新版本转测试阶段检测开发转测试的版本附属的文档是否全面,如果开发转测试文档齐全,组织测试项目组的成员遵照评审后的测试计划,开始测试执行;对发现的问题进行记录汇报;对每个版本发现的问题进行分析。
即:
检测转测试文档是否全面,并填写验收证明文档,其中应该包括:
☉系统设计(用户需求说明书)
☉需求分析报告
☉产品基线及说明文档
☉产品安装文件包
☉客户端、服务器、数据库安装、配置说明文件
☉单元测试报告及记录
☉集成测试报告及记录注:
以上非黑色字体文件为必须提供的文档,文档提供不全或开发拒绝协商,测试有权拒绝该产品的测试。
严格遵照测试计划和测试用例的测试执行
问题记录和BUG报告
当前版本的缺陷分析
4、修复版本巡回测试阶段
测试接到修复后转测试新版本,检测对应的版本控制记录,测试进行对应版本的回归测试,完成相应的脚本测试,并开始做随机测试和异常测试,同时对发现的问题进行记录汇报,对每个版本发现的问题进行分析。
即:
检测修复后转测试版本的版本控制记录
完成上个版本在当前版本上的回归测试严格遵照测试计划和测试用例的测试执行增加多条件激发的随机测试执行系统异常测试问题记录和BUG汇报当前版本的缺陷分析
5、验收测试产品测试达到测试结束标准时,停止测试,对整个产品的缺陷进行分析;组织相应的人员进行验收测试,测试通过后,进行产品发布。
衡定产品是否达到测试设计的结束标准
对产品缺陷进行分析
组织验收测试
出验收测试报告
2.2角色与职责
1、测试经理
——估算项目测试的工作量及时间进度
——与项目经理协调安排测试进度与测试人员,制定测试计划
——组织需求分析文档与设计文档的评审,提交评审结果
——组织测试案例的编写
——管理测试过程
——出具测试阶段报告、总结报告
——管理与归档各类测试文档
2、测试工程师
根据项目需求及性质,决定测试过程所使用的测试技术、测试方法及测试工具
搭建测试环境
编写测试案例编写测试程序
根据测试案例进行测试并记录测试过程
3、测试员
——根据测试案例进行测试并记录测试过程
4、文档管理员
——准备文档环境
——汇总提交测试记录
——根据测试记录汇总并编排测试文档
3.关键活动定义
3.1测试准备
负责人测试经理
参与人主要测试工程师
活动形式解读项目资料,与主要开发人员交流
目的熟悉项目需求,了解项目设计思想、设计方法与设计方案;基本确
定测试范围与测试方法
输入业务需求书、方案建议书、需求分析报告、系统总体设计
输出项目测试的范围与相应的测试方法
过程1、项目经理或主要开发人员对相关测试人员进行简单的业务培训
与技术培训,使之具备阅读项目资料所需的基本素质;
2、测试人员阅读项目资料,必要时可以与主要开发人员进行短时交流;
3、根据项目实际需求确定测试范围与测试方法。
备注
3.2测试方法设计
负责人测试经理
参与人测试工程师
活动形式根据测试需求,有针对的对测试任务进行具体的测试方法设计
目的让测试有效而简洁,尽量避免重复劳动,指导测试用例的编写,从
而提高效率
输入需求分析报告、系统概要设计文档
输出具体的测试方法如:
临界值法、二分法、零值法、异常法等
过程1、测试经理组织项目组成员对测试任务进行分析;
2、制定时宜的测试策略,
3、根据测试策略制定具体的测试方法
备注
3.3测试计划
负责人测试经理
参与人测试工程师
活动形式规划测试过程;编写测试计划
目的根据项目进度要求与预算要求、测试估算值制定相对平衡的测试计
划
输入需求分析报告、系统概要设计文档、测试估算值
输出测试计划
过程1、熟悉系统需求和概要设计
2、结合测试资源,合理对测试行为进行规划安排
3、根据测试任务进行测试时间合理分配,制定好每个里程碑任务
4、产生指导整个测试行为的测试计划
备注
3.4计划评审
负责人
参与人
活动形式
目的
输入
输出
过程
4、多余无用内容
测试经理
项目主管高管、测试部经理、项目经理阅读测试计划;召开评审会议;签字确认相关部门、人员认可测试计划
测试计划
测试计划评审表
1、评审测试计划是否合理
2、审核测试内容是否全面
3、审核时间里程碑是否合理
备注
3.5文档评审
负责人测试经理
参与人主要测试工程师
活动形式钻研文档、挑毛病;与设计人员探讨
目的在系统开始全面开发前找到系统设计中隐含的缺陷
输入需求分析报告、系统概要设计文档
输出文档评审记录
过程对测试相关的资源文档进行评审,找出并规避:
1、错误内容2、误导内容3、不可实现内容备注
3.6测试用例及评审
负责人参与人活动形式目的输入输出过程
测试经理
测试工程师钻研开发文档、编写测试案例;编写测试案例所需程序完成测试过程所需测试案例的编写需求分析报告、系统概要设计文档、测试计划测试用例
1、对测试用例的正常功能区域的覆盖点进行评审
2、对测试用例的逻辑和结构进行评审
3、对用例中包含的异常覆盖进行评审
4、对激发条件的多重性进行评审
备注
3.7环境准备
负责人
参与人
测试工程师开发工程师、系统工程师
活动形式与系统集成部人员一起进行环境安装;安装所需测试工具、测试程
序
目的根据测试计划搭建测试环境
输入测试计划
输出搭建好的测试环境
过程按照测试条件协调各方资源,进行测试环境搭建
备注
3.8测试执行
负责人测试经理
参与人测试工程师、测试员、文档管理员
活动形式测试
目的按照计划与测试案例执行测试过程,寻找系统缺陷
输入测试计划、测试案例
输出测试问题记录
过程1、建立满足测试条件的测试环境
2、根据测试用例进行测试执行
3、记录发现的缺陷并提交给测试经理确认
备注
3.9缺陷汇报/分析
负责人测试经理
参与人测试工程师
活动形式对版本发现的问题或者整个系统发现的问题进行汇报/分析
目的发现产品缺陷的分布和提高产品开发质量,最大的降低维护成本
输入Clearquest测试问题记录,版本资源文档,测试计划
输出缺陷分析报告
过程1、对所有问题进行分类、统计、分析
2、得出缺陷存在的周期曲线和分布功能区域图
3、周知项目组成员,督促提高开发质量
备注
3.10回归测试
负责人测试经理
参与人问题发现测试工程师或项目组相关测试工程师
活动形式设定原问题发现条件,再次检测修复后的系统是否还存在该问题
目的验证问题的修复情况
输入测试案例,系统资源文档
输出回归测试记录,clearquest中问题状态的改变
过程1、建立原用例测试环境
2、进行验证测试执行,并记录对应的结果
3、修改问题单在clearquest中的状态
备注
3.11随机/异常测试
负责人测试经理
参与人项目相关的测试工程师
活动形式根据自己对系统的了解,设计随机测试用例目的发现通过正常途径难以发现的隐藏问题
输入随机测试条件
输出
问题记录单
过程
1、
自定义随机测试条件
2、
安条件进行测试执行
3、记录测试结果备注
3.12阶段报告
负责人测试经理
参与人测试工程师
活动形式汇总分类测试数据;统计;根据缺陷分布找规律
目的统计分析测试记录;根据统计数据重新规划下一阶段测试计划
输入测试问题记录
输出测试阶段报告
过程1、分析阶段测试结果,包括阶段目标的实现,阶段内的测试方法、
测试发现的缺陷、测试策略等进行分析
2、得出阶段测试报告
3.13测试报告
负责人
参与人
活动形式
目的
输入
输出
过程
备注
测试经理
汇总分类测试数据;统计;根据缺陷分布找规律统计分析测试记录;根据统计数据评估软件质量与开发过程质量测试问题记录、测试阶段报告
测试总结报告
1、汇总测试数据
2、分类统计和分析这些数据,尽可能的找出其规律性
3、参考测试报告模板出测试报告
备注
4.测试文档简述
4.1开发转测试确认表
开发产品名称
是否具备
提供者
备注
《需求分析报告》
项目开发组
《系统设计说明书》
项目开发组
《产品安装配置说明书》
项目开发组
《单元测试报告》
项目开发组
《集成测试报告》
项目开发组
产品基线说明
配置管理组
产品安装包
项目开发组
其它
每个被测产品转到测试部,测试部需要检测产品配套的文档文件。
其中包括:
1、需求分析报告
2、系统设计说明书
3、产品安装配置说明书
4、单元测试报告
5、集成测试报告
6、产品基线说明
7、产品安装包注:
1、不同的产品,提供的文件可能不同,有些文件有,有些文件没有,可以根据具体情况和开发进行沟通,如果确实存在必备文档不能提供,测试可以考虑暂缓该产品的测试。
2、测试如果对得到的相关文档存在理解困难,需时和文档提供者保持联系,并及时解决。
3、提供的文档如果和系统本身功能存在大的差异,测试有必要和项目经理进行沟通确认。
必要时也可以考虑暂缓该产品的测试。
4、《产品安装配置说明书》在转测试时可以不提供,此时开发组必须辅助进行测试环境的安装配置。
5、单元测试报告、集成测试报告在转测试时可以不提供,此时测试组应先进行产品的单元测试、集成测试后才可以开始后续测试工作。
4.2需求变更控制文档
在测试过程中,开发对已经转测试产品的需求文档进行变更时,必须进行变更控制记录,并及时通知测试人员。
具体需求变更控制文档模板请参阅开发过程。
文档名称
功能编号
原内容
变更为
备注
4.3问题修复清单
对开发修改后的每个转测试版本,回归测试前开发组必须进行明确的说明,记录对应的服务器、数据库、客户端的修改情况和变化情况,从而避免测试的重复劳动,以便快速的回归问题,发现因为修改而引入的其它问题,改变测试策略和方针,修复测试漏洞。
版本
问题号
修改说明
问题修改人
4.4测试计划其中包括测试环境说明、测试时间安排、测试工作量估算、测试人员配置、测试方法、测试的主要内容、测试风险及测试标准说明等。
详见测试计划模版文档
4.5测试脚本(用例)
详见测试用例模板文档。
4.6问题报告
该文档详细记录了bug的发现过程和bug的产生特征。
详见问题报告模板文档。
4.7缺陷分析文档该文档是针对测试产品缺陷进行分析的一个文档,主要分析缺陷产生的区域、缺陷的类型、缺陷引入的条件和触发者、缺陷的严重程度、缺陷的版本分布情况等,是对每个测试版本的一个简单分析。
4.8测试报告文档测试报告是对整个产品的测试情况进行分析的一份详实报告,它从测试计划开始,到测试内容、测试结果、缺陷情况、版本缺陷情况等进行相关的统计汇报。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 测试 规范 流程 讲解