2023年6月30日发(作者：)

网通系统压力测试方案

网通压力测试方案

目

录

一、概述 ........................................................................................................................................... 3

1.1 项目背景和测试目的 ............................................................................................... 3

1.2 被测系统介绍 ........................................................................................................... 3

1.3 测试可接收条件 ....................................................................................................... 4

二、测试需求 ................................................................................................................................... 4

三、测试方法 ................................................................................................................................... 4

3.1 测试方法 ................................................................................................................... 4

3.2 测试案例 ................................................................................................................... 8

3.3测试流程 ............................................................................................................................. 8

3.4数据文件准备 ..................................................................................................................... 8

3.5测试脚本说明 ..................................................................................................................... 9

四、测试环境 ................................................................................................................................... 9

4.1网络拓扑图 ......................................................................................................................... 9

4.2环境配置 ............................................................................................................................. 9

五、测试实施 ................................................................................................................................. 10

5.1试资源与进度 ................................................................................................................... 10

5.2 测试机构和人员职责 .................................................................................................... 11

六、试存储管理规范 ..................................................................................................................... 12

6.1存储内容、地点、命名规则 ........................................................................................... 12

6.2存储目录结构 ................................................................................................................... 13

6.3备份 ................................................................................................................................... 13

附录1：Env_Check_list ................................................................................................................ 14

附录2：测试工具原理 .................................................................................................................. 15

测试方法及步骤 ............................................................................................................. 16

第2页 网通压力测试方案

一、概述

1.1 项目背景和测试目的

为了保障网通即将建设的综合营帐系统能够顺利实施，网通希望在项目正式实施前了解未来系统是否可以使用目前已经选用的技术进行搭建，即了解项目技术的可行性。另外，网通还希望了解使用不同技术实现的差异。

1.2 被测系统介绍

本次被测系统是针对网通项目的一个前期实验系统。系统逻辑结构图如下：

图1、系统逻辑结构图

整个系统分为三个主要部分，主要功能包括：

1. 系统A

系统A是整个系统的数据入口，可以将客户请求传给Biztalk或者直接传给系统B。系统A可以通过两种方法接收客户请求传给系统。一种通过Tuexdo

(A)接收用户请求，另一种可以直接通过WebLogic(A)接收用户请求。

2. Biztalk

第3页 网通压力测试方案

Biztalk是整个系统的中心，负责连接系统A和B，主要目的是同步处理系统消息。另外，由于测试需要，Biztalk本身可以接收用户请求（Http）。

3. 系统 B

可以看作系统的服务端。接收Biztalk的请求，并返回结果。

1.3 测试可接收条件

1、每次测试交易成功率在90%以上

2、用户每个请求的响应时间低于2秒

每次测试，以上条件必须同时满足，方视为本次测试通过。

二、测试需求

本次测试的需求包括：

1、Biztalk系统的处理能力

2、整个系统能够支持多少用户同时访问

3、不同技术间实现的差异

三、测试方法

3.1 测试方法

测试过程采用自动测试工具进行。目前暂时决定使用Mercury Interactive公司的测试产品：LoadRunner。

1、测试Biztalk系统的处理能力：

第4页 网通压力测试方案

Biztalk AICchannelHttpport Http/XMLHTTP

图2、测试Biztalk系统的处理能力

模拟多个Web类型的虚拟用户，同时向Biztalk系统发送HTTP请求，之后记录每个虚拟用户的响应时间。

2、整个系统能够支持多少用户同时访问

方法一：

模拟多个Web类型的虚拟用户，同时向WebLogic(A)发送HTTP请求，之后记录每个虚拟用户的响应时间。

Tuxedo(B)ServiceBTuxedo(A)ServiceABiztalkWTCWebLogic(B)WTCWebLogic(A)EJBJsp/servlet AICchannelEJBHttpportJsp/servletHTTP Http/XML图3、测试整个系统能够支持多少用户同时访问（方法一）

第5页 网通压力测试方案

方法二：

模拟多个Tuxedo类型的虚拟用户（即模拟Tuxedo客户端），同时向Tuxedo(A)的服务发送Tuxedo请求，之后记录每个虚拟用户的响应时间。

Tuxedo(B)ServiceBTuxedo(A)ServiceATuxedoBiztalkWTCWebLogic(B)WTCWebLogic(A)EJBJsp/servlet AICchannelEJBHttpportJsp/servlet Http/XML图4、测试整个系统能够支持多少用户同时访问（方法二）

3、不同技术间实现的差异

方法一：

模拟多个Tuxedo类型的虚拟用户（即模拟Tuxedo客户端），同时向Tuxedo(A)的服务发送Tuxedo请求，并且Tuxedo（A）发送的请求，不经过Biztalk系统，之后记录每个虚拟用户的响应时间。

第6页 网通压力测试方案

Tuxedo(B)ServiceBTuxedo(A)ServiceATuxedoWTCWebLogic(B)WTCWebLogic(A)EJBJsp/servletEJBJsp/servlet Http/XML图5、测试不同技术间实现的差异（方法一）

方法二：

模拟多个Web类型的虚拟用户，同时向WebLogic(A)的发送HTTP请求，并且WebLogic（A）发送的请求，不经过Biztalk系统，之后记录每个虚拟用户的响应时间。

Tuxedo(B)ServiceBTuxedo(A)ServiceAWTCWebLogic(B)WTCWebLogic(A)EJBJsp/servletEJBJsp/servletHTTP Http/XML

图6、测试不同技术间实现的差异（方法二）

第7页 网通压力测试方案

3.2 测试案例

虚拟用户类型

测试Biztalk系WEB

统的处理能力

测试目的 Case No.

并发用户数

交易循环

次数

001

002

003

004

整个系统能够支WEB 005

持多少用户同时006

访问

007

008

TUXEDO 009

010

011

012

不同技术间实现WEB 013

的差异

014

015

016

TUXEDO 017

018

019

020

3.3测试流程

正式测试过程如下：

1、确认被测环境正常（Env_Check_list）

2、确认测试环境设置（Env_Check_list）

3、开始测试

4、存储测试结果

5、系统调试

6、应用调试

7、环境维护

3.4数据文件准备

数据文件名称

包含内容

说明

数据量

第8页 网通压力测试方案

3.5测试脚本说明

脚本名称 描述 参数说明

（TranNo.:Tran名称:解释） （参数:说明）

四、测试环境

4.1网络拓扑图

被测系统服务器1服务器2服务器3网络测试机测试机控制台测试系统

图7、测试网络拓扑图

4.2环境配置

数据

（参数:文件:方法）

第9页

网通压力测试方案

被测系统

测试系统

网络

类型

服务器1

服务器2

服务器3

测试机

控制台

配置

软件

五、测试实施

5.1试资源与进度

项目任务分解

阶段

任务内容 完成标准 责任人

资源与

时间

0.5人天

0.5人天

2人天

项目定义，规划项目运作模式，项目设立项目 编制项目计划，组建项目班子与输出《项目计划》

启动

实施队伍

测试需求调研

测试计划和测试设计

明确测试需求、测试目标、界定测试范围、任务和具体内容

细化《测试方案》，定义测试范围，并定义各项测试活动和步骤，具体安排测试实施过程及测试进度

对测试方案定义的功能、性能测试范围、测试策略、测试组织实施过程、测试进度等进行评审

双方就测试需求达成共识

测试经理

测试人员

微软负责人

制定测试方案

输出《测试方案》测试经理

（初稿）

输出《测试方案》（讨论稿），对测试微软负责人

方案中涉及的各项测试经理

内容达成共识

应用正常运行

各测试软件正常运行

输出《测试数据准备清单》，并准备好测试数据

输出可执行的测试脚本

微软负责人

测试人员

测试人员

微软开发人员

测试人员

测试方案评审

1人天

搭建应用搭建应用所需的环境，并建立测运行环境 试数据库

测试搭建测试准备运行环境

工作

准备测试数据

搭建测试所需的环境，包括测试工具软件、性能监控软件等

准备必要的功能及压力测试所需的测试数据

1人天

1人天

1人天

测试开发压力按照压力测试案例设计，开发测开发 测试脚本 试脚本

第10页 网通压力测试方案

预测试

证明测试脚本可用，证明测试流程可用

证明测试环境配置合理

证明测试数据准备充分

按照预期可接收条件：

运行2x2场景成功

运行25x25场景成功

运行500或1000并发用户场景，测试经理和项目经理直到认为测试停止

按照预期可接收条件，系统已经不能承受

输出《性能测试评估报告》

微软负责人

微软开发人员

测试经理

1天

测试系统调优 使系统运行在最佳状态

执行

微软负责人

微软开发人员

测试经理

2天

测试系统究竟能够承受的业务极限测试

量

压力测试评估

测试评估 总结

总结

按照测试评估策略对性能进行评估，并对系统性能进行分析

测试人员 1天

输出项目报告、相关文档归档，输出《项目报告》

安排后续工作

测试人员

5.2 测试机构和人员职责

角色

网通项目经理

测试项目经理：

测试组

开发专家

测试专家

系统专家

任务

测试策略制定，管理协调

测试组织、管理协调

测试执行并协助进行结果分析

业务指导，调优指导

测试工具支持，测试方案审核

系统恢复、系统问题顾问

网通项目经理

测试项目经理

专家组

测试组

开发专家 测试专家 系统专家

图8、测试组织结构图

第11页 网通压力测试方案

六、试存储管理规范

6.1存储内容、地点、命名规则

 存储内容：

a) 测试脚本

b) 测试场景

c) 测试结果

d) 相关文档

e) 数据文件

 存储地点：

运行控制台的主机硬盘上，存储结构见下面图9。

 命名规则：

a) 测试脚本

LTscr_App_[SubApp_]version

说明：

LTscr：Load Test Script

App：业务名称

SubApp：子业务名称（[ ]可选）

Version：脚本的版本号

b) 测试场景

LTsce_App_[SubApp_]ConCurrUser_Iteration

说明：

LTsce：Load Test Scenario

App：业务名称

SubApp：子业务名称（[ ]可选）

ConCurrUser：并发用户数

Iteration：每个用户循环次数

c) 测试结果

LTres_ App_[SubApp_]ConCurrUser_Iteration _time

说明：

LTres：Load Test Result

第12页 网通压力测试方案

App：业务名称

SubApp：子业务名称（[ ]可选）

ConCurrUser：并发用户数

Iteration：每个用户循环次数

Time：第几次测试

6.2存储目录结构

DF_LoadTest

Script

Scenario

Pre_Test

Test

Result

Date( MM_DD_YYYY)

Document

DataFile

图9、测试存储结构图

说明：

Script：存储测试脚本

Scenario：存储测试场景

Result：存储测试结果

Document：存储相关文档

DataFile：存储数据文件

6.3备份

测试结果每天在测试结束后备份一次，将“D:LoadTest”目录，全部备份到磁带机或“AnyPCC: LoadTest_bak”

第13页 网通压力测试方案

附录1：Env_Check_list

日期：2002年___月___日___时___分

测试结果名称：____________________

检查内容如下：

检查项

被测试系统：

Web Server清除Cache 和临时文件

Web Server重新启动

Application Server 清除Cache和临时文件

Application Server重新启动

DB Server清除新生成的记录和临时文件

DB Server 重新启动

确认应用可以正常运行

测试系统：

测试机清除临时文件

测试机重新启动

控制台机器清除临时文件

控制台机器重新启动

测试机LoadRunner RCL已经启动

确认测试机临时空间大于1G

Iteration次数设置正确

不写log

确认Proxy设置

Simulate browser Cache enable

Download non-HTML resources enable

Simulate a new user each iteration enable

参数方法正确

DNS Cache enable

Keep-Alive enable

Concurent connections = 4

测试监督签字：________________________

检查人 结论 备注

第14页 网通压力测试方案

附录2：测试工具原理

Mercury Interactive 公司的客户机/服务器系统的压力测试工具LoadRunner，其工作原理为：通过一个中心控制点，在一个或几个主机上同时模拟成百上千的实际用户的操作，从而生成一致的、可测量的及可重复的系统负载，并记录特定交易操作的响应时间。概要地说：首先录制应用程序的操作过程，测试工具会自动生成可执行的脚本，该脚本运行起来，从服务器端看，就如同一个实际的用户在进行操作，我们称为虚拟用户。然后，通过中心控制点（Controller）设置测试场景，控制许多个虚拟用户在多台Agent机器上同时运行，监控运行状态，收集响应时间等性能数据。

 使用虚拟用户（Vuser）替代实际用户

每个模拟的用户即为一个虚拟用户，其实就是一个运行的测试脚本。

LoadRunner在PC上主要有两种Vuser：非图形用户界面的虚拟用户（Non-GUI Vuser）和图形用户界面虚拟用户（GUI Vuser）。

Non-GUI Vuser是直接通过API调用和Web/Application/DB服务器进行交互的，它的脚本是直接向服务器提交请求的类C语言程序。多个Non-GUI Vuser可运行于一台主机上。Vuser可通过Virtual User Generator来录制生成，在录制脚本中可以标明某一活动（transaction）的开始和结束点，用于具体度量这一活动的响应时间及性能，还可以在某一操作之前定义集结点（rendezvous），用于测试这一操作的多用户并发。

GUI Vuser模拟实际用户运行应用程序进行操作的情况，它的脚本记录了客户机上所有的界面操作。GUI Vuser可通过Mercury Interactive 公司的功能测试工具WinRunner来录制生成。

由于本次压力测试的目的是检验服务器对压力的承载能力，因此建议通过在一台主机上运行多个Non-GUI Vuser来模拟多用户的活动进行压力测试。

 测试脚本的参数化

测试脚本反映的是录制时输入的数据的情况。但由于录制操作可能引起原输入数据状态的变化，因此要修改测试脚本中的输入数据及与其相关的数据；而且为了更准确地模拟真实系统的运作，输入的数据及与其相关的数据就必须参数化，并且为该参数建立一个包含所有数据的参数文件。这样当模拟多用户进行压力测试时，就可控制每个虚拟用户使用参数文件中的不同数据。

通过中心控制点（Controller）管理虚拟用户

在中心控制点，定制测试场景，即将要在测试会话中发生的事件。定制包括模拟的用户个数、模拟用户所在的主机、模拟用户的动作等。

在中心控制点控制场景的运行，管理所有虚拟用户的活动，监控虚拟用户的第15页 网通压力测试方案

状态，也可以无人照料地运行。场景执行完后，可通过Controller的性能分析图形和报表对结果数据进行分析。

代理程序必须安装在参与测试的每一台主机上，当场景开始运行，代理程序负责Controller与主机之间的通讯。

LoadRunnerControllerLANApplication/WebServerLoadRunnerVusersDatabaseClient

 使用自动生成的图表和报表分析测试结果

在每个测试场景运行完后，Controller自动收集服务器、网络及客户端的性能数据，并以图形和报表的形式显示。其中包括服务器响应Vuser以及transaction

提交的请求和任务的时间；在运行期间的基于活动Vuser数目的transaction性能时间；服务器磁盘I/O、CPU使用情况，网络延迟等数据。

测试方法及步骤

1、建立虚拟用户（生成测试脚本）

在LoadRunner的Virtual User Generator中录制测试脚本，建立虚拟用户，一般一个业务操作录制成一个测试脚本，步骤如下：

1) 根据应用软件的体系结构、中间件、数据库或客户端与服务器之间的协议，选择对应的虚拟用户类型，如：WEB、Oracle、Tuxedo、WinSocket等等；

2) 指定要录制的可执行程序，开始录制；

3) 在Vuser init section 中记录登录应用系统的过程；

4) 在 Actions section中记录功能操作过程，适当加入事务（transaction）的开始与结束点（事务也可在脚本生成后，直接在脚本中加入）。当需要记录压力测试过程中某一操作的响应时间时，则在执行这一操作前定义事务的开始点，并给这一事务命名，在操作结束后定义该事务的结束点；

5) 在Vuser end section中记录退出系统的过程；

6) 回放测试脚本，检验测试脚本执行的正确性（有可能要恢复录制以前的数据状态，或进行必要的参数化）。

第16页 网通压力测试方案

2、 试脚本的参数化

测试脚本反映的是录制时输入的数据的情况，但为了更准确地模拟真实系统的运作，如模拟不同用户的登录，不同用户查询股票行情，不同用户在做不同的股票交易等情况，有些输入的数据必须参数化，并且为该参数建立一个包含所有可能的数据的参数文件。这样当模拟多用户进行压力测试时，就可控制每个虚拟用户使用参数文件中的不同数据。

参数的选择、参数文件的定制具体根据应用软件的实际情况而定，但要保证录制的脚本能够顺利地执行回放，且完成相应的业务功能。

3、 定制压力测试场景

在LoadRunner的Controller中，定制压力测试场景，也就是模拟一个多用户并发的情况，包括：运行虚拟用户的测试主机、在测试机上运行的虚拟用户数、虚拟用户运行的测试脚本、每个虚拟用户的循环次数等等。

1) 虚拟用户并发数：定义执行某一测试脚本的虚拟用户并发数，则虚拟用户并发总数为各脚本虚拟用户并发数之和；由于在运行测试脚本时，忽略了Think Time，因此一个虚拟用户的操作是非常连贯的，其强度远远大于一个实际用户的操作强度；另外，为了测试引起系统性能急剧下降的拐点和引起系统崩溃的崩溃点，并发的虚拟用户数需逐渐增加，每次增加的数量可视测试的具体情况而定。

2) 测试主机：选择运行某一测试脚本的测试主机。

3) 虚拟用户执行的脚本：选择虚拟用户执行的测试脚本，即完成某一业务功能的测试脚本。

4) Iteration Count：虚拟用户运行测试脚本Actions section部分的循环次数，增加循环次数是为了保证在某一稍长的时间段内有一个稳定的负载，这样统计的结果才比较准确。

需要注意的是，每台测试机上所支持的虚拟用户数，与测试机的配置和录制的应用程序的大小有关。每台测试机上运行的虚拟用户数不能太多，因为如果太多的话，性能瓶颈将会出现在客户端，那么测出的结果将毫无意义。

4、 运行压力测试场景

在LoadRunner的Controller中，运行压力测试场景，就可以控制测试机上的所有虚拟用户并发进行相应的操作。步骤为：

1) 启动测试机的Remote Command Launcher；

2) 在Controller中使测试机处于“连接”状态；

3) 在Controller中，对所有虚拟用户发出初始化（initialize）命令，测试主机的RCL启动Agent，并将虚拟用户初始化，执行测试脚本中Vuser init

section部分，使之登录系统；

第17页 网通压力测试方案

4) 在Controller中，对所有虚拟用户发出运行（run）命令，通过测试主机的Agent运行各虚拟用户，执行测试脚本中的Actions section部分，在Controller端监控虚拟用户的状态及执行结果；

5) 每个虚拟用户按指定的循环次数执行测试脚本中的Actions section部分，然后执行Vuser end section部分，退出应用系统；

6) 当每一个虚拟用户运行完成后，整个测试场景运行结束。在压力测试场景执行过程中，Controller会自动收集服务器、网络及客户端的性能数据，以及各事务的响应时间等。

5、 监控系统性能

在测试场景运行过程中，我们需要监控：

1) 监控运行虚拟用户的客户端的资源使用情况，使用Windows的性能监视器监控客户端的CPU、Memory等资源使用情况，以防止性能瓶颈出现在客户端；另外，可以在进行压力测试的同时，在另外的客户端上运行应用程序，也就是在系统负载较大时从最终客户的角度再进行相应功能的确认，并测试端到端的响应时间，也可将该响应时间与压力测试的响应时间进行比较，若结果差别不大，也可验证压力测试结果的可信性。

2) 监控数据库服务器、WEB服务器资源的使用情况，可以使用Quest

Software的I/Watch，或CA UniCenter和IBM Tivoli等专门的系统监控工具，来监控服务器端的CPU、Memory、Disk、Process、Network等资源使用情况，以便在压力测试时，判断性能瓶颈所在。

3) 监控数据库资源的使用情况，可以使用专门针对ORACLE的数据库监控工具，如， Quest Software的Spotlight、Space Manager、SQLab Xpert等监控磁盘空间的分配，磁盘I/O的竞争，内存区高速缓存的命中率，索引、锁等机制的运用以及性能不佳的SQL语句等。对这些资源情况进行分析，并找到性能瓶颈。

6、 分析测试结果

在Controller的Analysis中，分析并打印其中的性能报表，作为测试报告的附件：

Graph—Percentile:事务百分比对应的响应时间的图形，该图说明百分之几的事务是在多少响应时间以内完成的。如果已确定性能指标是95%的事务要在10秒内完成，那么可以根据该图判断是否达到性能指标；

Graph—Transaction Distribution:事务完成的相应时间的分布图，通过该图可以看出大部分事务完成的响应时间是多少秒；

Reports—Transaction Performance Summary：有关事务性能的总结报表，显示在测试场景中，所有事务的最小、最大、平均以及90%Percentile的响应时间；

根据压力测试过程中记录的数据库服务器、WEB服务器的CPU、Memory第18页 网通压力测试方案

以及Network性能数据以及数据库资源使用情况，进行分析，判断性能瓶颈所在。

第19页