文章目录
- 一、执行测试脚本的测试机
- 1.1 单机执行
- 1.2 分布式执行
- 二、性能测试脚本执行
- 2.1 准备工作
- 2.1.1 并发用户数与事务响应
- 2.1.2 并发用户数与应用服务器性能
- 2.1.3 并发用户数与数据库性能
- 2.2 登录脚本
- 2.2.1 一个用户登录
- 2.2.2 模拟5个用户并发执行（重点）
- 2.2.3 模拟10个用户并发执行
- 三、总结
一、执行测试脚本的测试机
执行性能测试前，需要根据要模拟的业务负载量来选择适当的测试机
1.1 单机执行
- Windows环境： 操作界面化、 直观、 易上手， 但是软件占用机器资源较多， 导致资源使用率不高； 可支持并发较低。
- Linux环境： 命令行操作， 结果查看不太方便， 但资源利用率相对较高； 可支持较高并发。
1.2 分布式执行
- 如果单台测试机（无论windows或linux）都无法满足负载量要求时，需要使用分布式的方法，使用多台测试机一起来模拟特定负载量的业务
- JMeter工具支持分布式压测，即多台机器同时执行同一个脚本，然后统计结果。
二、性能测试脚本执行
- 根据测试用例 —> 执行测试脚本
- 测试用例中，按照之前预设的性能指标，每一个业务对应一个用例页。
- 先基准——>再负载——>再稳定性
- 一般实际工作中，一条测试用例，大约测试1-3分钟，测试3-5轮，取平均值，记录到测试用例中。
2.1 准备工作
2.1.1 并发用户数与事务响应
在测试计划中添加—>聚合报告
| Label | #样本 | 平均值 | 中位数 | 90%百分位 | 95%百分位 | 99%百分位 | 最小值 | 最大值 | 异常% | 吞吐量 | 接收KB/sec | 发送KB/sec |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 登录 | 404 | 365 | 367 | 412 | 432 | 453 | 104 | 518 | 0.0 | 13.4 | 6.11 | 3.12 |
| 总体 | 404 | 365 | 367 | 412 | 432 | 453 | 104 | 518 | 0.0 | 13.4 | 6.11 | 3.12 |
2.1.2 并发用户数与应用服务器性能
# 监控服务器的资源配置 1、在服务器安装 配合jmeter 监听的工具（ServerAgent程序 ） 2、用来监控服务端的性能的工具， 包括cpu、 内存、 磁盘、 网络等性能数据 3、linux运行 ./startAgent.sh （启动之后，窗口最小化，不要退出） 4、监听的是整个服务器，和业务没关系，在测试计划中添加： 线程组->监听器->jp@gc - PerfMon Metrics Collector2.1.3 并发用户数与数据库性能
- 本案例中，应用服务器和数据库服务器放在一起，存储在同一台主机，省略测试过程。
- 实际中，（假如）应用服务器和数据库服务器是分开的，要进行测试
2.2 登录脚本
2.2.1 一个用户登录
1、并发用户数与事务响应
2、并发用户数与应用服务器性能
- CPU、内存、磁盘都是：百分比
- 网络显示带宽，单位 B（字节）
2.2.2 模拟5个用户并发执行（重点）
- 从当前指标来看，5个用户并发时TPS为18.3，响应时间为271ms（满足需求<3s）；
- 由于响应时间在需求许可范围内，但TPS达到需要要求的TPS（20），因此需要进一步加大负载量测试系统性能
- 资源指标在里面先忽略（因当前虚拟机资源不足，未执行性能测试时内存使用率就已经达到80%）
2.2.3 模拟10个用户并发执行
- 当前系统的TPS为19.5（接近20），响应时间为506ms（满足需求<3s）
- 问题是：资源使用率中CPU达到96%，内存达到82%，说明当前系统资源不足，需要提升系统配置。
三、总结
1、单接口的性能测试用例执行
- 构造性能测试时需要的数据
- 修改性能测试，以满足大量用户的并发执行
- 配置性能测试时的监控 —— 聚合报告 和 PerForm组件
- 分别模拟5/10/30/50/100用户，逐步增加并发量，记录性能指标
2、多接口组合（业务流程）的性能测试用例执行
- 当前业务流程中每个接口都达到性能要求后，再进行多接口组合测试
3、稳定性的性能测试用例执行
- 当单接口和业务流程的性能指标都达标后，再进行稳定性测试
- 稳定性测试：模拟真实用户的业务场景，进行长时间测试
- 通过运营统计获取真实用户的业务模拟（系统最常见的操作有哪些，每个操作的用户量比例是多少）
- 在Jmeter中按照运营数据设置线程组（用户操作）的用户量
- 按照要求设置运行时间，执行稳定性并监控性能指标
