性能测试方案

性能测试方案

修订记录

目录

目录 (3)

1概述 (4)

2测试目标 (4)

3测试设计 (5)

3.1对象分析 (5)

3.2测试策略 (5)

3.3测试模型 (5)

3.4测试环境描述 (5)

3.5详细测试方法 (6)

4统计测试数据 (8)

5性能测试报告输出 (11)

6性能调优与回归 (11)

1、概述

首页、注册、登录、站内交流、站内搜索、测试技术资料上传与下载等模块的性能测试工作。本文主要描述了上述模块的性能参考指标及测试方法，以便于性能测试实施人员与客户对系统从技术层面指导测试人员验证相关功能模块的负载能力，根据实际的性能监控数据考察系统最大的负载及相关指标情况，以便于客户对系统实施相关的调优工作，使其达到预期期望的压力和性能要求。

2、测试目标

本次性能测试工作验证系统：首页、注册、登录、信息检索、普通用户资料上传、在线观看视频等模块的性能需满足下表指标（场景指标）：

表 1性能指标列表

并发数=业务量/（时间段(小时单位)3600秒/每人每笔业务的处理时间）

3、测试设计

3.1对象分析

系统采用B/S（Browser/Server）模式设计。基于LAMP开发平台开发。

操作系统： Red Hat Enterprise Linux 4

Web服务器：apache 2.0

数据库服务器：mysql 5.0

开发语言：PHP

3.2测试策略

使用HP商用性能测试工具LoadRunner 9.1，模拟用户并发操作。测试系统首页、注册、登录、站内交流、站内搜索、测试技术资料上传与下载等模块在多用户并发操作下是否能够稳定正常运行。支持的最大并发数，各项指标是否能够达到预期的指标标准，并为后期系统调优提供指标数据支持。

3.3测试模型

3.3.1系统组网图（需客户提供）

图1系统组网图

3.3.2网络拓扑结构（需客户提供）

web服务器

应用服务器

邮件服务器

上传下载服务器

图2网络拓扑图

3.3.3系统业务流程（需客户提供）

一般用户通过浏览器发出业务请求，到Web服务器（Apache），Web服务器通过代码分析请求类别，如涉及数据库操作，则转发请求给应用服务器，最终获取数据，经过Web 服务器组合，反馈至客户端，完成用户的业务请求。

3.4测试环境描述

3.4.1测试环境需求

考虑到用户上传下载的任务耗用资源比较多，因此资料的上传下载服务器单设一台服务器。而WEB服务器、邮件服务器及应用服务器可以整合在一台服务器主机上完成。为了与真实的用户情境相结合，客户端采用5台负载生成器，另加一台控制器。

1、系统环境标准配置（客户提供）：

客户根据当前的系统配置情况提供测试服务器。

表 2系统硬件配置表

2、测试客户端配置：

表 3测试客户端配置表

3.4.2测试工具要求

HP公司LoadRunner 9.1英文版。

3.5详细测试方法

本部分主要描述测试方法，并发用户计算及测试启动等方面内容。

3.5.1测试方法综述

LoadRunner是HP公司的专业性能测试工具。它通过创建多个虚拟用户的方式，对录制的单用户脚本增加负载，来达到增加系统压力的测试目的。LoadRunner提供了Analysis 工具对压力运行的结果进行分析，得出测试脚本运行期间，系统响应事务的最小时间，平均时间和最大时间等性能信息，同时可监视各后台服务器的CPU占用率与内存使用情况。

本次性能测试工作利用该工具录制系统首页、注册、登录、站内交流、站内搜索、测试技术资料上传与下载等业务模块的功能使用脚本，对于无法录制的脚本需手动编写测试脚本进行模拟。通过综合场景的设计实现多用户多并发访问使用的业务模拟，最终根据测试结果分析找出系统可能存在的性能瓶颈。

3.5.2业务模型分析

本次测试共涉及系统首页、注册、登录、站内交流、站内搜索、测试技术资料上传与下载业务模块，下面具体分解这些业务模块。

系统首页访问

首页访问功能作为一般用户的入口，性能问题尤为重要，通常情况下用户的浏览方式为打开浏览器，输入首页地址，回车或跳转即可。业务模式较为简单。此处需注意的是系统是否有同IP不能登录多个用户的问题（IP限制问题）。

●业务模型

1、打开浏览器；

2、输入URL地址；

3、回车跳转并正确显示首页。

●并发用户计算

首页访问业务量期望在0:00-24:00这一时间段内达到300万的访问量。根据这样的业务量，首先统计出单用户单次访问首页时服务器的响应时间（可包括用户的思考时间，但统计性能结果时需排除），然后再进行计算。

考虑到场景的运行时间如果是24个小时（8:00-22:00）的话，可能时间段过长，增加测试难度，这里采用二八原则进行业务量与业务时间段的重新规划，即为80%的业务量在20%的时间内完成。那么300万首页访问量的80%即为240万，而24个小时的20%即为4.8小时。故本次测试，如果性能满足4.8小时内完成240万的业务访问量，为测试通过。

利用LoadRunner录制访问首页的脚本，在Controller中不设置持续时间运行一次，然后在Analysis中统计出单用户单次访问首页所需要的时间。假设此时得到的响应时间为t秒/次，则根据预期计算得出业务高峰大概出现在T小时内。那么单用户在T个小时内可访问首页的次数C=T*60分钟*60秒/t（秒/次），那么T个小时内PV_Count（页面访问量）大概需要Total_Vuser=PV_Count/C个Vuser来完成。此处的Total_Vuser即为测试时所用的并发数。

示例：

假设单用户单次访问首页，服务器的响应时间t=3秒/次，那么T（4.8小时）内单用户可访问4.8小时*60分钟*60秒/3（秒/次）=5760次，则初步估计的并发数Total_Vuser 为240万/5760次/人=416.67人，即大约为417个Vuser。而在实际使用中并发数不得超过200，则实际的并发数及运行时间如下：

417*4.8/200=10小时

即认为200的并发量持续10小时，

场景启动方式

通过上面的初步估算得出场景运行时的并发数，然后设计场景的启动方式，通常情况下，为了真实的模拟用户业务情况，有效的衡量服务器性能，大多数会采用逐步加压，持续施压，逐步减压的方式启动场景，我们这里同样使用这样的方式。场景启动方式如下：每10分钟增加4个Vuser，持续运行10个小时，10小时运行完成后，每10分钟退出4个Vuser。