性能测试方案

XXX容灾系统性能测试

性能测试方案

文档资料信息
服务名称： XX.XXX.XX.27~46（XXX应用服务器）
XXX.XXX.XX.123~24（XXX数据库）
项目经理： XX 文档版本号： 1.0
服务阶段： 项目实施 文档版本日期：
准备者： XX 准备日期：
审定者： 审定日期：
发送列表
发送者： 日期： 电话/传真：

接受者： 目的： 日期： 电话/传真：
审阅

版本历史
版本号： 版本日期： 修订者： 描述： 文件名：
1 2016-7-14 马鸿飞 服务器数

注意事项
内部传阅

目录
1 项目介绍 5
1.1 测试背景 5
1.2 测试目的 5
1.3 参考文档 5
1.4 缩略语和术语说明 5
2 测试范围 5
2.1 涉及系统 6
3 压测环境搭建 6
3.1 生产环境拓扑图 6
3.2 压测环境拓扑图 6
3.3 测试设备列表 6
3.4 测试环境和生产环境差异 6
3.5 性能测试机配置 7
3.6 性能测试工具 7
4 压测条件准备 7
4.1 准备工作 7
5 性能测试方案 7
5.1 性能测试策略 7
5.2 性能测试通过准则 8
5.3 测试业务模型 8
5.4 测试场景设计 8
5.4.1 第一轮测试 9
5.4.2 第二轮测试 12
5.5 测试数据要求 15
5.6 监控内容 15
6 测试计划 15
7 团队 16
8 风险 16
9 通过标准 16
10 优化建议 17

1项目介绍
1.1测试背景
随着业务量和业务能力的拓展，为了防止XXX系统因事故无法使用，建立灾备系统
1.2测试目的
本次性能测试的目的是检测灾备系统的性能情况。 作为XXX的灾备系统，能够在事故发生后切换至灾备系统，能够稳定运行。对该系统进行核心业务场景的性能测试。希望在模拟生产环境的情况下，能够收集相应的系统参数，作为灾备系统评估的依据。
1.3参考文档
《XXX环境应用服务器列表清单》、《XXXdb清单v2》、《XXX环境网络拓扑图》
1.4缩略语和术语说明
性能测试：在一定约束条件下（指定的软件、硬件和网络环境等）确定系统所能承受的最大负载压力的测试过程。
场景：一种文件，用于根据性能要求定义在每一个测试会话运行期间发生的事件。
虚拟用户：在场景中， LoadRunner 用虚拟用户代替实际用户。模拟实际用户的操作来使用应用程序。一个场景可以包含几十、几百甚至几千个虚拟用户。
虚拟用户脚本：用于描述虚拟用户在场景中执行的操作。
事务：表示要度量的最终用户业务流程。
并发数：单位时间内同时执行一种操作的用户数量
在线用户数：访问被测应用的用户数量，单位时间内用户不会同时对被测服务器发送请求，产生压力
TPS：Transaction Per Second，每秒事务数量，单位是 事务/秒
TRT:Transaction Response Time，事务响应时间，指TPS稳定时的平均事务响应时间，单位是秒

2测试范围
XXX灾备系统
2.1涉及系统
XXX灾备系统
3性能测试环境搭建
3.1生产环境拓扑图

3.2性能测试环境拓扑图

3.3测试设备列表
应用服务器37台，配置如下：
CPU个数 16
CPU型号 Intel® Xeon® CPU E7- 4820 @ 2.00GHz
内存：82G
系统 Linux

数据库服务器1台，配置如下：
CPU个数 60
CPU型号 Intel® Xeon® CPU E7-4870 v2 @ 2.30GHz
内存：380G
系统 Linux
数据库 ORACLE 11g

3.4测试环境和生产环境差异
按照最接近生产系统结构的原则，因只有两台数据库服务器，至少有一台参与性能测试，所以本次性能测试按照实际生产环境1:2比例缩小，也就是10台应用服务器，1台数据库服务器
因10台应用服务器对数据库服务器产生的压力太小，改为37台应用服务器和1台数据库服务器
3.5性能测试机配置
性能测试测试机1台，详情如下：
系统名称 Microsoft® Windows Server® 2008 Enterprise
处理器 Intel® Xeon® CPU E7- 4830 @ 2.13GHz，2134 Mhz，8 个内核，8 个逻辑处理器
内存 16.0 GB
备注：压测机CPU使用率<50% 内存<80% IOBUSY<50% 磁盘使用率<90% 网络带宽<30%
3.6性能测试工具
Loadrunner 11
4性能测试条件准备
4.1准备工作
1、测试功能点全部通过功能测试，确保功能上没有问题
2、准备性能测试环境服务器：
A、应用服务器10台
B、数据库服务器1台
3、准备性能测试机1台，需要安装Loadrunner 11并打通到应用服务器的网络
4、对于每个测试功能点，都要事先调试好相应脚本，并准备测试数据。保证脚本能够成功回放，数据正确
5、创建测试场景，配置好各场景设置
6、测试过程中保存好脚本及分析结果，并规范的对脚本和分析结果命名
5性能测试方案
5.1性能测试策略
1、关键资源不处于阻塞状态
A、服务器CPU利用率<70%
B、物理内存利用率<80%
C、场景通过率>99.99%
2、组合多个场景并发测试
3、测试执行
采用阶梯方式，并发数按照5、10、15、20….逐步增加，直至在某一个并发数增加后TPS达到峰值，并再增加并发造成响应时间增加，事件通过率降低
5.2性能测试通过准则
1、达到性能要求，在要求并发数用户下，系统响应时间小于或者等于客户要求的响应时间
2、在长时间运行后，系统不崩溃，各功能正常。
3、服务器CPU、内存、等参数保持稳定
4、测试停止后，一段时间内占用资源可以正常释放
5.3测试业务模型
以下根据生产环境（2016年6月26日当日按照工作10小时数据估算值TPS=并发数/平均响应时间=日交易量*0.8/7200）
序号 业务名称 平均处理时间 并发数量 高峰时段 业务量/天 备注(估算TPS)
1 员工登录 1.5s XX 9:00~11:00 XXX XXX
2 新建客户 15s XX 12:00~14:00 XXX XXX

5.4测试场景设计
1、员工登录
用例编号 NMYC_001
验证功能 员工登录
测试目的 被测系统是否能够满足大并发用户数登录的要求
前置条件 员工账号、密码
并发用户数 2500
思考时间 0s
方法 逐步设置并发用户数为2500个，模拟用户登录系统的负载压力情况，进行15分钟的连续压力测试，记录系统登录事务交易的平均响应时间、成功率，应用服务器、数据库服务器和网络的各项性能指标，作为系统在实际使用情况中的性能表现依据。对失败交易发生时的各项指标数据进行分析，定位问题发生的原因。
用例名称 并发数 期望响应时间（秒） 备注
员工登录 2500 <1.5s

2、新建客户
用例编号 NMYC_002
验证功能 新建客户
测试目的 被测系统能否满足大并发数新建客户的要求
前置条件 1、员工账号、密码
2、客户名称、客户证件号码、客户地址等
并发用户数 2500
思考时间 0s
方法 逐步设置并发用户数为2500个，模拟员工新建客户的负载压力情况，进行15分钟的连续压力测试，记录系统登录事务交易的平均响应时间、成功率，应用服务器、数据库服务器和网络的各项性能指标，作为系统在实际使用情况中的性能表现依据。对失败交易发生时的各项指标数据进行分析，定位问题发生的原因。
用例名称 并发数 期望响应时间（秒） 备注
新建客户 2500 <15s 　
5.4.1第一轮测试

5.4.1.1场景设置
员工登录
5.4.1.2测试结果

整体结果

基准测试虚拟用户数与TPS关系趋势图

基准测试虚拟用户数与处理时间关系趋势图

本次性能测试一共37台应用服务器，两台数据库服务器，压测30分钟

从压测图中可以看出，随着并发数增加（0-600）时间段（0:00-8:00）tps稳定上升，处理时间无太大变化
随着并发数增加（600-2500）时间段（8:00-15:00）TPS基本维持在2200—2300，处理时间随着并发数增加而增加
随着并发数增加（2500+）时间段（15:00-20:00）TPS呈现不规则跳动，处理时间也大幅度增加，同时错误事务数量变大，出现了接口异常和超时

因本次只压测了员工登录，门户部署的应用内存小于2.0G当TPS达到2300并发数最高为2500

5.4.2第二轮测试

5.4.2.1场景设置
新建客户
5.4.2.2测试结果

整体结果
XXX
基准测试虚拟用户数与TPS关系趋势图

XXX

基准测试虚拟用户数与处理时间关系趋势图
Xxx
5.5测试数据要求
客户设备号、员工工号及密码

测试数据需求列表
序号 适用场景描述 所需资源描述 数量 备注
1 员工登录 员工工号及密码 2500 　
2 客户定位 在用设备号码（接入号） 2500

5.6监控内容
6测试计划
编号 任务 参与人员 开始日期 结束日期
1 熟悉被测试系统，确定典型事务 测试人员
开发人员
业务人员 2016-7-3 2016-7-4
2 搭建测试环境，录制典型事务的脚本，增强脚本 测试人员
开发人员 2016-7-5 2016-7-10
3 执行测试并收集相关数据 测试人员 2016-7-13 2016-7-13
4 数据分析 测试人员 2016-7-13 2016-7-15
5 编写测试报告 测试人员 2016-7-15 2016-7-15

7团队
容灾项目组

8风险
风险描述 风险发生的可能性 风险对项目影响 规避方法
目前容灾环境先要经过生产环境的CSB-DEP，若系统双活可能会造成大量流水重复事务通过率下降，导致测试失败 低 高 单独部署CSB-DEP服务
测试数据大量预占，造成并发无法继续增加 低 高 数据准备充足
随着压力增加，系统异常，造成服务请求中断或者超时 高 高 及时做好服务器监控
存在重大错误，以致测试无法继续，需要开发部进行额外的调试和修改才能继续 低 高 代码质量控制
硬件或网络环境出现故障 低 高 无

9通过标准
1、性能测试场景通过，并满足并发、响应时间等要求
2、系统资源消耗
服务器CPU利用率<70%
物理内存利用率<80%
场景通过率>99.99%

3、性能测试结束后一段时间内，资源（系统资源及数据资源）释放正常

10优化建议
XXX