业务管理系统项目测试方案（讨论稿） 文档编号： 文件修改记录表修改内容要点 修改时间 修改人 审批人

业务管理系统项目测试方案

（讨论稿）

   文档编号：

 

                        

文件修改记录表

修改内容要点	修改时间	修改人	审批人

目     录

1......................................................................... 项目概述... 5

2......................................................................... 适用范围... 5

3......................................................................... 预期读者... 5

4......................................................................... 测试目的... 5

5......................................................................... 参考文档... 5

6......................................................................... 测试环境... 6

7......................................................................... 测试工具... 7

7.1  原则... 7

7.2  性能测试工具... 7

7.3  测试管理工具... 8

8......................................................... 风险预测和防范... 8

9......................................................................... 接收测试... 9

10....................................................................... 测试内容... 10

10.1    安装测试... 10

10.2    功能测试... 10

10.3    业务测试... 10

10.4    性能测试... 10

10.5    安全测试... 11

10.6    文档测试... 11

10.7    回归测试... 11

11....................................................... 测试通过的标准... 12

12................................................. 需提交的测试文档... 12

13....................................................................... 测试方法... 12

13.1    原则... 12

13.2    安装测试... 12

13.3    功能测试... 13

13.4    业务测试... 13

13.5    性能测试... 13

13.6    安全测试... 14

13.7    文档测试... 14

13.8    回归测试... 14

14....................................................................... 测试流程... 14

15............................................................ 项目组织管理... 15

15.1    人员管理... 15

15.2    项目管理... 16

15.3    错误管理... 16

15.3.1        错误的跟踪与记录... 16

15.3.2        错误的提交、修改与回归测试... 17

15.4    测试时间表... 17

1. 项目概述

1. 适用范围

本测试方案作为《业务管理系统》项目测试的实施依据。

1. 预期读者
2. 测试目的

本测试旨在检验软件功能、性能是否符合业主的需求。

1. 参考文档

1. 测试环境

C/S部分运行环境

1. 1. 服务器端：
      1. 硬件：
         1. CPU: 2路500 MHz RS64 III对称多处理器, 2路750 MHz RS64 IV对称多处理器, 二级缓存
         2. 内存：2GB
         3. 硬盘：80GB
      2. 软件：服务器端操作系统一般是HP-UNIX，Solaris，AIX。SCOUnix等。
      3. 数据库的数据量情况(现在、预计未来两年后)

目前对于省级财政来说，所有的预算单位一般在800到1000之间，一年内每个单位的指标在20条左右，用款计划在20*12=240条，直接支付申请在20*12=240，授权支付在50*12=300条，生成的会计凭证也大概在500条左右，这样就可以计算出一个单位一年的数据量大概在20+240+240+300+500＝1300，所有单位的数据量在1300*1000=1300000，每条数据的大小估计在2k左右，这样一年的数据大小在2.5G左右，加上各种日志信息和审核记录信息，所有的数据量应该在2.5G+2.5G*2*2=12.5G/年。

预计在两年内，由于预算执行的更加细化，一些原来很粗的支出变得明细，所以数据量应该是目前的2到3倍，这样数据量估计在12.5*3=37.5G/年。这里还是不考虑其他的业务系统数据存在在同一台机器上。

1. 1. 客户端：
      1. 硬件：PIII750以上，256M内存，10G硬盘
      2. 软件：Windows98/2000/XP
      3. 网络环境：C/S部分基本上在局域网内进行，所以按照普通的网络条件参考。一般是百兆的交换机和网卡，客户端是百兆接入。

B/S部分运行环境需求

1. 服务器端：
   1. 1. 硬件
      2. 软件
      3. 数据库的数据量情况(现在、预计未来两年后)

B/S的服务器端配置同C/S部分。

1. 应用服务器：
   1. 1. 硬件：2CPU、4G内存、10G硬盘
      2. 软件：操作系统可能是Windows2000或者是Unix，应用服务器采用WebLogic7
2. 客户端：
   1. 1. 硬件：同C/S客户端配置
      2. 软件（包括浏览器类型版本等）：Windwos98/2000/XP，浏览器为IE6.0及其以上版本。
3. 网络环境：客户端基本上采用拨号方式或者是DDN专线方式，拨号方式下速率平均为28k/s，专线情况下能够达到256k/s。

1. 测试工具
   1. 原则

测试方以手工测试为主。必要时（如：性能测试、回归测试）采用测试工具辅助测试，在整个项目的实施过程中也将使用Microsoft公司的VSS软件来进行错误管理以提高测试效率。

1. 1. 性能测试工具

国库财政集中支付管理系统中不同的功能部分采用了不同的软件结构：

1. C/S结构部分：
   1. 1. 预算单位集中支付管理系统；
      2. 门集中支付管理系统中的账务管理；
      3. 门集中支付管理系统中的基础管理部分；
      4. 清算银行集中支付管理系统中的基础管理部分；
      5. 代理银行集中支付管理系统中的基础管理部分。
2. B/S结构部分：
   1. 1. 门集中支付管理系统执行指标管理、计划管理、拨款单管理、支付管理、退款管理；
      2. 清算银行集中支付管理系统执行指标管理、计划管理、拨款单管理、支付管理、退款管理；
      3. 代理银行集中支付管理系统中执行指标管理、计划管理、拨款单管理、支付管理、退款管理。

根据不同的软件结构需要将使用不同的性能测试工具

1. C/S结构将采用Compuware公司的QALoad软件进行性能测试；
2. B/S结构将采用Compuware公司的QALoad软件进行性能测试，或选用其他适合B/S模式的测试工具,如MI公司的LoadRunner或Empirix公司的e_load；
   1. 测试管理工具

根据几方协商确认，测试过程中采用Microsoft公司VSS软件做为文档管理工具；且将于11：30，14：30，17：30，20：30四个时刻将错误记录通过IE浏览器提交到公司bug管理平台中。

1. 风险预测和防范

测试中的各种局限性使得测出软件系统中的全部错误或缺陷比较困难。为了能够更好的完成测试，我们对测试中可能产生的风险作出预测并制定了防范措施。

1. 风险：测试用例对功能与业务的覆盖不充分；

防范：通过补充和完善测试用例，减少功能的漏测；通过典型业务流程测试，检查各功能间关联及业务逻辑实现的正确性；

1. 风险：由于测试用例错误造成测试结果不正确；

防范：通过业主方、开发方与监理方对测试用例的评审，提高测试用例设计的质量；

1. 风险：由于测试环境的影响造成测试结果有误差；

防范：测试环境配置与实际运行环境要尽量一致；

1. 风险：由于在性能测试中测试工具选择错误造成测试结果有误差；

防范：在正式测试之前，对测试工具在该系统环境下进行可用性测试；

1. 风险：由于在正式测试过程中发现致命性错误造成对测试时间有影响；

防范：在正式测试过程中发现致命性错误，会及时的通知开发方，以期尽快解决，来减少影响。

1. 接收测试

接收测试条件：

1. 具备可应用于系统测试的软件：开发人员经过单元测试和集成测试，软件功能已基本实现；
2. 具备系统测试的环境；
3. 具备齐全的文档：
   1. 《业务管理系统业务需求》；
   2. 《性能需求表0608》；
   3. 《业务管理系统需求规格说明书》；
   4. 《业务管理系统概要设计》；
   5. 《业务管理系统详细设计》；
   6. 《业务管理系统用户手册》（包含安装与维护）；

接收测试的通过标准：

从公司的测试用例库中选用并执行适当的典型基础业务流程测试用例集，通过率在90％以上，其中通过\未通过的评判标准为：

1. 当执行用例时产生的错误级别为致命性错误或严重功能/性能错误时，此用例本身为未通过状态，受其影响导致不能正常进行的其他用例为未通过状态。
2. 当执行用例时产生的错误级别为告警性错误或建议性错误时，可以认为其用例为通过状态。

1. 测试内容
   1. 安装测试

1. 验证软件是否能按照用户手册的安装部分进行正常的安装和卸载
2. 检查系统安装过程的友好性：界面、提示与帮助信息是否一致、完整正确
   1. 功能测试

功能测试是系统测试阶段的一个重要任务。功能测试的目标是测试系统内各功能模块是否达到设计目标。

测试方在开发方完成单元测试及集成测试的基础上进行的全面、深入的系统功能测试，以确认需求说明中要求的功能都已实现，没有遗漏。

测试用例的设计将根据附件所列出的功能列表进行；测试用例将包括正确测试用例、错误测试用例，边界值测试用例。

1. 1. 业务测试

业务测试是检验系统是否达到业务管理系统的业务要求的关键步骤。业务测试过程中，通过对典型业务流程和特殊业务流程的模拟，可以发现系统在进行业务处理过程中是否符合业务的逻辑要求。

业务测试用例设计需要参考需方的日常业务操作中典型业务流程及特殊业务流程，测试过程中需要业主方熟悉系统业务流程的人员配合用例设计工作并参与测试。

1. 1. 性能测试

性能测试的目标是测试系统是否达到所需要的各项性能指标。

性能测试内容应包括日常业务情况下压力测试，高峰业务情况下压力测试及系统持续业务处理能力测试，并据此对系统的性能进行全面的评价。

性能测试的设计原则

分析系统的业务分布，挑选做性能测试的典型业务

按照实际运行中统计的业务并发量，设定压力测试的起始业务并发数量，以及并发量递增的增量

参照系统的峰值设计需求，逐步对系统加压至性能拐点

改变应用服务器的数量和配置情况，检查应用服务器对性能的影响

参照以上测试的结果，设计系统持续处理能力测试

业主方应选派业务人员和服务器及网络管理的技术人员参加性能测试。

1. 1. 安全测试

安全测试的目的是检查系统是否达到安全要求。由于此软件运行环境基本处于专用网内部。此次安全测试的内容包括：

1. 用户唯一性验证
2. 用户权限管理
3. 系统日志
   1. 文档测试

文档测试的目的是检查开发方提供的应用软件技术文档、用户文档内容的正确性、完备性、逻辑条理性和通俗易懂可读性，文档与软件系统的一致性以及版本配置的一致性。采用人工方法进行检测。

文档测试对象包括项目完成后开发方提交给业主方的所有技术文档资料和应随产品提交的所有用户文档，如用户手册（包含安装与维护部分）等。

1. 1. 回归测试

在最后一轮测试工作完成并且所有发现的错误都经开发人员修改完成后，为了验证开发人员在错误修改的过程中已经正确修改了发现的错误并且没有引入任何新的错误，需要做一次回归测试。回归测试将会运行所有的测试用例，以保证上线运行的软件的质量。

回归测试时根据功能测试和业务测试的结果，可能需要对测试用例进行必要的补充。

1. 测试通过的标准

1. 没有致命性错误与功能性错误，此处功能性错误是指规定的功能没有实现或不完整。
2. 没有严重影响系统运行的性能问题
3. 剩余的告警性、建议性错误与性能问题经过四方的讨论决定暂不修改

1. 需提交的测试文档

1. 《集中支付系统测试方案》
2. 《集中支付系统测试周报》
3. 《集中支付系统测试验收报告》

1. 测试方法
   1. 原则

本项目功能测试以手工测试为主，必要时可以使用辅助测试工具。性能测试使用测试工具，以达到模拟真实运行环境的要求。

1. 1. 安装测试
2. 《用户手册》中的安装说明部分能否顺利指导安装过程
3. 在不同环境下安装的正确性
4. 安装过程中可选方案是否都可行
5. 软件卸载以及卸载后重新安装，软件是否正常工作
   1. 功能测试

1. 依据软件需求规格书，结合系统功能列表设计出正确性测试用例
2. 对于需要资料合法性和资料边界值检查的功能，增加相应的错误和边界值测试用例
3. 执行测试用例
4. 检查测试结果是否符合功能需求
5. 评审功能测试结果
   1. 业务测试

1. 业主方的业务人员配合完成典型业务流程及特殊业务流程的设计
2. 根据业务流程设计测试用例
3. 执行测试用例
4. 检查测试结果是否符合业务需求
5. 评审业务测试结果
   1. 性能测试

1. 依据系统性能要求，制定出测试方案并设计出测试用例。
2. 在各客户端安装压力测试工具并录制测试脚本
3. 使用压力测试工具对客户端进行配置
4. 运行测试脚本，进行压力测试
5. 压力测试按照并发量递增的顺序进行
6. 对每笔交易的时间进行记录，得到不同并发度条件下系统响应时间变化曲线，判断其是否符合设计要求
7. 对系统内数据库服务器、应用服务器等系统的资源使用情况进行监控
8. 在高并发量情况下，增加应用服务器的数量，获得系统响应时间变化曲线
9. 通过同时对同一个资料表进行多种操作，测试锁表处理的正确性
10. 检查各种并发度下交易成功率和错误类型
11. 通过使系统长时间在高并发条件下的运行，测试系统性能是否有明显下降和是否存在有内存泄露情况出现，测试系统运行是否稳定
12. 归类、整理并上报测试过程中发现的性能缺陷
    1. 安全测试

1. 通过不同权限用户的使用，对用户使用系统的权限进行检查
2. 通过用户对系统的登录及使用，检查系统对用户一致性校验
3. 检查操作日志，验证其功能是否实现
   1. 文档测试

1. 检查开发方所提交的文档是否完整，内容是否正确
2. 依照开发方所提交的《用户手册》中的安装说明部分进行软件安装
3. 依照开发方所提交的《用户手册》进行软件使用、维护
   1. 回归测试

1. 根据功能测试和业务测试用例执行结果，按照需要对测试用例进行必要的补充
2. 执行补充测试用例
3. 将所有的功能测试用例和业务测试用例重新执行，测试软件修改了已有错误，并且没有引入新的错误。

1. 测试流程

1. 项目组织管理

为了保证软件的测试工作高质量、如期的完成，测试方必须精心进行项目组织，并实施严格的管理。

1. 1. 人员管理

本项目测试人员由一名项目督导、一名项目经理、测试工程师、及相关业务人员组成，具体人数将根据具体测试时间和任务安排而确定。

1. 项目督导：（1人）
   1. 监督、统筹及协调项目中各项活动；
   2. 负责建立软件测试的整个过程
   3. 负责培训软件测试人员及开发人员质量意识
   4. 负责指导测试的每一关键步骤
   5. 负责指导测试计划、测试案例、测试报告的编写
2. 项目经理：（1人）
   1. 项目整体和各关键阶段的技术负责人和管理人；
   2. 负责承担项目任务的计划、组织和控制工作，以实现项目目标；
   3. 负责向项目协调机构定期报告项目进展情况，就项目中存在的问题提出解决建议；
   4. 统筹及协调项目中各项活动和任务安排；
   5. 负责测试方和业务方，开发方的协调配合工作。
3.  测试工程师：（4人）
   1. 负责编写、制定测试用例；
   2. 负责实施测试；
   3. 负责将问题录入问题管理系统；
   4. 负责问题分类、总结；
   5. 负责测试文档的保存。
4.  业主的业务人员（3人）
   1. 负责在项目期间，参加和指导提出需求和需求分析，以及咨询解答项目实施过程中有关技术、业务及项目管理的问题；
   2. 负责评审测试用例，参与测试；
   3. 负责提供典型业务流程及特殊业务流程，并协助分析评审业务测试结果；

1. 1. 项目管理

项目的管理协调由业主方、开发方、监理方和测试方四方组成项目协调小组。项目协调小组由四方项目负责人组成，由业主方担任组长。其职责如下：

1. 在测试工作的各个阶段，四方之间互通信息、交流情况；
2. 决定与测试有关的开发和管理等重大事宜；
3. 当测试方与开发方产生争议时进行协调，并作出决策。
   1. 错误管理
      1. 错误的跟踪与记录

测试发现的错误分为以下四类：

1. 致命性错误：数据丢失，数据计算错误、系统崩溃和异常死机；
2. 严重功能/性能错误：规定的功能没有实现或不完整、设计不合理造成性能低下，影响系统的运营；
3. 告警性错误：不影响业务运营的功能/性能问题；
4. 建议性错误：软件设计和功能实现等不甚合理之处提出建议。

在测试执行过程中，把发现的错误提交到问题管理系统中，并对错误进行跟踪管理。每一个错误有以下生命周期：

发现—提交—修改—重新测试—结束

当对开发方提交的一个确定版本通过全面的系统测试，所有错误经确认后，提交给开发组有关成员进行修改。当所有错误的状态变为修改完成时，由开发方提交新的版本后，再开始下一轮系统测试。

1. 1. 1. 错误的提交、修改与回归测试

为保证进度，测试方应将一轮测试中发现的错误分批提交开发方。每一轮测试完成后提交完整的测试记录，并对发现的错误进行分类、统计和分析，形成软件问题报告。

为保证测试工作的顺利进行，除非必须，测试方在一轮测试完成之前不接受开发方提供的任何更新版本。

开发方完成修改工作后，将软件更新版本及问题更改报告提交测试方进行回归测试。问题更改报告应详细说明修改了的错误、更新了的组件、可能受修改影响的组件等。未能修改的错误应说明原因，当测试方、开发方在时间、进度、质量等问题上发生争议时，或测试中发现严重错误时，应及时报告给项目协调小组，必要时由协调小组进行决策。

测试方收到更新版本后，开始作下一轮测试。在软件基本稳定后，测试方进行全面的回归测试，以确认修改是否引入新的错误。

1. 1. 测试时间表

附件：集中支付系统功能列表

性能测试工具简介（QALoad）：

Compuware公司的QALoad是一个企业级的自动化负载测试工具。它通过可重复的、真实的测试彻底地度量应用的可扩展性和性能。在投产准备时期，QALoad可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试，并针对所发现问题对系统性能进行优化，确保应用的成功部署。它的优点非常突出：

首先，QALoad并不需要真正调用最终用户及其设备，就能够仿真数以千计的用户进行商业交易，从而使用户在测试阶段就可以预知业务量达到投产后真实水平时，系统的响应时间，以满足客户的服务品质要求。

其次，测试人员可以使用QALoad录制/回放功能来重复验证特定负载下的应用性能，以便客户可以充分地了解与容量相关的问题，快速确认性能瓶颈并进行优化和调整。

此外，QALoad 还提供一个定义、管理和执行负载测试的中心控制点-Conductor。它能够自动识别网络中可进行负载测试的机器，并在这些机器之间自动分布工作量，以避免网段超载。通过执行测试脚本。它还能管理无数的虚拟用户。从Conductor自动启动和配置远程用户，跨国机构甚至可以进行全球负载测试。

运用QALoad，测试人员可以不用手工编写脚本，也不必了解有关应用中间软件的详细知识和协议，就可以快速构造出最接近实际的测试方案。

此外，QALoad还可以捕获多种协议并在同一测试过程中执行它们；能准确地仿真浏览器与服务器之间的交互，包括多重联结，以使负载模拟更加准确；采用轮询法采集响应时间，减少进行大型负载测试时的网络资源耗费。

业务管理系统项目测试方案

（讨论稿）

   文档编号：

 

                        

文件修改记录表

修改内容要点	修改时间	修改人	审批人

目     录

1......................................................................... 项目概述... 5

2......................................................................... 适用范围... 5

3......................................................................... 预期读者... 5

4......................................................................... 测试目的... 5

5......................................................................... 参考文档... 5

6......................................................................... 测试环境... 6

7......................................................................... 测试工具... 7

7.1  原则... 7

7.2  性能测试工具... 7

7.3  测试管理工具... 8

8......................................................... 风险预测和防范... 8

9......................................................................... 接收测试... 9

10....................................................................... 测试内容... 10

10.1    安装测试... 10

10.2    功能测试... 10

10.3    业务测试... 10

10.4    性能测试... 10

10.5    安全测试... 11

10.6    文档测试... 11

10.7    回归测试... 11

11....................................................... 测试通过的标准... 12

12................................................. 需提交的测试文档... 12

13....................................................................... 测试方法... 12

13.1    原则... 12

13.2    安装测试... 12

13.3    功能测试... 13

13.4    业务测试... 13

13.5    性能测试... 13

13.6    安全测试... 14

13.7    文档测试... 14

13.8    回归测试... 14

14....................................................................... 测试流程... 14

15............................................................ 项目组织管理... 15

15.1    人员管理... 15

15.2    项目管理... 16

15.3    错误管理... 16

15.3.1        错误的跟踪与记录... 16

15.3.2        错误的提交、修改与回归测试... 17

15.4    测试时间表... 17

1. 项目概述

1. 适用范围

本测试方案作为《业务管理系统》项目测试的实施依据。

1. 预期读者
2. 测试目的

本测试旨在检验软件功能、性能是否符合业主的需求。

1. 参考文档

1. 测试环境

C/S部分运行环境

1. 1. 服务器端：
      1. 硬件：
         1. CPU: 2路500 MHz RS64 III对称多处理器, 2路750 MHz RS64 IV对称多处理器, 二级缓存
         2. 内存：2GB
         3. 硬盘：80GB
      2. 软件：服务器端操作系统一般是HP-UNIX，Solaris，AIX。SCOUnix等。
      3. 数据库的数据量情况(现在、预计未来两年后)

目前对于省级财政来说，所有的预算单位一般在800到1000之间，一年内每个单位的指标在20条左右，用款计划在20*12=240条，直接支付申请在20*12=240，授权支付在50*12=300条，生成的会计凭证也大概在500条左右，这样就可以计算出一个单位一年的数据量大概在20+240+240+300+500＝1300，所有单位的数据量在1300*1000=1300000，每条数据的大小估计在2k左右，这样一年的数据大小在2.5G左右，加上各种日志信息和审核记录信息，所有的数据量应该在2.5G+2.5G*2*2=12.5G/年。

预计在两年内，由于预算执行的更加细化，一些原来很粗的支出变得明细，所以数据量应该是目前的2到3倍，这样数据量估计在12.5*3=37.5G/年。这里还是不考虑其他的业务系统数据存在在同一台机器上。

1. 1. 客户端：
      1. 硬件：PIII750以上，256M内存，10G硬盘
      2. 软件：Windows98/2000/XP
      3. 网络环境：C/S部分基本上在局域网内进行，所以按照普通的网络条件参考。一般是百兆的交换机和网卡，客户端是百兆接入。

B/S部分运行环境需求

1. 服务器端：
   1. 1. 硬件
      2. 软件
      3. 数据库的数据量情况(现在、预计未来两年后)

B/S的服务器端配置同C/S部分。

1. 应用服务器：
   1. 1. 硬件：2CPU、4G内存、10G硬盘
      2. 软件：操作系统可能是Windows2000或者是Unix，应用服务器采用WebLogic7
2. 客户端：
   1. 1. 硬件：同C/S客户端配置
      2. 软件（包括浏览器类型版本等）：Windwos98/2000/XP，浏览器为IE6.0及其以上版本。
3. 网络环境：客户端基本上采用拨号方式或者是DDN专线方式，拨号方式下速率平均为28k/s，专线情况下能够达到256k/s。

1. 测试工具
   1. 原则

测试方以手工测试为主。必要时（如：性能测试、回归测试）采用测试工具辅助测试，在整个项目的实施过程中也将使用Microsoft公司的VSS软件来进行错误管理以提高测试效率。

1. 1. 性能测试工具

国库财政集中支付管理系统中不同的功能部分采用了不同的软件结构：

1. C/S结构部分：
   1. 1. 预算单位集中支付管理系统；
      2. 门集中支付管理系统中的账务管理；
      3. 门集中支付管理系统中的基础管理部分；
      4. 清算银行集中支付管理系统中的基础管理部分；
      5. 代理银行集中支付管理系统中的基础管理部分。
2. B/S结构部分：
   1. 1. 门集中支付管理系统执行指标管理、计划管理、拨款单管理、支付管理、退款管理；
      2. 清算银行集中支付管理系统执行指标管理、计划管理、拨款单管理、支付管理、退款管理；
      3. 代理银行集中支付管理系统中执行指标管理、计划管理、拨款单管理、支付管理、退款管理。

根据不同的软件结构需要将使用不同的性能测试工具

1. C/S结构将采用Compuware公司的QALoad软件进行性能测试；
2. B/S结构将采用Compuware公司的QALoad软件进行性能测试，或选用其他适合B/S模式的测试工具,如MI公司的LoadRunner或Empirix公司的e_load；
   1. 测试管理工具

根据几方协商确认，测试过程中采用Microsoft公司VSS软件做为文档管理工具；且将于11：30，14：30，17：30，20：30四个时刻将错误记录通过IE浏览器提交到公司bug管理平台中。

1. 风险预测和防范

测试中的各种局限性使得测出软件系统中的全部错误或缺陷比较困难。为了能够更好的完成测试，我们对测试中可能产生的风险作出预测并制定了防范措施。

1. 风险：测试用例对功能与业务的覆盖不充分；

防范：通过补充和完善测试用例，减少功能的漏测；通过典型业务流程测试，检查各功能间关联及业务逻辑实现的正确性；

1. 风险：由于测试用例错误造成测试结果不正确；

防范：通过业主方、开发方与监理方对测试用例的评审，提高测试用例设计的质量；

1. 风险：由于测试环境的影响造成测试结果有误差；

防范：测试环境配置与实际运行环境要尽量一致；

1. 风险：由于在性能测试中测试工具选择错误造成测试结果有误差；

防范：在正式测试之前，对测试工具在该系统环境下进行可用性测试；

1. 风险：由于在正式测试过程中发现致命性错误造成对测试时间有影响；

防范：在正式测试过程中发现致命性错误，会及时的通知开发方，以期尽快解决，来减少影响。

1. 接收测试

接收测试条件：

1. 具备可应用于系统测试的软件：开发人员经过单元测试和集成测试，软件功能已基本实现；
2. 具备系统测试的环境；
3. 具备齐全的文档：
   1. 《业务管理系统业务需求》；
   2. 《性能需求表0608》；
   3. 《业务管理系统需求规格说明书》；
   4. 《业务管理系统概要设计》；
   5. 《业务管理系统详细设计》；
   6. 《业务管理系统用户手册》（包含安装与维护）；

接收测试的通过标准：

从公司的测试用例库中选用并执行适当的典型基础业务流程测试用例集，通过率在90％以上，其中通过\未通过的评判标准为：

1. 当执行用例时产生的错误级别为致命性错误或严重功能/性能错误时，此用例本身为未通过状态，受其影响导致不能正常进行的其他用例为未通过状态。
2. 当执行用例时产生的错误级别为告警性错误或建议性错误时，可以认为其用例为通过状态。

1. 测试内容
   1. 安装测试

1. 验证软件是否能按照用户手册的安装部分进行正常的安装和卸载
2. 检查系统安装过程的友好性：界面、提示与帮助信息是否一致、完整正确
   1. 功能测试

功能测试是系统测试阶段的一个重要任务。功能测试的目标是测试系统内各功能模块是否达到设计目标。

测试方在开发方完成单元测试及集成测试的基础上进行的全面、深入的系统功能测试，以确认需求说明中要求的功能都已实现，没有遗漏。

测试用例的设计将根据附件所列出的功能列表进行；测试用例将包括正确测试用例、错误测试用例，边界值测试用例。

1. 1. 业务测试

业务测试是检验系统是否达到业务管理系统的业务要求的关键步骤。业务测试过程中，通过对典型业务流程和特殊业务流程的模拟，可以发现系统在进行业务处理过程中是否符合业务的逻辑要求。

业务测试用例设计需要参考需方的日常业务操作中典型业务流程及特殊业务流程，测试过程中需要业主方熟悉系统业务流程的人员配合用例设计工作并参与测试。

1. 1. 性能测试

性能测试的目标是测试系统是否达到所需要的各项性能指标。

性能测试内容应包括日常业务情况下压力测试，高峰业务情况下压力测试及系统持续业务处理能力测试，并据此对系统的性能进行全面的评价。

性能测试的设计原则

分析系统的业务分布，挑选做性能测试的典型业务

按照实际运行中统计的业务并发量，设定压力测试的起始业务并发数量，以及并发量递增的增量

参照系统的峰值设计需求，逐步对系统加压至性能拐点

改变应用服务器的数量和配置情况，检查应用服务器对性能的影响

参照以上测试的结果，设计系统持续处理能力测试

业主方应选派业务人员和服务器及网络管理的技术人员参加性能测试。

1. 1. 安全测试

安全测试的目的是检查系统是否达到安全要求。由于此软件运行环境基本处于专用网内部。此次安全测试的内容包括：

1. 用户唯一性验证
2. 用户权限管理
3. 系统日志
   1. 文档测试

文档测试的目的是检查开发方提供的应用软件技术文档、用户文档内容的正确性、完备性、逻辑条理性和通俗易懂可读性，文档与软件系统的一致性以及版本配置的一致性。采用人工方法进行检测。

文档测试对象包括项目完成后开发方提交给业主方的所有技术文档资料和应随产品提交的所有用户文档，如用户手册（包含安装与维护部分）等。

1. 1. 回归测试

在最后一轮测试工作完成并且所有发现的错误都经开发人员修改完成后，为了验证开发人员在错误修改的过程中已经正确修改了发现的错误并且没有引入任何新的错误，需要做一次回归测试。回归测试将会运行所有的测试用例，以保证上线运行的软件的质量。

回归测试时根据功能测试和业务测试的结果，可能需要对测试用例进行必要的补充。

1. 测试通过的标准

1. 没有致命性错误与功能性错误，此处功能性错误是指规定的功能没有实现或不完整。
2. 没有严重影响系统运行的性能问题
3. 剩余的告警性、建议性错误与性能问题经过四方的讨论决定暂不修改

1. 需提交的测试文档

1. 《集中支付系统测试方案》
2. 《集中支付系统测试周报》
3. 《集中支付系统测试验收报告》

1. 测试方法
   1. 原则

本项目功能测试以手工测试为主，必要时可以使用辅助测试工具。性能测试使用测试工具，以达到模拟真实运行环境的要求。

1. 1. 安装测试
2. 《用户手册》中的安装说明部分能否顺利指导安装过程
3. 在不同环境下安装的正确性
4. 安装过程中可选方案是否都可行
5. 软件卸载以及卸载后重新安装，软件是否正常工作
   1. 功能测试

1. 依据软件需求规格书，结合系统功能列表设计出正确性测试用例
2. 对于需要资料合法性和资料边界值检查的功能，增加相应的错误和边界值测试用例
3. 执行测试用例
4. 检查测试结果是否符合功能需求
5. 评审功能测试结果
   1. 业务测试

1. 业主方的业务人员配合完成典型业务流程及特殊业务流程的设计
2. 根据业务流程设计测试用例
3. 执行测试用例
4. 检查测试结果是否符合业务需求
5. 评审业务测试结果
   1. 性能测试

1. 依据系统性能要求，制定出测试方案并设计出测试用例。
2. 在各客户端安装压力测试工具并录制测试脚本
3. 使用压力测试工具对客户端进行配置
4. 运行测试脚本，进行压力测试
5. 压力测试按照并发量递增的顺序进行
6. 对每笔交易的时间进行记录，得到不同并发度条件下系统响应时间变化曲线，判断其是否符合设计要求
7. 对系统内数据库服务器、应用服务器等系统的资源使用情况进行监控
8. 在高并发量情况下，增加应用服务器的数量，获得系统响应时间变化曲线
9. 通过同时对同一个资料表进行多种操作，测试锁表处理的正确性
10. 检查各种并发度下交易成功率和错误类型
11. 通过使系统长时间在高并发条件下的运行，测试系统性能是否有明显下降和是否存在有内存泄露情况出现，测试系统运行是否稳定
12. 归类、整理并上报测试过程中发现的性能缺陷
    1. 安全测试

1. 通过不同权限用户的使用，对用户使用系统的权限进行检查
2. 通过用户对系统的登录及使用，检查系统对用户一致性校验
3. 检查操作日志，验证其功能是否实现
   1. 文档测试

1. 检查开发方所提交的文档是否完整，内容是否正确
2. 依照开发方所提交的《用户手册》中的安装说明部分进行软件安装
3. 依照开发方所提交的《用户手册》进行软件使用、维护
   1. 回归测试

1. 根据功能测试和业务测试用例执行结果，按照需要对测试用例进行必要的补充
2. 执行补充测试用例
3. 将所有的功能测试用例和业务测试用例重新执行，测试软件修改了已有错误，并且没有引入新的错误。

1. 测试流程

1. 项目组织管理

为了保证软件的测试工作高质量、如期的完成，测试方必须精心进行项目组织，并实施严格的管理。

1. 1. 人员管理

本项目测试人员由一名项目督导、一名项目经理、测试工程师、及相关业务人员组成，具体人数将根据具体测试时间和任务安排而确定。

1. 项目督导：（1人）
   1. 监督、统筹及协调项目中各项活动；
   2. 负责建立软件测试的整个过程
   3. 负责培训软件测试人员及开发人员质量意识
   4. 负责指导测试的每一关键步骤
   5. 负责指导测试计划、测试案例、测试报告的编写
2. 项目经理：（1人）
   1. 项目整体和各关键阶段的技术负责人和管理人；
   2. 负责承担项目任务的计划、组织和控制工作，以实现项目目标；
   3. 负责向项目协调机构定期报告项目进展情况，就项目中存在的问题提出解决建议；
   4. 统筹及协调项目中各项活动和任务安排；
   5. 负责测试方和业务方，开发方的协调配合工作。
3.  测试工程师：（4人）
   1. 负责编写、制定测试用例；
   2. 负责实施测试；
   3. 负责将问题录入问题管理系统；
   4. 负责问题分类、总结；
   5. 负责测试文档的保存。
4.  业主的业务人员（3人）
   1. 负责在项目期间，参加和指导提出需求和需求分析，以及咨询解答项目实施过程中有关技术、业务及项目管理的问题；
   2. 负责评审测试用例，参与测试；
   3. 负责提供典型业务流程及特殊业务流程，并协助分析评审业务测试结果；

1. 1. 项目管理

项目的管理协调由业主方、开发方、监理方和测试方四方组成项目协调小组。项目协调小组由四方项目负责人组成，由业主方担任组长。其职责如下：

1. 在测试工作的各个阶段，四方之间互通信息、交流情况；
2. 决定与测试有关的开发和管理等重大事宜；
3. 当测试方与开发方产生争议时进行协调，并作出决策。
   1. 错误管理
      1. 错误的跟踪与记录

测试发现的错误分为以下四类：

1. 致命性错误：数据丢失，数据计算错误、系统崩溃和异常死机；
2. 严重功能/性能错误：规定的功能没有实现或不完整、设计不合理造成性能低下，影响系统的运营；
3. 告警性错误：不影响业务运营的功能/性能问题；
4. 建议性错误：软件设计和功能实现等不甚合理之处提出建议。

在测试执行过程中，把发现的错误提交到问题管理系统中，并对错误进行跟踪管理。每一个错误有以下生命周期：

发现—提交—修改—重新测试—结束

当对开发方提交的一个确定版本通过全面的系统测试，所有错误经确认后，提交给开发组有关成员进行修改。当所有错误的状态变为修改完成时，由开发方提交新的版本后，再开始下一轮系统测试。

1. 1. 1. 错误的提交、修改与回归测试

为保证进度，测试方应将一轮测试中发现的错误分批提交开发方。每一轮测试完成后提交完整的测试记录，并对发现的错误进行分类、统计和分析，形成软件问题报告。

为保证测试工作的顺利进行，除非必须，测试方在一轮测试完成之前不接受开发方提供的任何更新版本。

开发方完成修改工作后，将软件更新版本及问题更改报告提交测试方进行回归测试。问题更改报告应详细说明修改了的错误、更新了的组件、可能受修改影响的组件等。未能修改的错误应说明原因，当测试方、开发方在时间、进度、质量等问题上发生争议时，或测试中发现严重错误时，应及时报告给项目协调小组，必要时由协调小组进行决策。

测试方收到更新版本后，开始作下一轮测试。在软件基本稳定后，测试方进行全面的回归测试，以确认修改是否引入新的错误。

1. 1. 测试时间表

附件：集中支付系统功能列表

性能测试工具简介（QALoad）：

Compuware公司的QALoad是一个企业级的自动化负载测试工具。它通过可重复的、真实的测试彻底地度量应用的可扩展性和性能。在投产准备时期，QALoad可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试，并针对所发现问题对系统性能进行优化，确保应用的成功部署。它的优点非常突出：

首先，QALoad并不需要真正调用最终用户及其设备，就能够仿真数以千计的用户进行商业交易，从而使用户在测试阶段就可以预知业务量达到投产后真实水平时，系统的响应时间，以满足客户的服务品质要求。

其次，测试人员可以使用QALoad录制/回放功能来重复验证特定负载下的应用性能，以便客户可以充分地了解与容量相关的问题，快速确认性能瓶颈并进行优化和调整。

此外，QALoad 还提供一个定义、管理和执行负载测试的中心控制点-Conductor。它能够自动识别网络中可进行负载测试的机器，并在这些机器之间自动分布工作量，以避免网段超载。通过执行测试脚本。它还能管理无数的虚拟用户。从Conductor自动启动和配置远程用户，跨国机构甚至可以进行全球负载测试。

运用QALoad，测试人员可以不用手工编写脚本，也不必了解有关应用中间软件的详细知识和协议，就可以快速构造出最接近实际的测试方案。

此外，QALoad还可以捕获多种协议并在同一测试过程中执行它们；能准确地仿真浏览器与服务器之间的交互，包括多重联结，以使负载模拟更加准确；采用轮询法采集响应时间，减少进行大型负载测试时的网络资源耗费。