系统测试方案V1.4

系统测试方案

制作单位：XXXXXXX

文档编号:(按照XXXXXX文档资料统一编码规则编制文档编号，由XXXX填写)

版本号:（按照XXXXXXX关于版本号管理的有关规定填写，由科技部门填写）

负责人（技术）:

编写人员:

    (参加需求编写的所有人员,包括业务部门参加人员、软件中心参加人员)

校对人员:

修 订 记 录

1.1文档目的

描述文档编写的主要目的。

1.2项目背景

描述项目发生的背景。

1.3参考资料

本测试的目标是保证XX系统所有功能完成的正确性并验证现有的XX产品及流程正确的执行，分析是否符合业务需求说明书指定的功能。具体包括：

检查XX系统所有功能点的正确性，在系统上线前尽可能多地发现系统缺陷并进行修正。

验证XX系统基本产品及其流程的合理性和一致性，满足产品目前的要求及未来的发展需求。

第三章 测试范围

3.1功能点正确性测试

对XX系统的XX个功能点进行全面的测试，设计尽可能详细的测试案例进行测试，功能点如下： 

界面整体性测试包括如下测试内容：

各功能区界面一致性检查

非功能区页面功能正确性检查(包括登录页面、页面公共区域)

页面输入项校验规则检查

页面公共按钮功能检查

3.3业务流程正确性测试

对被测系统业务中的功能所涉及的基本流程进行全面、正确性测试，由于流程测试涉及到多个岗位及每个岗位的功能、职责，覆盖的业务知识较多，需要进行详尽、全面、合理、仔细的进行案例设计。

3.4基本产品的配置测试

对行里的基本产品进行配置，并通过业务流程进行测试产品功能和实施流程的正确性。

第四章 测试策略

4.1测试实施流程

本次XX系统测试采用标准测试流程进行实施，包括5个主要测试阶段和过程：

测试计划：制订测试方案/测试进度计划

测试需求分析：根据业务需求及需求说明书整理测试需求，对业务需求或需求说明书进行测试并提交缺陷记录

测试案例设计：根据测试需求设计测试案例

测试执行：执行已评审的测试案例并提交软件缺陷、复测缺陷

测试总结：分析测试执行结果和数据，编写测试报告

测试实施流程图

测试实施过程中的产出物，包括测试需求、测试案例、测试执行结果、测试缺陷，使用HP公司的Quality Center进行统一管理，并实现各测试资产之间的关联。

4.2测试需求分析方法

根据行方提供的XX系统的需求文档及开发方的XX系统模型，对XX的各个功能点和业务流程进行分析，测试需求分析结果至少应包括如下内容：

功能点分析

业务规则约束

业务流程分析

产品功能分析

测试需求分析结果统一记录在测试管理工具Quality Center(试用版)中，便于和案例、缺陷的关联以及测试度量指标的统计分析。

在测试需求分析阶段，测试人员需要对业务需求或需求说明书进行测试，并提交缺陷记录。

4.3测试案例编写策略

根据测试需求分析结果有所侧重的原则

在测试需求分析结果的基础上，根据系统功能点和业务流程的特点，在测试案例设计时应有不同侧重：

对系统功能点：需求功能点尽可能多的测试案例进行验证，包括正案例、反案例、边界值案例等

对业务流程：应根据产品规则的约束和岗位的职责设计尽可能多的流程测试案例，以验证办理一个产品从开始到结束的所有过程的正确性

冒烟测试案例设计

对重要功能点和基本产品的业务流程，应设计一个基本功能检查案例，用于系统测试进入标准中的冒烟测试检查。

测试案例管理

测试案例统一记录在测试管理工具Quality Center(试用版)中，便于和需求、缺陷关联以及测试度量指标的统计分析，也利于测试执行管理。

4.4测试数据申请策略

要求测试人员在测试需求分析阶段开始着手准备测试数据。

测试人员根据测试需求分析和测试案例设计时的数据需求，整理出对被测系统及关联的外围系统功能测试账号等方面的类型要求和数量需求，统一汇总后按照测试数据申请流程进行申请。

4.5测试执行管理策略

测试轮次安排策略

本次XX系统测试执行过程共分为4个轮次：

✓第1轮：冒烟测试执行(执行检查系统基本功能的冒烟测试案例)

✓第2轮：功能点全面测试执行(执行除冒烟测试案例之外所有功能点案例)

✓第3轮：业务流程测试执行(执行除冒烟测试案例之外所有业务流程案例)

✓第4轮：系统全面测试(带生产数据)

测试结果验证策略

对测试结果的正确性验证主要通过XX系统界面显示和流程流转等验证的方式，若因环境因素等各种原因确需其他系统配合通过日志检查报文或通过柜面前端查询等方式进行结果验证时，须提出申请由测试中心进行协调和沟通。

    测试结果记录

测试执行计划、测试日志、测试执行结果均在测试管理工具Quality Center(试用版)中进行记录，实现测试资产的统一管理。

4.6测试问题/缺陷管理

测试人员发现的测试缺陷，测试组与业务、开发需要定期/不定期的进行确认。

缺陷管理工具

本次XX系统测试的问题/缺陷使用测试管理工具Quality Center的缺陷管理模块进行统一管理。

缺陷管理流程图

注：仲裁组由开发项目经理、业务人员和测试项目经理组成。

缺陷状态定义

1-紧急：2-3小时（需测试组长跟开发组长做口头提醒/电话）

2-非常高：1天内（需测试组长跟开发组长做口头提醒/电话,Mail）

3-高：3天内

4-中：5天内

5-低：5天以上

4.7测试效率保证策略

迭代测试的策略

由于本次系统测试时间紧，任务重，留给测试设计的时间不长，在具备测试环境条件的情况下尽早开始测试执行，同时抓紧时间完善测试案例执行完整测试，测试执行分轮次进行。

保证重点的策略

本次XX系统的测试重点是系统提供的所有功能点和业务流程，对测试需求按业务和产品的重要性做优先级分类，在时间或条件有限的情况下，先保证优先级高的功能点和业务流程完成测试，以保障项目进度。

第五章 测试约束

5.1测试执行准入标准

当达到如下条件时，系统测试可进入正式的测试执行阶段：

测试环境准备就绪

开发方已提交经过内部测试的稳定版本并部署到系统测试环境

开发方已提交相关技术文档（需求文档、设计文档、用户说明书等）及内部测试的相关文档（测试方案、测试案例、测试报告等）

内部测试中测试案例应记录测试执行结果，测试范围应和需求文档、设计文档一致；如有不一致，开发方应对不一致项进行说明，并经过行方项目经理认可或通过评审

冒烟测试通过

（注：冒烟测试是对测试对象进行功能快速抽查的一种测试类型。它主要用于执行测试入口标准的印证，也称绿灯测试、连通性测试。）

5.2测试中止条件

测试过程中，如发生以下任何一种情况，则中止测试活动，并及时通知开发方：

发现程序不是最新版本

主要模块功能不能正常运行，且影响其它模块的功能测试

业务需求出现较大变更，程序也需要修改

开发方修改时间及新版本发布时间由业务方、开发方、测试方三方商定，修改完成后继续进行测试。

5.3测试准出标准

达到下述条件，可结束本次系统测试：

严重级别以上的所有缺陷均已修复并复测通过，总体缺陷修复率在90%以上，未修复缺陷均有暂缓修复说明

已完成该阶段全部测试案例的运行，提交的系统测试报告经各方评审通过

所有测试工作产品均已提交并通过审核

第六章 测试资源

6.1人力资源

通过XX软件在金融应用测试领域的基于功能点测试工作量评估模型(FPA)，本次测试投入的总工作量约为XX人月（不包括UAT测试）。考虑到项目测试实施工期很短，为减少沟通成本，提高执行效率，在测试需求和案例编写阶段，XX公司申请中高端测试人员，其余人员由行方调配，在完成测试需求分析和测试案例设计后继续进行测试执行，本次合作测试公司方测试人员共需X人（其中测试需求和测试案例设计阶段X人，测试执行阶段X人），行方需派出项目经理1人，职责如下：

列示本次测试的软、硬件测试环境。

在本次XX系统测试实施过程中，拟采用的测试工具包括：

说明本次测试的详细进度计划，对应的测试人员资源，建议采用Project显示。

第八章 沟通管理计划

说明本项目约定的沟通方式的组织者、参与人员、时间频度及产出物等内容。

第九章 测试度量管理计划

现阶段制定的测试度量TPI的对应基础数据以及数据来源和说明，测试项目经理负责统一收集汇总下表中列出的所有度量基础数据，将收集到的所有基础数据填入《度量数据收集汇总表模板》中，自动计算得出TPI值。

测试风险管理是对影响项目测试的各种可能发生的风险进行识别和评估，分析其发生概率及发生后对项目的影响程度，提出规避方法和应对计划，从而有效规避测试风险，在风险发生时采取必要的补救措施使损失减少到最低限度。