稳定性是Android产品质量的底线。功能再多，如果系统动不动就死机、重启、卡死，用户体验会直接崩塌。而这类稳定性问题往往具有偶发性，普通的功能测试很难覆盖到。Android Faults故障测试的核心思路是：与其被动等待故障发生，不如主动制造故障，让系统在最恶劣的条件下运行，从而尽早暴露缺陷。本文将围绕故障测试的原理、常用注入手段以及日志分析方法展开，带你搭建一套可落地的稳定性验证方案。
一、故障测试的基本原理与适用场景
故障测试，英文常称Fault Injection（故障注入），本质上是一种加速失效的验证方法。一个运行正常的系统，其内部往往隐藏着未被触发的错误路径，比如某个服务没有处理空指针、某个驱动没有做异常兜底。这些错误路径平时不执行，一旦遇到极端条件，比如内存耗尽、存储器写入失败、进程被系统强制杀死，就会导致崩溃甚至整机重启。
故障测试的做法就是在受控环境下人为触发这些极端条件。举个典型例子：通过工具持续占用内存，把可用内存压到阈值以下，迫使Android的低内存查杀机制（LMK）启动，此时就能验证各个应用是否正确处理了onTrimMemory回调、被杀后是否能正确恢复现场。如果某个应用在恢复时出现数据丢失或界面错乱，就说明其状态保存逻辑有缺陷。
常见的适用场景包括：系统级长稳测试前的加压验证、关键版本发布前的回归、驱动或HAL层的异常处理验证、以及厂商定制功能的压力测试。需要注意的是，故障测试与常规的压力测试不同：压力测试强调高负载下的性能表现，故障测试则强调异常条件下的存活与恢复能力，两者互补，不能互相替代。
二、常用故障注入手段与工具实战
Android平台下有多种成熟的故障注入方式，按注入对象可以分为内存故障、进程故障、IO故障、内核故障四类。下面逐一介绍。
1. 内存压力注入
内存是最常见的故障源。常用工具有memtester、stress-ng，以及Android自带的am memory相关命令。stress-ng功能全面，推荐优先使用：
# 持续占用2GB内存，运行10分钟 adb shell stress-ng --vm 4 --vm-bytes 512M --timeout 600s # 混合压力：内存 + CPU + IO 同时施压 adb shell stress-ng --vm 2 --vm-bytes 1G --cpu 4 --io 2 --timeout 1800s
其中--vm指定虚拟内存压力进程数，--vm-bytes指定每个进程占用的内存量。测试期间建议通过dumpsys meminfo持续观察各进程内存变化，重点关注是否有进程被LMK查杀后无法恢复。
2. 进程故障注入
进程级故障主要通过monkey和手动kill来模拟。monkey是Android官方提供的稳定性利器，它向系统发送伪随机的用户事件流：
# 一万次随机事件，允许产生崩溃，指定包名 adb shell monkey -p com.example.app --throttle 300 -s 100 \ --ignore-crashes --ignore-timeouts -v -v 10000
除了monkey，还可以周期性地强制杀死关键进程，验证系统守护机制：
# 循环杀死system_server，验证系统是否能够自动重启恢复 while true; do adb shell kill $(adb shell pidof system_server) sleep 30 done
这种做法比较激进，适合在开发阶段的工程机上执行，不适合在用户量产版本上使用，否则可能触发不可恢复的故障。
3. IO与存储故障注入
存储故障包括写入失败、磁盘满、IO超时等。可以用dd或fio模拟磁盘空间耗尽：
# 向data分区写入大文件直到空间耗尽 adb shell dd if=/dev/zero of=/data/local/tmp/fill.img bs=100M count=200
写入前务必记录分区剩余空间，测试完成后及时删除填充文件。此外，内核层面可以使用fault-inject接口，通过debugfs配置/sys/kernel/debug/fail_page_alloc等节点，让内核按概率注入内存分配失败，这对验证驱动异常处理逻辑非常有用，但需要内核开启CONFIG_FAULT_INJECTION选项。
三、故障日志分析与结果判定
故障注入只是手段，能从日志中定位问题才是测试的核心产出。Android系统中与崩溃相关的日志主要有三类，需要建立固定的采集流程。
第一类是logcat中的应用崩溃信息。搜索FATAL EXCEPTION关键字即可定位Java层崩溃堆栈，重点关注崩溃所在的线程和异常类型。第二类是tombstone文件，位于/data/tombstones/目录，记录Native层崩溃的寄存器状态、调用栈和信号信息，配合带符号的so库可以还原出准确的崩溃位置。第三类是kernel panic日志，如果整机重启且logcat无异常，就要检查/proc/last_kmsg或pstore中的/sys/fs/pstore/console-ramoops内容，判断是否发生了内核崩溃。
一个实用的判定标准是分级评估：轻微问题（应用闪退但可自动重启）、一般问题（系统服务崩溃导致功能不可用）、严重问题（系统重启、死机、无法开机）。测试报告中应记录故障注入的方式、持续时间、出现问题的频率以及对应日志，便于开发复现和归因。
四、搭建持续化稳定性测试流程的建议
单次的故障测试价值有限，更推荐把它纳入持续集成体系。可以每天夜间在固定批次的工程机上自动执行一轮组合故障注入，白天由测试人员分析前一晚产生的异常日志。脚本层面使用Python封装adb命令即可实现调度，配合Jenkins或内部测试平台做任务分发。
在用例设计上，建议遵循从单一故障到组合故障的递进原则：先单独验证内存不足、进程被杀等单一场景，确认系统通过后再叠加组合，比如高内存压力加monkey事件流的场景。每次注入之间保留足够的恢复观察期，比如十分钟，让系统有机会自愈，这样测出的问题才更接近真实用户场景。
最后要强调测试环境的纪律性：故障测试期间不要手动干预设备，不要安装无关应用，保持日志采集进程常驻。只有环境可控，产出的崩溃日志才有分析价值。坚持执行一段时间后，你会发现那些平时神出鬼没的偶现问题，大多能在故障测试中稳定复现，稳定性问题的治理也就从被动救火转变为主动预防了。
Android Faults故障测试稳定性测试修改时间：2026-09-05 14:08:43