性能测试服务解决方案

方案概述

XX银行的核心业务系统是运行多年的系统。随着业务量的逐年上升,对安全生产提出了挑战。因此需要进行一次性能评估测试,达到:第一,当前系统能够达到的峰值;第二,对于未来3-5年的预期,发现系统瓶颈,为系统调优做准备。

需要通过性能测试,来发现当前系统的瓶颈,以确定哪些部分需要进行优化,为后期的系统调优提供依据。

总体目标

对核心系统进行峰值测试,达到:
第一, 对核心业务系统进行分阶段进行性能测试。
第二, 根据当前的运行情况,分析性能测试场景、估算最高吞吐量,然后根据吞吐量进行性能测试(模拟高峰),看系统是否存在隐藏缺陷。
第三, 在各个性能测试场景之下,持续对系统加大压力,测试系统的最大容量(平均响应时间在可接受范围内),并且发现系统在达到最大容量之后是否出现异常,为安全生产提供指标。
第四, 对系统未来3-5年的压力进行预估(数据量和交易量),并根据预估结果进行测试,发现性能瓶颈和需要优化的节点。
第五, 根据测试情况,提交测试报告和缺陷报告。

性能测试方法论

1.性能测试分类

性能测试(Performance Testing):性能测试方法是通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生成性能要求。即在特定的运行条件下验证系统的能力状况。

负载测试(Load Testing):在给定的测试环境下,通过在被测系统上不断增加压力,直到性能指标超过预定指标或某种资源使用已经达到饱和状态,目的是了解系统性能容量和处理能力极限。负载测试的主要用途是发现系统性能的拐点,寻找系统能够支持的最大用户、业务等处理能力的约束。也可以理解为扩展性测试(Scalability Testing),即在固定测试环境,在其它测试角度(负载方面)不变的情况下,变化一个测试角度并持续增加压力,查看系统的性能曲线和处理极限,以及是 否有性能瓶颈存在(拐点)。主要意义是从多个不同的测试角度去探测分析系统的性能变化情况,配合性能调优。测试角度可以是并发用户数、业务量、数据量等不 同方面的负载。

压力测试(Stress Testing):测试系统在一定饱和状态下系统能够处理的会话能力,以及是否出现错误,一般用于稳定性测试。可以理解为资源的极限测试。测试关注在资源处于饱和或超负荷的情况下,系统能否正常运行,是一种在极端压力下的稳定性测试。其主要意义是通过测试调优保证系统即使在极端的压力情况下也不会出错甚至系统崩溃。

配置测试(Configuration Testing):通过对被测系统的软硬件环境的调整,了解各种不同环境对性能影响的程度,从而找到系统各项资源的最有分配原则。主要用于性能调优,在经过测试获得了基准测试数据后,进行环境调整(包括硬件配置、网络、操作系统、应用服务器、数据库等),再将测试结果与基准数据进行对比,判断调整是否达到最佳状态。

并发测试(Concurrency Testing):模拟并发访问,测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题,如内存泄漏、线程锁、资源争用问题。测试目的并非为了获得性能指标,而是为了发现并发引起的问题。

可靠性测试(Reliability Testing):通过给系统加载一定的业务压力的情况下,让应用持续运行一段时间,测试系统在这种条件下是否能够稳定运行。需要和压力测试区分开,两者的测试环境和测试目的不一样。压力测试强调在资源极限情况下系统是否出错,可靠性测试强调在一定的业务压力下长时间(如24×7)运行系统,关注系统的运行情况(如资源使用率是否逐渐增加、响应是否是否越来越慢),是否有不稳定征兆。

2.性能测试的一般过程

我们把性能测试分成以上阶段:

测试计划阶段
规划测试过程,编写测试方案、测试计划。
准备测试人员,搭建测试环境。

建立测试模型阶段
根据历史数据,构建测试模型,包括:压力模型、业务模型、数据模型、监控模型等。
测试模型主要是根据历史信息和未来的预期来构建。

创建测试场景阶段
创建测试模型之后,就需要创建不同的测试场景。
根据每日业务分布情况和特殊营业日的业务分布情况,对峰值曲线进行分析,主要分析曲线的峰值和拐点(曲率发生大的变化节点),拆分场景。

创建测试脚本
根据测试场景和具体的业务,创建测试脚本。
测试脚本依赖于测试工具。测试脚本需要考虑到被测试系统的响应速度等问题。

执行与监控
根据测试场景和加压方式等,进行测试。
测试分成多个轮次进行。

测试分析
分析测试结果。在测试过程中,会进行压力测试、负载测试、性能测试三个部分的测试(本次测试),并且获得随着压力增长而变化的性能监控数据。
通过对数据的分析,获得测试报告,对发现的缺陷提交缺陷。

3.性能测试模型

性能测试模型,分成:压力模型、业务模型、数据模型、监控模型、风险模型等。

压力模型
压力模型,就是根据系统的历史数据,分形当前系统压力的方法。
主要是对峰值的交易百分比进行分析处理,获得模拟的峰值。

业务模型
根据不同的业务品种(交易)来进行分析,分析在不同的场景下,交易的百分比分布情况。

数据模型
数据模型,主要是根据当前系统的数据量和关联。
数据模型需要在测试时候选择不同的关联数据。例如:典型机构的选取等。

监控模型
对哪些部分进行监控,监控的数据。

风险模型
系统存在哪些风险,也就是需要重点关注的数据和瓶颈。
对于重点关注的数据和瓶颈,需要进行重点测试。

环境环境

1. 测试环境

系统结构

说明:
1、 前置系统服务器主要负责柜面渠道、网银渠道之外的渠道,以及与第三方系统的接口;
2、 核心业务系统采用AS/400的系统;

软件配置

资源名称/类型

配置

数据库管理系统

DB2(AS400)、未知(前置系统)

应用软件

核心业务系统、前置系统

客户端前端展示

柜台业务系统

自动测试工具

性能测试工具

测试管理测试工具

N/A

测试策略

制订测试策略,首先有对测试进行分析,识别在影响性能测试的风险项。然后根据风险项来制订测试策略。

压力模型

当前高峰的压力(下图为节日交易数据):

取最高峰的数据为日均XX笔/日;
每小时最高交易量为: XX笔/小时,高峰时刻的平均吞吐率为:XX笔/秒。

1.估算模型一

从每日交易的分布情况来看,......。
最高吞吐率目标:75.9*120%=91笔/秒。

2.估算模型二

从交易高峰时段来看,按照......来计算:
XX/(7*3600) = XX笔/秒。

3.峰值估算

根据两个模型的估算,我们可以把交易的最大峰值设置到XX笔/秒。

测试场景模型分析

一般营业日
根据XX银行的数据:

节假日
节假日的情况如下:

峰值包括2个:
第一,上午10-11点高峰,占总交易量的10.07%;
第二,下午3-4点高峰,占总交易量的11.39%;

场景

场景

场景描述

备注

上午8-9点

 

 

上午10-11点

 

 

下午3-4点

 

 

下午11点

 

 

测试策略

不同客户端加压的影响

如上图,是系统的拓扑结构。可以看到在性能测试中,可以通过客户端发起交易来给系统进行加压,也可以通过发送报文的方式来加压。两种产生的效果差异在于:

比较项目

协议加压

客户端加压

脚本的复杂

简单,容易产生大的压力

复杂,需要更多的客户端来执行。每个客户端都模拟鼠标、键盘的输入输出,更真实

VU

不需要很多的虚拟用户(VU)

需要更多的虚拟用户(VU)

测试环境

比较简单,基本上单机即可

需要更复杂的测试环境,通过界面操作,每1-3分钟发起一个交易

场景真实模拟

需要编写比较复杂的脚本

能够模拟更真实的场景(如二段式交易)

客户端并发个数

支持模拟多个并发

能够模拟更多的客户端并发

测试脚本分类

脚本分类

属性

备注

客户端加压脚本

面向操作的脚本

 

客户端加压到后台脚本

面向协议

 

前置加压脚本

面向协议

需要更多的虚拟用户(VU)

网银界面加压脚本

面向操作界面

需要更复杂的测试环境,通过界面操作,每1-3分钟发起一个交易

网银协议脚本

面向协议

能够模拟更真实的场景(如二段式交易)

测试交易选取

测试数据选取
压力数据是按照一天的峰值时间段(如9点到10点)的数据交易量来进行模拟。

性能测试执行

压力产生模型

性能测试指标
性能指标的前提:交易成功率超过99.5%。
吞吐率:
并发数:
平均响应时间:
CPU占用率:
I/O:
数据库(锁、sql执行时间等)数据库是AS/400上的,还需要开发专门的程序分析性能

沪ICP备07036474号 2003-2017 版权所有 上海泽众软件科技有限公司 Shanghai ZeZhong Software Co.,Ltd.