软件测试 性能测试报告
(LoadRunner)
目录
1 概述
1.1 目的
1.2 背景
1.3 范围
2 测试概要
2.1 测试环境
2.2 人力资源
2.3 测试工作量
3 测试内容及方法
3.1 测试需求/目标
3.2 测试内容
3.3 测试工具
4 测试过程
5 压力测试设计
6 测试结果及分析
6.1 网站处理性能评估
6.2并发用户测试
7 结果分析
7.1 场景执行情况
7.2 Statistics Summary（统计信息摘要）
7.3 Transaction Summary（事务摘要）
7.4 HTTP Responses Summary（HTTP响应摘要）
7.5 并发数分析
7.6 响应时间
7.7 每秒点击数
1 概述
1.1 目的
本测试报告为测试学生选课管理系统管理员的添加学生以及查询学生信息等方面的访问的性能测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述网站是否符合需求。
1.2 背景
考虑到用户数量及数据的增多给服务器造成压力不可估计，因此计划对网站负载性能测试，在系统配置不变的情况下，在一定时间内，服务器在高负载情况下的性能行为表现，便于对系统环境进行正确的分析及评估。
1.3 范围
本次测试主要是针对管理员的查询以及添加学生功能的性能测试。
2 测试概要
2.1 测试环境
PC机：联想小新15笔记本
操作系统：windows 10
测试机与被测服务器在同一局域网进行，排除了网速限制及网速度不稳定性。
2.2 人力资源
下表列出了所有参与此项目的测试人员：
|
角色 |
资源数量/具体人员 |
|
测试员 |
王锋 |
2.3 测试工作量
|
任务 |
开始时间 |
结束时间 |
总计（天数） |
总计（人时） |
|
计划 |
2012/6/2 |
2012/5/20 |
7 |
7 |
|
实际 |
2012/6/2 |
2012/5/27 |
7 |
14 |
3 测试内容及方法
3.1 测试需求/目标
在大用户量、数据量的超负荷下，获得服务器运行时的相关数据，从而进行分析系统的稳定性。
3.2 测试内容
学生选课管理系统管理员的添加学生以及查询学生信息等方面操作在大负荷情况下处理数据的能力及承受能力。
测试方法：
|
场景 |
并发用户数量 |
运行场景设置 |
测试点 |
|
登录 |
10 |
8分钟 |
服务器稳定性及操作响应时间 |
3.3 测试工具
主要测试工具为：LoadRunner性能测试工具
辅助软件：FastStone Caoture，Word2019
4 测试过程
4.1 测试脚本录制
首先进行测试脚本的录制，本次脚本录制选择的是谷歌浏览器，具体配置情况如下图所示，此处的选项需要格外注意，如果选错了就容易出现打不开浏览器以及脚本没有记录等一系列情况：
4.2进行脚本录制以及回访测试脚本
按照计划的运行顺序，依次执行脚本录制，运行完毕后得到预期结果
得到结果后进行脚本回放，检查脚本录制时候成功，如下图所示则是成功
5 压力测试设计
此次压力测试如下图所示，没有加入思考时间，共启动了10个用户，也就是说10个线程
6 测试结果及分析
6.1 网站处理性能评估
这次测试属于局域网环境进行，排除了外网的网速限制及不稳定性。
6.2并发用户测试
并发用户数：
这次测试没有加入思考时间（think time），虚拟用户数如下所示，可以看出与我们开始是设置的线程数是相符合的。
每秒通过的事务数
说明：用户的整个执行流程都录制在Action(循环)部分，所以Vuser_int (开始)和Vuser_end(结束)部分所通过的事务比较少。
事务的响应时间
可以看出由于Action是第一个加载的事务，里面加载的东西比较多，所以响应式时间也比较长一点
吞吐率
点击率
7 结果分析
7.1 场景执行情况
该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如上图所示。从该图我们知道，共历时8分。
7.2 Statistics Summary（统计信息摘要）
该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图所示。从该图我们得知，本次测试运行的最大并发数为10，总吞吐量为262956906字节，平均每秒的吞吐量为545554字节，总的请求数为33655，平均每秒的请求为69.824，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。
7.3 Transaction Summary（事务摘要）
该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况，如上图所示。从该图我们得到每个Action的平均响应时间与业务成功率。
7.4 HTTP Responses Summary（HTTP响应摘要）
该部分显示在场景执行过程中，每次HTTP请求发出去的状态，是成功还是失败，都在这里体现，如图5- 6所示。从图中可以看到，在本次测试过程中LoadRunner共模拟发出了6213次请求（与“统计信息摘要”中的“Total Hits”一致），其中“HTTP 200”的是6190次，而“HTTP 204”则有23，说明在本次过程中，经过发出的请求大部分都能正确响应了，但还是有部分未得到任何返回内容，但未影响测试结果，“HTTP 200”表示请求被正确响应，而“HTTP 204”表示服务器成功处理了请求，但未返回任何内容。
7.5 并发数分析
“Running Vusers（运行的并发数）”显示了在场景执行过程中并发数的执行情况。它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息，将这些图与事务图结合使用可以确定Vuser的数量对事务响应时间产生的影响。上图显示了百度性能测试过程中Vusers运行情况，从图中我们可以看到，Vusers的运行趋势与我们场景执行计划中的设置是一样，表明在场景执行过程中，Vusers是按照我们预期的设置运行的，没有Vuser出现运行错误，这样从另一个侧面说明我们的参数化设置是正确的，因为使用唯一数进行参数化设置，如果设置不正确，将会导致Vuser运行错误。
7.6 响应时间
这张图是平均事务响应时间与结果摘要中的“Transaction Summary”合成的。
此次测试用户操作流程简单，但10并发用户对服务器造成高度负载，服务器运行不稳定。
从设置10人的压力分析，响应速度太慢，超出用户的感觉快速响应时间。
7.7 每秒点击数
“Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“Average Throughput (bytes/second)”也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这三者结合起来分析。从图中可以看出， “Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，则表示服务器虽然能够接受服务器的请求，但返回结果较慢，可能是程序处理缓慢。
