XX项目DLV系统测试方案V.docx
《XX项目DLV系统测试方案V.docx》由会员分享，可在线阅读，更多相关《XX项目DLV系统测试方案V.docx（21页珍藏版）》请在冰豆网上搜索。
XX项目DLV系统测试方案V
.XX项目_DLV_系统测试方案_V.
————————————————————————————————作者：
————————————————————————————————日期：
哈尔滨银行信息化项目建设
[项目名称]
系统测试方案
项目编号:
版本号：
编制单位：
文档信息：
文档名称
作者
审批人
说明
文件名称
版本信息
版本号
修改日期
作者
修改描述
1
简介
1.1目的
本文档内容是指导哈尔滨银行XX系统实施项目进行测试工作的纲领。
测试团队（包括项目领导、管理组、测试团队、支持团队）将严格按照本方案的内容实施测试活动。
1.2内容描述
本文档的内容主要包括：
∙测试范围
∙测试目标
∙前提和假设
∙测试策略
∙测试准备
∙测试计划和进度
∙测试管理和报告
1.3术语和定义
序号
术语
全称和说明
1.
2.
3.
2测试范围
XX系统测试的范围包括：
⏹模块功能测试：
验证XX系统全部模块的功能实现，包括客户管理、授信业务审查审批、合同管理、放款管理、支付管理、贷后管理等；验证所有后台批处理作业对数据的处理；初步验证数据迁移质量。
⏹用户接受测试：
◆测试客户、业务全生命周期中涉及所有流程的正确性，相应功能的完整性；
◆测试系统各模块之间的连通性和正确性，以及系统内模块与外围接口的数据准确性和稳定性（包含容错/自动重发机制）。
⏹数据迁移质量验证：
在迁移数据库环境中，对历史数据进行抽查及可延续操作性验证。
下图为本次XX系统测试所覆盖的功能模块以及相关的外围接口系统：
功能模块包括：
外围接口包括：
批量接口包括：
XX系统测试的范围不包括：
⏹单元测试，由系统的开发团队在单元测试期间完成。
⏹系统集成测试，由系统的开发团队在开发结束后完成。
⏹性能测试具有独立的测试环境。
⏹数据迁移整体质量验证由开发团队在迁移测试过程中完成。
3测试目标
Ø模块功能测试
⏹测试用例对测试需求的覆盖率达到100%。
⏹测试用例的执行率达到100%。
⏹各个模块的最后一轮测试，测试用例的通过率达到90%。
⏹没有严重、重要和中等程度的遗留缺陷，次要的和有待改进的遗留缺陷有明确的解决方案、时间以及用户的认可。
⏹对于新发生的需求变更，按照项目整体需求变更流程解决。
Ø用户接受测试
⏹测试用例对接口需求的覆盖率达到100%。
⏹测试用例的执行率达到100%。
⏹最后一轮测试，测试用例的通过率达到95%。
⏹没有严重、重要和中等程度的遗留缺陷，次要的和有待改进的遗留缺陷数不超过当前缺陷总数的5%，且次要的和有待改进的遗留缺陷有明确的解决方案、时间以及用户的认可。
⏹对于新发生的需求变更，按照项目整体需求变更流程解决。
Ø数据迁移质量验证
⏹测试用例对XX需求的覆盖率达到100%。
⏹测试用例的执行率达到100%。
4前提和假设
⏹功能性测试的各个模块（或子系统）按计划完成，开发方的单元测试和系统集成测试已通过，没有严重和重要的遗留缺陷（基线版本允许遗留的缺陷需得到开发负责人的签字审核）。
⏹开发方提交全部的系统集成测试用例及相应的测试报告，要求测试用例100%覆盖所有的系统功能点、且100%被执行。
⏹系统外围接口开发按计划完成，内部测试通过，没有重要和严重的遗留缺陷。
⏹测试所需要的软件和硬件设备及时到位，没有重大偏差或者延误。
⏹符合要求的测试人员及时到位，准备就绪。
⏹测试团队拿到最新且审核通过的业务需求文档（如需求规格说明书、接口说明书、详细设计说明书、数据字典、界面原型）。
⏹需求没有发生重大的变更。
⏹数据迁移验证前，迁移数据库已通过迁移组内部的准确性测试。
⏹开发组根据测试计划和测试版本发布计划按时发布版本、修正缺陷。
5测试策略
5.1测试覆盖
要求每个测试需求都能够被测试用例覆盖，并且每个测试用例都要求被执行到。
测试用例对测试需求的覆盖率，以及测试用例的执行率将通过测试管理工具进行跟踪统计（如果工具无法实现，将人工进行统计并记录在Excel中）。
5.2准入准出规则
以下描述测试活动各个阶段的进入前提和退出标准，前一阶段的退出准则自动成为后一阶段的进入前提。
⏹阶段完成小结会议：
每一个阶段完成前，测试项目管理组将召开阶段性小结会议。
●会议将评审该阶段各项退出标准是否达到，基本达到或者未达到。
●会议将评审下一个阶段的进入前提是否达到，基本达到或者未达到。
●根据评审结果，项目管理组将决定该阶段是否完成并且进入下一个阶段。
●会议也将决定下一阶段的细化的工作计划和任务。
⏹阶段启动会议：
每一个阶段的阶段完成小结会议同时作为下一个阶段的启动会议。
5.2.1测试计划阶段
⏹准入前提：
●获得需求文档，如需求规格说明书；
●获得设计文档，包括数据及数据库设计、接口设计、用户界面设计、详细设计（可选）；
●获得测试文档，即开发团队的系统集成测试计划、测试用例、和测试报告；
●获得项目上线计划书、项目实施计划书、以及生产环境配置说明书；
●接受XX系统的基本培训。
⏹退出标准：
●提交测试方案，评审通过；
●提交测试计划，评审通过。
5.2.2测试准备阶段
⏹准入前提：
●获得最新且审核通过的需求文档，包括需求规格说明书、详细功能需求列表；
●获得最新且审核通过的设计文档，包括数据库说明、接口说明、数据迁移方案、界面说明。
⏹退出标准：
●测试人员通过培训；
●测试工具准备完毕；
●提交测试需求，评审通过；
●提交测试用例，评审通过；
●提交测试需求覆盖矩阵，评审通过；
●测试基础配置数据准备完毕，评审通过；
●测试软硬件环境搭建完毕；
●开发方的系统集成测试完成并提交测试报告；
o测试报告经评审会议通过，得到开发项目领导组的认可；
o系统集成测试全面覆盖将提交的系统的需求；
o测试文档和报告获得项目管理组的认可。
5.2.3测试执行阶段
⏹准入前提：
●完整的待测试系统经过开发方充分的系统集成测试；
●开发组提交的基线版本通过准入审核；
●系统通过冒烟测试；
●测试执行管理工具已经准备好；
●测试环境和基础配置数据准备完成，可以执行测试；
●测试用例通过评审；
●相关的DBA、网管和测试系统的维护人员配合支持测试的顺利进行。
●进入用户接受测试的模块，经模块功能测试后不得遗留严重、重要和中等程度的缺陷，且次要的和有待改进的遗留缺陷有明确的解决方案、时间以及用户的认可；
●进入数据迁移质量验证前，需获得迁移组内部测试通过的迁移数据库。
⏹退出标准：
●按计划执行完所有测试级别（功能测试、用户接受测试）；
●测试用例的执行率达到100%；
●核心级测试用例保证执行2到3轮；
●每个模块，最后一轮模块功能测试的测试用例通过率达到90%，可以退出模块功能测试的执行阶段；
●每个模块，最后一轮用户接受测试的测试用例通过率达到90%，可以退出用户接受测试的执行阶段；
●数据迁移质量验证的最后一轮，确保数据准确性。
5.2.4测试报告阶段
⏹准入前提：
●测试执行完成，获得测试用例执行统计信息；
●获得测试进度统计信息；
●获得测试缺陷统计信息。
⏹退出标准：
●提交功能性测试报告，评审通过；
●提交缺陷分析报告，评审通过。
5.3测试用例编写
本测试使用的测试用例模板采用“04.测试管理\01测试管理\01.模板文档\HRB-XX系统测试-测试用例（模板）–整合.xls”。
测试用例数（初步估算）：
2000至5000个。
测试用例编写工作量（初步估算）：
300人天。
5.4风险评估
风险代号
风险描述
严重程度
应对措施
001
项目范围大，测试周期紧
中
严格执行测试计划，必要时调整部分里程碑时间点
002
前期需求文档不全，包括需求规格说明书、系统界面原型
高
让前期参与需求定义的业务人员参与测试需求分析，及早发现需求方面的缺陷
003
业务组长无法全职投入
中
项目领导组要支持业务组长的测试工作，尽量少安排其他工作
004
测试组员无法按时到位，或资源不足
高
向业务部门提出抽调要求，请业务部门支援测试工作
005
提交测试的版本缺陷较多
中
在测试执行正式启动前，需对基线版本质量准入条件进行评估；
测试过程中执行冒烟测试判断每一个版本是否能展开执行
006
测试执行过程中，缺陷修改进度太慢、无法按时提交版本
高
开发组要严格执行版本发布计划、缺陷修改计划
007
需求频繁变更，导致回归测试
高
严格执行变更管理，必要时增加测试周期
6测试准备
6.1测试环境
6.1.1概述
本次测试需要搭建独立的测试环境。
目前认为至少需要两套环境：
A套用于各个模块的功能测试、接口集成测试和用户接受测试；B套历史数据迁移质量验证测试。
6.1.2配置列表
以下具体描述测试环境中各项资源的要求。
ØA环境－服务器端
服务器名称
服务器型号
IP
硬件资源
软件
数据库服务器
WEB服务器应用服务器
ØB环境－服务器端
服务器名称
服务器型号
IP
硬件资源
软件
数据库服务器
WEB服务器应用服务器
Ø客户端环境
资源名称
资源类型
数量
硬件资源
软件
操作前台
客户端运行的PC
根据测试团队成员人数确定
IE7浏览器
6.2测试人员
项目组织架构图如下：
项目组内成员结构说明：
角色
工作方式
职责/要求
人数
备注
项目经理
兼职
●负责项目方向性问题解决
●重大项目变更的签署
1
测试组长
（业务组）
全职
●负责日常工作进度、问题等协调、监督和报告
●缺陷管理和统计报告
●协调项目组间沟通
●管理各业务模块测试小组，管理测试流程和测试进度
●解决项目小组提交的业务问题，制定决策
●接受测试相关培训
●确认需求问题
●确定本组成员构成
●对本组测试成员分配工作任务。
●带领测试组员编写测试用例（功能、业务流程），提出测试数据需求
●对本组提交的测试用例进行审核确认
●带领测试组员测试执行，包括验证缺陷修改、回归测试等
●缺陷报告，必要时提供缺陷重现
●验收并确认项目关键交付成果
1
测试组长
（技术组）
全职
●负责项目的总体协调和管理
●与业务协调人一同具体制定并执行功能测试进度计划
●负责总体技术和开发有关问题的决策
●管理协调测试支持方面的工作
●测试工具的配置、使用和培训
●测试环境的版本管理
●负责领导并完成接口测试、数据管理、性能测试、压力测试
●验收并确认项目关键交付成果
1
测试管理组
全职
●管理协调测试支持方面的工作
●负责每日测试进度跟踪，测试情况汇总
●测试报告编写
1
IT人员
技术支持资源配置组
全职
●基础测试数据的配置
●测试工具的配置、使用和培训
●测试环境的版本管理
1
IT人员
接口测试组
全职
●接受测试相关培训
●编写测试用例（数据、接口、业务流程），提出测试数据需求
●根据测试需求准备测试数据，并负责日常数据的修改备份等
●完成接口测试
●根据测试需求准备测试数据，并负责日常数据的修改备份等
IT人员
业务测试组员（业务人员）
全职
●接受测试相关培训
●编写测试用例（功能、业务流程），提出测试数据需求
●测试执行，包括验证缺陷修改、回归测试等
●缺陷报告，必要时提供缺陷重现
6.3测试数据
用例相关的测试数据，请参考相应的测试用例。
测试用到的基础配置数据需求，将在测试准备阶段由技术支持组负责向业务人员收集整理，并在开发团队的帮助下准备。
测试执行阶段后期，如果历史迁移数据库已经准备完毕，可以在迁移数据库中执行用户接受测试。
外围接口系统用到的测试数据，根据接口测试组的需求由测试团队在测试准备阶段提供。
6.4测试工具
工具名称
使用范围
掌握程度
需要培训（Y/N）
计划培训时间
测试需求分析、用例设计、执行管理和结果分析
熟练使用
Y
SVN
文档版本管理
简单使用
Y
7测试计划和进度
7.1测试整体计划
7.2详细测试计划
7.2.1测试需求及用例编写计划
任务名称
任务说明
开始时间
结束时间
7.2.2测试执行计划
8测试管理和报告
8.1测试流程
本项目使用标准的测试流程，以下是根据测试阶段分解的测试活动。
测试阶段
测试活动
产出物
责任人
8.2测试管理
8.2.1缺陷管理
Ø缺陷严重程度定义：
严重性
描述
举例
1-严重
致命错误，不能完全满足系统要求，基本业务功能未实现，系统崩溃，不稳定或者挂起等导致系统不能正常运行。
1）系统崩溃，死机，无法退出，无法继续操作，或因其他软件系统出错。
2）业务流程或者重要功能出错，例如主要业务流程不能进行，或者严重的金额计算错误。
3）数据通讯错误，与数据库连接错误。
2-重要
严重影响系统要求或者基本功能实现，没有变通办法且无法更正，（重新安装或者重启动不属于更正办法）。
使得系统不稳定，破坏数据，产生错误结果，部分功能无法执行。
1）一般性功能不符，业务流程不正确，需求没有实现等。
2）重要的流程和场景下，导致数据错误，操作无效，操作结果错误。
3）程序接口错误。
4）造成数据库不稳定的错误。
3-中等
一般性错误
1）非重要功能无法正确执行，实现不正确，实现不完整，但不影响关联功能（如删除是没有考虑数据关联，对其他模块造成影响）。
2）界面上一些控件点击无效，对数据操作不能正确实现。
3）非严重性的错误结果。
4-次要
轻微问题，使操作者不方便或者遇到麻烦，但不影响功能，或者影响程度有限。
1）界面错误（界面提示错误或者不友好信息）。
2）界面定义不一致，格式不规范，语言不标准。
3）可编辑区同不可编辑区不容易分辨。
4）键盘支持不好，不能回车换行等。
5）系统处理需要优化
5-有待改进
测试建议（非缺陷）。
1）系统初始值的建议。
2）流程优化建议。
Ø缺陷管理流程图
8.2.2变更管理
Ø变更管理流程图：
Ø测试团队对变更的处理：
●所有需求的变更以变更管理组（即流程管理部）的书面确认为准；
●所有变更（包括需求变更、设计变更等），测试组长都应该要求开发团队给出变更结果的影响范围评估、和预计实现的时间；
●测试组长对变更信息进行评估，确定要维护的测试组件（包括测试需求、测试用例、相关缺陷）和所需时间；
●测试组员维护测试需求、测试用例、和相关缺陷，并挑选回归用例；
●对包含变更实施的版本进行变动的验证和相应的回归测试。
8.2.3配置管理
Ø配置管理流程：
Ø配置管理的测试对象：
●测试过程中的所有流程、模板、会议纪要、需求文档、测试文档、测试版本、培训文档、和最终提交件等；
●以上管理的对象保证在维护后重新提交到配置管理系统中；
●在项目的里程碑时刻，为以上管理对象统一建立基线。
8.2.4测试版本发布
Ø测试版本发布流程：
●常规发布
●紧急发布
Ø测试版本发布计划模板：
序号
计划发布时间
实际发布时间
存放路径
发布负责人
发布属性
版本备注
基线标签号
测试目的
冒烟测试结果
8.2.5测试评审
本次项目将实施以下四个级别的评审：
评审名称
评审时间
评审内容
评审人
测试计划评审
测试计划、方案提交
测试计划和方案是否完善，策略是否正确，覆盖是否全面等
项目经理，测试经理，测试管理，测试组长
测试设计评审
测试需求分析文档、测试用例提交
测试需求分析是否完整、正确、一致、无歧义、可量化；
测试用例是否完全覆盖测试需求，内容是否具体明确、可执行
测试组长，测试组员，开发方需求负责人
项目领导
测试执行启动评审
测试执行启动之前
计划有无重大修改，用例是否完成，人员是否就绪，应用是否就绪，环境和数据准备情况，问题和风险
项目经理，测试经理，测试管理，测试组长，业务协调，研发协调
测试报告评审
测试执行结束
用例执行率，缺陷发生率，缺陷解决情况等
项目经理，测试经理，测试管理，测试组长，业务协调，研发协调
8.2.6测试进度追踪
8.3测试报告列表
8.3.1进度报告
本测试遵循项目组统一规定的进度追踪报告模板，分为日报和综合统计，
备注：
除了报告以上数据的统计结果外，还需对统计结果进行分析，并总结此阶段的主要问题和应对措施。
8.3.2缺陷记录
本测试遵循项目组统一规定的缺陷报告模板，
备注：
除了报告以上数据的统计结果外，还需对统计结果进行分析，并总结此阶段的主要问题和应对措施。
8.3.3缺陷分析报告
最终的整体缺陷分析报告将使用项目组统一规定的缺陷分析报告模板，
8.3.4测试报告
最终的整体测试报告将使用项目组统一规定的测试报告模板，
9附录
无
升级会员 