性能测试报告模板
7,475 Views『作者：RickyZhu 转载务必注明出处和作者』
Tag:testing
经常在论坛或者MSN上问及测试报告应该怎么写,其实不同的公司或者不同的测试类型,测试报告的模板也不尽相同,性能测试作为测试中最重要的部分,测试报告的要求也比较高, 这是一份Mercury官方版的性能测试模板,希望对从事性能测试并且苦于没有测试报告模板的朋友提供一点帮助.
xxxxxxxxxx
性能测试报告
2007年3月4日
目 录
目前，XXXX的XXXXXXXX核心业务系统（以下简称新业务系统）已先后在XXXX、成功上线，从而公司的XXXX信息管理逐步走上了集中管控的道路。后续，xxx等34家分公司的XXXX信息也将分布进入业务系统，从而将会势必出现新业务系统中信息大量增长的态势。
随着新业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：XXXX大数据量的“冲击”，在XXXX信息进入时，系统能稳定在什么样的性能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。
本《性能测试规划书》即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的XXXXXXXX核心业务系统的性能测试。
xxxx业务系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针对XXXXXXXX核心业务系统进行的），该业务系统的主要功能包括：xxxxx
在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数，
xxxxxx
主要功能如下：
Ø xxx
Ø xxxxx
Ø
本次测试是针对XXXXXXXX核心业务系统的性能特征和系统的性能调优而进行的，主要需要获得如下的测试指标。
1、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。
2、应用系统的吞吐率：即应用系统在单位时间内完成的交易量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的交易数量。
3、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。
xxxx业务系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。
1.2.1 系统总体结构
描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。
本次性能测试中各类交易都是由若干功能模块组成的，每个交易都根据其执行特点分成了若干操作步骤，每个步骤就是一个功能点（即功能模块），在xxx业务系统中，各种交易及其包含的功能模块关系如下：
1． xxx
2． xxxx
3． xxxx
本次压力测试主要设计的功能模块以及所属的路径如下表
|
名称 |
所属交易 |
路径 |
本次性能测试中，选择的各类交易的业务流程如下：
1．xxxxxx
2．xxxxxxx
3．xxxxxx：
4．xxx：
5．xxxxx
6．xxxx
查询交易的业务流程只是单一步骤的，即：输入查询条件后获取查询结果，因此在本次性能测试中只作为一个事物处理，交易流程图略。
本次性能测试的关键点，就是查看xxxx业务系统在并发压力下的表现，即：支持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的交易处理能力，并找出各类交易的性能瓶颈。
本次性能测试环境与真实运行环境基本一致，都运行在同样的硬件和网络环境中，数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端都是通过浏览器访问应用系统。
其中具体的硬件和网络环境如下：
Ø 服务器设备：IBM 570（DBserver）， IBM 690（APserver）
Ø 操作系统： AIX
Ø 网络环境： LAN（10M）
Ø 数据库：Oracle
Ø 客户端： PC （Windows ）
网络拓扑和结构图如下：
从广泛意义上讲性能测试包括：压力测试、稳定性测试、负载能力测试和可扩展性测试等。在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案，本次XXXXXXXX核心业务系统的性能测试主要是采用通常的压力测试模式来执行的，即：逐步增加压力，查看应用系统在各种压力状况小的性能表现。
在本次性能测试中，也将使用美科利的新产品性能测试诊断工具（Diagnostic）对测试应用的各层进行监控，判断J2EE各层次的各类方法和类的调用使用时间和效率，并帮助开发人员分析J2EE应用的各类交易的性能瓶颈点。
在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。
本次压力测试是指针对现行的xxx核心业务系统的联机交易处理能力的测试，检验系统的吞吐率。本系统的压力测试主要是针对xxxxx，检查在日间交易高峰时期，并发用户数较多的时候的处理能力等等。
压力测试的目的就是检验系统的最大吞吐量，检验现行的xxxx业务系统在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。
本次针对xxxx核心业务系统所进行的压力测试的测试目的为：
² 给出xxxx系统当前的性能状况
² 定位新业务系统性能瓶颈或潜在性能瓶颈
² 总结一套合理的、可操作的、适合公司现实情况的性能测试方案，为后续的性能测试工作提供基本思路。
使用美科利公司（Mercury）的性能测试软件LoadRunner，对现行的xxxx业务系统进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调用各台测试前台，发起各种组合的交易请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。
使用的测试用例包括：联机处理交易和查询交易，其中联机交易测试试用的交易包括：xxxx查询类交易包括：xxxx
测试用例列表包括：
|
交易种类 |
案例一 |
案例二 |
案例三 |
案例四 |
|
|
30% |
40% |
25% |
10% |
|
|
10% |
10% |
25% |
0% |
|
|
20% |
10% |
15% |
0% |
|
|
20% |
20% |
15% |
10% |
|
|
30% |
20% |
20% |
80% |
本次测试将依照如下场景进行测试：
|
用户数 功能模块 |
业务操作 |
交易配比（%) |
200 |
400 |
700 |
1000 |
针对每个测试案例，都将采用逐步加压和瞬间加压两种客户端连接方式进行，查看服务器端在客户端的连接数量变化过程中对应的处理能力，测试运行安排如下：
· 每隔2秒增加1个用户连接，最多增加到200个用户，查看并记录运行情况
· 每隔2秒增加2个用户连接，最多增加到200个用户，查看并记录运行情况
· 一次性连接10个用户，查看记录运行情况
· 一次性连接100个用户，查看记录运行情况
在本次性能测试中，各类测试指标包括测试中应该达到的某些性能指标，这些性能指标均是来自应用系统设计开发时遵循的业务需求，当某个测试的某一类指标已经超出了业务需求的要求范围，则测试已经达到目的，即可终止压力测试。
2.1.4.1 应用软件级别的测试指标：
1) 联机交易类的执行情况
ü 交易的平均响应时间（期望值：<15s）
ü 交易的最大响应时间（期望值：<30s）
ü 平均每秒处理交易数量（分别记录单位时间内成功、失败和停止的交易数量）
ü 交易成功率 （期望值：>95%）
ü 不同并发用户数的状况下的上述记录值
2）测试结果分析情况
ü 单笔记录的处理时间（期望值：<15s）
ü 单位时间内的处理交易笔数（期望值：>10个）
ü 某个时间段内的交易处理数量
ü 单笔能处理的最大数据量
ü 在每个交易处理中最大（最耗时）的模块
ü 在不同数量的测试数据基础上的上述记录值
2.1.4.2 网络级别的测试指标：
ü 吞吐量：单位时间内网络传输数据量
ü 冲突率：在以太网上监测到的每秒冲突数
2.1.4.3 操作系统级别的测试指标：
ü 进程/线程交换率：进程和线程之间每秒交换次数
ü CPU利用率：即CPU占用率（％）
ü 系统CPU利用率：系统的CPU占用率（％）
ü 用户CPU利用率：用户模式下的CPU占用率（％）
ü 磁盘交换率：磁盘交换速率
ü 中断速率：CPU每秒处理的中断数
ü 读入内存页速率：物理内存中每秒读入内存页的数目
ü 写出内存页速率：每秒从物理内存中写到页文件中的内存页数目或者从物理内存中删掉的内存页数目
ü 内存页交换速率：每秒写入内存页和从物理内存中读出页的个数
ü 进程入交换率：交换区输入的进程数目
ü 进程出交换率：交换区输出的进程数目
2.1.4.4 数据库级别的测试指标：
ü 数据库的并发连接数：客户端的最大连接数
ü 数据库锁资源的使用数量
2.1.5.1 案例数据：满负荷压力
根据测试系统的硬件条件，选择满负荷的压力，在系统的资源使用基本维持在90%左右的状况下，测试xxx核心业务系统的处理能力。
1． xxxxx
2.1.6 运行状况记录
记录可扩展性测试中的测试结果及其系统的运行状况。除了记录测试指标以外，应该结合测试实时记录系统各个层次的资源和参数。主要包括：
ü 硬件环境资源
ü 服务器操作系统参数
ü 网络相关参数
ü 数据库相关参数：具体数据库参数有所不同，结合各个数据库独有的特点记录
xxxx务系统的性能测试共计执行了2次，两次执行的脚本流程作了调整，其他的环境和数据都一样。在测试数据准备完备以后，第一次测试中，操作流程为每次交易都执行用户登录操作，第二次测试中，操作流程为先进行用户登录，然后每次交易都不再执行用户登录。
3.1 测试描述
两次测试都是在12月22日凌晨进行的。
第一次测试执行了30分钟左右，执行脚本都是采用每次交易都执行登录操作，测试过程中，交易的执行速度随着测试的进行，越来越慢，交易的响应时间越来越长，交易出错（超时）情况也越来越严重，交易在执行到30分钟左右，用户登录交易开始大量失败（超时）并导致后续的交易都无法完成，于是终止本次测试。
第二次测试执行了50分钟左右，在第一次测试的基础上，调整交易流程，让每次交易都只登录一次，然后顺序执行交易逻辑。测试开始初期，交易的响应时间随着交易并发量的增加而快速增加，在测试执行了10分钟左右，所有的用户登录操作都基本完成，此后交易响应时间开始减少，并比较平稳的执行，绝大部分交易执行比较平稳成功率也很高，除了两个交易：xxx(Audit_Transaction)和 xxx(ClaimRegister_Transaction)，这两个交易的执行速度特别慢，交易相应时间一直都维持在190秒左右和160秒左右，这两个交易超时现象严重，交易成功率很低，很多交易都因为超时而失败。
3.2 测试场景
测试中，使用逐步加压的模式，采用：每隔2秒启动1个并发用户（Vuser）的方式，即：每隔1秒，启动1个Vuser，在7分钟左右启动所有的Vuser（200个），执行登录，并根据设置的时间间隔发起交易。
这次测试都部署在如下的场景中。
运行的脚本部署在3台PC机，主要目的就是检查在较大压力的情况下，xxxxx心业务系统的性能表现。
Ø 选择了2台PC，每台PC机部署了70个左右并发用户，
Ø 选择1台PC，部署60个左右的并发用户，并运行LoadRunner的控制器（Controller）
3.3 测试结果
两次测试AP服务器主机上的CPU利用率如下：
可以看出在两次测试执行中第一次（1:52 – 2:20）测试过程中CPU的利用率都几乎达到了100%，第二次测试中（2:45- 4:00）CPU的利用率也达到了95%以上。
两次测试在数据库（Oracle）服务器上主机上的CPU利用率如下：
可以看出两次测试执行中第一次（1:52 – 2:20）测试过程中CPU的利用率很低，第二次测试中（2:45- 4:00）CPU的利用率较高也达到了75%以上，但两次测试的CPU的IO等待时间却都比较高，IO和CPU利用率对照表如下：
可以看出两次测试执行中第一次（1:52 – 2:20）测试过程中CPU的IO等待率较低，因为大多数的交易都是用户登录，都压在AP服务器上了，第二次测试中（2:45- 4:00）CPU的IO等待率较高，都达到了80%以上。
两次测试的网络压力并不大，网络流量如下：
AP服务器监控的网络流量
DB服务器上监控的网络流量
从图中可以看出，在10M的局域网中，网络流量并不大。
3.3.1 第一次测试
第一次测试使用了200个并发用户，并发用户的启动信息如下：
各类交易的交易相应时间 （秒）
|
Color |
Scale |
交易名称 |
最小 |
平均 |
最大 |
|
|
1 |
AutoUW_Transaction |
0.0 |
23.733 |
87.871 |
|
|
