系统测试规程.docx
- 文档编号:23137609
- 上传时间:2023-05-08
- 格式:DOCX
- 页数:17
- 大小:241.97KB
系统测试规程.docx
《系统测试规程.docx》由会员分享,可在线阅读,更多相关《系统测试规程.docx(17页珍藏版)》请在冰豆网上搜索。
系统测试规程
软件系统测试规程
Clark
江苏华丽网络工程有限公司
修订记录
版本
修订说明
作者
审核
审核日期
1.0
编写全部
Clark
目录
1目的1
2适用范围1
3图例说明1
4规程文档结构1
5规程2
5.1进入准则2
5.2测试策划2
5.2.1流程图2
5.2.2活动描述3
5.3测试设计3
5.3.1流程图3
5.3.2活动描述4
5.4测试执行4
5.4.1流程图4
5.4.2活动描述5
5.5缺陷管理6
5.5.1流程图6
5.5.2活动描述7
5.5.3缺陷等级8
5.5.4缺陷状态8
5.6变更管理9
5.7退出准则9
5.8规程接口9
6文件清单9
7图表索引10
1目的
使软件系统测试活动是规范和有计划的
及时对软件产品进行系统测试,验证系统是否满足需求规格的定义,找出与需求规格不相符合或与之矛盾的地方
测试中发现的缺陷保证被记录、跟踪直到关闭;对项目的缺陷数据进行量化的分析
2适用范围
本规程适用于以下人员
项目经理
软件测试组
软件项目组
配置管理工程师
3图例说明
在本文中用到了以下图例,特此说明:
过程:
用于描述要执行的活动和过程;
判定点:
用于描述流程中是否满足某个条件后的分流点;
接口:
用于描述引用的接口规程;
文档:
用于描述输入、输出的文档;
开始节点:
用于表示流程的入口;
结束节点:
用于表示流程的结束;
4规程文档结构
图表1:
规程文件结构
文档结构图说明:
1.《系统测试计划》是根据项目的规模和重要性来确定,是可裁减的。
一般来说,《系统测试进度计划》是必须的。
但对于公司认定的小项目,可以没有《系统测试进度计划》,具体要求按照公司的相关规定《小项目软件过程管理指南》执行;
2.《系统测试用例》在测试管理工具TestDirector中进行编写和管理,可以根据需要导出到Word;
3.项目组可根据系统的实际需要,通过提交功能或兼容性或性能测试任务单来启动相应的测试任务,后二者的测试一般都需要在完成功能测试的基础上才可执行;
4.《缺陷记录跟踪表》是指从TestDirector里导出缺陷记录到Excel时的文件格式,测试中发现的缺陷都将使用TestDirector来进行记录、跟踪和管理;
5规程
5.1进入准则
项目启动,并由项目经理与部门(高级)经理、测试组组长商量,确定此项目需要安排独立的测试人员加入。
5.2测试策划
5.2.1流程图
图表2:
测试策划流程
5.2.2活动描述
《系统测试计划》或《系统测试进度计划》都需要项目组提供相关的项目文档作为主要编写依据;
《系统测试计划》是可裁剪的,《系统测试进度计划》是必须的(小项目除外);不管有没有编写《系统测试计划》,都需要对《系统测试进度计划》进行评审,以确保时间上能与开发进度相一致,并且保证整个软件测试活动是有序的;
《系统测试计划》的评审需要软件工程组各类成员的代表共同参与(限于篇幅在图中没有表达出来,特在此说明),评审的具体形式可根据项目开发计划中的要求进行;对《系统测试进度计划》的评审形式一般为走查;
5.3测试设计
5.3.1流程图
图表3:
测试设计流程
5.3.2活动描述
《系统测试用例》的评审需要软件工程组各类成员的代表共同参与,特别是熟悉需求和设计的代表必须参加,评审的具体形式可根据项目开发计划中的要求进行;
编写《系统测试用例》的时候,需要遵循《系统测试用例编写规范》上的具体要求。
应以《系统需求规格说明书》作为主要的依据,设计文档、实际可运行的程序雏形都可作为编写的辅助材料。
在编写过程中,应多与分析、设计人员沟通,不明确的地方以项目经理的答案作为衡量标准;
根据公司的实际情况,测试用例的编写和评审都将采取迭代的方式进行,逐步完善;在整个设计过程中,可以阶段性的部分评审,但在正式测试前应至少完成一次整体性的评审;
《系统测试用例》评审时,测试人员应讲解测试用例的编写思路,主要的关键点,并提出不能确定的问题,由熟悉需求和设计的人员进行确认和补充,以达到确保《系统测试用例》有效覆盖系统需求的目的;
测试组内部走查的时候,需要使用《系统测试用例检查表》。
5.4测试执行
5.4.1流程图
图表4:
测试执行流程
5.4.2活动描述
项目组在单元测试完成后,可提交系统测试的任务。
项目经理应在演示前提交《系统功能测试任务单》,任务单上应列出该版本修改了哪些特征项,以及指明测试的要点和时间要求;
测试评估是指,由项目经理或指定人员把《系统功能测试任务单》上的本次测试的范围在测试系统中进行功能演示,在演示的同时进行业务重点的讲解。
在对系统进行第一次演示时,项目组需要结合需求说明的PPT文档,先对测试人员介绍系统需求以及业务逻辑关系,然后再开始系统的操作演示。
双方对系统的可测试性达成一致后,即可开始测试;如果双方对可测试性无法达成一致时,则应及时向高级经理反映,并相互协商解决问题;
系统提交测试时,一般都需要演示,如果项目组认为不需要演示,则必须经过测试组组长的同意
演示任务必须在测试环境中执行,项目组需要将程序发布到测试组的服务器上,在一次测试当中程序不允许更新,具体可参见《系统测试环境发布流程》。
测试组接收测试任务前系统演示要达到的要求:
1)演示时没有任何明显的错误;2)上次测试发现的缺陷都已修改。
项目组给测试组系统测试计划预留时间至少为2天。
一轮测试结束后,测试人员应及时将测试结果及主要情况、缺陷统计反馈填写在《系统功能测试任务单》上,并提交给项目经理审核,电子签名确认,标志着一轮测试任务的结束。
测试任务单需存放在各项目组的配置库中,同时入测试组配置库。
在一个项目中进行多次测试时,每次测试的结果都反馈在《系统功能测试任务单》上,在整个项目的测试工作完成后,应编写《系统测试总结报告》;在项目开里程碑会议的时候,需要提交阶段性的《系统测试总结报告》;
测试组组长应对各个项目的《系统测试总结报告》进行审核,项目组也应对各类测试报告进行走查;
测试人员应严格按照测试进度计划的安排,进行测试工作,如果根据项目的实际情况,时间上有差异的,则应尽力配合项目组方面的时间安排,有需要时应主动采取加班等方式来保证按时按质地完成测试任务,必要时可向测试组组长申请加派人手增援;
测试人员应严格按照测试用例执行测试,并在测试中不断对测试用例进行完善和补充;
项目组可根据系统的实际需要,向测试组提出功能测试以外的测试请求,比如:
兼容性测试和性能测试,需要提交相应的《兼容性测试任务单》或《性能测试任务单》,这两种类型的测试不需要演示,只要具备测试条件(一般在完成功能测试的前提下)即可进行。
执行性能测试前需要编写《性能测试计划》,跟项目经理或主要开发人员确定性能测试的范围和各项性能预期指标,编写性能测试脚本,组织和执行性能测试,并作好观察和记录。
性能测试一般需要2天的准备时间,所以项目组有性能测试需求时,可尽量提前一些通知测试组,以方便做准备工作。
5.5缺陷管理
5.5.1流程图
图表5:
缺陷管理流程
5.5.2活动描述
在TD的缺陷库中新增一个缺陷之前,应先检查有没有类似的缺陷已经存在,避免重复。
缺陷填写的详细要求请参照《缺陷填写规范》;
在任何情况下,“拒绝”、“暂缓”和“冻结”缺陷的时候,都需要在TD的备注中填写“拒绝”、“暂缓”或“冻结”的原因;并与测试人员当面沟通,避免因为理解上的偏差或系统版本的偏差等原因而随意地放过一个缺陷;暂缓缺陷和冻结缺陷,需要经过评审,由产品经理对缺陷定位和解决.在缺陷管理中只有产品经理有权限对缺陷进行“冻结”。
对”拒绝”和”暂缓”的缺陷有争议,测试组可以在系统演示时向项目组提出。
对于每条暂缓的缺陷,项目组与测试组协商确定是否需要再测试此类缺陷。
原来暂缓和拒绝的缺陷,如果缺陷不存在了,由测试组关闭。
测试组每两个月进行批量关闭。
在项目组中只有项目经理具有“Rejected”缺陷的权限;对每一条缺陷需要填写“原因分析”;
当测试人员对项目经理“拒绝”的缺陷有争议并无法达成一致的时候,可向评审委员会提出申请。
评审委员会,是指由高级经理、项目经理、开发、测试以及其他相关的专家组成的评审小组,对有争议的缺陷进行最终的确认。
(评审委员会的成员并不是固定的,而是根据实际情况的需要组成);
从上面的流程图可以看出,对缺陷的管理实际上就是通过TestDirector来对缺陷的状态进行变化;也就是说缺陷从产生到关闭都是在TD里进行的,如果需要将缺陷记录形成文件,可以通过TD来导出到Excel或其他格式的文件;
5.5.3缺陷等级
严重程度
名称
缺陷等级
英文名称
描述
建议
4
Suggestion
测试人员对系统的一些建议,不影响系统的使用功能,开发人员可根据实际情况选择是否修改。
高
3
High
功能不能使用或在使用中出现的问题影响了系统的稳定性、造成数据存储错误或将错误数据带入下一环节、一些重要特性或性能不能达到指定的要求等。
中等
2
Medium
功能可以使用、在出错后做出一定处理,操作能够继续进行或功能实现有误,但问题的出现应不影响本功能或其他功能的实质性使用。
低
1
Low
用户界面显示、对齐、文字错误等。
具体的缺陷等级示例可以参考“缺陷填写规范”。
图表6:
缺陷等级
5.5.4缺陷状态
状态名称
英文名称
描述
新发现
New
是指当测试工程师在执行测试时新发现一个问题的时候的状态
打开
Open
是指当项目经理把新发现的问题分配给某位开发工程师以后的状态
已修改
Fixed
是指开发工程师完成被分配问题的修改后的状态
被拒绝
Rejected
是指项目经理在评审新发现的问题时认为该问题与其他问题重复或者不是一个缺陷的时候,才可以标识为该状态,并需要说明理由。
只要是缺陷都不应被标识为拒绝。
重新打开
Reopen
是指测试工程师对已修改的问题进行验证时发现该问题仍然存在,则将此问题标识为该状态
已关闭
Closed
是指测试工程是对已修改的问题进行验证以后,认为该问题已经修正。
暂缓
Respite
是指项目经理认为需要修改,但因为特殊原因暂缓修改的。
该类缺陷需经过评审,,产品经理同意暂缓的缺陷,需写明原因及修改时间。
未修改的暂缓缺陷在项目收尾阶段分析、整理后提交到维护组。
冻结
frozen
是指项目组因技术或其它原因而没法修改并确定不修改的缺陷,该类严缺陷需经过评审,同意冻结的,由产品经理标识为该状态。
图表7:
缺陷状态
说明:
该缺陷状态的划分是参考MI公司的测试工具产品TestDirector中对缺陷的管理。
5.6变更管理
在项目的开发过程中,当有影响到测试的变更(如需求变更、开发进度变更)发生的时候,项目经理应及时通知相关的测试人员,测试人员接到变更通知后,应对该次变更情况作出分析,然后根据分析结果,对《测试进度计划》或《系统测试用例》等测试资源进行修改或补充(即将变更部分重新走测试策划、设计、执行的流程),并采取走查方式跟相关的开发人员进行确认;
项目上线后一个月集中以会议形式给测试组演示需求/功能上的变更,在演示后,测试人员根据演示情况更新测试用例。
5.7退出准则
系统测试用例通过了评审,测试用例达到了有效覆盖系统所有可测试的需求(功能/特征项);
按照系统测试进度计划完成了系统测试;
测试结果,系统满足需求规格说明书的要求;
在系统测试中发现的缺陷都已经得到合理地处理(理论上只要不是“Rejected”和“frozen”的缺陷都应该被“Closed”)
5.8规程接口
《配置管理规程》
《技术评审规程》
6文件清单
序号
文件名称
文件标识
系统测试计划
系统测试进度计划
新建/修改TD库申请表
系统测试用例
系统功能测试任务单
兼容性测试任务单
性能测试任务单
性能测试计划
缺陷记录跟踪表
系统测试总结报告
出厂测试报告
现场测试报告
用户手册
系统测试用例编写规范
缺陷填写规范
用户手册编写规范
WinRunner编程规范
LoadRunner编程规范
系统测试用例检查表
用户手册检查表
系统测试检查表
7图表索引
图表1:
规程文件结构2
图表2:
测试策划流程3
图表3:
测试设计流程4
图表4:
测试执行流程5
图表5:
缺陷管理流程7
图表6:
缺陷等级8
图表7:
缺陷状态9
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 测试 规程
![提示](https://static.bdocx.com/images/bang_tan.gif)