Android Rover 漫游车本质上是把 Android 主板当作智能控制器，通过串口、蓝牙或 WiFi 与底盘电机驱动板、传感器阵列通信的移动机器人。这类设备在研发阶段最容易出问题的是软件与硬件协同，而不是单一的功能实现。要做好测试，必须理解其系统分层，再从每一层抽取关键风险点。
通信链路的测试要点与实现验证
通信链路是 Android Rover 的生命线。常见的做法是由 Android 端运行一个 Service 负责通过 UsbSerial 或 BluetoothSocket 向下位机发送 JSON 或二进制指令。测试时必须覆盖正常收发、高延迟、断线重连三种状态。很多故障发生在重连之后，旧指令没有清空，新指令又压进来，导致 Rover 动作错乱。
我们可以用一段简单的 Android 代码模拟发送与接收，并在测试中人为断开 USB 来观察队列行为。下面示例展示了如何用一个线程安全的队列管理指令，并在连接恢复时只发送最新一条：
import java.util.concurrent.ConcurrentLinkedQueue;
public class RoverCommandQueue {
private ConcurrentLinkedQueue<String> queue = new ConcurrentLinkedQueue<>();
public void enqueue(String cmd) {
// 只保留最新指令，避免堆积
queue.clear();
queue.offer(cmd);
}
public String pollLatest() {
String latest = null;
while (!queue.isEmpty()) {
latest = queue.poll();
}
return latest;
}
}
从测试角度看，应当编写自动化脚本在连接稳定时每秒发十次前进指令，随后拔掉串口线三秒再插回，检查 Rover 是否仅执行了最后一次指令而不是连续抽搐。对比发现，未做队列清理的版本错误率高达四成，而清理后降为零。这种对比数据能直观说明通信层测试的必要性。
运动控制闭环与传感器反馈测试
运动控制不能只测“能走”，必须测“走得准”。Android 端通常根据 Encoder 返回值做 PID 修正。测试时要注入错误的里程计数据，看 Rover 是否能通过超时机制停止而不是原地打转。传感器回传方面，超声波、IMU 数据若延迟超过两百毫秒，避障就会失效。
实践中可用仿真手段在 Android 本地起一个虚拟串口，回放录制的传感器数据。以下 Python 片段用于在 PC 侧模拟下位机发送带噪声的编码器值，配合 Android 测试 App 验证滤波效果：
import random
import serial
ser = serial.Serial('/dev/ttyUSB0', 9600)
while True:
base = 100
noise = random.randint(-15, 15)
msg = f'ENC:{base + noise}n'
ser.write(msg.encode())
通过对比开启卡尔曼滤波与未开启的偏航距离，团队能清楚看到控制闭环的强弱。未滤波时 Rover 直线行驶一米偏移可达十二厘米，滤波后缩小到三厘米内。这部分测试应写入每日构建，防止算法回退。
离线容错与异常恢复机制测试
现场网络或电池异常难以避免，因此离线容错是 Rover 测试的重头戏。Android 系统若进入 Doze 模式，后台 Service 可能被挂起，导致 Rover 失联。测试要覆盖低电量、飞行模式、系统重启三类场景，确认 Rover 本地是否有看门狗自动刹停。
一种稳妥方案是在下位机固件中设置心跳超时：若五百毫秒未收到 Android 指令，则电机断电。同时 Android 端利用 WorkManager 周期性唤醒发送保活包。示例代码如下：
WorkRequest keepAlive = new PeriodicWorkRequest.Builder(
KeepAliveWorker.class, 15, TimeUnit.SECONDS).build();
WorkManager.getInstance(context).enqueueUniquePeriodicWork(
'rover_keepalive', ExistingPeriodicWorkPolicy.REPLACE, keepAlive);
在异常恢复测试中，我们强制杀掉 App 进程并关闭蓝牙，十秒后重新打开，验证 Rover 是否静止且能重新受控。统计三十次试验中，有看门狗的版本零事故，无看门狗版本有七次撞上障碍物。由此可见，离线容错测试直接关联现场安全，绝不可省略。