上篇聊了单元测试，用GTest把每个模块单独测一遍。PID控制器没问题，里程计逻辑没问题，路径规划算法也没问题。但把这些模块拼到一起，机器人跑起来就一定能正常工作吗？

现实往往不是这样。

模块A输出的数据类型和模块B期望的输入对不上，坐标系定义不一致导致数值差了个负号，时间戳没对齐让滤波器直接发散。这些问题单元测试根本抓不到，因为单元测试只关心单个模块内部的逻辑，不关心模块之间怎么协作。

集成测试干的就是这件事：把模块拼起来，验证接口处的行为是否正确。

集成测试的三层模型

机器人软件系统通常可以分成三层：感知层、决策层、执行层。感知层处理传感器数据，输出环境信息；决策层做路径规划、任务调度；执行层负责控制电机、输出力矩。

集成测试也按这三层来组织。

感知-决策集成：把感知模块的输出喂给决策模块，验证决策模块能不能正确理解环境信息。比如激光雷达扫描出障碍物点云，路径规划器能不能正确识别并绕开。

决策-执行集成：决策模块输出一条轨迹，执行模块能不能跟踪上。轨迹的速度、加速度有没有超出执行层的物理极限。

端到端集成：从传感器原始数据进去，到电机控制指令出来，整个链路跑通。这是最接近真实场景的测试。

集成测试中最常见的坑

做过几个机器人项目之后，你会发现集成测试暴露的bug类型非常集中。

坐标系不匹配是最经典的。模块A输出的是body坐标系下的速度，模块B期望的是world坐标系。数值本身没问题，坐标系搞反了，机器人就往反方向跑。这种bug在单元测试里根本不会出现，因为每个模块单独测的时候坐标系都是自洽的。

时间戳问题也很头疼。激光雷达一帧扫描耗时100ms，这100ms里机器人已经移动了一段距离。如果点云数据没有做运动补偿，和IMU数据融合的时候就会出现明显的位置跳变。集成测试要验证的就是这种跨模块的时间同步问题。

数据频率不一致是另一个高频问题。IMU跑200Hz，激光雷达跑10Hz，视觉跑30Hz。下游的融合模块如果简单地取最新值，高频传感器的数据会被大量浪费，低频传感器的延迟会被放大。集成测试要检查各模块的输出频率是否符合设计预期，以及下游模块的处理逻辑是否合理。

还有个容易忽略的是资源竞争。两个模块同时访问同一个串口读传感器数据，或者同时写同一个文件做日志记录。单元测试里每个模块单独跑没问题，集成到一起就开始丢数据、写乱。这类bug往往表现为偶发性错误，特别难复现。

ROS2项目中的集成测试实战

ROS2里做集成测试有个天然优势：节点之间的通信基于Topic/Service/Action，接口定义很清晰。你可以写一个测试节点，订阅某个Topic，验证收到的消息是否符合预期。

import rclpy
from geometry_msgs.msg import Twist

def test_cmd_vel_format(node):
    """验证路径规划器输出的速度指令格式正确"""
    received = []
    sub = node.create_subscription(
        Twist, '/cmd_vel',
        lambda msg: received.append(msg), 10)
    # 等待消息到达，超时5秒
    timeout = node.get_clock().now() + rclpy.duration.Duration(seconds=5)
    while len(received) == 0 and node.get_clock().now() < timeout:
        rclpy.spin_once(node, timeout_sec=0.1)
    assert len(received) > 0, "未收到cmd_vel消息"
    assert not math.isnan(received[0].linear.x), "线速度为NaN"

这种测试的关键是时间。单元测试不需要考虑时间，但集成测试必须处理消息延迟、超时、乱序这些现实问题。ROS2的launch_testing框架就是为这个设计的，它可以在一个launch文件里启动所有节点，然后运行测试脚本，最后清理环境。

接口契约测试

接口契约测试是集成测试的一种轻量级做法。核心思想是：每个模块对外声明自己的接口契约——输入什么格式、输出什么格式、在什么条件下保证什么行为。集成测试就是验证这些契约是否被遵守。

举个例子，你的里程计模块对外承诺：

• 输入：左右轮转速（float64，单位rad/s）
• 输出：位姿（x, y, theta），坐标系为odom
• 保证：输入为0时输出不变

测试的时候，你给里程计模块喂一组预设的转速数据，检查输出的位姿是否符合承诺。同时，你也要验证下游模块（比如EKF定位）是否正确理解了里程计输出的坐标系和数值范围。

契约测试的好处是：当某个模块内部实现改了，只要契约不变，其他模块的测试就不用改。这大大降低了维护成本。

数据管道集成测试

机器人系统里有一条很重要的数据管道：传感器数据采集→预处理→特征提取→融合定位。这条链路上任何一个环节出问题，最终定位结果就会偏。

集成测试要验证的是整条管道的数据流。做法是：录制一段真实场景的传感器数据（rosbag），然后离线回放，检查每个环节的输出是否在合理范围内。

# 录制测试数据
ros2 bag record -o test_bag /scan /imu/data /odom/raw

# 回放并运行测试
ros2 launch my_robot integration_test.launch.py \
    bag_path:=./test_bag \
    test_script:=test_localization_pipeline.py

这种测试的价值在于可重复性。同样的输入数据，每次跑出来的结果应该一致。如果某次改了代码之后结果偏了，说明改动引入了回归问题。实际项目中，我们维护了十几段不同场景的测试数据——直行、转弯、上下坡、室内外切换——覆盖了大部分典型工况。每次提交代码都要跑一遍，确保改动没有破坏已有功能。

面试追问

"集成测试和系统测试有什么区别？"集成测试关注模块间接口，系统测试关注整体功能是否满足需求。集成测试是开发团队自己做的，系统测试往往有QA团队参与。面试时把这两层的边界讲清楚，说明你对测试体系有全局理解。

"你们怎么处理集成测试的环境依赖？"用Docker容器化测试环境，保证每次CI跑的环境一致。传感器数据用录制的bag文件模拟，不依赖真实硬件。关键节点用mock节点替代，比如用一个mock激光雷达节点发布预录制的扫描数据。这样集成测试可以在任何一台Linux机器上跑，不需要接实际传感器。

"集成测试跑一次要多久？"好的集成测试应该控制在5分钟以内。如果太长了，说明测试粒度太粗或者数据量太大。可以按功能拆分成多个测试套件并行跑。我们当时的做法是把感知相关的集成测试和导航相关的集成测试分开，CI里并行执行，总时间控制在3分钟左右。

"集成测试发现问题怎么定位？"这是集成测试最大的痛点。单元测试失败了直接看代码就知道哪里错了，集成测试失败了只知道接口处行为不对，不知道是哪个模块的问题。解决思路是在接口处加日志，把每个模块的输入输出都记录下来，失败时回放日志定位问题模块。这也是为什么接口契约测试很重要——它帮你缩小了排查范围。

---

集成测试是单元测试和系统测试之间的桥梁。单元测试保证每块砖没问题，集成测试保证砖和砖之间砌得牢。跳过集成测试直接上系统测试，等于把问题留到最后才暴露——那时候修一个bug可能要改三个模块。

我见过太多团队在集成阶段翻车。单元测试全绿，信心满满地合代码，结果一上实车各种奇怪行为。查了两天发现是某个模块的输出单位从弧度改成了角度，下游模块完全不知道。这种问题如果在集成测试里就能抓到，修复成本可能只有十分钟。

下一篇聊仿真测试。用Gazebo搭建虚拟环境，在CI里自动跑仿真，这是比集成测试更进一步的验证手段——不光验证接口，还验证物理行为。

---

如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。 你的支持是我持续更新的最大动力。

「机器人软件开发面试·从入门到精通」连载系列 

上一篇：第327篇 单元测试实战——Google Test在机器人项目中的应用

下一篇预告：第329篇 仿真测试——Gazebo CI自动化验证

有任何问题欢迎评论区留言，我会尽量回复。