自动化内存压力测试是可控、可观察、能回溯的低内存状态模拟，需区分系统级（如OOM Killer）与应用级（如LMK杀进程）目标，结合专用工具、实时监控与结构化验证路径。
自动化内存压力测试不是简单地把内存“塞满”，而是有节奏、可观察、能回溯地制造可控的低内存状态，让系统和应用在临界点附近暴露真实行为。
明确目标：区分系统级与应用级压力
系统级压力（如 Linux 的 OOM Killer 触发、swap 频繁交换）关注内核内存管理是否稳定；应用级压力（如 Android 的 LMK 杀进程、Java 堆 OOM、Native 内存泄漏）聚焦 App 在资源紧张时能否优雅降级。两者需分开设计、协同验证。
- Linux 服务器场景：用 stress 模拟多进程持续驻留内存，配合 vmstat 1 和 dmesg -T | tail -20 实时捕获 OOM 日志
- Android 真机测试：用 Fill RAM 工具渐进式填充可用 RAM，避开系统级杀进程，专注观察目标 App 的 Activity 重建、Service 被终止、Bitmap 加载失败等行为
- Zephyr 嵌入式系统：通过 SLAB 分配器主动耗尽特定内存池，验证任务调度是否退化、中断响应是否延迟，而非盲目填满整个 RAM
选择合适工具并配置关键参数
工具选错或参数失当，容易导致测试失效或误判。重点不是“压得多”，而是“压得准”。
-
stress：用
--vm-hang让内存长期驻留（如--vm-hang 60），避免页回收太快；禁用 swap 可用swapoff -a配合 tmpfs 占用，更贴近物理内存耗尽场景 -
memtester：适用于硬件级稳定性验证，命令如
memtester 512M 3表示循环测试 512MB 内存 3 次，适合部署在 CI 流程中做回归检查 - Android 自研工具或 ADB 脚本：通过
adb shell am startservice启动内存填充服务，结合dumpsys meminfo <package>定期采集堆内存、Native Heap、Graphics 内存三类指标
必须配套实时监控与日志捕获
没有监控的压力测试等于盲测。关键不是看“压没压上去”，而是看“系统和 App 怎么反应”。
- 基础层：每秒执行
free -h或读取/proc/meminfo中 MemAvailable、SwapFree、Buffers 字段 - 进程层：用
ps aux --sort=-%mem | head -10或top -o %MEM定位异常内存增长进程；Android 上用adb logcat | grep -i "lowmemory\|kill\|oom"捕获 LMK/OOM 相关日志 - 应用层：在 App 内埋点监听
ComponentCallbacks2.onTrimMemory()回调级别（如 TRIM_MEMORY_RUNNING_MODERATE），验证缓存清理逻辑是否触发
设计可重复、可判定的验证路径
一次成功的自动化测试，必须定义清晰的“通过标准”和“失败信号”，不能只靠人工看日志。
- 例如 Android 测试脚本可设定：当 MemAvailable < 200MB 持续 10 秒后，目标 App 未发生 ANR、未抛出 OutOfMemoryError、关键 Service 仍处于 STARTED 状态，则视为通过
- Linux 服务测试可断言：stress 运行期间，dmesg 输出无 “Killed process” 记录，且 vmstat 的 so（swap out）值始终为 0
- 所有测试应输出结构化结果（如 JSON），包含时间戳、内存水位、关键进程状态、错误日志摘要，便于 CI/CD 自动归档与比对
