XXX系统外包项目测试计划事例.docx
- 文档编号:5618064
- 上传时间:2022-12-29
- 格式:DOCX
- 页数:30
- 大小:31.20KB
XXX系统外包项目测试计划事例.docx
《XXX系统外包项目测试计划事例.docx》由会员分享,可在线阅读,更多相关《XXX系统外包项目测试计划事例.docx(30页珍藏版)》请在冰豆网上搜索。
XXX系统外包项目测试计划事例
XXX系统外包项目(二期)
测试计划
(V1.0.00)
编写人:
编写日期:
审核人:
审核日期:
修订页
编号
章节名称
修订内容简述
修订日期
修订前版本号
修订后版本号
修订人
批准人
G.1简介导言
G.1.1目的
编写本文档的目的在于确定现有外包项目的信息,描述外包项目测试范围,定义测试条件和目标、测试策略和要求,分析可能的风险,提供相应的规避措施或应急对策,并策划测试整体进度的计划和人力资源安排。
XXX系统外包项目(一期)测试的目的在于通过测试交易系统业务功能及流程实现的正确性、可靠性、易用性,确保系统符合业务需求规格说明书的要求,且系统性能指标和数据库服务器管理方案满足应用要求。
G.1.2背景
外包项目立项时间、部门等,业务背景、系统背景。
如果不是一期外包项目,则说明一期项目上线以来的情况。
介绍研发公司和研发团队、测试团队等。
G.1.3范围
XXX系统应用结构中主要包括:
这里可以根据系统中的主要功能,按照子系统或大的模块功能进行说明。
G.1.4参考文档
需求规格说明书文档
……
规范文档:
《XXX测试管理规范》
《XXX公司测试外包项目管理规范》
G.2测试约束
遵循测试进入和结束条件,进行外包项目测试管理工作,并按启动和结束准则指导各阶段的测试工作。
G.2.1测试进出条件
1.进入条件
测试进入的条件应满足以下要求:
●外包项目研发计划已确定。
●需求规格说明书已通过评审。
●测试需求范围已明确界定。
2.退出条件
退出整个测试应满足以下条件:
●所有测试轮次执行过程均符合通过准则(合同中有约定)的要求。
●系统遗留的致命和严重级别缺陷数为0(一定得到修复),其他级别的缺陷都被关闭或具有明确的处理意见。
●系统功能测试报告和性能测试报告通过评审。
●协助客户的UAT测试报告通过评审,且软件需求测试覆盖率达到100%。
G.2.2测试通过和失败准则
1.通过准则
通过准则描述每一轮测试通过的条件,如下所述:
●测试用例全部执行完毕,功能点覆盖率达到100%,测试用例执行率达到100%,但是由于各种条件制约,无法构造或无法满足测试条件的用例除外。
●致命和严重级别的缺陷全部修复,其他缺陷95%以上被关闭。
●回归测试或执行本轮新增测试用例时不再出现问题。
2.失败准则
失败准则即某轮次测试失败的条件如下:
●测试用例执行过程中,系统瘫痪、电脑宕机或测试环境发生故障,导致无法继续进行。
●存在严重影响系统功能或性能缺陷的错误。
该轮次测试失败,则遵照测试再启动准则实施,对于失败轮次的测试要记录故障原因。
G.2.3测试启动/结束/暂停/再启动准则
1.测试启动准则
1)集成测试启动准则
①测试环境搭建完成并通过检验。
②外部系统接口完成接入并调试通过。
③集成测试用例通过评审。
④开发方根据外包项目组约定提交测试模块及对应的功能列表清单,并100%完成内部测试。
⑤冒烟测试中90%的功能通过。
2)功能测试启动准则
①功能测试用例通过评审。
②冒烟测试中90%的功能通过。
③第一轮功能测试启动:
系统的所有子系统研发完成,包括数据移植脚本完成,完成了集成测试,并通过了系统功能测试入口准则。
④第二轮功能测试启动:
第一轮测试中发现的缺陷全部得到修复,第一轮测试结果分析结束,系统所有模块功能全部提交(没有尚未完成的功能)。
⑤第三轮功能测试启动:
第二轮测试中发现的缺陷全部得到修复,第二轮测试结果分析结束。
⑥第四轮功能测试启动:
第三轮测试中发现的缺陷全部得到修复,第三轮测试结果分析结束。
并事先与交易所确定了联合测试时间,集成测试第三轮完成。
3)性能测试启动准则
①完成了集成测试和功能测试的第一轮测试,系统主要业务功能流程正常。
②性能测试计划和用例通过评审。
③性能指标已经量化,且能采集到时间、空间和资源利用率等性能指标数据。
④独立于功能测试环境的性能测试环境准备完毕。
4)UAT测试启动准则
①完成了系统功能测试,系统满足了需求规格说明书上的要求。
②系统中所有致命和严重缺陷得到了修复,其他所有未修复的缺陷都进行了相应的处理。
2.测试结束准则
1)集成测试结束准则
①整个系统集成完成,能够正常工作,业务流转正常。
②集成测试用例全部执行完毕。
③致命和严重级别的缺陷100%解决,一般缺陷85%解决,其他级别的缺陷80%解决。
④集成测试计划、集成测试报告通过评审。
2)功能测试结束准则
①功能满足业务需求规格说明书的要求。
②测试用例全部执行完毕,通过率为100%。
③在最后一个版本中,发现的缺陷不超过已提交缺陷的5%。
④测试中发现的缺陷全部关闭。
⑤功能测试报告通过评审。
3)性能测试结束准则
①根据性能测试计划执行所有测试用例完成,测试出系统基本性能参数,并分析系统性能瓶颈。
②提交系统性能分析报告。
③性能测试分析报告通过评审。
4)UAT测试结束准则
①UAT测试用例执行完毕。
②客户确认系统通过,提交UAT测试报告。
③客户提交的UAT测试计划、UAT测试报告通过评审。
3.测试暂停/再启动准则
被测系统的某些重要模块、功能中存在着致命性缺陷导致测试无法继续进行时,则可以暂停,等待缺陷修复后再启动测试。
如果某些功能具有致命性缺陷,但是不影响其他方面的测试,则可以继续对其他非关联性内容进行测试。
G.2.4版本发布约定
在集成测试的过程中,研发团队交付的系统是一次性集成测试版本,主要是跟网银渠道和柜面渠道的集成、与核心系统集成,以及与模拟系统之间的集成。
整个集成测试3轮且分两个阶段实施:
第一个阶段是全部模块提交后;第二个阶段是在行内两轮功能测试后,与交易所进行集成测试。
集成测试之前提交一个通过冒烟测试达到测试入口准则的版本,集成测试阶段采用随时提交缺陷并且随时修复和验证的方式。
在功能测试执行过程中,共执行4轮功能测试,每轮一个版本,包括通过冒烟测试达到入口准则的一个版本,尤其是第一个功能测试版本,后面每周二和周四发布两个版本。
第四轮功能测试是与交易所联合测试的,同样采用周二和周四发布版本的方式。
在紧急情况下或存在重大缺陷导致测试无法进行时,要临时发布更新版本,需要经过测试项目经理或者测试组长的同意。
版本发布流程,采用研发编译提交代码,质量部门做版本控制,并在质量部门的测试环境中部署的方式。
G.2.5缺陷严重级别定义
缺陷平重级别表
严重程度级别
缺陷性质
定义标准
一级
致命缺陷(系统级)
造成服务器操作系统、相关应用服务器宕机,整个系统网络系统瘫痪等缺陷。
二级
严重缺陷(应用级)
影响系统稳定性、部分网络系统瘫痪类应用级的Bug;造成本应用系统或相关的应用子系统宕机。
三级
一般缺陷(业务级)
业务处理终止或者出错、交易出错及其一致性问题、安全、容错或性能方面问题、安装部署与组织标准不符等问题
四级
微小缺陷(操作级)
易用性、界面规范性、提示错误等问题五级建议缺陷(文档级)安装部署手册、操作手册、在线帮助、代码冗余、可跟踪性等问题
G.2.6缺陷优先级别定义
缺陷优先级别表
优先级别
定义标准
紧急
基本业务流程缺陷、功能类错误,特别是对继续进行测试有阻碍的缺陷
一般
不影响业务流程的功能缺失,或者非功能类缺陷,如界面元素位置、提示信息等
紧急缺陷要求1个工作日内解决,一般缺陷要求2~3个工作日内解决。
特别是对于导致测试环境,或者系统不能正常使用的缺陷,需要立即解决。
如果因技术或者环境原因不能按照以上时间要求解决的缺陷,就需要挂起。
G.3测试需求
根据与客户项目经理和相关负责人的沟通,确定本次测试的主要测试范围。
整个测试活动主要包括研发提交一次性系统集成的集成测试、系统功能测试和性能测试,其中包括产品集成测试3轮、系统功能测试4轮(包括与其他系统联调测试)、性能测试3轮,以及协助客户进行的用户验收测试(UAT),这些测试轮次中并未包括每轮测试前检查启动准则采用的冒烟测试等测试活动。
G.3.1物理部署图
可以直接用客户需求文档或概要设计文档中的图。
G.3.2系统逻辑构架图
可以直接用客户需求文档或概要设计文档中的图。
1.产品集成需求
这里列出集成测试需要验证的接口需求
集成测试需求表
序号
系统大类
子系统
验证借口
优先级
2.系统功能业务需求
这里列出系统业务功能需求。
功能测试需求表
序号
系统大类
功能模块
功能
分类
优先级
3.非功能需求表
非功能测试需求包括性能测试需求、批处理性能、备份恢复测试需求、安全性分析、日志管理等测试需求。
这里列出系统性能需求。
性能测试业务需求表
序号
测试需求
被验证的需求
优先级
G.4测试策略
G.4.1产品集成测试
1.测试描述
产品集成测试描述表
测试目标
XXX系统各相关子系统集成成功,与外围模拟系统集成成功。
XXX系统正常工作,业务连通
技术或手段
通过冒烟测试,验证系统可进入系统集成测试;
手工执行集成测试用例,验证XXX系统主功能完备,业务流工作正常
完成标准
所计划的集成测试用例全部执行,所发现的缺陷已全部得到处理
需要考虑的特殊事项
确定或说明那些将对随后的功能测试实施和执行造成影响的事项或因素(内部的或外部的)
2.测试方法描述
根据系统集成测试需求,设计集成测试用例并执行,验证系统主要功能实现的完整性。
特别是涉及到穿越多个子系统的功能的连通性和系统业务数据流是否正常。
例如,客户通过柜面和网银进行资金进出、清算、委托下单、账户资金查询等。
通过集成测试的实施,掌握如何核对账户数据,如何在模拟系统中做清算,XXX系统中的交易平台和备份平台如何做清算等,为功能测试的顺利进行做准备。
3.产品集成测试策略
产品集成测试策略表
测试活动
测试策略
整体
①整个系统集成测试采用所有相关子系统和各模块一次性集成模式,由于柜面渠道研发进度落后一些,将在集成测试的第一轮次后期集成到系统。
②整个产品集成测试分成3轮,前两轮在系统功能测试之前执行,最后一轮集成测试是与模拟资金系统进行集成的,在系统功能测试第4轮与资金系统联合测试之前执行,时间上与第3轮功能测试并行。
③集成测试前,必须对提交的集成测试版本通过冒烟测试来检查是否满足集成测试的入口准则。
如果不满足入口准则,则打回研发团队完善系统,只有满足集成测试入口准则的评估才能进入集成测试(如果不能通过入口准则,则会影响整体测试的进度)。
④在集成测试阶段,使用独立的闭合的二期测试环境,包括核心系统、模拟系统。
配合质量部门做好系统交付版本的版本控制。
⑤集成测试中以接口功能测试为主。
并不关注系统全部的功能,而是关注模块、子系统直接的连通性。
出口准则是网银、柜面、交易平台和投资平台、核心系统一级与模拟系统能够正常交互,功能连通性达到90%以上
入口准则检查(冒烟测试)
①选择典型的集成测试用例,执行测试,确认穿越接口的功能正确。
②如果满足入口准则,则执行第一轮集成测试。
③如果不满足入口准则,则返回研发团队完善系统,在通过入口准则检查后,执行第一轮集成测试。
第一轮
第二轮
第三轮
G.4.2系统功能测试
1.测试描述
功能测试描述表
测试目标
①确保被测试系统的功能正确,其中渠道、后台功能是否正确。
前端功能包括交易委托、交易查询、凭证、报表等功能要满足业务需求规格说明书的要求。
②保证新开户的个人客户、法人客户和自营客户能够进行正常的交易,且账务正确
技术或手段
利用有效的和无效的业务数据来执行各业务场景包括的测试用例(在QC中是测试实验室中设计的测试执行流),以核实以下内容:
①在使用有效数据时得到预期的结果。
②在使用无效数据时,具有异常处理机制并显示相应的错误消息或警告消息,去掉研发人员在调试代码时使用的调试信息。
③各黄金业务交易规则都得到了正确的应用
完成标准
所设计的功能测试用例全部执行,所发现的缺陷已全部得到处理。
确保业务功能全部被覆盖
需要考虑的特殊事项
确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)
2.测试方法描述
根据系统功能需求,设计验证需求实现的测试用例并执行,验证功能实现的完整性和正确性,尤其是客户资金账户、会计清算等的正确性。
例如,中立仓申报、风险控制、参数管理等。
系统功能测试采用第一轮和第二轮手工执行全部测试用例的方法,第二轮时开始设计自动化测试,录制自动化测试脚本。
在第二轮功能测试中,将记录每个客户的输入,尤其是与资金相关的输入和输出,以作为自动化测试的参数化数据。
第三轮测试和最后一轮与交易所的联调验证测试自动化测试脚本,与手工测试并行执行。
3.功能测试策
功能测试策略表
测试活动
测试策略
整体
①新增加功能的测试,即在测试范围“优先级”中标注为“高”的条项;涉及到交易、清算等资金变化相关的优先级都标识为“高”。
②相对于功能发生变更、升级功能的测试,即在测试范围“优先级”中标注为“中”的条项。
③整个XXX系统关键功能的回归测试,即在测试范围“优先级”中标注为“低”的条项。
④整个系统功能测试分成两个小组,手工测试和自动化测试小组。
但是自动化测试小组利用空余时间准备自动化测试,同时参与第一轮手工功能测试。
根据系统交易上的特点进行分工,主要分为委托交易、交割和中立仓、风险监控、提货。
保证各个功能点的功能覆盖。
整个测试工作以账务正确为重点
整体
⑤在测试过程中,每周发布两个版本进行测试,版本控制由质量部门项目经理负责。
⑥第一轮测试必须通过冒烟测试等手段,验证交付的系统是否满足系统功能的条件。
重点关注交付系统功能本身和测试环境问题。
⑦在测试的后面轮次中采用手工测试和自动化测试相结合的方式。
⑧在进入第一轮功能测试之前,对于功能测试环境准备有两种方案。
第一种方案:
把模拟系统和二级系统的账户中的持仓、资金、库存等进行同步,保证数据一致,原来开设的账户继续使用,以保证清算的二级系统账务对平,测试之前首先保证一级系统清算对平。
第二种方案:
在模拟系统中新开两个席位——个人和法人。
测试组在研发组的协助下重新开户,这样保证在新的席位下无历史数据,以保证清算的账务对平,测试之前首先保证一级系统清算对平。
这两种方案的优缺点请参考本表后的方案对比表。
⑨在功能测试环境中账户准备好后,对数据库进行备份,保证在需要时恢复数据库
入口准则检查
①对两轮集成测试发现的问题进行修复后的系统进行系统功能测试入口检查,在冒烟测试中从系统功能测试用例中选择典型的业务场景进行测试,检查的依据是G.2.3中的功能测试启动准则。
②如果不满足启动准则,则研发团队在完善系统后,执行第一轮系统功能测试。
③如果满足启动准则,则直接进入系统功能测试第一轮测试,冒烟测试中发现的缺陷在第二轮测试中进行验证
第一轮
第二轮
第三轮
第四轮
4.环境准备两种方案对比
环境准备方案对比表
第一种方案
第二种方案
优点
缺点
测试组建议
G.4.3性能测试
1.测试描述
该外包项目的性能测试在生产模拟环境上实施,所有环境设备与上线环境设备配置一致或接近,实际性能指标应该高于在测试环境上得到的指标。
性能测试描述表
测试目标
测试系统各关键环节基本性能指标,尤其是并发交易量、响应时间等指标。
分析系统性能瓶颈,并提交性能测试报告
技术或手段
①在生产模拟环境中,进行并发测试,获取系统响应指标。
②实施负载压力测试,分析系统性能瓶颈。
③在大数据量条件和长时间工作的条件下,对系统进行测试,评估系统稳定性
完成标准
按性能测试方案完成测试,提交性能测试报告并通过评审
需要考虑的特殊事项
测试所需的生产设备按要求及时到位,并能正常工作
2.测试方法描述
对批处理性能测试,选取批处理、利率调整等交易相关的时间点,进行批处理并记录处理时间、系统资源占用状况,然后进行性能瓶颈分析。
对系统交易性能测试,选取典型功能场景进行针对性测试,使用相应的性能测试脚本和场景进行测试,分析响应时间的状况和性能计数器
3.性能测试策略
测试类型策略表
测试类型
测试策略
基准测试
基准测试系统在无其他负载的情况下,测试典型业务的响应时间指标,以作为响应时间的基准进行评估。
测试策略:
①在与运营环境相同或相近的环境上进行基准测试。
②用典型单业务测试脚本,在一个用户负载迭代10次的情况下,执行3遍,取均值,作为基准性能数据进行记录,包括响应时间、吞吐量、CPU和内存等。
③典型单业务包括……
单一业务压力负载测试
混合业务压力负载测试
大数据量下
混合业务压力测试
清算性能测试
大数据量下稳定性测试
G.4.4数据库服务器测试
1.测试描述
数据库服务器相关的测试包括两项:
数据库服务器的主备切换测试、数据库备份与恢复测试。
数据库服务器测试描述表
测试目标
①主备切换核实:
主机宕机、备机接管主机的工作、继续生产运行。
②对数据备份和恢复测试,文件恢复的操作和结果正确。
③日志管理测试
技术或手段
①主备切换测试:
建立双机冷备测试环境,进行主机断线和恢复运行操作,检查系统的访问和备机的切换状况。
②数据备份与恢复测试:
根据实现方案设计场景,执行备份和恢复脚本,通过系统功能来验证备份和恢复情况
完成标准
成功地核实出主备切换按照预期的方式运行;成功地核实出数据备份与恢复按照预期的方式运行
需要考虑的特殊事项
测试环境具备主备数据库服务器,且提供测试外包项目组访问测试环境的权限
2.测试方法描述
对主备切换测试,在本地建立双机备份模拟环境,通过主机掉电、关机、断开跳线等方式来模拟主机故障状况,通过系统访问和备机状态查看命令检查切换和系统运行状况;主机恢复运行后,通过命令及系统访问检查备机运行和切换状况。
对数据备份和恢复测试,在本地测试环境中,在系统运行了一段时间以后进行交易操作,使用备份文件和相应的方式恢复备份时的数据,通过系统功能和账务信息的变化来验证数据备份和恢复状况。
3.数据库测试策略
数据库测试策略表
测试活动
测试策略
备份和恢复测试
主要测试数据库主机在意外断开的情况下,切换到的备份机是否正常运转,且对正常用户交易业务不造成影响。
测试策略:
①正常处理交易时,通过掉电、关机、断开网线3种方式断开数据库主机服务,检查这些异常是否对系统已有数据产生破坏。
②在主机恢复正常后,检查上一步骤中交易客户的账务、信息等是否正常。
③由于数据库放在主备共用的磁盘阵列上,所以不涉及到数据库的备份
注:
测试期间应有数据库备份机,如果没有备份机该测试将无法验证。
G.4.5安全性和访问控制测试
1.测试描述
安全性和访问控制测试侧重于安全性的以下两个关键方面:
●应用程序级别的安全性。
包括对数据或业务功能的访问。
●系统级别的安全性。
包括对系统的登录或远程访问、网络传输等。
由于系统级别的安全性属于运维制度、网络和系统管理的职能,所以不在XXX系统中进行测试
安全测试描述表
测试目标
应用程序级别的安全性主要核实以下内容:
①核实XXX系统用户只能访问权限组内赋予的功能或数据。
②系统本身具有风险控制能力。
例如,对于自营业务在系统中有无风险防范功能。
③黄金业务功能中的认证方式,验证有效
技术或手段
确定并列出各权限组的用户,核实这些用户只能访问其被授权访问的功能或数据;使用网络协议分析软件分析系统中交互的敏感信息
完成标准
成功地核实出各权限组的用户能够按照预期的方式运行;对敏感信息的处理满足安全要求
需要考虑的特殊事项
由于网银渠道是集成在整个客户的系统内的,所以并不关注整个网银的安全性,而是关注黄金系统本身的安全因素
2.测试方法描述
根据系统安全性和访问控制功能的需求,设计验证安全性的测试用例并执行。
例如,各角色只能处理与角色相关的操作,而不能访问到或者处理其他角色的信息和操作。
结合功能测试,对用户身份验证方式进行测试,测试结果安全、有效。
安全性和访问性测试,主要在系统功能测试阶段来测试。
3.安全性测试策略
安全性测试策略表
测试活动
测试策略
安全性和访问控制测试
主要测试应用级别上的账户权限安全,包括登录安全、资金账户安全。
测试策略:
①在网银端验证个人客户、法人客户登录安全后,账户安全及传输数据的安全可通过分析、网络抓包等手段验证。
②通过验证客户出入金、委托交易等业务操作时的资金账务安全。
③客户管理端的级别账户权限安全,对内部(自营交易员)风险控制机制进行分析等。
④对系统中的数据安全进行分析
G.4.6用户界面测试
1.测试描述
用户界面(UI)测试用于核实用户与软件之间交互界面的规范性。
UI测试的目标是确保用户界面能通过测试对象的功能来为用户提供相应的访问或浏览功能。
另外,UI测试还可确保UI中的对象按照预期的方式运行,并符合公司或行业的标准。
界面测试描述表
测试目标
需要核实以下内容:
①通过测试进行的浏览可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(“Tab”键、鼠标移动和快捷键)的使用。
②窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准
技术或手段
为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可以正确地进行浏览,并处于正常的对象状态
完成标准
成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准
需要考虑的特殊事项
并不是所有定制或第三方对象的特征都可以访问
2.测试方法描述
根据系统的功能和界面要求,并结合Windows平台的界面规范,以及用户操作习惯、构面规范和网上金融操作规程,设计并执行测试用例,验证界面的规范性、一致性和合理性。
例如,客户信息管理页面,验证页面控件的布局、风格、访问方式等对业界标准和外包项目规范是否符合,和系统其他同类页面相
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- XXX系统外包项目 测试计划 事例 XXX 系统 外包 项目 测试 计划