压力测试报告

IT软件系统性能测试报告

文档说明

目录

1.引言 (5)

1.1.项目标识 (5)

1.2.系统概述 (5)

1.3.测试目的 (5)

1.4.测试环境 (6)

1.4.1软件环境逻辑架构 (6)

1.4.3软件环境 (7)

1.4.4测试工具 (7)

1.5.测试数据 (7)

2.测试指标及结果 (8)

2.1.测试指标说明 (8)

2.2.测试指标结果 (8)

3.测试结果 (8)

3.1.典型交易基准测试 (8)

3.1.1.业务范围 (9)

3.1.2.测试方法 (9)

3.1.3.场景设置 (9)

3.1.4.测试结果 (9)

3.1.5.结果分析 (10)

3.2.单交易负载测试 (10)

3.2.1.业务范围 (10)

3.2.2.测试方法 (10)

3.2.3.场景设置 (10)

3.2.4.测试结果 (11)

3.2.5.结果分析 (11)

3.3.稳定性测试 (11)

3.3.1.业务范围 (11)

3.3.2.测试方法 (12)

3.3.3.场景设置 (12)

3.3.4.测试结果 (12)

3.3.5.结果分析 (12)

3.4.容量测试 (14)

3.4.1.业务范围 (14)

3.4.2.测试方法 (15)

3.4.3.场景设置 (15)

3.4.4.测试结果 (15)

3.4.5.结果分析 (16)

4.测试进度 (16)

5.测试结果评估 (16)

6.系统评价 (17)

7.调优方案 (17)

8.测试遗留问题 (17)

9.附件 (17)

1.引言

1.1.项目标识

1.2.系统概述

银行非零售客户内部评级系统主要包括：评级政策管理、评级对象管理、信用评级管理、客户违约管理、评级监控管理、统计分析平台以及系统管理等共计七个模块，涵盖了内部评级的主要功能以及部分与内评相关的衍生功能。

本系统可应用于银行非零售客户的内部评级及其可配置化的流程。同时，系统提供多种外部接口，可供其他系统调用内评数据。

本系统一方面可以满足银行监管部门对于内部评级初级法的监管要求，同时为银行各业务条线的授信业务提供专业的评级服务；另一方面也有利于我公司扩大整个银行风险管理领域的市场份额，可提升公司在该领域的综合竞争力。

1.3.测试目的

通过对系统的性能测试，达到如下目的：

1.了解银行非零售内部评级系统的并发支持能力，预估系统的业务容量。

2.通过各种业务场景的测试实施，为系统调优提供数据参考。

3.了解业务系统的稳定性。

4.检验系统在异常业务场景下的容错能力。

5.通过性能测试发现系统瓶颈，并进行优化。

6.系统最大吞吐量、

7.系统各业务在各种压力交易下的运行状况、

8.获取系统处理能力。

1.4.测试环境

1.4.1软件环境逻辑架构

1.4.2硬件环境

1.4.3软件环境

1.4.4测试工具

1.5.测试数据

测试数据库：X,数据库实例名：X, 用户/密码：XXX

2.测试指标及结果

2.1.测试指标说明

被测系统在测试期间需要满足的相关性能指标数据，包括但不限于平均响应时间(ART)、事务处理量（TPS）、资源使用率等，是评价系统性能表现的主要依据。

2.2.测试指标结果

3.测试结果

根据不同的测试目的共设计4个业务模型测试场景：典型交易基准测试场景，单交易负载测试场景，稳定性测试场景，容量测试场景。

比对性能测试指标要求,符合预期，通过压力测试.

3.1.典型交易基准测试

在测试环境经过确认，脚本预验证之后，针对每支选定的交易或操作，在系统无压力的情况下，单交易用户迭代若干次，获取每个交易或操作的平均响应时间，以此作为多用户并发测试的基准和参考。

3.1.1.业务范围

3.1.2.测试方法

使用性能测试工具LR模拟客户端向目标系统发送交易请求，在系统无压力的情况下重复50-100次（或10分钟），每次迭代间等待1秒，获取交易的平均响应时间、TPS、点击率作为衡量指标。

3.1.3.场景设置

3.1.

4.测试结果

3.1.5.

结果分析

1、 所有交易执行正常，无执行失败交易；

2、在基准测试过程中，各种指标均满足性能要求。

3.2. 单交易负载测试

在完成单交易基准测试后，针对测试模型中的每一支交易或每一个操作，采用多个（5-15，视具体情况而定）虚拟用户数进行负载测试，获取业务处理性能和系统资源利用率等数据，并验证交易是否存在并发性问题。

3.2.1. 业务范围

3.2.2. 测试方法

使用LR 模拟客户端向目标用户发送业务请求，并接受返回结果的脚本。采用梯度发送的方式逐步增加系统请求的压力，每个梯度测试持续运行10-15分钟并记录测试相关数据，获取该交易最大处理能力，同时进行资源监控，问题定位测试结果分析。

3.2.3. 场景设置

3.2.5.结果分析

1)所有交易执行正常，无执行失败交易；

2)在单交易并发测试过程中，各种指标均满足性能要求。

3.3.稳定性测试

对系统的稳定性场景设计相关案例，例如：7×24小时系统保持稳定。主要关注系统是否稳定，系统是否存在内存泄漏等问题。异常情况的恢复或调整能力：如数据库异常连接中断、进程意外终止、磁盘满、宕机、硬件负载均衡器宕机等。

验证系统长时间负载运行的情况下，性能表现是否稳定。

3.3.1.业务范围

最大并发用户，持续运行24h，查看系统处理能力是否平稳。

3.3.3.场景设置

3.3.

4.测试结果

3.3.5.结果分析

1.资源图

CPU（数据库）

MEM（数据库）

2.结果图

ART（响应时间）

TPS

测试时间为24小时，2016/2/18 18:54 - 2016/2/19 19:33前12小时为2016/2/18 18:54-2016/2/19 8:54，ART及TPS稳定，后12小时为2016/2/19 8:55- 2016/2/19 19:33 ART及TPS稳定，因为夜间无外界影响或者影响小，白天网络有受影响，因此TPS有一定程度下降，ART会相应增加，情况属于合理。

3.4.容量测试

在既定的测试模型下，在给定的测试限制条件下，通过在被测试系统上逐步增加的并发用户数，梯度增加压力，获得系统响应时间、吞吐量、CPU和内存的使用等性能数据。确定在各种工作负载下系统的性能指标，直到突破限定条件。获取在不同压力下的性能表现，以及交易的TPS、响应时间、系统资源利用率等指标数据。经过测试分析获取应用系统在该测试环境下的最大处理能力。

3.4.1.业务范围

序号场景名称场景说明

4 容量测试场景1、业务范围：模型发布、客户同步、发起评级、正

式评级、违约认定申请、违约重生申请、违约技术

调整、用户同步

3.4.2.测试方法

根据测试模型中的交易比例构成测试场景，使用LR模拟客户端向目标系统发起交易请求。按照并发梯度的方法，逐步提升并发用户数的压力，每组梯队运行15-20分钟。观察并收集应用系统的CPU、内存、磁盘的占用情况、交易响应情况、交易成功率等指标。直到系统出现容量拐点或瓶颈后结束测试。（若在各项参数指标满足参考预设值，同时交易响应时间，TPS指标满足业务需求即可记录和结束测试；若在测试过程中，某项指标未达到预期，随即进入调优过程，直至达标后记录最后测试结果；若因时间等原因无法完成最终调优过程，详细描述测试过程，并记录当前系统的最高性能处理能力。

3.4.3.场景设置

3.4.4.测试结果

3.4.5.结果分析

1) 有少量失败交易，符合最低要求；

2)在单交易并发测试过程中，各种指标均满足性能要求。

4.测试进度

测试地点：北马路258号1006室

5.测试结果评估

压力测试过程中，在测试单交易负载：评级发起交易时，发现系统中数据库有连接未关闭的问题，并对解决情况进行了确认，确认已解决缺陷；同时在用

Nmon监控数据库时，发现额外系统同时在用数据库，导致25、26宕机，后通过科技协调，数据库为内评系统单独压测使用，此间影响了测试进度。

由于上线时间较紧，测试周期不够等因素而不能进行完全充分测试时，稳定性测试暂定为24小时，后续可进行72小时压测。

6.系统评价

通过本次性能测试，所有模块均达到性能要求，满足项目的目标。

7.调优方案

无需

8.测试遗留问题

9.附件

缺陷：

1：评级发起交易时，发现系统中数据库有连接未关闭。