性能测试分析报告案例
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
测试执行：
测试准备阶段完毕后，确保测试环境、测试程序、测试过程、测试数据，且均已验证通过后，然后在指定的时间内可对系统施实性能测试，性能测试执行分为两个阶段：
1、性能基准测试：系统在轻负载环境下，模拟各业务的单用户交易，评估当前系统的性能表现，并作为后续压力测试的性能比较基准；
2、单交易负载测试：
3、负载压力测试：仿真现实，模拟大批量并发业务交易，评估系统在高负载情况下系统的性能表现。
****公司****管理系统
性能测试分析报告
（V2.0）
文档信息
标题
****公司****管理系统性能测试分析报告
创建日期
2008-12-01
打印日期
文件名
存放目录
所有者
作者
张三
修订记录
日期
描述
作者
对结论进行细化
李四
文档审核/审批
此文档需如下审核。
姓名
职务/职称
签名
签名日期
1测试背景1
1.1测试目标1
5.1.2
CPU利用率分析：
在上图中我们可以看出3000用户、4500用户及6000用户时，CPU利用率均在正常范围内，系统表现良好。
5.1.3
系统处理能力分析：
可以看出，在无基础数据的情况下，系统处理能力随用户数的增加呈线性上升趋势，即系统无性能瓶颈，6000用户时系统处理能力达到每小时173880笔，满足并超出客户提出的4小时20万张发票的处理能力。
3、当所有用户加载完毕后连续运行15分钟；
4、用户调度策略：每1秒启动30个虚拟用户。
业务场景一
序号
交易
业务
配比
执行
时间
操作
间隔
1
开具发票
100%
15分钟
120秒
业务场景二
序号
交易
业务
配比
执行
时间
操作
间隔
1
开具发票（无合同）
85%
15分钟
120秒
2
开具发票（有合同）
15%
说明：
按照以上场景设置，可估算出模拟用户数与每小时业务量的对应关系如下：
1）压力测试实施模型：
通过自动化测试工具模拟最终用户向服务器发起业务请求，进行性能测试。通过测试工具对测试过程中系统各点进行监控，每一次测试结束后工具自动采集测试结果并生成原始报告供分析使用。
2）压力测试实施基本流程：
测试环境准备
系统性能压力测试环境要求与生产系统的软、硬件环境保持一致，并具有相同规模的业务数据，并保证软件版本与生产环境保持一致。
15%
5.4.1
在4500用户压力下，各操作响应时间如下：
业务操作
平均响应时间（秒）
有合同_登录
6.07
有合同_开具发票
37.83
有合同_录入并开具
6.38
有合同_退出
3.85
有合同_选择合同
34.96
无合同_登录
6.27
无合同_开具发票
4.45
无合同_录入并开具
6.18
无合同_退出
3.84
说明：
此时有合同的开具发票、选择合同操作的响应时间已远远超过5秒，其它大部分操作响应时间也超过了5秒。
5.1.1平均响应时间梯度对比6
5.1.2系统资源利用率7
5.1.3系统处理能力8
5.2业务场景一对比测试分析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
1、开发正确、有效的性能测试脚本，模拟企业用户开具发票操作行为，作为测试有效实施的基础；
2、通过性能测试，客观、公正评估在当前测试环境下，被测系统的各项性能指标表现；
3、验证被测系统的业务处理能力是否能够满足在业务高峰期的性能要求，为被测系统上线提供参考依据。如不满足，对性能瓶颈进行定位分析，提供性能调优建议。
解决方法：
开发人员修改程序，点击重新登录时清除session，并在测试过程中，完成开具发票操作后就点击重新登录。重新执行测试后，此现象消失。
5.4
在测试过程中，用户提出部分用户需要在开具发票是选择合同，因此设计以下场景进行测试。
序号
交易
业务配比
执行时间
1
开具发票（无合同）
85%
15分钟
2
开具发票（有合同）
5.2.2
下图是相同压力情况下，有基础数据与无基础数据系统的处理能力对比。
处理能力分析：
在有基础数据的情况下，单从处理能力看，依然可以满足客户所提出的要求，但与之前的无基础数据的处理能力比较发现，基础数据的存在是对处理能力有较大影响。
5.2.3
下图是相同压力情况下，有基础数据与无基础数据各事务资源利用率对比图：
内存8G
硬盘500G 7200转
Win2003 Server
3.1.2
使用生成的6800万条数据。
3.1.3
类型
应用及版本号
备注
应用服务器
Weblogic8.1
数据库
Oracle9i
3.2
3.2.1
测试机配置：
类型
数量（台）
IP
配置
备注
控制台
1
Intel E4600 2.4GHz
内存2G/硬盘400G 7200转
1.2
测试自2008年11月20日启动，至12月01日测试执行结束。
1.3
**大厦*座**层
1.4
单位
姓名
备注
****公司
***
***
***
***
北京###公司
***
****
2
压力测试采用业界成熟的自动化性能测试工具，通过创建压力测试程序、构建压力测试模型，对被测试系统实施自动化压力测试，最后形成压力测试结果分析报告。
5.2
序号
用户数
每小时业务量
基础数据量
1
6000
180000
无
2
6000
126000
大于1800万
5.2.1
下图是不同压力情况下，有基础数据与无基础数据各操作响应时间对比图：
平均响应时间分析：
同样压力的情况下，在无基础数据的情况下，响应时间均小于5秒。当基础数据量在1800万的时候，6000用户压力下响应时间大幅度提高，超过客户所提出5秒之内的要求。
模拟用户数
3000
4500
6000
每小时业务量
90000
135000
180000
5
说明：术语解释
（事务）－ LoadRunner中定义，为一个流程中某个环节的称谓，一个流程可称为一个大的事务，在这个大的交易中包含许多的小的事务。
响应时间－ LoadRunner中衡量流程中各个事务性能的最佳手段，计算的是端到端的时间，说的通俗一点，从点击应用中的某个控件，到从数据库返回数据到客户端，整个过程都被计算在事务的响应时间内。
场景－ LoadRunner中专门术语。它是所有测试资源包括测试脚本、运行设置、运行用户数等的集合。在这个场景中，可以定义并发用户的数目，定义要运行的脚本，或者说运行的流程类型。在一个场景中，可以是单个流程，也可以是多个流程的混合。
虚拟用户－ LoadRunner中特定术语，为模拟现实中的实际用户，测试软件使用虚拟用户代替真实的用户。
Win2003 Server
负载发生器
9
Intel E4600 2.4GHz
内存1G/硬盘400G7200转
Win2003 Server
3.2.2
采用Mercury Interactive公司的LoadRunner测试及分析软件作为测试工具。
LoadRunner简介：
LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。在LoadRunner的帮助下，用户可以以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。LoadRunner 能够对整个企业架构进行测试，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助用户更快的查找和发现问题。此外，LoadRunner 能支持广泛的协议和技术，可以为用户的特殊环境提供特殊的解决方案。
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ຫໍສະໝຸດ Baidu试环境搭建4
3.2.2测试软件4
4测试设计5
4.1模拟用户数5
4.2测试模型建立5
5测试结果分析6
5.1业务场景一（无基础数据）梯度压力测试分析6
5.1
5.1.1
下图是不同用户数下各事务的平均响应时间随用户数变化的曲线：
事务
3000用户
4500用户
6000用户
登录
0.56
1.312
2.14
开具发票
0.24
0.87
2.08
录入并开具
0.43
1.098
2.70
平均响应时间分析：
从上图中可以看出，各操作的响应时间随着用户数的增加呈上升趋势，但都没有超过5秒，在可接受范围内。
测试数据准备：
测试数据要求尽量模拟真实业务数据，而且具有一定可重用性。能贯穿各相关系统，保证业务流程的顺畅正确。具体的数据类型和数据量需要根据选择的交易类别或性能测试场景设置而定。
此外性能测试会产生大量的虚拟用户，需要消耗大量的测试数据。其数量直接关乎测试结果。测试中所需的基本数据类型为：
系统用户数据：登陆系统使用的用户名-口令等，数量与虚拟用户数一致。
本次测试采用的LoadRunner版本为9.0。
4
4.1
依据系统目前的业务量以及未来业务量增长，对当前系统分别按3000、4500、6000用户进行压力测试，以评估系统在不同压力梯度情况下的性能表现。
4.2
此次性能测试的业务选择，应覆盖各性能关键业务，并通过****公司、北京***公司双方协商选取被测业务。根据协商选定如下业务进行性能测试：
CPU利用率分析：
相同压力下，因有基础数据情况下响应时间变长，系统处理能力下降，CPU利用率也随之下降，这说明系统瓶颈出现在了其他方面。
5.3
在系统测试过程中，我们发现WebLogic的JVM可用内存逐渐减少，下图是在WebLogic监控台所监控到的情况：
为了验证确认此现象，进行了4500用户6个小时的测试，当测试执行到1小时左右，WebLogic JVM基本已无内存可用，如下图所示：
业务数据：每个虚拟用户模拟真实用户进行操作时使用到的数据。
辅助数据：为保证业务操作的正常进行而设置的基本信息资料。
测试程序开发：
利用在历史数据收集步骤中所获得的典型用户的系统访问模式，做为测试程序开发的依据。该测试程序应该覆盖典型用户的系统访问模式所涉及的操作。脚本的开发是利用LoadRunner Vugen进行脚本录制，开发，参数化，调试的过程。
5.4.2
下图是无合同4500用户与有合同4500用户情况下系统处理能力对比图：
分析：
此时系统处理能力仍然满足4小时20万张发票的要求，但因响应时间过长，认为系统性能不满足要求。
5.4.3
资源利用率分析：
因响应时间过长，出现大量的队列等待，导致CPU利用率下降。
5.5
现象：
有合同“开具发票”、“选择合同”操作的响应时间过长。
测试结果分析报告：
压力测试结果经过确认有效后，将汇总压力测试结果，形成最终的性能测试分析报告。
3
3.1
3.1.1
系统
IP地址
所在主机配置
备注
应用服务器
CPU：Xeon MP X4600 2.6GHz
内存8G
硬盘200G 7200转
Win2003 Server
数据库服务器
CPU：Xeon MP X4600 2.6GHz
被占用内存无法释放，导致被测系统在长时间运行后响应时间明显上升，处理能力明显下降，如下图所示：
分析：
用户在登录时，系统会自动生成一个session，并占用部分内存，而这个session的过期时间设置为2小时，按照用户习惯分析，当用户使用直接关闭IE窗口退出系统的方式退出，这个session是不释放的，并继续占用内存。测试过程中没有做退出操作，导致大量用户session不释放。根据上图显示，40分钟时性能开始下降，此时在线用户数约为37.5*60*40=90000。
压力模型定义：
此次性能测试的用例选择，按照****公司提供的业务数据进行分析抽取，用例选取是性能测试压力模型设计的首要任务。用例选取的原则是：
1)典型的交易和业务流程
2)用户操作使用频繁
3)对系统性能影响较大
4)性能测试压力符合业务系统实际的实际交易发生比例
实际执行场景的设置尽量模拟实际业务进行，运行时长，操作间隔（思考时间），循环间隔，并发间隔，用户加载和减压时间根据系统基准测试结果进行判断和设置。
开具发票
以此基础上定义测试执行压力模型：
在混合业务场景压力梯度测试过程中，分别按3000、4500、6000用户进行压力测试，在各个压力测试过程中保持测试场景和调度测试的完全一致，使结果具有很好的可比性。
压力测试执行场景描述如下：
1、模拟用户数：3000、4500、6000
2、Pacing：120秒；
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业务场景二（有合同）17
6.3稳定性18
7调优建议18
8签字确认19
1
1.1
对****公司****管理系统的开具发票功能进行性能测试，客观、公正评估系统的性能现状。
测试准备阶段完毕后，确保测试环境、测试程序、测试过程、测试数据，且均已验证通过后，然后在指定的时间内可对系统施实性能测试，性能测试执行分为两个阶段：
1、性能基准测试：系统在轻负载环境下，模拟各业务的单用户交易，评估当前系统的性能表现，并作为后续压力测试的性能比较基准；
2、单交易负载测试：
3、负载压力测试：仿真现实，模拟大批量并发业务交易，评估系统在高负载情况下系统的性能表现。
****公司****管理系统
性能测试分析报告
（V2.0）
文档信息
标题
****公司****管理系统性能测试分析报告
创建日期
2008-12-01
打印日期
文件名
存放目录
所有者
作者
张三
修订记录
日期
描述
作者
对结论进行细化
李四
文档审核/审批
此文档需如下审核。
姓名
职务/职称
签名
签名日期
1测试背景1
1.1测试目标1
5.1.2
CPU利用率分析：
在上图中我们可以看出3000用户、4500用户及6000用户时，CPU利用率均在正常范围内，系统表现良好。
5.1.3
系统处理能力分析：
可以看出，在无基础数据的情况下，系统处理能力随用户数的增加呈线性上升趋势，即系统无性能瓶颈，6000用户时系统处理能力达到每小时173880笔，满足并超出客户提出的4小时20万张发票的处理能力。
3、当所有用户加载完毕后连续运行15分钟；
4、用户调度策略：每1秒启动30个虚拟用户。
业务场景一
序号
交易
业务
配比
执行
时间
操作
间隔
1
开具发票
100%
15分钟
120秒
业务场景二
序号
交易
业务
配比
执行
时间
操作
间隔
1
开具发票（无合同）
85%
15分钟
120秒
2
开具发票（有合同）
15%
说明：
按照以上场景设置，可估算出模拟用户数与每小时业务量的对应关系如下：
1）压力测试实施模型：
通过自动化测试工具模拟最终用户向服务器发起业务请求，进行性能测试。通过测试工具对测试过程中系统各点进行监控，每一次测试结束后工具自动采集测试结果并生成原始报告供分析使用。
2）压力测试实施基本流程：
测试环境准备
系统性能压力测试环境要求与生产系统的软、硬件环境保持一致，并具有相同规模的业务数据，并保证软件版本与生产环境保持一致。
15%
5.4.1
在4500用户压力下，各操作响应时间如下：
业务操作
平均响应时间（秒）
有合同_登录
6.07
有合同_开具发票
37.83
有合同_录入并开具
6.38
有合同_退出
3.85
有合同_选择合同
34.96
无合同_登录
6.27
无合同_开具发票
4.45
无合同_录入并开具
6.18
无合同_退出
3.84
说明：
此时有合同的开具发票、选择合同操作的响应时间已远远超过5秒，其它大部分操作响应时间也超过了5秒。
5.1.1平均响应时间梯度对比6
5.1.2系统资源利用率7
5.1.3系统处理能力8
5.2业务场景一对比测试分析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
1、开发正确、有效的性能测试脚本，模拟企业用户开具发票操作行为，作为测试有效实施的基础；
2、通过性能测试，客观、公正评估在当前测试环境下，被测系统的各项性能指标表现；
3、验证被测系统的业务处理能力是否能够满足在业务高峰期的性能要求，为被测系统上线提供参考依据。如不满足，对性能瓶颈进行定位分析，提供性能调优建议。
解决方法：
开发人员修改程序，点击重新登录时清除session，并在测试过程中，完成开具发票操作后就点击重新登录。重新执行测试后，此现象消失。
5.4
在测试过程中，用户提出部分用户需要在开具发票是选择合同，因此设计以下场景进行测试。
序号
交易
业务配比
执行时间
1
开具发票（无合同）
85%
15分钟
2
开具发票（有合同）
5.2.2
下图是相同压力情况下，有基础数据与无基础数据系统的处理能力对比。
处理能力分析：
在有基础数据的情况下，单从处理能力看，依然可以满足客户所提出的要求，但与之前的无基础数据的处理能力比较发现，基础数据的存在是对处理能力有较大影响。
5.2.3
下图是相同压力情况下，有基础数据与无基础数据各事务资源利用率对比图：
内存8G
硬盘500G 7200转
Win2003 Server
3.1.2
使用生成的6800万条数据。
3.1.3
类型
应用及版本号
备注
应用服务器
Weblogic8.1
数据库
Oracle9i
3.2
3.2.1
测试机配置：
类型
数量（台）
IP
配置
备注
控制台
1
Intel E4600 2.4GHz
内存2G/硬盘400G 7200转
1.2
测试自2008年11月20日启动，至12月01日测试执行结束。
1.3
**大厦*座**层
1.4
单位
姓名
备注
****公司
***
***
***
***
北京###公司
***
****
2
压力测试采用业界成熟的自动化性能测试工具，通过创建压力测试程序、构建压力测试模型，对被测试系统实施自动化压力测试，最后形成压力测试结果分析报告。
5.2
序号
用户数
每小时业务量
基础数据量
1
6000
180000
无
2
6000
126000
大于1800万
5.2.1
下图是不同压力情况下，有基础数据与无基础数据各操作响应时间对比图：
平均响应时间分析：
同样压力的情况下，在无基础数据的情况下，响应时间均小于5秒。当基础数据量在1800万的时候，6000用户压力下响应时间大幅度提高，超过客户所提出5秒之内的要求。
模拟用户数
3000
4500
6000
每小时业务量
90000
135000
180000
5
说明：术语解释
（事务）－ LoadRunner中定义，为一个流程中某个环节的称谓，一个流程可称为一个大的事务，在这个大的交易中包含许多的小的事务。
响应时间－ LoadRunner中衡量流程中各个事务性能的最佳手段，计算的是端到端的时间，说的通俗一点，从点击应用中的某个控件，到从数据库返回数据到客户端，整个过程都被计算在事务的响应时间内。
场景－ LoadRunner中专门术语。它是所有测试资源包括测试脚本、运行设置、运行用户数等的集合。在这个场景中，可以定义并发用户的数目，定义要运行的脚本，或者说运行的流程类型。在一个场景中，可以是单个流程，也可以是多个流程的混合。
虚拟用户－ LoadRunner中特定术语，为模拟现实中的实际用户，测试软件使用虚拟用户代替真实的用户。
Win2003 Server
负载发生器
9
Intel E4600 2.4GHz
内存1G/硬盘400G7200转
Win2003 Server
3.2.2
采用Mercury Interactive公司的LoadRunner测试及分析软件作为测试工具。
LoadRunner简介：
LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。在LoadRunner的帮助下，用户可以以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。LoadRunner 能够对整个企业架构进行测试，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助用户更快的查找和发现问题。此外，LoadRunner 能支持广泛的协议和技术，可以为用户的特殊环境提供特殊的解决方案。
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ຫໍສະໝຸດ Baidu试环境搭建4
3.2.2测试软件4
4测试设计5
4.1模拟用户数5
4.2测试模型建立5
5测试结果分析6
5.1业务场景一（无基础数据）梯度压力测试分析6
5.1
5.1.1
下图是不同用户数下各事务的平均响应时间随用户数变化的曲线：
事务
3000用户
4500用户
6000用户
登录
0.56
1.312
2.14
开具发票
0.24
0.87
2.08
录入并开具
0.43
1.098
2.70
平均响应时间分析：
从上图中可以看出，各操作的响应时间随着用户数的增加呈上升趋势，但都没有超过5秒，在可接受范围内。
测试数据准备：
测试数据要求尽量模拟真实业务数据，而且具有一定可重用性。能贯穿各相关系统，保证业务流程的顺畅正确。具体的数据类型和数据量需要根据选择的交易类别或性能测试场景设置而定。
此外性能测试会产生大量的虚拟用户，需要消耗大量的测试数据。其数量直接关乎测试结果。测试中所需的基本数据类型为：
系统用户数据：登陆系统使用的用户名-口令等，数量与虚拟用户数一致。
本次测试采用的LoadRunner版本为9.0。
4
4.1
依据系统目前的业务量以及未来业务量增长，对当前系统分别按3000、4500、6000用户进行压力测试，以评估系统在不同压力梯度情况下的性能表现。
4.2
此次性能测试的业务选择，应覆盖各性能关键业务，并通过****公司、北京***公司双方协商选取被测业务。根据协商选定如下业务进行性能测试：
CPU利用率分析：
相同压力下，因有基础数据情况下响应时间变长，系统处理能力下降，CPU利用率也随之下降，这说明系统瓶颈出现在了其他方面。
5.3
在系统测试过程中，我们发现WebLogic的JVM可用内存逐渐减少，下图是在WebLogic监控台所监控到的情况：
为了验证确认此现象，进行了4500用户6个小时的测试，当测试执行到1小时左右，WebLogic JVM基本已无内存可用，如下图所示：
业务数据：每个虚拟用户模拟真实用户进行操作时使用到的数据。
辅助数据：为保证业务操作的正常进行而设置的基本信息资料。
测试程序开发：
利用在历史数据收集步骤中所获得的典型用户的系统访问模式，做为测试程序开发的依据。该测试程序应该覆盖典型用户的系统访问模式所涉及的操作。脚本的开发是利用LoadRunner Vugen进行脚本录制，开发，参数化，调试的过程。
5.4.2
下图是无合同4500用户与有合同4500用户情况下系统处理能力对比图：
分析：
此时系统处理能力仍然满足4小时20万张发票的要求，但因响应时间过长，认为系统性能不满足要求。
5.4.3
资源利用率分析：
因响应时间过长，出现大量的队列等待，导致CPU利用率下降。
5.5
现象：
有合同“开具发票”、“选择合同”操作的响应时间过长。
测试结果分析报告：
压力测试结果经过确认有效后，将汇总压力测试结果，形成最终的性能测试分析报告。
3
3.1
3.1.1
系统
IP地址
所在主机配置
备注
应用服务器
CPU：Xeon MP X4600 2.6GHz
内存8G
硬盘200G 7200转
Win2003 Server
数据库服务器
CPU：Xeon MP X4600 2.6GHz
被占用内存无法释放，导致被测系统在长时间运行后响应时间明显上升，处理能力明显下降，如下图所示：
分析：
用户在登录时，系统会自动生成一个session，并占用部分内存，而这个session的过期时间设置为2小时，按照用户习惯分析，当用户使用直接关闭IE窗口退出系统的方式退出，这个session是不释放的，并继续占用内存。测试过程中没有做退出操作，导致大量用户session不释放。根据上图显示，40分钟时性能开始下降，此时在线用户数约为37.5*60*40=90000。
压力模型定义：
此次性能测试的用例选择，按照****公司提供的业务数据进行分析抽取，用例选取是性能测试压力模型设计的首要任务。用例选取的原则是：
1)典型的交易和业务流程
2)用户操作使用频繁
3)对系统性能影响较大
4)性能测试压力符合业务系统实际的实际交易发生比例
实际执行场景的设置尽量模拟实际业务进行，运行时长，操作间隔（思考时间），循环间隔，并发间隔，用户加载和减压时间根据系统基准测试结果进行判断和设置。
开具发票
以此基础上定义测试执行压力模型：
在混合业务场景压力梯度测试过程中，分别按3000、4500、6000用户进行压力测试，在各个压力测试过程中保持测试场景和调度测试的完全一致，使结果具有很好的可比性。
压力测试执行场景描述如下：
1、模拟用户数：3000、4500、6000
2、Pacing：120秒；
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业务场景二（有合同）17
6.3稳定性18
7调优建议18
8签字确认19
1
1.1
对****公司****管理系统的开具发票功能进行性能测试，客观、公正评估系统的性能现状。