干扫地机器人测试这行有些年头了每年经手的样机少说也有几十台。很多人一听到“扫地机器人测试”第一反应往往都是“这不是放地上让它自己跑两圈就行了吗”。真不是这么回事。一台扫地机器人要交付到用户手里背后要过的关卡比大多数人想象中多得多硬件从电机、传感器到电池得逐项验证软件从SLAM算法到App交互得反复回归最后还得把它扔进各种真实得不能再真实的场景里看它会不会在黑色地毯上一头撞上落地灯会不会被儿童玩具的电源线缠住拖行会不会因为一道门槛把自己卡在卫生间里出不来。这篇内容我就把扫地机器人软硬件测试和场景化测试这套东西按我实际做项目时的思路从头到尾捋一遍包括测试体系怎么搭、每一步在测什么、为什么这么测以及那些文档里不怎么会写的坑。无论你是刚入行的测试工程师、想给自家产品补全测试体系的团队负责人还是单纯好奇扫地机器人为什么偶尔“犯傻”的普通用户应该都能找到点有用的东西。1. 扫地机器人测试的整体设计思路——为什么“软硬件并举、场景为王”1.1 先从一台扫地机器人的组成聊起要聊测试得先搞清楚被测对象是什么。一台主流的扫地机器人拆开来看硬件层面大致包括激光雷达LDS或视觉传感器VSLAM方案、ToF/红外传感器、陀螺仪和加速度计IMU、超声波及碰撞传感器、驱动轮电机、边刷电机、滚刷电机、尘盒与水箱组件、电池及充电管理模块还有作为大脑的SoC主控芯片。这些硬件背后对应的是复杂的软件系统感知与SLAM建图算法、路径规划与运动控制算法、传感器数据融合处理、固件状态机逻辑比如清扫、回充、卡困、休眠等状态切换再往上层走还有App配网、地图管理、预约清扫等交互逻辑。这里我想强调一个容易被新手忽略的点扫地机器人是一个典型的“多传感器融合、软硬深度耦合”的产品。很多时候一个问题到底算硬件问题还是软件问题根本分不清。比如一台机器在深色地毯上反复打转可能是红外传感器对深色材质吸收红外导致误判也可能是避障算法把地毯边缘识别成了障碍物还可能只是轮子打滑导致里程计漂移。所以测试体系的第一原则就是不要孤立地测硬件或测软件而是先搭一个能覆盖“器件—整机—场景”三个层次的测试框架。1.2 三类测试的分工与协作我习惯把扫地机器人的测试分成三个大块硬件测试、软件测试、场景化测试。硬件测试解决的是“东西会不会坏、安全不安全”的问题比如电机寿命、电池循环、跌落可靠性、传感器测距精度、充电座对接成功率等。软件测试解决的是“逻辑对不对、算法准不准”的问题比如建图是否漂移、避障是否误判、路径覆盖率是否达标、OTA升级失败能否回滚。场景化测试则把前两者合在一起解决的是“在用户家里到底行不行”的问题——它不关心单个模块的指标只关心整机在真实或接近真实的复杂环境中的综合表现。这三块不是按先后顺序串行的而是并行交叉的。硬件稳定版出来之前软件测试可以在仿真环境里先跑场景化测试发现问题后又会把问题重新拆解成硬件问题或软件问题回到对应环节去修复和复测。下面我按这三个方向逐一展开说说每一块具体怎么做。2. 硬件测试从零部件到整机每一关都在验证“会不会坏”2.1 关键硬件模块的测试指标硬件测试如果从底层做起就是先测模块再测整机。我列几个扫地机器人上最容易出问题的模块和核心测试项这些都是项目里实际会填进测试用例库的内容。硬件模块核心测试项常见指标参考说明激光雷达测距精度、扫描频率、角分辨率测距精度±1~2cm典型10Hz扫描环境光过强或灰尘堆积都会影响精度电机轮子/边刷/滚刷堵转电流、噪音、寿命寿命测试通常要求连续运转几百小时以上头发、线缆缠绕会加大堵转概率电池循环寿命、过充过放保护、温升数百次循环后容量保持率有明确下限低温充电、高温放电都要覆盖碰撞传感器触发力、响应时间、按压寿命触发力不能太灵敏也不能太迟钝直接决定“轻碰缓行”的体验IMU/陀螺仪零偏稳定性、温漂短时间内角度漂移越小越好对SLAM和轮式里程计融合很关键充电极片/充电座对接成功率、接触阻抗反复对接成功率建议超过99%极片氧化、错位是常见失效模式实际执行的时候模块级测试通常会用专门的工装夹具来固定姿态、控制力度和角度。比如说测碰撞传感器不能靠人手去按得用推拉力计加线性模组确保每次触发的位置和速度一致不然测出来的触发力度数据根本没有可比性。另外硬件测试里有个很容易被忽略的点样本量。如果你只拿一台样机测电机寿命测过了就认为产品没问题那大概率后面会被批量生产的良率教育一番。我一般的做法是研发验证阶段至少3台样机做全项试产阶段掰到10台以上关键项如电池循环、电机寿命要分不同批次取样因为供应商产线的批次差异真的能差出不少。2.2 整机可靠性与安全性测试模块测完进入整机阶段。整机可靠性测试的核心目的是模拟用户几年使用周期内可能遇到的各种折腾把早期失效在出厂前暴露出来。最常见的整机测试项目有这几类跌落测试把整机从一定高度比如70~80cm模拟充电座或桌边滑落以不同姿态自由跌落到硬质地面常见为大理石、木板一般要求特定次数内无壳体开裂、无功能失效。注意不要只跌底面顶盖、侧面、边角都要跌这四个方向的实际损坏概率差别很大。长时间老化跑图在标准测试房里让机器连续工作24到72小时反复执行“清扫—回充—再清扫”的循环。重点观察电机温升、电池续航衰减、尘盒堵塞后吸力下降情况以及长时间运行后传感器的稳定性。这里我踩过坑有一版样机跑老化测试跑到第30个小时激光雷达开始出现偶发性丢帧原因是电机振动导致雷达排线松动。如果老化时间不够长这种间歇性故障根本复现不出来。充电循环测试连续充放电几百个循环记录电池容量、充电时间、充电温度变化同时验证过充保护是否正常工作。线缆缠绕和滚刷缠绕测试准备标准长度的电源线、数据线、地毯流苏故意让机器碾过看滚刷会不会被死死缠住导致停机。扫地机器人售后问题里“滚刷缠绕”常年排在前三名这个测试必须做透。进出充电座测试反复让机器从不同角度、不同电量状态下回充统计对接成功率和回充时间同时测试充电座被轻微移位后机器能否重新调整对准。整机可靠性测试的“坑点”在于很多问题不是单次测试能暴露的而是需要组合操作才能触发。举例来说机器先在一次清扫中吸入了少量灰尘然后回到充电座上充电充电过程中灰尘可能受潮结块下次启动时风机启动就被卡住。这种复合型问题靠单项测试根本发现不了所以我会每隔一段时间就把测过的样机做一次“脏机器连续使用”的专项模拟用户偷懒一个月不倒尘盒的真实使用状态。2.3 环境适应性测试说到环境适应性测试早期很多团队都不够重视觉得扫地机器人只在室内工作环境能恶劣到哪去。直到被用户投诉“突然不扫了”才发现南方的回南天、北方的供暖期、西部的沙尘每一个都能给你整出新问题。环境适应性测试通常包括高温高湿测试温度40℃左右、相对湿度90%以上验证整机长时间运行的稳定性重点关注电子元器件结露、电池鼓包风险。低温测试0℃到-10℃环境下的启动和运行主要看电池放电能力下降是否会导致续航缩水、充电是否正常液晶屏或按键是否反应迟钝。高低温循环冲击在高温和低温之间快速切换模拟室内外温差或者极端天气下的温度变化最容易暴露的问题是塑料件变形、传感器参数漂移。静电放电和电磁兼容测试这是入网和销售合规的硬指标但在早期研发阶段我也建议做摸底不然等送测机构再发现问题改板成本会高很多。环境测试的结果往往直接指导产品改进。我之前遇到过一个典型案例一台样机在35℃高温环境下跑了一个小时后激光雷达的建图开始缓慢漂移后来定位到IMU在高温下零漂增大导致融合算法精度下降。这个问题的修复不是靠换传感器而是在算法里加了对IMU温漂的补偿模型。所以说硬件测试发现的问题常常需要软件配合一起解。3. 软件测试算法、固件和App一个都不能少3.1 感知与建图算法的测试方法软件测试在扫地机器人上的分量这几年越来越重因为产品同质化竞争已经拼到算法层面了。感知与建图这块我拆成SLAM建图、障碍物识别、场景理解三个方向来讲。SLAM建图的测试重点有几个一是建图准确性机器在一个标准户型里跑完一圈生成的户型图与实际户型的长宽比例误差要在合理范围内二是重定位能力如果用户把机器从充电座搬到另一个房间再启动机器能不能快速搞清楚自己在哪里三是构图稳定性同一户型跑三次每次生成的地图差异要足够小否则用户会在App上看到“今天的地图跟昨天不一样”的诡异现象。障碍物识别的测试就要结合传感器方案来设计。纯激光雷达方案看不到低矮物体对黑色、镜面物体的反射率敏感视觉方案受光线影响大在暗光下识别率会明显下降ToF和红外对材质敏感。所以算法测试用例通常按“传感器类型×障碍物材质×环境光线”三个维度来矩阵化设计。这里我要特别说一句算法测试不能只测“正常场景”必须大量注入“边界输入”。比如把一个垃圾桶的图片剪成只有一半、把地毯的花纹调成看起来像楼梯的边缘、把阳光直射下的地板强光阴影混在一起看算法会不会误判。这些用例很多是用仿真和图像回放的方式生成的纯靠实机摆放障碍物效率太低。3.2 运动规划与避障测试的关键指标建完图之后机器要能自己规划路径还要能灵活避开障碍物。这一块的测试指标主要有清扫覆盖率在标准测试房内完成一次清扫后实际清扫面积占总可清扫面积的比例。行业里正常水平建议在90%以上旗舰产品甚至会要求更高。重复清扫率同一个区域被重复扫了多少次重复率太高说明路径规划效率低会浪费续航。脱困成功率把机器置入桌椅腿丛、门槛、电源线堆等困境记录它能在多长时间内成功脱身完全不脱困或需要人工救援都算失败。贴边清扫能力沿墙和角落清扫时边刷能不能有效覆盖墙角线区域这直接关系到用户对扫得干不干净的体感。运动规划测试的难点在于“量化”。覆盖率可以通过在App地图上叠加网格来统计但脱困能力的评判标准更难定。我的做法是先定义“困境等级”从低到高划分为单个桌腿、密集椅腿、线缆环绕、狭窄过道、复杂混合场景五个等级每个等级规定测试次数和成功标准防止测试人员靠主观感觉“这个应该算过了”。避障测试里有一个我特别想提醒的坑不要为了通过“避障测试”而把避障灵敏度调得过高。之前有一版软件把避障阈值调得很激进结果是线缆是避开了但打扫覆盖率掉到了70%多而且机器在稍微暗一点的环境里会对着空气绕圈看起来很傻。避障和覆盖率在本质上是矛盾的测试的核心不是让每一项都拿满分而是找到用户体验最佳的那个平衡点。3.3 固件稳定性与App交互测试固件测试看起来没有算法那么“高大上”但恰恰是用户骂声最多的地方。想想看突然不会回充、半夜自己启动清扫、App一直显示离线哪一个不是分分钟让用户血压升高的事情。固件稳定性测试要重点关注状态机切换在正常清扫、暂停、回充、休眠、OTA升级、手动搬动、低电量等状态之间随意切换任何异常的状态残留都会导致后续逻辑错乱。举个例子机器在扫到一半时被用户手动搬回充电座此时固件应该能识别“我已经被搬动”并取消未完成的清扫任务如果状态机处理不当机器可能自认为还在清扫中之后突然原地启动非常危险。OTA升级测试也不只是“升上去能不能用”要验证升级中断、断网续传、版本回滚、双分区切换这些异常流程。我见过一次升级失败导致机器变砖的事故原因就是升级过程中断电固件既没写入完整版本也没保留旧版本可回退。这种事故一旦发生在用户家里绝对是大规模客诉。App交互测试则要覆盖配网绑定、建图进度展示、地图编辑设虚拟墙、选区清扫、耗材寿命提醒、预约清扫、消息推送等全流程。特别要提醒的是兼容性测试安卓机型和iOS版本千差万别实测中经常出现旧机型CPU性能不足导致App端地图渲染卡顿或者在iOS新版本上Wi-Fi定位权限变更导致配网失败。这类问题通常需要真机测试矩阵来覆盖光靠模拟器远远不够。4. 场景化测试把机器扔进真实生活里检验4.1 为什么实验室测完还不够到这里你可能会问硬件也测了、软件也测了为什么还要单独做场景化测试答案是实验室环境太“干净”了和真实家居环境之间的差距大到让人崩溃。实验室测试房通常是标准化的均匀灯光、平整地面、几个固定障碍物、没有杂物。但真实用户家里是什么样早晨八九点的阳光会斜射进客厅在木地板上拉出长长的影子茶几底下散落着数据线、遥控器、零食碎屑地毯是深灰色的边缘还有点卷起厨房地面有防滑纹路刚拖完地还有水渍儿童房的乐高颗粒满地都是。这些变量叠加起来任何一个都会让扫地机器人的传感器和算法瞬间“破防”。场景化测试的价值就在这里它把软件测试和硬件测试的结果放到真实生活的大染缸里滚一遍发现那些“单模块指标全过但组合到一起就翻车”的系统性问题。4.2 搭建场景库的几个维度做场景化测试首先要建场景库。一个比较完整的场景库应该覆盖下面几个维度户型维度从一室一厅的小户型到四室两厅的大平层再到复式、Loft、带阳台和卫生间的复杂户型。每种户型的家具密度、房间连通性差异很大。地面材质维度实木地板、复合地板、瓷砖、大理石、深色地毯、浅色短毛地毯、长毛地毯、地面有地暖的瓷砖等。不同材质对传感器反射、轮子打滑、吸力负载的影响完全不同。光线维度强光直射、逆光、黄昏低照度、夜晚关灯后的全黑环境、灯具频闪环境下各来一轮。障碍物维度桌腿椅腿是基本款还需要包括落地灯底座、体重秤、电风扇底座、鞋架、绿植盆栽、儿童玩具、宠物水碗、电源线、窗帘拖地、门垫、垃圾桶等。附加脏污维度宠物毛发、猫砂颗粒、面粉/粉尘、液体污渍、酱油渍、湿垃圾中的果皮如果想做得更极致还可以测宠物粪便不用担心都是用仿生道具替代的。每个维度里的元素又要继续组合比如“深色地毯逆光桌腿密集区”这种组合单测某一项可能都没问题组合在一起才会暴露出传感器误判、避障策略混乱、覆盖率下降等一系列连锁反应。真实场景里的问题绝大多数都是组合条件触发的。4.3 高频场景测试用例参考我在实际项目里总结了一套高频场景用例这里挑几个典型的分享给大家参考。客厅综合场景把客厅模拟成带沙发、茶几、电视柜、落地灯、绿植、地毯和一组散落玩具的状态。考核重点包括地毯边缘会不会被误判为障碍物、玩具周围能否有效避障且不把玩具卷进滚刷、落地灯细长底座能否被识别并绕开、覆盖率能否保持在合理水平、扫完能否准确回到充电座。厨房湿滑场景在瓷砖地面撒少量水渍和油渍摆上垃圾桶和瓶瓶罐罐再人为制造一个窄通道。重点关注轮子会不会在湿滑地面打滑导致定位漂移、污水会不会被吸入风机造成异味、在窄通道内能否顺利掉头通过。床底与低矮空间场景把床底高度设置成比机器高度略高几厘米周边再堆几个纸箱。重点看机器能否主动探测低矮空间并钻入清扫会不会在钻入后因为高度变化导致激光雷达撞到床板或者进去之后因为光线太暗导致视觉避障失效出不来。宠物家庭场景地板上撒宠物毛发和猫砂同时放置一个仿真宠物粪便和几个宠物玩具。这个场景是很多旗舰机型翻车的高发区毛发缠绕滚刷、猫砂被边刷打飞、宠物粪便被识别失败后直接碾过每一个都是灾难级体验。全屋多房间循环场景让机器在完整户型里执行“清扫—回充—再清扫”跨房间任务中间人为搬动机器、开关房门、改变家具位置考核建图更新和重定位能力。这个用例模拟的是用户真实的使用节奏——没有人会每天固定时间清空客厅所有东西等机器来扫。场景化测试的用例执行我建议配合标准操作规范SOP每个用例要定义清楚前置条件、场景摆放示意、操作动作比如中途何时搬动机器、数据记录项视频、日志、App截图、传感器数据和通过标准。没有SOP的场景测试测出来的结果往往不可复现问题定位时追溯成本极高。5. 仿真测试与自动化用MuJoCo训练扫地机器人到底行不行5.1 仿真测试解决什么问题聊到“训练扫地机器人用MuJoCo可以吗”这个问题我的答案是完全可以而且现在越来越多团队正在这么做但前提是要搞清楚仿真测试的边界在哪里。仿真测试在扫地机器人领域的价值主要体现在三个方面。第一是效率在真实环境里摆一次场景可能要十分钟跑一次测试要十几分钟甚至半小时而在仿真环境里同样的时间可以跑几十上百遍还能并行执行。第二是覆盖度仿真可以轻松生成现实中很难搭出来的极端场景比如上千种随机家具布局、各种诡异的光照组合、传感器故障注入这种“撒网式”探索在实机测试中成本高得离谱。第三是开发效率硬件还没定型时算法团队就能通过仿真提前开始调参和验证不用死等硬件改版。5.2 MuJoCo在扫地机器人测试中的落地方式MuJoCo是一个高精度的物理仿真引擎主打接触动力学和关节运动仿真底层对刚体碰撞、摩擦力、关节约束的建模做得比较细。扫地机器人身上全是带接触的运动部件——轮子与地面摩擦、边刷与障碍物碰撞、滚刷卷入异物、充电极片与充电座的金属接触这些如果用通用游戏引擎模拟物理精度远远不够而MuJoCo这类物理引擎的建模方式天然适合。具体能怎么用我见过和能想到的落地方式有这几种动力学与里程计仿真通过建模机器人的轮径、轴距、轮速、地面摩擦系数等参数仿真出轮式里程计和IMU融合后的位姿输出。用这种方式可以快速验证运动学模型是否正确也可以注入不同的地面打滑系数观察对构图精度的影响。避障策略训练配合强化学习在仿真环境里让机器大量试错学习不同障碍物下的避障行为。MuJoCo的物理反馈能给策略学习提供合力的奖励信号比如“别怼得太猛”“卡住了要尝试换个方向”。传感器噪声注入与失效模拟仿真里可以方便地给传感器叠加高斯噪声、随机丢失帧、突然断电等异常状态用这些数据训练算法在恶劣输入下的鲁棒性这在实机上很难安全地复现。虚拟场景压力测试搭一批随机化的虚拟户型自动生成地毯、桌腿、门槛等元素脚本自动跑回归统计覆盖率、碰撞次数、卡困率。这种场景级回归仿真的运行量是实机测试的百倍级别。不过必须提醒的是仿真结果不能直接等同于真实体验。仿真里的传感器模型再精细也只是对真实物理世界的一种近似真实环境中灰尘堆积、光线反射、线缆缠绕的复杂性仿真很难完全还原这就是业内常说的“sim-to-real gap”仿真到现实的鸿沟。5.3 仿真与实机结合的推荐流程我推荐的做法是“仿真做面、实机做点、数据闭环”的组合策略。第一步用仿真做大规模算法回归和策略训练。比如每次改动避障策略之后先在仿真里跑两千个随机户型看覆盖率、碰撞次数、卡困率等指标的统计学变化快速筛选掉明显变差的版本。第二步仿真通过后再把候选版本部署到实机上在核心标准场景和真实用户场景里做小批量验证重点确认仿真中没发现的问题。这里要注意实机验证的样机数量不能太少至少覆盖三台以上而且要包含不同批次的硬件避免单机差异掩盖问题。第三步把实机测试中发现的失败案例录下来转成仿真里的回归测试用例。比如实机里发现在某个落地灯底座附近机器会反复转圈把那个落地灯的模型和对应地面材质在仿真里重建出来加入自动化回归集确保后续代码改动不会重新引入这个bug。这套流程走顺之后团队对仿真的依赖度会越来越高但实机验证永远不能省。我自己见过太多次“仿真满分、实机翻车”的案例最典型的是一次在仿真里调整边刷转速仿真显示清扫效率大幅提升结果实机上发现转速一高瓜子壳会被直接打飞而不是吸入尘盒这种物料颗粒动态仿真里根本没建模。所以尊重仿真但别迷信仿真。6. 常见问题与排查技巧实录6.1 建图和定位相关的“老大难”问题一建好的地图发生漂移房间形状变形。排查思路是优先检查轮式里程计是否打滑然后检查激光雷达或视觉传感器固定是否松动再看IMU数据是否异常。场景测试里最容易触发这个问题的就是卫生间和厨房的湿滑瓷砖以及深色地毯区域。问题二机器从充电座出发后无法精确定位。要么是充电座周围特征点太少要么是机器刚启动时传感器数据还没稳定。解决方法通常是在算法里增加启动预热逻辑或者引导用户把充电座放在家具较多的区域。问题三视觉方案在暗光环境下频繁重定位失败。这个比较好理解摄像头在光照不足时提取不到足够特征点。排查时先确认是否有补光灯再看补光灯的光照角度会不会被结构件遮挡最后检查算法是否针对低照度做了图像增强。6.2 硬件和机械机构的典型问题问题一滚刷频繁缠绕头发和线缆。硬件上要检查滚刷两端轴承的密封结构看看头发有没有可能从端部缝隙钻进去软件上要检查防缠绕策略是否及时反转滚刷。只能软硬结合一起改进单靠一边都很难根治。问题二充电极片接触不良导致回充失败。先看极片的弹力是否充足再看极片位置与充电座电极的偏差容差是否合理。场景化测试中很容易发现机器稍微没停正就会导致极片搭不上这种情况对“对准精度”和“极端片宽度”都要做优化。问题三机器人在门槛或地毯边缘卡住。如果驱动轮的动力不足或悬挂行程不够机器就越不过去这个坎。有时候降低避障灵敏度能减少卡困次数但代价是碰撞变多更合理的方案是优化悬挂结构和驱动轮胶皮摩擦力。6.3 问题排查速查表现象可能原因排查方向建图漂移/地图变形轮子打滑、传感器松动、IMU温漂检查地面是否湿滑、硬件固定是否牢靠、日志里的IMU数据回充失败极片接触不良、回充算法不对准、充电座移动先测硬件极片压力与位置公差再看算法对准策略避障过于激进导致覆盖率低障碍物识别阈值太低、传感器误报回放传感器数据适当放宽避障阈值或增加信任度加权清扫时噪音突然变大滚刷缠绕、风机进异物、轴承磨损拆机检查机械结构重点看滚刷两端和风机进风口半夜自动启动定时预约逻辑异常、消息推送误触发检查固件RTC时钟和App定时任务的状态机吸力逐渐变小尘盒滤网堵塞、风机进灰、风道漏气检查尘盒密封圈、滤网使用寿命、风机叶轮积灰情况这个速查表只是一个起点实际项目里每个问题都要结合运行日志主要集中在传感器原始数据、建图发布坐标消息、状态机切换记录来做具体分析。我的体会是测试工作里最有价值的不是把用例跑完而是在问题出现时能快速定位问题属于软件、硬件还是场景组合因素这决定了解决路径完全不一样。最后分享一点个人的实操心得测试扫地机器人必须要学会“还原用户行为”而不是只盯着测试规程。用户不会按照你的用例把环境摆得整整齐齐他们会在地板上放毛毯换鞋凳和猫粮碗会忘了关卧室门会让机器去扫刚浇过水的绿植旁边。所以我在做场景化测试时始终要求自己把注意力放在那些“乱糟糟”的真实组合上。测试规范是骨架还原真实生活才是灵魂。这个思路不仅适用于扫地机器人也适用于任何一款软硬结合的家用产品。希望这些从项目里摸爬滚打出来的经验能帮你少踩几个坑。