着陆器测试和普通Android应用测试最大的不同，在于每一帧物理状态都会影响下一帧输入的有效性。如果只把测试目标定义为最终不坠毁，往往会放过大量中间缺陷：例如侧倾角度已经超过安全阈值但被后续反向推力救回，或者燃料消耗异常却因为成功着陆而没有被发现。本文以Android Lander类模拟应用为例，讨论如何把姿态控制、碰撞检测和输入时序拆成可独立验证的单元。
姿态控制与物理状态的增量断言
姿态控制的测试不能只比较初始状态和结束状态，需要把每次物理步进后的角度、角速度、线性速度放进断言链中。着陆器通常有一个主推进器和若干姿态调节喷口，每次点按会改变角加速度，再通过积分更新角速度与角度。在单元测试中可以把时间步长固定为16毫秒，模拟60帧设备，然后验证连续三帧左转输入后角速度是否单调递增，角度是否落在预期区间。
这样做的好处是能够发现积分顺序错误。比如有的实现先更新位置再更新速度，有的先更新旋转再计算推力分量，最终着陆位置可能相差几米。测试里可以把力分解和运动学积分拆开，用一个纯JVM测试验证姿态更新函数，再通过参数化用例传入不同初始角速度。下面是一个简化的姿态更新测试，它断言左侧喷口开启后角速度不会反向，并且燃料消耗量被正确累加。
// 姿态更新单元测试
@Test
public void leftThrusterShouldIncreaseAngularVelocity() {
LanderPhysics physics = new LanderPhysics(0.0f, 0.0f, 100.0f);
physics.applyLeftThruster(0.016f);
physics.applyLeftThruster(0.016f);
float angularVelocity = physics.getAngularVelocity();
assertTrue(angularVelocity > 0.0f);
assertEquals(2 * 0.8f, physics.getFuelConsumed(), 0.001f);
}
上面代码中假设喷口每次消耗0.8单位燃料，角速度增量由力矩除以转动惯量得出。实际项目里可以把这些常量提取到配置对象，让测试覆盖不同机型密度和惯性张量。还要注意浮点比较的容差，Android设备上的FPU行为基本一致，但模拟器和真机在低功耗模式下可能有精度差异，建议用delta而不是完全相等。
碰撞检测与地形交互的边界用例
着陆器测试的另一半风险集中在地形碰撞。平坦地面上的成功着陆很容易通过，真正的缺陷往往出现在斜坡顶点、平台边缘和V形沟槽。把地形抽象成一系列线段后，碰撞检测需要同时处理顶点接触和边接触，否则高速下落时可能穿模。测试用例应当包含三种典型地形：正斜率、负斜率和极窄平台，并分别验证接触法线方向是否正确、恢复系数是否在预期范围内。
边界用例的价值在于暴露离散碰撞检测的漏判。如果物理步长过大，着陆器在两帧之间从平台上方直接移动到下方，就会完全绕过碰撞。Android上低帧率设备更容易触发这种问题。测试时可以在16毫秒步长之外增加33毫秒和50毫秒两种慢帧率场景，通过连续模拟多次步进，断言着陆器要么停在平台表面，要么触发碰撞回调，绝不会出现位置在平台下方却没有任何接触记录的情况。
另一个常见错误是碰撞后姿态被重置。例如着陆器以20度倾角接触地面，开发者只修正了垂直速度，却把角速度一并清零，导致原本可以靠侧向滑动卸力的过程变得僵硬。测试要分别验证切向速度和法向速度的处理：法向速度按恢复系数衰减，切向速度则根据摩擦系数逐步减小，而不是直接归零。下面这段测试模拟斜坡着陆，并确认碰撞后角速度没有被错误清零。
// 斜坡碰撞测试
@Test
public void slopeLandingShouldKeepAngularVelocity() {
Terrain terrain = new SlopeTerrain(30.0f);
LanderPhysics lander = new LanderPhysics(5.0f, 2.0f, 0.0f);
lander.setAngularVelocity(1.5f);
lander.step(0.016f);
assertTrue(lander.isTouchingGround());
assertTrue(lander.getAngularVelocity() > 0.0f);
assertTrue(lander.getVerticalSpeed() < 0.5f);
}
地形数据本身也应该被纳入测试。如果地形段之间角度超过90度，物理引擎可能生成错误法线，测试可以在加载阶段就检查相邻线段夹角，避免运行时出现明显不合理的反弹方向。
自动化测试框架整合与设备差异处理
把着陆器的物理逻辑和Android视图层解耦后，自动化测试可以分成三层：纯JVM单元测试负责姿态更新与碰撞数学；Robolectric或仪器测试负责Activity重建后的状态恢复；真机测试负责触控采样率和传感器延迟。三层之间不要共享太多状态，否则一个测试的失败会掩盖另一个测试的缺陷。建议引入接口封装加速度计和陀螺仪，方便在测试中注入固定传感器数据。
设备差异对比着陆器测试尤其重要。不同厂商的传感器采样率从50Hz到200Hz不等，触控事件也可能带有不同抖动。测试套件里应该包含对输入时间戳的校验，确保上一帧输入和下一帧输入之间不会因为系统动画或GC停顿导致超过100毫秒的空档。如果出现空档，物理引擎可以按固定步长补帧，但补帧逻辑本身也需要测试，避免在后台恢复后突然产生一次超大推力。
最后可以把测试结果接入持续集成，但不建议在CI上运行完整真机矩阵，成本太高。比较务实的做法是每次提交先跑物理逻辑单测和地形碰撞参数化测试，夜间再跑几台不同Android版本的真机。对失败用例要保留完整日志，包括帧率、传感器原始值和随机种子。着陆器这种强物理应用一旦出现偶发穿模，没有随机种子和输入回放几乎无法复现，所以测试设计阶段就应该把可重复性作为硬性要求。
Android Lander着陆器测试物理引擎修改时间：2026-10-05 01:30:11