B2C业务后台测试报告
1、测试内容：
本次压力测试是仿B2C业务后台的实际应用的软硬件环境及用户使用过程的系统负荷，长时间运行测试软件来测试被测服务器的可靠性，同时记录LoadRunner执行脚本的相关内容，分析出系统各个瓶颈。
1.1测试项：
1.1.1 登录（计划模拟20、50、100、200并发）
1.1.2 登录后在预订中心的订单管理里面查询今天的订单（计划模拟20、50、100、200并发）
1.1.3 登录后在预订中心的预订机票里面查询航班信息（计划模拟20、50、100、200并发）
1.1.4 登录后在出票中心的报表里面查询最近一个月的报表（计划模拟20、50、100、200并发）
1.1.5 登录后在酒店管理的酒店订单查询里面查询最近一个月的酒店订单（计划模拟20、50、100、200并发）
1.2测试工具：
LoadRunner8.1，IE8浏览器
1.3测试系统要求：
内存最好在512M 以上，安装LoadRunner的磁盘空间至少剩余500M。
操作系统最好是Windows 2000。
1.4测试环境：
计算机品牌：联想 笔记本
操作系统：微软 Windows XP 专业版 Build 2600 (Service Pack 3)CPU：双核
内存：2 GBytes
磁盘：WDC WD3200BEVT-22ZCT0
本机空载时Memory和CPU情况：
1.5使用LoadRunner进行压力测试的步骤：
1.5.1录制脚本：
打开登录界面：http://172.16.2.87:8081/bko/；输入用户名：test，密码：【保密】，分机号：【为空】；点击“进入”按钮进行相关操作，等页面录制完毕才能关闭浏览器，再停止录制，然后回放脚本检查，最后确定回放的脚本要正确。
1.5.2执行脚本：
打开相关的脚本，设置好脚本运行的参数，执行脚本并且记录响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系。
1.5.3对脚本录制过程中进行分析：
系统能够承受多大的压力，虚拟用户几个同时进行操作作为标准，记录有用数据并且进行分析。
2、测试结果【只做了登录的压力测试，下面其他的需要把问题解决后才能进行测试】：
2.1 登录（计划模拟20、50、100、200并发）【每秒加载4，达到并发数持续5-10分钟，每秒停止4个】
2.1.1 LoadRunner记录的相关参数如下：
Vusers数：400
最大并发用户数：400
Total Trans/Sec(Passed)业务操作响应时间是：
His per Second每秒点击数：
Throughput吞吐量：
Pages Downloaded per Second下载组件大小：
Trans Response Time
Running Vusers
HTTP Responses per Second
Connections Per Second
Vusers with Errors
问题1：
2.1.2服务器相关参数如下：
Memory【内存】、CPU：
在达到400并发持续运行6、7分钟CPU就占满了，如下图所示：
这证明在登录并发量至高达到400个并发。
Tomcat问题：
在连接过程中有些用户未能连接，如下图：
这证明数据库需要优化。
2.2登录后在预订中心的订单管理里面查询今天的订单（计划模拟20、50、100、200并发）【每秒加载4，达到并发数持续5-10分钟，每秒停止4个】
LoadRunner记录的相关参数如下：
Vusers数：
最大并发用户数：
Total Trans/Sec(Passed)业务操作响应时间是：
His per Second每秒点击数：
Throughput吞吐量：
Pages Downloaded per Second下载组件大小：
服务器相关参数如下：
Memory【内存】：
CPU：
2.3 登录后在预订中心的预订机票里面查询航班信息（计划模拟20、50、100、200并发）【每秒加载4，达到并发数持续5-10分钟，每秒停止4个】
LoadRunner记录的相关参数如下：
Vusers数：
最大并发用户数：
Total Trans/Sec(Passed)业务操作响应时间是：
His per Second每秒点击数：
Throughput吞吐量：
Pages Downloaded per Second下载组件大小：
服务器相关参数如下：
Memory【内存】：
CPU：
2.4 登录后在出票中心的报表里面查询最近一个月的报表（计划模拟20、50、100、200并发）【每秒加载4，达到并发数持续5-10分钟，每秒停止4个】
LoadRunner记录的相关参数如下：
Vusers数：
最大并发用户数：
Total Trans/Sec(Passed)业务操作响应时间是：
His per Second每秒点击数：
Throughput吞吐量：
Pages Downloaded per Second下载组件大小：
服务器相关参数如下：
Memory【内存】：
CPU：
2.5 登录后在酒店管理的酒店订单查询里面查询最近一个月的酒店订单（计划模拟20、50、100、200并发）【每秒加载4，达到并发数持续5-10分钟，每秒停止4个】 LoadRunner记录的相关参数如下：
Vusers数：
最大并发用户数：
Total Trans/Sec(Passed)业务操作响应时间是：
His per Second每秒点击数：
Throughput吞吐量：
Pages Downloaded per Second下载组件大小：
服务器相关参数如下：
Memory【内存】：
CPU：
3、具体结果以及如何得到：
3.1分析原则：
1.具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
2.查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈
? 网络瓶颈（对局域网，可以不考虑）
? 服务器操作系统瓶颈（参数配置）
? 中间件瓶颈（参数配置，数据库，web服务器等）
? 应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
3.2分析的信息来源：
1 根据场景运行过程中的错误提示信息
2 根据测试结果收集到的监控指标数据
3.2.1错误提示分析：
分析实例：
3.2.1.1实例1
Error: Failed to connect to server “172.16.2.87″: [10060] Connection
Error: timed out Error: Server “172.16.2.87″ has shut down the connection prematurely 分析：
A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题）
B、应用服务没有死（应用服务参数设置问题）
对应的Apache和tomcat的最大链接数需要修改，如果连接时收到connection refused消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况和服务器硬件的情况来定，建议每次增加25%！
C、数据库的连接，数据库启动的最大连接数（跟硬件的内存有关）。
D、我们的应用程序spring控制的最大链接数太低
3.2.1.2实例2
Error: Page download timeout (120 seconds) has expired
分析：
A、应用服务参数设置太大导致服务器的瓶颈
B、页面中图片太多
C、在程序处理表的时候检查字段太大多
D、实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境
3.2.1.3实例3
Error “http://172.16.2.87:8081/bko/... ...”
分析：
A、脚本设计错误，造成页面异常。服务器有响应！
B、并发数过大，造成服务器响应延迟。
3.2.1.4实例4
Error page “text=xxxxx”
分析：
A、脚本设计问题，例如，前一脚本修改了某些内容，造成后面的脚本访问异常。
B、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。只能反复修改脚本！
3.2.2监控指标数据分析
3.2.2.1 Vusers数
Loadrunner 系统设置的虚拟用户数目。Vuser去实际调用事先制作的脚本文件中的应用。 每个Vuser产生响应的操作，所有的操作对服务器形成并发。
颜色 比例 度量 图最小值 图平均值 图最大值 图中间值 图SD
1 Run 0.0 21.25 44 41 21.276
在实际测试中，Vusers可以根据实际情况的需要，在测试过程中增加或者减少。
3.2.2.2最大并发用户数：
颜色 比例 度量 最小值 平均值 最大值 SD
100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043
0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924
0.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201
应用系统在当前环境下能承受的最大并发用户数。
在方案运行中，如果出现了大批用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
从上图可以看出：在测试运行到4个小时左右的时候，apache的点击数/秒开始迅速增加！
3.2.2.3业务操作响应时间：
使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
颜色 比例 度量
1 最小值
1 平均值
1 最大值
分析事务的响应情况，要每次详细分析，目前还只能观察到响应时间过长的事务！
3.2.2.4每秒点击数
负载测试期间每秒内 Vuser 在 Web 服务器上点击的次数。可根据点击次数来估算 Vuser 生成的负载数。
颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD
1 点击次数 69.908 105.736 130.244 103.666 12.186
从图中不难看出，在4小时的时候，点技数明显增高。和apache的每秒点击数增大的时间相吻合！
3.2.2.5吞吐量
负载测试期间 Web 服务器上的吞吐量(字节)。吞吐量表示在任何指定秒内 Vuser 从服务器接收到的数据量。此图可估计 Vuser 生成的负载量(服务器吞吐量)。
颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD
1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473
同样，从图中可以看出，在4个小时的时候，web服务器的吞吐量开始增高。在图中还可以看到吞吐量的走势图，从开始到进行到4个小时反弹之前呈降低的趋势，这是因为系统在初期调用的资源都是直接来之服务器，运行一段时间后系统的部分资源来自缓存。
3.2.2.6下载组件大小
每个页面的组件大小，且包括组件的标头的大小！
页面组件大小的分析表格比较复杂，实际分析中可以通过loadrunner的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件，如果其影响到了页面的下载速度，则要想办法将其改小！
3.2.2.7 Apache资源
显示APACHE web服务器上的资源摘要。前面已经提到过以并发点击数为主。
颜色 比例 度量 最小值 平均值 最大值 SD
100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043
0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924
0.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201
3.2.3服务器资源监控指标（目前通过top监察）：
3.2.3.1内存：
Windows server 2003资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
实际测试中，当并发点击数出现突然剧增前后，内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈！
内存资源成为系统性能的瓶颈的征兆：
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(out of memory errors)
3.2.3.2处理器：
Windows server 2003资源监控中指标CPU占用率持续超过80%（对该值的要求，根据具体应用和机器配置而要求不同，有资料表明95％），表明瓶颈是CPU。
实际测试中，当并发点技数出现突然增加前后，cpu的占用率持续保持在86％以上！ 说明，目前系统用应用的cpu也是测试的瓶颈！
CPU资源成为系统性能的瓶颈的征兆：
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU)
过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time)
3.2.4数据库服务器：
数据库服务器目前测试观察，当web服务器点击率增大时，观察mysql数据库的最大连接数，仍未超过系统设置的最大连接数。所以，暂时未发现数据库的瓶颈！
3.2.5分析的结论：
以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显，比较利于观察的作为分析案例。
根据以上分析结果综合分析，当前测试环境下，当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析，用户在4个小时的时候，并发数迅速增加前后的值在400左右！分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距！
测试时间：2010-5-10
测试工程师：梁英杰
第二篇：系统-压力测试报告
修订记录
目 录
1 测试对象概述... 2
2 测试目的说明... 2
3 测试环境组网... 2
4 性能测试方案... 2
5 性能测试总体结果... 2
6 性能测试过程分析... 2
1.1 场景一：Web页面300个用户并发登录操作... 2
1.2 场景二：Web页面500个用户并发登录操作... 2
1.3 场景三：Web页面700个用户并发登录操作... 2
1.4 场景四：Web页面1000个用户并发登录操作... 2
7 改善建议: 2
8 数据记录... 2
性能测试报告
1 测试对象概述
为满足系统,现场多用户并发登陆,以及多用户并发,
能稳定正常运行,而做的压力测试,根据测试结果数据反应系统的支撑能力。
2 测试目的说明
2.1 性能需求：
本系统在 目录3 测试环境软硬件配置及网络下,支持如下参数：
并发登陆:1) 300用户并发登录 2）500用户并发登录 3）700用户并发登录
3 测试环境组网
3.1 系统软硬件配置
本次测试环境单机模式，和真实环境稍有区别；
3.2 系统组网图
测试的网络环境为100Mbps局域网，请求以及结果返回的网络传输时间可忽略不计;
4 性能测试方案
1.脚本开发方案: .
2.场景设置方案: .
3.指标监控方案: .
5 性能测试总体结果
1.1 300用户并发登陆测试通过。系统稳定处理请求,服务器稳定,CPU,内存利用率低,;
1.2 500用户并发登陆测试通过。系统稳定处理请求,服务器稳定,CPU,内存利用率低,;
1.3 700用户并发登陆测试失败。系统请求点击率下降,响应时间较慢,CPU不够稳定;
1.4
6 性能测试过程分析
1.1 场景一：Web页面300个用户并发登录操作
系统环境：
1， 存在注册用户4842个, 300个用户测试任务，并发提交登录
2， 自动执行完毕后，停止下发测试任务的用户操作。
测试结果：
上图中绿色和红色曲线表示进入首页和进入登录页测试任务的响应时间情况:
1.300个测试任务首页的事务响应时间，依曲线看完全稳定，响应时间在1S左右. (去31s)
2.300个测试任务登录的事务响应时间，依曲线看相对比较稳定，响应时间在21S左右。
上图中模拟300个用户并发登录，进入首页及进入登录页事务通过情况:
300个测试任务登录的事务总数2035,其中通过数2009,成功通过率98.7%
结论：满足需求。
1.2 场景二：Web页面500个用户并发登录操作
系统环境：
1， 存在注册用户4842个, 500个用户测试任务，并发提交登录
2， 自动执行完毕后，停止下发测试任务的用户操作。
测试结果：
上图中绿色和红色曲线表示进入首页和进入登录页测试任务的响应时间情况:
1.500个测试任务首页的事务响应时间，依曲线看完全稳定，响应时间在3S左右. (去31s)
2.500个测试任务登录的事务响应时间，依曲线看比较稳定，响应时间在37S左右,较久。
上图中模拟500个用户并发登录，进入首页及进入登录页事务通过情况:
500个测试任务登录的事务总数2665,其中通过数2618,成功通过率98.2%
结论：满足需求
1.3 场景三：Web页面700个用户并发登录操作
系统环境：
1， 存在注册用户4842个, 700个用户测试任务，并发提交登录
2， 自动执行完毕后，停止下发测试任务的用户操作。
测试结果：
上图中绿色和红色曲线表示进入首页和进入登录页测试任务的响应时间情况:
1.700个测试任务首页的事务响应时间，依曲线看完全稳定，响应时间在6S左右. (去31s)
2.700个测试任务登录的事务响应时间,依曲线看比较不稳定，响应时间86S左右,较久。
上图中模拟700个用户并发登录，进入首页及进入登录页事务通过情况:
700个测试任务登录的事务总数2454,其中通过数2305,成功通过率93.9%
结论：不满足需求。
1.4 场景四：Web页面1000个用户并发登录操作
系统环境：
3， 存在注册用户4842个, 1000个用户测试任务，并发提交登录
4， 自动执行完毕后，停止下发测试任务的用户操作。
测试结果：
上图中绿色和红色曲线表示进入首页和进入登录页测试任务的响应时间情况:
1.1000个测试任务首页的事务响应时间，依曲线看相对不稳定，响应时间在8S左右. (去31s)
2.1000个测试任务登录的事务响应时间,依曲线看完全不稳定，响应时间126S左右,较久。
上图中模拟1000个用户并发登录，进入首页及进入登录页事务通过情况:
1000个测试任务登录的事务总数2480,其中通过数568,成功通过率22.9%
结论：不满足需求。
7 改善建议:
本次在单机模式上进行的测试,如随着多用户同时访问同一操作而造成性能问题时,
建议进行部署集群,负载均衡,分布式等方案来尝试提高服务器的承受能力
8 数据记录
