XXX项目性能测试报告模板汇总

1、项目名称系统 性能测试分析报告 北京XXXX信息技术有限公司 2013年XX月XX日 性能测试分析报告 1 测试背景 目录 1 1.1测试目标 1 1.2测试时间 1 1.3测试地点 1 1.4测试人员 1 2 测试方法简介 1 3 测试环境 3 3.1被测系统 3 3.1.1硬件环境 3 3.1.2数据库环境 4 3.1.3软件环境 4 3.2测试系统 4 3.2.1测试环境搭建 4 3.2.2测试软件 4 4 测试设计 5 4.1模拟用户数 5 4.2测试模型建立 5 5 测试结果分析 6 5.1业务场景一 XXX测试分析. 6 5.1.1平均响应时间梯度对比 6 5.1.2系统资源利用率

2、 7 5.1.3系统处理能力 8 5.2业务场景XXX测试分析. 8 5.2.1平均响应时间对比. 8 5.2.2处理能力对比 9 5.2.3资源利用率对比图. 9 5.3系统稳定性测试 10 5.4有、无合同场景对比测试. 11 5.4.1响应时间分析 11 5.4.2处理能力对比图 12 5.4.3资源利用率对比图. 13 5.5业务场景二调优对比测试. 13 5.5.1第一次调优 14 5.5.2第二次调优 15 5.5.3第三次调优 16 6 测试结论 17 6.1业务场景一（无合同） 17 6.2业务场景二（有合同） 18 6.3稳定性 18 7 调优建议 18 公开 第1页 性能测

3、试分析报告 1测试背景 1.1测试目标 对XX公司XX系统进行性能测试，客观、公正评估系统的性能现状。 1、开发正确有效的性能测试脚本，模拟最终用户操作行为，作为测试有效实施的基础; 2、通过性能测试，客观、公正评估在当前测试环境下，被测系统的各项性能指标表现; 3、验证被测系统的业务处理能力是否能够满足在业务高峰期的性能要求，为被测系统 上线提供参考依据。如不满足，对性能瓶颈进行定位分析，提供性能调优建议。 1.2 测试时间 公开第22页 此处编写测试执行的开始时间至结束时间。 例如：测试自2013年XX月XX日启动，至XX月XX日测试执行结束。 1.3 测试地点 此处列明测试执行的所在办公

4、地点*大厦*座*楼层 1.4 测试人员 单位 姓名 备注 北京XXXX信息 * 技术有限公司 * 测试方法简介 压力测试采用业界成熟的自动化性能测试工具, 通过创建压力测试程序、构建压力测试 模型，对被测试系统实施自动化压力测试，最后形成压力测试结果分析报告。 1）压力测试实施模型: 进行性能测试。通过测试工 通过自动化测试工具模拟最终用户向服务器发起业务请求, 具对测试过程中系统各点进行监控，每一次测试结束后工具自动采集测试结果并生成原始报 告供分析使用。 2.模拟大量的真实用户生 成压力 被测系统 性能监控器 虚拟用户生成器 控制器1厂 5.产生性能分析报告 4.测试结果被搜集及 保存起来

5、供分析 3.监控器实时捕获系统的性能 状态 1.Controller起到调度压力测 试并管理监控器 Web 服务器 应用服务器数据库服务器！ Z /! ? 2）压力测试实施基本流程: 测试环境准备 系统性能压力测试环境要求与生产系统的软、 硬件环境保持一致，并具有相同规模的业 务数据，并保证软件版本与生产环境保持一致。 压力模型定义: 此次性能测试的用例选择，按照*公司提供的业务数据进行分析抽取，用例选取是性 能测试压力模型设计的首要任务。用例选取的原则是: 1) 典型的交易和业务流程 2) 用户操作使用频繁 3) 对系统性能影响较大 4) 性能测试压力符合业务系统实际的实际交易发生比例 ，循

6、环 实际执行场景的设置尽量模拟实际业务进行，运行时长，操作间隔（思考时间） 间隔，并发间隔，用户加载和减压时间根据系统基准测试结果进行判断和设置。 测试数据准备: 测试数据要求尽量模拟真实业务数据，而且具有一定可重用性。能贯穿各相关系统，保 证业务流程的顺畅正确。具体的数据类型和数据量需要根据选择的交易类别或性能测试场景 设置而定。 此外性能测试会产生大量的虚拟用户，需要消耗大量的测试数据。其数量直接关乎测试 结果。测试中所需的基本数据类型为: 系统用户数据：登陆系统使用的用户名-口令等，数量与虚拟用户数一致。 业务数据：每个虚拟用户模拟真实用户进行操作时使用到的数据。 辅助数据：为保证业务操

7、作的正常进行而设置的基本信息资料。 测试程序开发: 做为测试程序开发的依 利用在历史数据收集步骤中所获得的典型用户的系统访问模式, 据。该测试程序应该覆盖典型用户的系统访问模式所涉及的操作。脚本的开发是利用 LoadRunner Vugen进行脚本录制，开发，参数化，调试的过程。 测试执行: 测试准备阶段完毕后，确保测试环境、测试程序、测试过程、测试数据，且均已验证通 过后，然后在指定的时间内可对系统施实性能测试，性能测试执行分为两个阶段: 1、 性能基准测试：系统在轻负载环境下，模拟各业务的单用户交易，评估当前系统的 性能表现，并作为后续压力测试的性能比较基准; 2、 单交易负载测试: 3、

8、 负载压力测试：仿真现实，模拟大批量并发业务交易，评估系统在高负载情况下系 统的性能表现。 测试结果分析报告: 压力测试结果经过确认有效后，将汇总压力测试结果，形成最终的性能测试分析报告。 3测试环境 3.1被测系统 3.1.1硬件环境 系统 IP地址 所在主机配置 备注 CPU Win2003 Server 应用服务器 内存 硬盘 CPU Win2003 Server 数据库服务器 内存 硬盘 3.1.2数据库环境 使用生成的6800万条数据。此处编写数据库的整体环境也可以，没有数据库环境，则 写无。 3.1.3软件环境 类型 应用及版本号 备注 应用服务器 Weblogic8.1 数据库

9、Oracle 9i 3.2测试系统 3.2.1测试环境搭建 测试机配置: 类型 数量（台） IP 配置 备注 控制台 1 192.168.3.129 Intel E4600 2.4GHz Win2003 Server 内存2G/硬盘400G 7200转 负载发 9 192.168.3.130- Intel E4600 2.4GHz Win2003 Server 丄耳H 生器 192.168.3.138 内存1G/硬盘400G 7200转 3.2.2测试软件 采用Mercury In teractive公司的LoadRu nner测试及分析软件作为测试工具。 LoadRunner 简介: 在 L

10、oadRunner 的 LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。 帮助下，用户可以以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问 题。LoadRunner能够对整个企业架构进行测试，它通过模拟实际用户的操作行为和实行实 时性能监测，来帮助用户更快的查找和发现问题。此外, LoadRunner能支持广泛的协议和 技术，可以为用户的特殊环境提供特殊的解决方案。 本次测试采用的LoadRunner版本为11.0。 4测试设计 4.1模拟用户数 依据系统目前的业务量以及未来业务量增长，对当前系统分别按 3000、 4500、 6000 用 户进行压力测试，

11、以评估系统在不同压力梯度情况下的性能表现。 4.2测试模型建立 此次性能测试的业务选择，应覆盖各性能关键业务，并通过 *公司、北京*公司双 方协商选取被测业务。根据协商选定如下业务进行性能测试: 开具发票 此处编写性能测试的测试用例，包括了场景的描述以及其他用例细节 以此基础上定义测试执行压力模型: 在混合业务场景压力梯度测试过程中，分别按 3000、4500、6000用户进行压力测试, 在各个压力测试过程中保持测试场景和调度测试的完全一致，使结果具有很好的可比性。 压力测试执行场景描述如下: 1、模拟用户数: 3000、 4500、 6000 2、Pacing： 120 秒; 3、当所有用户

12、加载完毕后连续运行15分钟; 4、用户调度策略：每 1秒启动30个虚拟用户。 业务场景 序号 交易 业务 配比 执行 时间 操作 间隔 1 开具发票 100% 15分钟 120秒 业务场景二 序号 交易 业务 配比 执行 时间 操作 间隔 1 开具发票（无合同） 85% 15分钟 120秒 2 开具发票（有合同） 15% 说明: 按照以上场景设置，可估算出模拟用户数与每小时业务量的对应关系如下: 模拟用户数 3000 4500 6000 每小时业务量 90000 135000 180000 5测试结果分析 说明：术语解释 （事务）-LoadRunner中定义，为一个流程中某个环节的称谓，一个流

13、程可称为 一个大的事务，在这个大的交易中包含许多的小的事务。 响应时间一LoadRunner中衡量流程中各个事务性能的最佳手段，计算的是端到端 的时间，说的通俗一点，从点击应用中的某个控件， 到从数据库返回数据到客户端, 整个过程都被计算在事务的响应时间内。 场景LoadRunner中专门术语。它是所有测试资源包括测试脚本、运行设置、运 行用户数等的集合。在这个场景中，可以定义并发用户的数目， 定义要运行的脚本, 或者说运行的流程类型。 在一个场景中，可以是单个流程，也可以是多个流程的混 合。 虚拟用户一LoadRunner中特定术语，为模拟现实中的实际用户，测试软件使用虚 拟用户代替真实的用

14、户。 5.1业务场景一 XXX测试分析 此处用简明扼要的几个字或一句话概括执行用的用例场景， 也相当于是给测试用例取 一个比较形象的名字。 5.1.1平均响应时间梯度对比 F图是不同用户数下各事务的平均响应时间随用户数变化的曲线: 事务 3000用户 4500用户 6000用户 登录 0.56 1.312 2.14 开具发票 0.24 0.87 2.08 录入并开具 0.43 1.098 2.70 +登录 亠开具发票 录入并开具 平均响应时间分析: 从上图中可以看出，各操作的响应时间随着用户数的增加呈上升趋势，但都没有超过 秒，在可接受范围内。 5.1.2系统资源利用率 cpu利用率（% CP

15、U利用率（ CPU利用率分析: 在上图中我们可以看出 3000用户、4500用户及6000用户时，CPU利用率均在正常范围 内，系统表现良好。 5.1.3系统处理能力 系统处理能力分析: 口4500用 户 4500用 户 口 6000用户 口 6000用户 可以看出，在无基础数据的情况下，系统处理能力随用户数的增加呈线性上升趋势, 系统无性能瓶颈，6000用户时系统处理能力达到每小时173880笔，满足并超出客户提出的 4小时20万张发票的处理能力。 5.2业务场景XXX测试分析 序号 用户数 每小时业务量 基础数据量 1 6000 180000 无 2 6000 126000 大于1800万

16、 5.2.1平均响应时间对比 F图是不同压力情况下，有基础数据与无基础数据各操作响应时间对比图: 响应时间对比图 （无基础数据） （有基础数据） （无基础数据） （有基础数据） 平均响应时间分析: 同样压力的情况下，在无基础数据的情况下，响应时间均小于5秒。当基础数据量在 1800万的时候，6000用户压力下响应时间大幅度提高，超过客户所提出5秒之内的要求。 5.2.2处理能力对比 F图是相同压力情况下，有基础数据与无基础数据系统的处理能力对比。 TPS寸比图 hIPS 处理能力分析: 在有基础数据的情况下， 单从处理能力看，依然可以满足客户所提出的要求，但与之前 的无基础数据的处理能力比较发

17、现，基础数据的存在是对处理能力有较大影响。 5.2.3资源利用率对比图 F图是相同压力情况下，有基础数据与无基础数据各事务资源利用率对比图: CP利J用率对比图 口 CPI CPU利用率分析: CPU利用率也随 相同压力下，因有基础数据情况下响应时间变长，系统处理能力下降, 之下降，这说明系统瓶颈出现在了其他方面。 5.3系统稳疋性测试 如果系统做了稳定性测试，则此处对稳定性测试进行分析和描述，如果没有可以去掉 在系统测试过程中，我们发现WebLogic的JVM可用内存逐渐减少，下图是在WebLogic 监控台所监控到的情况： 吞吐童: 队列长度: 队列已经处理的请求数。 AJjj 血 队列中

18、的等待请求数0 991514624 111 JVM堆中当前可用的內存量（字节b 为了验证确认此现象，进行了4500用户6个小时的测试，当测试执行到1小时左右, WebLogic JVM基本已无内存可用，如下图所示： 吞吐負 队列已经处理的请求数。 队列怅度: 1073741024 队列中的等待请求数。 1 0600801 20 内有使用率: 处理能力明显 被占用内存无法释放， 导致被测系统在长时间运行后响应时间明显上升, 下降，如下图所示： KJ- 75- To es： KJ- 53 d 40- 亦 30： X 20- 应 1 AvGijg口 TiJi*治咅加*1客白 Iiiii4 皿钊011

19、*200:5100:59CH:Qe b）查询合同信息业务逻辑有问题，导致“选择合同”操作响应时间过长; 从数据库监控中看到，以下两个SQL的Disk Reads最大: SELECT * FROM HI BARGAIN WHERE SKZZH=:1 AND BG_STATE= 正常 SELECT IV_AMOUNT FROM HI_INVOICE WHERE BG_CODE=:1 AND （IV_STA TE=正常or IV_STATE=冲红）AND IV_STA TE_2=正常 经开发人员确认，这两个 SQL是查询合同信息使用的 SQL 2、系统参数 a） WebLogic线程数设置过小; b

20、) Oracle 的 shared pool、buffer cache设置过小。 我们对各原因分别进行优化后进行测试，最终进行了以下调整: 1、调整 shard pool 为 104MB 2、调整 buffer cache 为 504MB 3、调整查询合同信息业务逻辑 4、修改weblogic线程数为150 调优结果见以下分析。 5.5.1第一次调优 首先修改业务逻辑， 在进入开具发票页面时不加载合同信息。然后修改数据库参数， 修 改 shard pool 为 104M、修改 buffer cache 为 504M。 F图是4500用户调优前后响应时间对比图: 事务名称 平均响应时间（调优前）

21、 平均响应时间（调优后） 合同_登录 6.07 1.2 合同_开具发票 37.83 1.283 合同 录入并开具 6.38 1.378 合同 退出 3.85 0.232 合同 选择合同 34.96 0.483 开票 登录 6.27 1.215 开票 开具发票 4.45 0.568 开票_录入并开具 6.18 1.492 开票 退出 3.84 0.269 4500用户响应时间对比图 40 35 30 25 20 15 10 5 0 nTL.rL. 4500用户（调优前） 4500用户（调优后） 登录具发票并岸退出择合同登录具发票并开具退岀 口人同口人同开严开 合合同合开开票 在图中我们可以看出调

22、优前后，在相同压力的情况下，响应时间大幅度下降。调优效果 明显，已满足响应时间小于 5秒的业务要求。 此时系统处理能力也有明显的提升。 系统处理能力 tpS 4500用户（调优前） 4500用户（调优后） 5.5.2第二次调优 由于此时 WebLogic线程经常出现队列，因此将 WebLogic线程最大值由100调整为150。 调整后系统处理能力由36.004上升为37.394。但由于此时系统处理能力已接近场景设计最 大值，因此效果不明显，需要进行一次6000用户的对比测试。 开 口 4500用户 6000用 户 J选 开 票_录 合开 口 同-录 合合同_ 合合同 开票开票_ 系统处理能力

23、I 口 tpS 6000用户时，响应时间明显变长，部分操作已超过 5秒，而系统处理能力也有明显的 下降，因此系统仍然存在性能瓶颈。 5.5.3第三次调优 此时主要的优化方向为优化业务逻辑，因此测试人员提出建议， 将查询合同信息的两个 SQL合并为一个SQL,这样能够减少大量的查询次数，降低数据库压力。 开发人员将此业务逻辑优化后，进行了一次6000用户的对比测试，结果如下: 合 6000用户（调优前） 口 6000用户（调优后） 系统处理能力 可以看出，调整业务逻辑后，各操作响应时间大幅度缩短，系统处理能力有了明显提升。 I 口 tpS 此时系统处理能力达到每小时 164876 笔。 6测试结论 测试结论要分场景的去进行结果分析，如下所示，场景1如何，场景2如何 6.1业务场景一（无合同） 173880笔开发票业 1、系统在测试硬件、无基础数据的情况下，系统处理能力达到每小时 务，满足客户所提出的 4小时处理20万笔开发票业务，响应时间小于5秒的处理能力。 2、系统在测试硬件、 有基础数据（1800万条）的情况下，系统处理能力达到每小时122580 笔开发票