上篇聊了单元测试用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(seconds5) while len(received) 0 and node.get_clock().now() timeout: rclpy.spin_once(node, timeout_sec0.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自动化验证有任何问题欢迎评论区留言我会尽量回复。