性能测试分析报告
1.测试背景
2.测试目的
本次测试的目的是：
进行应用服务器的压力测试，找出应用服务器能够支持的最大客户端数。
3.测试概要描述
3.1被测系统描述
3.2测试时间
20##-10-29
3.3测试地点
深圳安亿通科技发展有限公司
3.4测试人员
胡柏明
3.5测试工具和环境
测试工具：loadrunner 8.1
测试环境：
操作系统：Microsoft Windows XP professional SP3
处理器：Intel（R） Pentium（R） 4 CPU 1.70GHZ
3.6测试方案简介
场景描述一：
设置系统登陆并发用户10个，同时加载所有用户，开始场景，事务响应时间在5S内
场景描述二：
增强脚本，添加事务和集合点，设置系统登陆并发用户20个，同时加载所有用户，开始场景，事务响应时间在15s内
场景描述三：
增强脚本，添加事务和集合点，设置系统登陆用户50个，每1S加载一个用户，开始场景，事务响应时间在15s内
场景描述四：
1用户登陆“重大危险源GIS应急救援辅助支持系统”模块，总共25个用户，同时加载所有用户，实现用户并发操作
2.用户点击“救援基础资料”-“救援物资存放地点”
3.用户点击“新增”按钮，新增的记录显示记录列表
5.点击“返回主页”，返回到“重大危险源GIS应急救援辅助支持系统”模块
6.增强录制脚本，对“仓库编码”进行参数化，取随机数值
4.测试结果和结论
4.1测试结论
1）同时加载所有用户，全部通过，平均事务响应时间在15s
2）同时加载所有用户，全部通过，平均事务响应时间在22S。随着登陆完成，用户数逐渐减少。用户数减少到17时，平均事务响应时间有了明显的变化；在用户数减少到5时，事务响应时间达到最大值。
3）每1S加载一个用户，50个用户，全部通过。平均响应时间在46S。登陆完成后，开始释放用户，用户数为45时，平均事务响应时间有了明显的增长。用户数为2时，平均事务响应时间达到最大值。
4）事务全部通过，平均事务响应时间在19S左右。完成操作后，开始释放用户，用户数为19时，平均事务响应时间有明显增长。用户数为1时，平均事务响应时间达到最大值
4.2测试结论的限制
4.3对系统的建议
5.原始数据和报告
5.1测试执行记录
5.2原始数据和报告
1.
2.
3.
4. 
5.3测试工具生成的报告
场景1（10个用户并发操作）
场景2：
场景3
场景4：
第二篇：性能测试分析报告模板
目录
1. 引言... 1
1.1. 编写目的... 1
1.2. 项目背景... 1
1.3. 定义... 1
2. 测试背景... 1
2.1. 测试重点关注指标... 2
3. 测试执行策略... 2
3.1. 测试方法... 2
3.2. 测试脚本开发原则... 2
3.3. 统一的测试设置原则：... 2
3.4. 50个用户响应时间曲线图及点击率... 3
4. 测试结论... 3
1. 引言
1.1. 编写目的
本文档通过对性能测试的描述，记录性能测试的结果并对该结果进行分析。供项目组开发成员和测试成员阅读。
1.2. 项目背景
测试Xx项目所能承受的压力。
测试时间：
测试地点：
1.3. 定义
响应时间：客户端从发送请求的那一刻起到收到应用程序响应的最后一个字节时止而不
得不等待的时间长短；
通过率: 在测试过程中，服务器处理的请求数与总的请求数之比；在测试中通过率不低
于98％视为系统运行正常；
思考时间: 用户在操作过程中的延时；在测试时分两种情况，取消think时间和不取消
think时间；当取消了think时间，测试过程更接近于并发访问；不取消thin
k时间，测试过程更接近于真实的环境。
Total Throughput(bytes):在整个测试过程中，从服务器返回给客户端的所有字节数量
Total Hits : 按照客户端向后台发起了多少次用户计算,而不是按照用户的鼠标点击次数计算。如：在访问一次页面中，假设该页面包含5个图片，那么，用户只要点鼠标一次就可以访问该页面，而loadrunner视该访问的点击量为1+5=6次
2. 测试背景
此次测试应用服务器为192.0.0.6的服务器上进行测试，数据库服务在192.0.0.7，访问通过192.0.0.15进行appache页面访问。
2.1. 测试重点关注指标
l 测试系统的体系架构能否经得住大负荷的业务压力。
l 测试各业务模块中存在的系统瓶颈
重点考察了如下指标：
l 本地系统的响应能力：即在各种负载压力情况下，本地系统的响应时间，也就是从客户端交易发起，到服务器端的交易应答返回客户端所需要的全部时间，包括网络传输时间和服务器处理时间。
l 应用系统的吞吐率：即应用系统在单位时间内完成的交易量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的交易数量。
l 应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。
3. 测试执行策略
3.1. 测试方法
本次测试以性能测试为主，不涉及功能测试。
本次性能测试的主要方法是：使用性能测试软件工具LoadRunner，对被测系统进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调用各测试压力机器，发起各种组合的交易请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。
3.2. 测试脚本开发原则
针对绩效系统的特点，选取用户使用频率最高、数据量大、使用人员最广泛、最具代表性的功能点进行性能测试
在开发测试脚本的过程中，我们遵循如下原则：
l 所有的测试脚本均增加检查点，确保交易的成功率指标的可靠性。
l 把“登录系统”操作放在vuser_init中，把“退出系统”操作放在vuser_end部分，保证脚本只登录和退出系统一次，其余操作就是反复执行真正的业务操作。
l 所有的测试脚本进行严格的关联增强，保证脚本执行时候的可靠性。防止脚本报告执行正确，而数据没有加入到数据库中的现象出现。
3.3. 统一的测试设置原则：
l 每15秒钟增加10个用户，达到最大并发用户数后持续时间晚上执行一晚上，白天以小时为单位，然后按照每15秒钟减少10个用户的方式减压，直至测试结束。
l 所有Vu以线程的方式运行。
l 所有测试脚本执行的时候忽略思索时间think time，关闭Log。
l 对浏览器的模拟：每次循环以一个新的用户登录系统，并且清空Cache内容，每次浏览器对Web服务器静态页面的访问都要真正下载该页面，而不是从cache中获取。这样的设置保证了最严格的测试。也会使真实用户进行访问时所获得的性能体验要好于本测试报告中所报告的性能结果。
3.4. 50个用户响应时间曲线图及点击率
通过本次程序修改后加压，点击率在260对于55的cpu目前空闲在45%左右，与上一次提高了45%,此次调整对应用性能提高比较大,登记响应时间为1.8秒，查询的平均响应为2.7秒。