目录
6、性能测试（ Performance Testing ）的分类
性能测试基本概念
1、并发用户
• 严格意义的并发：
即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务 。
• 广义范围的并发：
这种并发与前一种并发的区别是尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。
2、并发用户数
• 并发用户数是指同时进行请求的客户数量
• 并发用户数用于模拟用户的真实负载情况（并发情况是对系统最大的考验）
• 并发数≠同时使用系统的用户数
3、请求响应时间
• 响应时间指的是从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间。
4、吞吐量
• 定义：吞吐量指的是单位时间内处理的客户端请求数量。
• 通常情况下，吞吐量用 “请求数 /秒”或者“页面数 /秒”来衡量。
• 从业务角度看，吞吐量也可以用 “业务数/小时或天 ”、“访问人数 /天”、“页面访问量 /天”来衡量。
5、吞吐率
• 单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量。它是衡量网络性能的重要指标。通常情况下，吞吐率用 “请求数 /秒”或者 “页面数 /秒”来衡量
6、性能测试（ Performance Testing ）的分类
• 负载测试（ Load Testing ）
负载测试是指在一定的软件、硬件及网络环境下，运行一种或多种业务，在不同虚拟用户数量的情况下，测试服务器的性能指标是否在用户的要求范围，以此确定系统所能承载的最大用户数、最大有效用户数以及不同用户数下的系统响应时间及服务器的资源利用率
通过逐渐加压的方式，直到性能指标超过预订指标或某种资源使用已经达到饱和的状态，目的是了解系统性能容量和处理能力极限。
主要用途：发现系统性能的拐点，寻找系统能够支持的最大用户，业务等处理的能力的约束。
负载测试通常描述一种特定类型的压力测试，即增加用户数量以对应用程序进行压力测试。
• 压力测试（ Stress Testing ）
压力测试是指在一定的软硬件及网络环境下，模拟大量的虚拟用户向服务器产生负载，使服务器的资源处于极限状态下并长时间连续运行，以测试服务器在高负载情况下是否能够稳定工作
压力测试通过确定一定系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
压力测试是为了发现在什么条件下您的应用程序的性能会变得不可以接受，即通过测试找到系统的最大用户数
• 配置测试（ Configuration Testing ）
基准测试是指再一定的软件，硬件及网络环境下，模拟一定数量的虚拟用户运行一种或多种业务，将测试结果作为基线数据，在系统调优或系统评测的选择提供决策数据
意义：主要用于性能调优，在经过测试获得了基准测试数据后，进行环境调整（包括硬件配件、网络、操作系统、应用服务器、数据库等），再将测试结果与基准数据进行对比，判断调整是否达到最佳状态
• 并发测试（ Concurrency Testing ）
测试多用户访问的，考察系统中某个应用、模块或者数据处理的时候是否存在死锁或者性能瓶颈等问题。
意义：在系统处理能力达到峰值状态时候，监测系统资源，找到资源使用率最高的，确定系统性能瓶颈
• 容量测试（ Volume Testing ）
容量测试是指在一定的软件，硬件及网络环境下，在数据库中构造不同数级别的数据记录 ，运行一种或多种业务在一定虚拟用户数量的情况下，获取不同数量级别的服务器性能指标，以确定数据库的最佳容量和最大容量。
容量测试的目的是通过测试预先分析反映出软件系统应用特征的某项指标极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行
意义：确定测试对象在给定时间内能够持续处理的最大负载或工作量。对软件容量的测试，能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力
• 可靠性测试（ Reliability Testing）
通过给系统加载一定的业务压力的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行，
可靠性测试强调在一定的业务压力下长时间（如：24X7）运行系统，关注系统的运行情况（如资源使用率是否逐渐增加、响应是否越来越慢），是否有不稳定征兆。（长时间运行可以观察系统是否有内存泄漏的情况）
• 失败测试（ Failover Testing ）
有容错机制、冗余备份、负载均衡的系统，通过模拟错误操作和异常情况来测试相关功能
--容错机制：用户误操作、系统能够及时响应，给出错误提示
--冗余备份：
~例如硬件，可以设计两块处理器板卡，互为备份，主要处理器工作，和备用处理器实时同步数据，如果主处理器异常中断，自动启动备用处理器。
~软件，例如：数据库备份
--负载均衡：一组服务器或者设备，用户访问页面服务器，会有一个均衡的算法，把用户链接到当前负载最轻的服务器或者设备上
性能测试报告模板
性能测试报告
北京市XXXXX限公司
二零二一年七月
工件版本变更记录：
| 版本号 | 拟制/修改日期 | 拟制/修改人 | 修改记录 | 批准人 |
| 1.0 | 2021/7/19 | XXXXX | 新建 | XXXXX |
目录
1.2 测试目的
4 测试策略
4.1人力资源
4,2测试用例
5.1 聚合报告
5.2 系统吞吐量
5.3 资源占用率
6 分析与建议
6.1 测试结论分
6.2 问题
1 文档说明
1.1 编写目的
本次测试报告为xxx系统的性能测试总结报告，目的在于总结性能测试工作，并分析测试结果，描述系统是否符合xxx系统的性能需求。
1.2 测试目的
本次性能测试的目的是检测xxx系统的性能情况。即：为了xxx系统上线后能够稳定运行，有必要在上线前对核心业务场景的压力情况有充分了解。因此，希望在模拟生产环境的情况下，模拟上线后的用户并发数，对系统核心业务进行压力测试，收集相应的系统参数，并最终作为上线的依据。
1.3 读者对象
预期参考人员包括用户、测试人员、开发人员、项目管理者、质量管理人员和需要阅读本报告的高层经理。
1.4 参考资料
| 名称 | 是否可用 | 备注 |
| XXX性能测试方案 | 是 |
1.5 术语解释
线程数：并发用户数
请求数Samples：发出了多少个请求，例：模拟10个用户，每个用户迭代10次，就是100次
平均响应时间Average：单个请求平均响应时间（毫秒）
中位数Median： 50％ 用户的响应时间（毫秒）
90% Line：90％ 用户的响应时间
Min：最小响应时间（毫秒）
Max：最大响应时间（毫秒）
错误率Error%：出现错误的请求的数量/请求的总数
吞吐量Throughput：表示每秒完成的请求数（Request per Second），是指在没有帧丢失的情况下，设备能够接受的最大速率
KB/Sec：每秒从服务器端接收到的数据量；1GB＝1024MB，1MB＝1024KB，1KB＝1024Bytes。
1.6 系统压力强度估算
并发用户的经验公式为：使用系统的用户数量*（5%~20%）
系统响应时间判断原则（2-5-10原则）如下：
系统业务响应时间小于2秒，判为优秀，
用户对系统感觉很好；
系统业务响应时间在2-5秒之间，判为良好，用户对系统感觉一般；
系统业务响应时间在5-10秒之间，判为及格，用户对系统勉强接受；
系统业务响应时间超过10秒，判断为不及格，用户无法接受系统的响应速度；
2 测试环境
2.1 测试环境
网络环境：广域网（100M）
软件环境：
1 操作系统：Windows 10
2 应用服务软件：WebSphere，Tomcat5.5
3 数据库：MySQL
硬件环境：
| 硬件名称 | 数量（台） | 型号 | CPU | 内存 | 备注 |
| 应用服务器 | |||||
| 数据库服务器 | |||||
| 测试客户端 |
2.2 测试工具
| 工具 | 版本 |
| Jmeter | 4.0 |
| Perfmon Metrics Collector | 2.1 |
| ServerAgent | 2.2.1 |
| nMon | 16h v2 |
3 测试需求
3.1 测试功能点
×××××××
3.2 性能需求
注：1. 如果未提出实际性能需求可简写或省略该项
2. 此项根据产品需要可适当修改
并发用户数达到x时，登录系统平均响应时间不超过x秒；
并发用户数为x时，操作主要的业务流平均响应时间在用户接受的范围内，系统 运行正常；
X小时运行组合测试用例时，系统正常运行不崩溃；
若系统容量不能达到要求的并发数或运行时间时，验证一下达到哪一个数值时，系统将不能支持
4 测试策略
4.1 人力资源
| 名称 | 测试时间 | 执行人员 | 备注 | |
| 开始时间 | 结束时间 | |||
| 测试方案 | ||||
| 测试脚本 | ||||
| 环境、数据准备 | ||||
| 结果分析、测试报告 | ||||
4.2 测试用例
| 用例编号 | N_login_0001 | ||
| 验证功能 | 系统登录 | ||
| 测试目的 | 被测系统是否能够满足大并发用户数登录的要求 | ||
| 前置条件 | 已注册用户的账号与密码 | ||
| 方法 | 设置并发用户数为100个，模拟用户登录系统的负载压力情况，进行30分钟的连续压力测试，记录系统登录事务交易的平均响应时间、成功率，应用服务器、数据库服务器和网络的各项性能指标，作为系统在实际使用情况中的性能表现依据。对失败交易发生时的各项指标数据进行分析，定位问题发生的原因。 | ||
| 用例名称 | 并发用户数 | 响应时间期望< | 备注 |
| 系统登录并发 | 100 | 5s | |
| 用例编号 | |||
| 验证功能 | |||
| 测试目的 | |||
| 前置条件 | |||
| 方法 | |||
| 用例名称 | 并发用户数 | 响应时间期望< | 备注 |
5 测试结果（图文）
5.1 聚合报告
情景一：（说明）
聚合报告图
情景二（说明）
聚合报告图
5.2 系统吞吐量
截图
5.3 资源占用率
最优负载条件下：
CPU使用率（图）
内存占用率（图）
磁盘使用率（图）
6 分析与建议
6.1 测试结论分析
1. 经过多次测试和数据报表分析，可以得出如下结论：
2.当总体并发用户数为450-500时，系统具有最优性能表现；当事务并发数超过500时，事务失败率整体上升，系统到达性能拐点。
3.多事务混合条件下，系统巅峰TPS在90左右，平均吞吐量在13-18/s。
4.在小压力条件下（10并发），最大事务响应时间为查询用户信息事务的2042毫秒，平均在600毫秒左右系统。整体事务微观响应速度较优。
5.满负载条件下，登录具有最佳的性能表现，平均响应时间为7000-12000毫秒；查询用户信息事务性能较差，平均响应时间在30000-40000区间。满负载条件下系统整体微观响应时间较差。查询用户接口由于其使用极为频繁，建议进行SQL效率调优
6.系统资源方面，内存占用率始终处于高位水平（90%以上），磁盘空间由于日志写入而不断被占用。
6.2 问题
1.测试过程中发现了如下显著问题：
2.加密验签功能并未生效-现阶段任何签名均可通过验签。属于功能性问题，不影响性能表现。
3.日志文件由于不断写入导致磁盘占满，建议调低系统日志级别，并做好定期日志备份。
4.内存占用处于高位水平，需要进一步探查原因。
扫一扫
1764
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
