一、核心概念辨析：性能测试 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、内存、电量、流量）和复杂网络环境的深度关注。
