Android错误测试并不是简单地在真机上点几下、看看有没有崩溃。它需要关注的错误形态比想象中多：Java或Kotlin层未捕获异常、Native崩溃、ANR、内存泄漏导致的OOM、权限拒绝后的静默失败、异步回调中的逻辑错误，以及不同厂商ROM上的兼容性问题。测试阶段如果只覆盖正常路径，很多错误要到线上才会爆发。把错误路径当成一等公民来设计用例，才能在发版前拦住大部分可预测的异常。
一、Android错误类型与常见触发场景
Android平台上的错误可以粗略分成四类。第一类是未捕获异常，常见的有NullPointerException、IndexOutOfBoundsException、ClassCastException、NumberFormatException。它们通常出现在空值判断缺失、集合越界、类型强转错误、字符串转数字失败等场景。第二类是ANR，主线程执行耗时操作超过系统阈值就会触发，比如在onCreate里直接做网络请求或大量文件读写。第三类是内存问题，包括OutOfMemoryError、内存泄漏、频繁GC导致的卡顿。第四类是静默失败，比如权限被拒绝后代码仍然继续执行，导致功能缺失但不崩溃，这类错误最容易被忽略。
以一个简单的计算器类为例，除数为零、空字符串转数字、列表越界都能触发不同类型的异常。代码中如果没有显式捕获，这些异常会沿着调用栈向上抛出，最终导致应用崩溃。测试人员需要把这些边界条件枚举出来，而不是只测正常输入。下面的Java代码展示了几个典型触发点：
public class ErrorTrigger {
public int divide(int a, int b) {
return a / b; // b为0时抛出ArithmeticException
}
public int parse(String input) {
return Integer.parseInt(input); // input为null或非法格式时抛出NumberFormatException
}
public String getItem(List<String> list, int index) {
return list.get(index); // index越界时抛出IndexOutOfBoundsException
}
}
除了Java层异常，ANR同样需要重点测试。主线程被阻塞超过5秒会触发ANR，典型原因是主线程做了文件解析、数据库操作或者同步网络请求。测试时可以通过StrictMode检测主线程中的磁盘读写和网络访问，也可以使用adb命令模拟ANR场景。内存泄漏则常见于Activity被销毁后仍被静态对象、Handler、匿名内部类持有引用。泄漏累积到一定阈值后，应用在低端设备上更容易出现OOM。错误测试必须把这些场景纳入用例库。
二、错误测试的自动化实践与用例设计
手工测试无法覆盖所有异常路径，自动化测试是错误测试的基础。JUnit和Robolectric适合做本地单元测试，前者验证纯Java逻辑，后者可以在JVM上模拟Android环境。Espresso则用于UI层面的交互测试，验证界面元素是否存在、点击后的状态变化。针对错误场景，单元测试应当显式断言异常被抛出，并验证异常类型和消息。
以Robolectric为例，可以在本地模拟Activity生命周期，验证在onDestroy后释放资源、取消注册监听器。错误测试用例要覆盖空值、越界、非法参数、异步回调失败等边界条件。例如使用Mockito模拟一个回调接口，让它在特定条件下返回失败，观察业务层是否正确处理错误分支。下面的测试代码展示了如何用JUnit断言除零异常：
import org.junit.Test;
import static org.junit.Assert.assertThrows;
public class ErrorTriggerTest {
@Test
public void divideByZeroShouldThrowArithmeticException() {
ErrorTrigger trigger = new ErrorTrigger();
assertThrows(ArithmeticException.class, () -> trigger.divide(10, 0));
}
@Test
public void parseInvalidInputShouldThrowNumberFormatException() {
ErrorTrigger trigger = new ErrorTrigger();
assertThrows(NumberFormatException.class, () -> trigger.parse("abc"));
}
}
Espresso测试可以验证错误提示是否正确显示。例如输入非法数据后，界面是否弹出错误提示而不是直接崩溃。自动化测试需要和CI流水线结合，每次提交代码后自动运行本地测试和仪器化测试。这样可以把错误拦截在合并阶段，减少发版前的回归压力。测试用例设计上，建议采用等价类划分和边界值分析，把空字符串、零、负数、超大数值、超长字符串、特殊字符等输入都纳入测试矩阵。
对于异步错误和并发问题，单次测试很难稳定复现。可以引入压力测试工具，比如使用Monkey随机生成事件，配合日志收集系统观察崩溃点。Robolectric还可以模拟不同SDK版本和屏幕尺寸，提前发现兼容性错误。错误测试的自动化程度越高，线上遗漏异常的概率就越低。
三、全局异常捕获与崩溃日志分析
测试阶段能拦截一部分错误，但线上环境复杂，全局异常捕获仍然是兜底手段。Android应用可以通过实现Thread.UncaughtExceptionHandler接口，在应用崩溃前收集线程信息、堆栈轨迹、设备型号、系统版本、前后台状态等现场数据。这些数据对于定位错误至关重要。自定义异常处理器通常会在应用入口处注册，并在捕获异常后保存日志到本地文件或直接上报到服务端。
public class CrashHandler implements Thread.UncaughtExceptionHandler {
private Thread.UncaughtExceptionHandler defaultHandler;
public void init(Context context) {
defaultHandler = Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler(this);
}
@Override
public void uncaughtException(Thread t, Throwable e) {
String log = Log.getStackTraceString(e);
// 将log写入文件或上报到服务器
if (defaultHandler != null) {
defaultHandler.uncaughtException(t, e);
}
}
}
崩溃日志分析需要关注几个关键字段：异常类型、堆栈信息的第一行、发生时间、应用版本、设备型号和系统版本。通过聚合相同签名，可以快速判断某个崩溃是首次出现还是重复发生，以及影响面有多大。ANR日志则通常需要分析traces.txt文件，查看主线程当时阻塞在哪个调用。内存泄漏可以使用LeakCanary等工具生成引用链，定位持有者。
Native崩溃比Java崩溃更棘手，因为堆栈信息是Native层的，需要结合NDK工具链和addr2line还原符号。对于不具备Native调试能力的团队，可以考虑接入成熟的崩溃监控服务，它们会自动收集、聚合、告警。监控服务还能记录崩溃前的用户操作路径，帮助复现。测试人员应当定期登录监控后台，回顾线上错误趋势，把高频崩溃回归到测试用例中。
四、错误回归与监控链路设计
错误测试不是一次性的工作，而是一个持续回归的过程。每次修复一个线上崩溃，都需要同步添加对应的自动化测试用例，避免后续迭代再次引入相同错误。回归用例可以放在独立的错误测试套件中，与正常功能测试并行运行。对于难以自动化的场景，比如特定机型上的渲染错误，可以维护一份手工测试清单，在发版前进行定向验证。
监控链路的完整设计包括客户端采集、服务端存储、聚合分析、告警通知。客户端采集要控制数据量，避免上传过大日志影响性能。服务端需要支持按版本、机型、地域、错误类型筛选。告警策略可以设置崩溃率阈值，超过阈值立即通知相关人员。测试团队需要关注发版后的前24小时数据，观察崩溃率是否异常上升。
错误测试的最终目标不是消灭所有异常，而是把错误控制在可接受范围内，并保证关键路径稳定。通过分类梳理、自动化测试、全局捕获、监控回归四个环节，可以形成一条完整的错误防线。测试人员需要和开发、运维协作，把错误数据反馈到需求评审和代码评审中，从源头减少错误引入。
Android错误测试异常捕获崩溃日志修改时间：2026-09-27 01:53:25