密级：普通

XXX系统

性能测试报告

目录

目录.... 2

版本记录.... 3

文档信息.... 3

修订历史记录：.... 3

1项目简介.... 4

1.1编写目的... 4

1.2术语解释... 4

1.3使用人员... 4

1.4解释权限... 4

2项目背景.... 5

2.1 项目背景... 5

2.3测试场景... 5

3测试环境.... 5

3.1网络环境... 6

3.2服务器环境... 6

3.3客户端环境... 6

4网站场景运行情况.... 7

4.1（功能点1）... 7

5测试结果及分析.... 8

5.1能力... 8

5.2限制... 8

5.3改进建议... 9

版本记录

文档信息

修订历史记录：

1项目简介

1.1编写目的

本测试报告反映了XXX系统性能测试情况。主要包含每个版本经开发部发布后测试组的测试结果：主要测试系统模块以及各模块的性能测试结果。本报告对XXX系统压力测试的过程进行描述、总结，并对测试结果进行分析，对现操作系统性能做出评价和优化。通过压力测试，确认XXX系统在并发用户、系统吞吐量、系统响应时间等综合的性能指标。

1.2术语解释

1.3使用人员

本报告对XXX系统压力测试的过程进行描述、总结，对测试结果进行分析，对现操作系统性能做出评价。因此适用人员可以为跟该系统有关的技术人员，包括开发人员、测试人员以及该项目的管理人员。

1.4解释权限

本文档由    XXXX公司编写，由XXXX解释。

2项目背景

2.1 项目背景

项目名称：XXX项目

简    称：XXX

项目代号：无

开发单位：XXXX公司

主管部门：PMO

2.3测试场景

使用LoadRunner Controller 构建压力测试场景。

1.   将用VU Generator调试好的脚本添加到测试场景中；

2.   根据测试用例，将文件名参数化；（将脚本中的文件名，选择为从列表中选择，将内容为文件名的txt文件导入，按编号进行unique.）

3.   设置压力加载方案，按方案计划，同时加载所有的Vuser，运行前初始化所有的Vuser，直到运行完成；

4.   设置运行时设置：运行时设置-Internet-首选项-选项-步骤下载超时改为最大值，HTTP请求连接超时改为最大值，运行时设置-思考时间-忽略思考时间。

5.   选择脚本；

6.   设置要获取windows 资源图；

7.   在测试环境下调试压力场景，用少量虚拟用户数测试，将收集测试结果发给开发人员，分析当前设置下的压力场景是否能满足要求；

8.   如果测试结果符合开发人员要求，压力场景构建工作结束；如果测试结果开发人员认为不满足要求，则需要做相关修改，并重做步骤1到步骤7。

3测试环境

本测试报告主要对XXX系统的测试做报告。XXX系统的测试主要包括：系统功能点的测试、系统性能的测试、系统功能的关联性测试、系统用户图形界面测试以及文档测试等内容。

以上一系列的测试旨在保证AMS档案管理系统在数字化环境下正确、完整、便捷地实现档案业务，满足业务需求和系统需求。

本测试报告主要对各个里程碑版本的测试情况进行统计和汇总。针对系统需求的覆盖率和测试用例的执行率对测试结果进行评价，并描述本次测试所存在的缺陷以及残留问题。

3.1网络环境

3.2服务器环境

3.2.1服务器硬件

3.2.2服务器软件

3.3客户端环境

3.3.1客户端硬件

3.3.2客户端软件（性能测试用）

4网站场景运行情况

4.1（功能点1）

系统截图

场景设置：(根据需要确定并发数及需要的分析图表)

300个用户并发

具体数据：以下数据均过滤掉了thinktime。

图表4-1 300用户运行的整个场景

图表4-2 300用户并发场景

图表4?3 80用户事务响应时间

图表4?4 80用户事务数据吞吐量

图表4-5 80用户客户端CPU及内存占用

5测试结果及分析

5.1能力

网站部分对于xx,xx功能点的要求，分别进行了用户的并发操作，其中由于网络连接与网段影响等因素，可能对测试结果带来偏差。

测试过程中，系统大约可支持200个用户数的并发，且不存在报错，并以此可估算出可支持的最大在线用户数，具体并发量估算过程如下：

　常用的确定并发用户数的公式是：C = nL/T =活动用户数×操作时间/系统运行时间，按照这个公式反推过来，活动用户数=系统运行时间×并发用户数/操作时间，各个功能点若当前最大并发用户数为200，完成一次操作的平均时间为5s，场景运行时间为20分钟，那么系统活动用户数可估算为：20×200/5=800，即目前系统理论可支持大约800个活动用户。

5.2限制

u  网站利用端部分功能限制（BS部分）（根据实际情况）

1.   功能点1：进行测试时，系统在测试初期响应速度过慢，导致初始用户报错，在运行一段时间后，系统将可以正常运行，网站端可以正常进行访问，通过多次测试发现，网站利用端在进行压力测试时最多可支持200用户进行操作，当使用300个并发用户进行登录测试时，系统在正常运行用户数超过200时则会出现报错。

2.   功能点2:300用户进行并发功能点2，web服务器监视资源值波动过大，存在相应稳定隐患，同时通过数据吞吐量测试截图可以发现系统在与web服务器进行交互时需要较高的网络环境进行支持，否则就会出现数据吞吐量在一定时间内波动超过可接受范围的值的现象出现。

综上所述，以上小结及此次压力测试结果仅作为客观依据，可根据档案生产系统今后实际使用情况进行参考。

5.3改进建议

在整个场景测试过程中，常出现的报错情况包括：（根据实际情况）

1.   数据连接超时

2.   服务器连接过早关闭

3.   Web服务器返回500错误

上述错误都是在进行大量用户并发操作时产生，xx功能的响应时间过长，且对大数据量的查询较慢，占用系统资源较多，建议设置合理的索引，对部分SQL语句进行优化；最后，在大用户量进行并发操作使web服务器响应时间过长时，可以考虑实施“队列”策略对用户登录以及其他操作进行优化。

根据档案生产系统今后的使用和用户量增长情况，建议应用服务器尽量使用稳定可靠的中间件产品（Weblogic或Websphere）以及可靠稳定的硬件产品和网络服务。

 

第二篇：性能测试报告模板案例

性能测试报告模板案例

某项目性能测试报告

1 测试环境

1.1 硬件环境

机器 cpu 内存 磁盘 网卡 操作系统

数据库服务器

（虚拟机）

intel pentium d

cpu 3.2ghz

512mb 15g 10.0mbps win2003enterpriseserver

客户端（测试

机）

intel celeron

cpu 1.6ghz

1gb 160g 100.0mbps win2003enterpriseserver

1.2 软件环境

类型 名称

操作系统 windows 2003 enterprise server

数据库软件 microsoft sql server 2000 enterprise edition sp4 应用软件 xxx信息管理系统

压力测试软件 loadrunner 9.0

其它工具 秒表

2 秒表结果

序号 功能名称 事件 第一次 第二次 第三次 平均值

1 用户登录

登录 3.09 2.92 2.64 2.88

加载模块 2.27 2.03 2.00 2.10

2 a功能

打开 7.18 6.89 6.77 6.95

保存 3.60 3.80 2.90 3.43

完成 2.01 3.80 2.98 2.93

3 b功能

接收归档 1.87 1.13 1.54 1.51

归档查看 0.58 0.94 0.89 0.80

4 c功能

申请 0.86 0.82 0.96 0.88

审批 0.65 0.77 0.75 0.72

授权 0.78 0.83 0.73 0.78

查看 7.77 7.62 7.51 7.63

5 d功能

打开 5.38 4.94 4.74 5.02

发送通知 0.89 0.96 0.87 0.91

6 e功能 打开 2.09 1.89 2.00 1.99

接收整改 0.47 0.50 0.52 0.50

拒绝整改 0.62 0.50 0.49 0.54

7

保存 0.58 0.63 0.64 0.62

8 f功能

打开 0.51 0.47 0.55 0.51

保存 0.70 0.63 0.67 0.67

删除 0.58 0.60 0.63 0.60

3 测试方法

3.1 测试关键业务选择

我们通过秒表结果和验收时验收人员的反馈重点在a功能打开，c功能查看，d功能打

开等业务从时间的角度中看比较慢，那么我们选择这三个业务从不同测试方法来进行说明。

3.2 测试方法介绍

第一种方法：

在所选的三个关键业务开始和结束的代码中增加计时器，得出操作该业务的准确的消耗 时间。

第二种方法：

选择a 功能打开业务，使用loadruner9.0工具分别模拟5 用户、10 用户、15 用户、 20 用户并发时数据库方的性能情况，包括该业务操作时纯粹的数据库执行时间，以及实时 了的数据库服务器资源消耗情况。

4 测试结果

4.1 第一种方法结果

业务名称 第一次 第二次 第三次

a功能打开 6.08 6.12 6.01

c功能查看 6.66 6.71 6.44

d功能打开 4.56 4.32 4.32

4.2 第二种方法结果

业务名称 并发数（个） avg（(秒) min (秒) max(秒)

a功能打开 5并发 1.312 0.969 1.711

10并发 1.713 0.969 2.328

15并发 2.165 0.936 3.219

20并发 2.732 0.995 4.391

1. 5并发数据库服务器资源消耗情况

性能指标 建议值 当前值（avg） 说明

cpu（处理器） <75% 27.655 %processor time cpu 使用

memory（内存） 00-20 22.835 page faults/sec

i/o(磁盘) 无 0.108 %disk time

2. 10并发据库服务器资源消耗情况

性能指标 建议值 当前值（avg） 说明

cpu（处理器） <75% 31.000 %processor time cpu 使用

memory（内存） 00-20 / page faults/sec

i/o(磁盘) 无 0.027 %disk time

3. 15并发据库服务器资源消耗情况

性能指标 建议值 当前值（avg） 说明

cpu（处理器） <75% 31.025 %processor time cpu 使用

memory（内存） 00-20 23.581 page faults/sec

i/o(磁盘) 无 0.053 %disk time

4. 20并发据库服务器资源消耗情况

性能指标 建议值 当前值（avg） 说明

cpu（处理器） <75% 32.876 %processor time cpu 使用

memory（内存） 00-20 23.940 page faults/sec

i/o(磁盘) 无 0.078 %disk time

5 测试分析

根据测试结果可以看出a 功能打开，c 功能查看，d 功能打开在个业务通过秒表记录

的时间、代码计时器、loadruner并发模拟执行时间要相差大。因为秒表记录是手工记录肯 定有较大误差。pb 代码计时器比较准确但是它包含了与数据库交互以及打开控件（编辑器） 等时间。 loadruner 并发模拟是记录与数据库交互的时间。

通过4.2 可以看出在当前环境下（数据库服务器一台虚拟机，只有512mb 内存），在

20 用户并发时，a功能打开执行时间avg在3 秒以内，而数据库服务器资源使用情况非常 稳定。

6 测试结论

根据测试结果和测试分析，我们可以初步认定a 功能打开，c 功能查看，d 功能打开 三个业务性能瓶颈不在数据库，而是在调用控件（编辑器）时花费的时间较长。

建议开发人员优化调用控件（编辑器）的代码，工程实施时客户端的配置要较高，内存 至少1g以上。