发布时间:2020-05-26
本次案例分享是通过性能测试工具PerformanceRunner(简称PR)查看某访问平台性能需求是否满足产品设计要求,总结测试阶段的测试以及分析测试结果,明确被测系统通过性能测试出现的问题。
性能参数 |
性能目标 |
有效工作时间 |
系统应能保证 99.99%的时间按设计工作时间正常运行 |
响应时间 |
人员信息登记提交及人员出入信息加载响应时间均在3s以下 |
并发用户 |
系统能够支持 500 以上用户的并发处理 |
序号 |
模块名称 |
功能点 |
功能概述 |
1 |
人员信息登记
|
人员信息登记提交 |
提交人员基本信息到服务器保存 |
2 |
人员出入信息 |
人员出入信息加载 |
加密人员出入信息页面 |
用途 |
硬件配置 |
软件配置 |
应用服务器 |
CPU:双核内存:16G;应用分配内存:8G |
操作系统:windows10 |
测试客户端 |
CPU:双核内存:16G 应用分配内存:8G |
操作系统:windows10 浏览器:Google Chrome 工具:PerformanceRunner1.1.3 |
数据库服务器 |
对应于应用服务器 |
测试策略
本次性能测试主要为500虚拟用户并发下,测试系统的运行情况,数据是否能够保证完整性,系统是能够保持稳定性,以及系统响应时间是否符合标准,具备较好的用户体验效果。
执行方式
使用第三方工具 Fiddler 录制脚本,导入到性能测试工具PerformanceRunner 中,根据用例场景,与项目组研发修改脚本细节,编写必填参数,集成测试环境调试后执行,使用资源管理器监控cpu 等系统参数的性能,并通过 PerformanceRunner的报告分析找出系统瓶颈。
测试工具
工具类型 |
工具名称 |
版本 |
用途 |
性能测试工具 |
PerformanceRunner |
1.1.3 |
性能测试 |
典型场景测试结果与分析
1)并发测试测试用例:500个用户执行提交人员登记信息及,及加载人员出入信息页面。
2)实际结果:用户访问时,平均响应时间较快,为2.22 秒左右,符合客户要求。
3)用例描述如下:
基准测试测试用例 |
|||
用例名称 |
500个用户执行 |
用例编号 |
1 |
测试步骤 |
1.部署性能测试环境 |
||
2.用 Fiddler 录制脚本 |
|||
3.使用 PerformanceRunner 修改脚本后运行 |
|||
场景设计 |
1.设计用户数量 500 |
||
2.设计运行时间为 10 分钟 |
|||
执行时间 |
10分钟 |
||
预期结果 |
1.页面响应时间平均值不超过 3 秒 |
||
2.CPU 使用率平均值不能高于 80% |
|||
3.物理内存使用率不超过 80% |
PerformanceRunner 分析结果:
1)平均响应时间:(注:事务响应时间记录单位为毫秒)
2)每秒事务数:
3)事务对照表:
|
测试项 |
事务名称 |
平均响应时间/s |
每秒事务数 |
1 |
人员信息提交 |
submit |
1.06 |
202.418tps/s |
2 |
人员信息提交+人员出入信息加载 |
Total |
2.22 |
202.309tps/s |
4)点击率和吞吐量:
每秒点击量 |
吞吐量(兆) |
607 |
2.172 |
5)系统指标:
CPU 占用率 |
内存占比 |
82% |
28..9% |
10.结论
1)实际结果:在 500 并发用户访问时,所有事务响应时间均为 2 秒左右,在 3 秒内;服务器 CPU 使用率平均值过高,建议提升服务器硬件性能,或部署服务器集群,分离数据库系统。
2)每次测试过程的场景如下:
A.加压方式:以 500 用户压力测试为例,每10s同时加压 50 虚拟用户,全部运行。
B.稳定性持续时间:为了保证测试过程充分和数据准确,每次脚本运行时间持续 10分钟。
C.减压方式:每10s卸载100虚拟用户。
D.思考时间:忽略所有思考时间。
E.其他设置:完全模拟Chrome浏览器行为;模拟浏览器缓存;网络带宽不限。
总结:此次通过通过性能测试工具PerformanceRunner500虚拟用户并发测试时,事务响应时间基本平稳,但是系统资源中CPU占用过高,已超出服务器 80%,此次判定不通过。
最后,小编关于性能测试工具PerformanceRunner的案例分享就结束了,后续我们还将分享更多有关知识。
相关阅读:
您的信息已成功提交!
我们的客服人员稍后会与您联系