一、核心概念辨析:性能测试 vs. 压力测试
首先,我们必须清晰理解这两者的目标和区别:
| 测试类型 | 主要目标 | 要回答的问题 | 常用工具 |
|---|---|---|---|
| 性能测试 | 评估系统在特定负载下的表现。 | 在100个并发用户下,页面的平均响应时间是多少? | JMeter, LoadRunner, Gatling, Lighthouse |
| 压力测试 | 评估系统在极限或超负荷负载下的稳定性和恢复能力。 | 当并发用户数达到2000时,系统会崩溃吗?出错率是多少?停止压力后能自动恢复吗? | JMeter, LoadRunner, Gatling, Locust |
二、Web端性能与压力测试
Web端测试的核心是服务器、网络和前端资源。
1. 前端性能测试(渲染性能)
-
目标:评估用户在浏览器中感受到的流畅度。
-
方法与时序分解:
一次完整的页面加载包含了从网络请求到界面渲染的多个关键阶段,其核心时序流程如下:

-
工具与方法:
-
Chrome DevTools:使用 Lighthouse 生成全面的性能报告;使用 Performance 面板录制并分析运行时性能,查看帧率、布局重排等。
-
WebPageTest:一个强大的在线工具,可以从全球多个地点、不同浏览器和网络条件下测试你的网站,并提供丰富的性能指标和视频录像。
-
2. 后端性能与压力测试(服务器性能)
-
目标:评估服务器、数据库和应用逻辑的承载能力。
-
如何进行(以JMeter为例):
-
创建测试计划:
-
线程组:模拟并发用户。设置线程数(用户数)、循环次数等。
-
HTTP请求采样器:定义要测试的API接口或网页URL、请求方法、参数等。
-
-
配置测试数据:
-
使用 CSV Data Set Config 来参数化请求,例如模拟不同用户登录。
-
-
添加监听器:
-
添加 查看结果树、聚合报告、响应时间图 等监听器来查看结果。
-
-
执行与分析:
-
从低并发(如50用户)开始,逐步增加,观察响应时间、吞吐量 和错误率的变化。
-
关键性能指标:
-
响应时间:P95或P99值(95%或99%的用户响应时间)比平均值更有意义。
-
吞吐量:每秒处理的请求数(QPS/RPS)。
-
错误率:失败请求的百分比。
-
-
-
进行压力测试:
-
持续增加并发用户数,直到系统的吞吐量不再增长(甚至下降)且错误率显著上升,此时便找到了系统的性能瓶颈和极限。
-
-
三、App端性能与压力测试
App端测试在关注服务端接口性能的同时,更需关注移动设备本身的资源消耗和系统特性。
1. App端性能测试要点
| 测试维度 | 测试内容与工具 |
|---|---|
| CPU & 内存 | 工具:Android Studio Profiler, Xcode Instruments, PerfDog。 • 测试各种操作场景下(启动、页面切换、复杂动画)的CPU和内存占用,检查是否存在内存泄漏。 |
| 流量 & 电量 | 工具:Android Studio Profiler, 手机系统自带监控。 • 测试App在典型使用场景下的流量消耗。 • 监控App的电量消耗,排除因频繁网络请求、GPS使用、Wake Lock使用不当导致的耗电问题。 |
| 启动时间 | 工具:adb命令, Xcode Metrics。 • 冷启动:进程被杀后,从点击图标到第一帧完全绘制的耗时。 • 热启动:App仍在后台,再次切换到前台的耗时。 |
| 流畅度 | 工具:PerfDog, 开发者选项中的“GPU呈现模式分析”。 • 关注 FPS,并分析掉帧场景。 • 检查是否存在过度绘制。 |
| 弱网络测试 | 工具:Charles, Fiddler, 硬件网络模拟器。 • 模拟2G/3G、高延迟、高丢包等弱网环境,测试App的响应、超时处理和容错机制。 |
2. App端压力测试
-
目标:测试App在长时间、高负荷运行下的稳定性,以及服务端接口在App端高并发调用下的表现。
-
方法:
-
Monkey / MonkeyRunner (Android):
-
系统自带工具,可模拟用户随机操作(点击、滑动等),对App进行“乱按”式的压力测试,常用于发现崩溃和无响应问题。
-
-
Maxim (Android):
-
一个更智能、高效的Monkey替代品,支持多种测试策略。
-
-
服务端接口压测:
-
方法同Web端。通过抓包(Burp/Charles)获取App发出的API请求,然后在JMeter中重构这些请求,对服务端进行大规模并发压测。这是发现服务端瓶颈最有效的方式。
-
-
四、通用测试流程
一次完整的性能/压力测试,无论Web或App,都应遵循以下科学流程:
-
需求分析与目标制定:
-
明确性能指标:例如“首页P95响应时间<2秒”、“支持1000用户并发登录”。
-
确定测试范围:测试哪些核心业务场景(如登录、下单、支付)。
-
-
测试环境准备:
-
环境应尽可能与生产环境一致(硬件、软件、网络配置)。
-
-
测试脚本与场景设计:
-
录制或编写脚本,模拟用户真实操作。思考时间 和 ** pacing**(步调时间)的设置对模拟真实流量至关重要。
-
-
执行测试与监控:
-
从基准测试开始,逐步增加负载。
-
全程监控:不仅要监控性能测试工具的数据,更要监控服务器的CPU、内存、磁盘I/O、网络带宽、数据库连接数和应用日志。
-
-
结果分析与定位瓶颈:
-
分析测试报告,确定性能瓶颈点(是应用代码、数据库、缓存、还是网络?)。
-
使用 APM工具(如AppDynamics, ARMS)可以帮助快速定位代码级瓶颈。
-
-
优化与回归测试:
-
开发团队针对瓶颈进行优化。
-
性能测试团队进行回归测试,验证优化效果。
-
总结:
-
Web端:侧重于服务器响应、网络传输和前端资源加载。
-
App端:在服务端基础上,增加了对移动设备有限资源(CPU、内存、电量、流量)和复杂网络环境的深度关注。
浙公网安备 33010602011771号