最近不少做测试的朋友来问机器人测试怎么做尤其是扫地机器人整机测试这一块。大家可能觉得机器人测试门槛高其实把它拆开来看很多思路和互联网测试是相通的只是多了一些硬件、传感器和运动控制的概念。这篇文章就以扫地机器人整机测试为主线从测试环境、测试项拆解、用例设计、缺陷定位到自动化思路整理一套可以落到实际工作中的完整方案。如果你准备进入机器人测试岗位或者已经在做硬件测试但想系统梳理扫地机器人整机测试项这篇文章都可以作为一个参照。全文不会涉及具体厂商的机密数据所有案例和代码都是通用的工程实践可以直接迁移到你的测试项目中。1. 扫地机器人整机测试到底测什么1.1 从用户视角理解整机测试扫地机器人本质上是一个“会移动的家电”用户买回去之后最关心的不是某个传感器参数有多高而是几个非常朴素的问题能不能把地面扫干净、拖干净。能不能自己避开台阶、数据线、拖鞋。会不会卡住、迷路、乱撞。App 能不能正常建图、划区、预约。用一段时间之后会不会出现质量问题。整机测试要回答的正是这些问题。它不是在某个部件上做单点验证而是要把整台机器放到接近真实家庭的环境里模拟用户的使用行为去验证整机在功能、性能、可靠性、安全性、体验等多个维度上是否达到设计要求。所以扫地机器人整机测试的定义可以概括为在整机完整装配、固件正常烧录、App 可正常连接的前提下对机器人进行系统级、场景级、用户级的测试验证。1.2 整机测试与部件测试的区别很多刚从软件测试转过来的同学容易把整机测试和部件测试混在一起。这里做一个简单区分。部件测试关注的是“单个模块是否合格”。比如激光雷达的测距精度、陀螺仪的角速度漂移、电机的堵转保护、电池的充放电曲线。这些测试通常在部件实验室完成有标准测试夹具重复性好。整机测试关注的是“所有部件组合在一起后系统能不能正常工作”。比如激光雷达装在机器人上之后配合 SLAM 算法是否还能稳定建图电机转动时产生的振动会不会干扰陀螺仪数据拖布支架安装不到位会不会导致 App 误报水箱异常。换句话说部件测试解决“器件本身有没有问题”整机测试解决“整机系统能不能交付”。1.3 为什么整机测试越来越重要扫地机器人已经从“单机清扫工具”变成了“智能家居终端”它身上有激光雷达、ToF 传感器、超声传感器、IMU、摄像头、电机驱动、电池管理、Wi-Fi 模块、拖地水箱等多个子系统还要和 App 云平台配合工作。系统越复杂模块之间的交互问题就越多。很多问题在部件测试阶段无法暴露只有在整机长时间运行、多种场景切换、异常操作叠加的情况下才会出现。这也是扫地机器人整机测试岗位需求持续增长的原因。2. 测试环境与测试工具准备2.1 测试场地与物料扫地机器人整机测试不能只在办公桌上做需要搭建一个接近家庭环境的测试场地。一个相对标准的整机测试环境至少包括一块平整的测试区域面积建议不小于 10 平方米如果做全屋巡航和断点续扫测试20 到 30 平方米更合适。不同材质地面比如瓷砖、木地板、短毛地毯用于测试地面识别、清扫模式和越障能力。关门、开门两种状态用于测试定位与地图切换。固定障碍物包括墙壁、桌椅腿、门槛、推拉门轨道。动态障碍物包括拖鞋、数据线、宠物玩具、体重秤等常见家居物品。光线条件可调节比如开灯、关灯、傍晚弱光、强阳光直射用于验证视觉传感器和激光雷达在不同光线下的表现。粉尘与碎屑物料比如面粉、细沙、纸屑、猫砂、米粒、瓜子壳、头发丝、液体污渍用于清扫和拖地性能测试。这里要特别说明测试物料的粒径和材质需要根据产品定位来选择。比如定位“养宠家庭”的产品就要重点准备宠物毛发和猫砂场景定位“懒人全屋清洁”的产品就要覆盖干湿混合垃圾。2.2 工具链与版本说明整机测试通常需要以下工具链机器人整机样机建议准备多台因为部分可靠性测试会明显损耗样机。配套 App 的调试版本或正式版本。串口调试工具用于抓取机器人主控日志常见的有 PuTTY、MobaXterm、SecureCRT。ADB 工具用于连接机器人或 App 调试部分扫地机器人基于 Android 系统或具备 ADB 调试口。抓包工具用于查看 App 与云端的通信数据常见有 Charles、Fiddler、Wireshark。功耗仪、红外测温枪、噪声计、电子秤、测距卷尺等基础测量设备。录像设备用于记录测试过程中的异常现象尤其是复现问题时非常重要。版本方面机器人固件、App 版本、云端接口版本都可能随时迭代。测试前一定要确认被测设备的固件版本号、App 版本号、测试环境网络并且在测试报告中记录清楚。版本信息不需要照抄某个固定值而是要养成“每次测试都先记录版本”的习惯。2.3 数据采集基础环境拿到一台测试样机后第一步不是直接开测而是先确认能不能抓到日志。以常见的 Linux 主控或 Android 主控为例先用串口连接机器人的调试接口确认可以进入系统 shell。# 查看串口设备Linux/macOS 环境 ls /dev/ttyUSB* ls /dev/ttyACM* # 使用 minicom 或 screen 连接串口波特率常见 115200 sudo minicom -D /dev/ttyUSB0 -b 115200 # 或 sudo screen /dev/ttyUSB0 115200连接成功后通常可以做以下操作输入命令查看进程列表确认导航、清扫、传感器等进程是否在运行。进入日志目录查看或者导出运行日志。使用 printf 或 echo 向串口发送调试指令触发指定功能。日志抓取是后续定位问题的基础如果测试开始前没有确认日志通道遇到问题时会非常被动。3. 扫地机器人整机测试项拆解扫地机器人整机测试项比较多我把它归纳为五个大方向。3.1 功能测试功能测试是整机测试的基础主要验证产品的每一项功能是否符合需求定义。常见的功能测试项包括开关机与待机短按开机、长按关机、充电时自动开机、电量耗尽自动关机。清扫模式自动清扫、定点清扫、沿边清扫、划区清扫、全屋清扫。拖地功能拖布安装检测、水箱安装检测、出水量调节、拖地禁区设置。充电回充低电量自动回充、手动召回、断点续扫后回充、长时间找不到充电座。预约与定时App 设置定时任务验证机器人在设定时间自动启动。语音功能如果产品带语音助手需要验证语音指令识别、唤醒、离线指令。悬崖防跌落在桌面、楼梯口验证机器人不会掉落。功能测试看起来简单但执行时要特别关注状态组合。比如“预约清扫过程中用户手动暂停然后取消预约再次启动清扫”这种操作链才是整机测试真正容易发现问题的地方。3.2 清扫性能测试清扫性能是扫地机器人的核心指标也是用户感知最明显的部分。整机层面的清扫性能测试一般关注以下指标吸尘覆盖率在规定区域内机器人清扫完成后有效覆盖面积与可清扫面积的比值。除尘率清扫前后标准粉尘重量或面积的变化比例。单次清扫时长满电状态下完成指定区域清扫需要多久。边角清扫能力墙边、桌腿、直角角落的积尘残留情况。越障能力能否越过门槛、地毯边缘、电源线。防缠绕能力在地面布置头发、线缆观察滚刷是否被缠绕导致停转。尘盒密封性清扫结束后尘盒与风道连接处是否有漏灰。一个容易忽略的点是清扫性能测试必须控制变量。比如扫同一块区域每次摆放的垃圾量、位置、形态都要尽量一致否则测试结果没有可比性。比较好的做法是固定一张“标准房间测试地图”每次测试前清理场地再按同样规则布置垃圾。3.3 导航与避障测试扫地机器人如果扫不干净用户可能只是抱怨如果乱撞、迷路、卡住用户就会退货。所以导航与避障在整机测试中优先级非常高。导航避障相关的测试项包括建图精度机器人完成全屋探索后生成的地图与真实户型是否一致墙体是否平直房间分割是否准确。定位准确性机器人在地图中的位置与真实位置是否匹配长时间运行后是否出现位置漂移。路径规划效率相同区域清扫路径是否规整是否存在大量重复、遗漏。避障能力对拖鞋、体重秤、宠物粪便、数据线等低矮障碍物的识别和绕行表现。被困自救在桌底、床底、狭窄过道等场景被卡住后能否自动脱困或发出提醒。悬崖响应在台阶边缘机器人停止或转向的灵敏度。测试导航避障时建议把每一个场景都录像。因为导航问题是空间和时序相关的只看文字记录很难还原现场。3.4 安全与可靠性测试安全测试和可靠性测试决定产品能不能长期稳定使用这部分问题一旦发生往往是批量性的后果也比较严重。安全类测试项碰撞力度机器人撞击障碍物时的力度是否在安全范围尤其是老人和儿童家具。充电安全充电过程中电池温度、充电座温度是否正常是否有过充保护。噪音水平最大吸力模式下整机噪音是否在标准限值内。电气安全整机是否存在漏电风险电源适配器是否通过认证。阻燃要求主控板、电池区域是否使用阻燃材料。可靠性类测试项长时间运行连续运行多少小时或多少个清扫循环后功能是否正常。耐久测试滚刷、边刷、轮子、拖布支架在模拟耐久测试后是否磨损严重。跌落测试搬运、意外跌落情况下整机结构是否损坏。高低温环境在高温、低温环境下电池放电、充电是否异常。湿度与防水拖地后底部是否进水传感器是否受潮失灵。可靠性测试周期长、耗材多一定要在项目早期就排入测试计划否则等产品快上市了才做风险非常大。3.5 App 与联动测试现在扫地机器人很少脱离 App 单独使用App 侧的测试也属于整机测试范围。App 相关测试项配网与连接机器人配网成功率、配网耗时、配网失败后的恢复机制。实时状态App 中状态展示与实际机器人状态是否一致比如清扫中、暂停、回充、故障。地图管理地图加载、重命名、编辑、重置是否正常。远程控制手指方向键控制机器人移动的响应时延和准确性。固件升级整包升级、增量升级、升级失败后回滚机制。多设备管理一个 App 绑定多台机器人家庭共享成员权限是否正常。断网场景路由器重启、Wi-Fi 断开、切网后 App 与机器人的恢复表现。App 联动测试的核心在于“状态一致性”。机器人端的状态和 App 端的状态必须时刻同步只要出现一次“App 显示回充中但机器人还在原地清扫”的现象就是一个潜在客诉点。4. 从需求到用例整机测试用例设计方法4.1 测试用例要素与模板和软件测试一样扫地机器人整机测试也需要有明确的测试用例。一条完整的整机测试用例建议包含以下信息。用例字段说明示例用例编号唯一标识便于管理TCS-NAV-0001所属模块功能模块或测试项分类导航避障测试标题一句话描述测试场景冰箱与墙之间窄缝通过性测试前置条件测试开始前需要满足的条件机器人电量80%以上场地已布置窄缝测试步骤可执行的操作步骤1. 将机器人放置在窄缝前 2. 启动自动清扫 3. 观察机器人进入窄缝的行为预期结果符合需求的行为描述机器人可通过窄缝或检测到空间不足后自动转向不陷入卡死实际结果执行后的真实表现通过备注日志路径、视频编号、设备编号样机SNSN20250301日志路径/log/nav/20250301_01.tar.gz在这个模板基础上每个用例还可以增加“测试数据”“关联需求编号”“用例优先级”等字段。重点是每一条用例都要能追溯到需求否则测试没有依据。4.2 用例优先级与场景矩阵整机测试用例数量通常很大不可能每一条都在每个版本完整回归所以要对用例做优先级划分。P0核心功能和安全相关一旦失败就阻断发布。比如悬崖跌落、充电起火风险、无法开机。P1用户高频使用场景失败会影响体验。比如建图失败、回充失败、拖地不出水。P2低频场景或边界场景失败影响有限。比如定时任务在跨天场景下不执行。P3体验优化类属于建议项。比如提示音音量大小不合适。除了单条用例的优先级还建议做“场景矩阵”。因为整机测试更关注多个功能叠加之后的组合表现。比如组合场景低电量10% 开启拖地 断网 预约清扫启动。这种多条件叠加的场景单个功能测试时不会发生但用户真实使用时可能遇到。4.3 用例执行与记录用例执行看起来简单实际对整机测试工程师的要求非常高。执行时要注意严格按照前置条件准备环境特别是电量、场地布置、网络状态。每一步操作要留痕迹机器人上的操作、App 上的操作、环境的改变都要记录。发现异常不要立即重置环境先保留现场抓取日志录像拍照。执行完每一条用例后及时更新用例状态避免事后回忆。对于扫地机器人测试来说现场记录能力尤其重要。很多问题只能在特定位置、特定时间复现测试人员如果没有良好的记录习惯问题后续处理会非常困难。5. 高频问题定位与缺陷分析5.1 常见问题现象与原因对照扫地机器人整机测试中下面这些问题出现频率很高。问题现象常见原因初步排查思路清扫过程中突然停止App 无报错传感器数据异常或任务线程卡死查看主控日志确认是软件异常还是硬件掉线机器人找不到充电座充电座信号接收异常或地图定位漂移检查充电座是否被遮挡查看红外地标识别状态建图后地图倾斜或房间错位IMU 数据漂移或 SLAM 初始化时机器人被移动查看陀螺仪原始数据对比建图时机器人移动路径拖地拖不干净出水量不足或拖布贴合压力不够检查水泵出水量、拖布支架装配间隙App 显示离线实际和机器人连接正常云端长连接断开App 与云端状态不同步抓取 App 与云端接口数据查看 websocket 状态边刷把垃圾打飞边刷转速与行走速度不匹配对比高速、低速模式下的垃圾轨迹这些问题在测试中很难完全避免关键是遇到问题后能不能快速定位根因。定位能力是整机测试工程师和初级测试员拉开差距的核心。5.2 问题复现技巧机器人测试中的问题复现比纯软件测试要复杂因为它依赖物理环境。我的建议是记录问题发生的精确坐标。在测试场地地面上用贴纸做标记问题在哪里发生就记录哪个格子的坐标。保持环境不变化。发现问题后先不要移动机器人不要扫地不要收走障碍物原样拍视频。固化触发条件。找出问题触发的必要条件是什么比如“电量低于 20%”“地毯边缘”“强光直射激光雷达”。用最小化场景复现。先把问题简化到最少的条件组合比如只保留一个障碍物看问题是否还能复现。复现的价值在于给开发提供可操作的输入。如果测试人员只提“清扫时卡住”开发很难定位如果测试人员能给出“机器人在坐标 (120, 80) 附近剩余电量 30%地面有一根黑色数据线触发红外避障后反复横跳”开发就更容易找到算法里的问题。5.3 从日志和传感器数据定位问题日志是定位问题的第一手材料。下面是一个简单的 Python 脚本示例用于解析机器人导出的传感器日志提取指定时间段内的传感器数据。# 文件路径tools/parse_sensor_log.py 解析扫地机器人传感器日志的示例脚本 日志格式假设为 CSV字段如下 time, sensor_type, sensor_value import csv import sys from collections import defaultdict def load_sensor_log(file_path): data defaultdict(list) with open(file_path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: sensor_type row.get(sensor_type, ).strip() try: value float(row.get(sensor_value, 0)) except ValueError: value 0.0 data[sensor_type].append({ time: row.get(time, ).strip(), value: value, }) return data def query_range(data, sensor_type, start_time, end_time): 提取某个传感器在指定时间范围内的数据 result [] for item in data.get(sensor_type, []): if start_time item[time] end_time: result.append(item) return result if __name__ __main__: if len(sys.argv) ! 2: print(用法: python parse_sensor_log.py 日志文件路径) sys.exit(1) log_file sys.argv[1] sensor_data load_sensor_log(log_file) # 示例查看 IMU 和超声波传感器数据 for sensor in [imu_gyro_z, ultrasonic]: print(f传感器类型: {sensor}) for item in sensor_data.get(sensor, [])[:10]: print(f 时间: {item[time]}, 数值: {item[value]})这个脚本帮你快速筛选出不同类型传感器随时间变化的数据。实际项目中你可以根据主控日志格式调整解析逻辑。当开发需要查看某个时段的数据时这类小工具能节省大量人工翻日志的时间。6. 自动化测试在整机测试中的应用6.1 哪些环节适合自动化不是所有整机测试都适合自动化盲目自动化反而会增加维护成本。我比较推荐从下面几个环节开始App 配网、状态展示、远程控制这类操作适合用 App 自动化框架来跑。日志抓取和日志分类保存适合用脚本自动化。重复性回归用例比如开关机 100 次、回充 50 次可以结合硬件工装做自动化。传感器数据一致性检查适合用脚本解析和校验。不适合自动化的场景通常是强物理操作类比如布置宠物粪便、模拟毛发缠绕这些场景人为布置更接近真实。6.2 App 自动化测试示例扫地机器人 App 的自动化测试可以基于 Appium 或 Android 原生测试框架来做。下面是一个简化示例展示用 Python pytest Appium 控制 App 内点击“开始清扫”按钮并校验状态的过程。# 文件路径test_app_sweep.py 扫地机器人 App 自动清扫测试示例 需要提前安装 appium、pytest 和对应 driver import pytest from appium import webdriver def init_driver(): caps { platformName: Android, appPackage: com.example.robotapp, appActivity: .MainActivity, noReset: True, } return webdriver.Remote(http://localhost:4723/wd/hub, caps) pytest.fixture(scopemodule) def driver(): drv init_driver() yield drv drv.quit() def test_start_sweep(driver): # 进入主界面后找到“开始清扫”按钮并点击 start_btn driver.find_element(id, btn_start_sweep) start_btn.click() # 等待状态切换为“清扫中” driver.implicitly_wait(5) status_text driver.find_element(id, tv_status).text assert 清扫中 in status_text, f状态异常当前显示: {status_text} def test_stop_sweep(driver): # 点击“暂停/停止”按钮 stop_btn driver.find_element(id, btn_pause) stop_btn.click() driver.implicitly_wait(3) status_text driver.find_element(id, tv_status).text assert 已暂停 in status_text, f状态异常当前显示: {status_text}这段代码的主要作用是验证 App 点击指令后界面状态是否正确变化。真实项目中还需要处理弹窗、耗时等待、截图失败信息等细节。测试执行前必须用一台已经完成配网的机器人和一个可登录的测试账号。需要注意的是App 自动化只能证明 App 层面响应正常不能证明机器人真实开始清扫。要验证整机行为还需要在机器人侧通过电流变化、运行日志、传感器数据等做交叉确认。这是 App 自动化和整机自动化最大的区别。6.3 数据回放与回归机器人测试中还有一种很实用的自动化手段——传感器数据回放。借助仿真平台或数据回放工具把实际采集到的传感器数据回放给导航算法验证算法修改后是否仍然能正确处理同一段场景。这种方式的优点是不依赖实体机器人可以并行跑大量场景。回归速度快同一份数据可以反复回放。可比较性好算法修改前后的输出可以直接对比。它不能完全替代整机实测因为传感器数据和真实环境之间还有差异但作为回归手段非常有价值。7. 测试报告与项目推进经验7.1 测试报告的结构一份完整的扫地机器人整机测试报告至少要包含以下几个部分。测试版本信息固件版本、App 版本、云平台版本、样机编号。测试环境描述场地类型、地面材质、特殊障碍物布置。测试范围与用例统计本次执行了多少条用例P0/P1/P2 各多少条通过率多少。问题清单遗留问题、已关闭问题、阻塞问题。风险说明哪些问题可能影响发布时间、涉及哪个模块。测试结论建议通过、有条件通过或不通过。写测试报告时尽量用数据说话。比如“P0 用例 45 条通过 43 条通过率 95.6%”比写“基本通过”更有说服力。7.2 缺陷分级与流转整机测试的问题要按严重程度分级一般分为四类。致命缺陷可能导致安全事故、主控板烧毁、机器人完全无法工作。严重缺陷核心功能不能使用比如无法建图、无法返回充电座。一般缺陷功能可用但体验较差比如沿边清扫漏扫较大区域。轻微缺陷不影响功能但影响观感或细节体验比如提示音文字显示错误。Android 端或内部缺陷管理工具处理流程通常是测试人员提交缺陷 - 开发分析定位 - 修复后提交测试 - 测试回归 - 关闭。整机测试中缺陷复现频率很重要如果一条问题只出现一次一定要在提交时注明偶然性并尽量补充现场记录。7.3 测试准入准出建议扫地机器人项目的测试不可能无限期进行建议项目组提前约定测试准入准出条件。准入条件可以包括本轮测试固件已编译完成版本号清晰。已知致命问题已修复或已有明确绕过方案。测试样机数量和状态满足测试计划要求。准出条件可以包括P0 用例通过率 100%。P1 用例通过率达到 95% 以上没有未关闭的严重缺陷。遗留缺陷有明确的风险评估和排期。测试报告已输出测试结论已确认。如果你正在负责整机测试的排期建议把可靠性测试的时间留足这是最容易压缩也最容易出问题的板块。8. 想入行机器人测试应该补哪些技能8.1 技能地图很多同学关心机器人测试岗位怎么准备。结合行业常见要求我整理了一张技能地图。基础测试能力测试用例设计、缺陷生命周期、测试报告编写这是所有测试岗位通用的基础。软硬件结合知识理解传感器、电机、电池、充电座、Wi-Fi 模块的基本原理不需要会硬件设计但要能看懂硬件参数和异常现象之间的关系。系统与日志能力能使用串口、ADB 命令能看懂系统日志能快速提取关键信息。数据分析能力能用 Python 或 Excel 处理传感器数据做简单的统计分析和异常判断。自动化能力至少掌握一种自动化测试框架比如 Pytest、Appium能写简单的自动化脚本。场景化测试思维能站在用户实际使用场景设计测试用例而不是只盯着需求文档。对应岗位面试时考官通常不会问特别偏门的源码细节更关注你是否理解整机测试的流程和思路。8.2 学习建议如果你是从软件测试转过来建议按顺序补齐这几块经验。第一步先买或借一台扫地机器人把它当测试对象用起来。熟悉 App 的每个功能入口记录使用过程中的异常现象。这是成本最低、效果最好的入门方式。第二步尝试抓取和分析日志。无论是串口日志还是 App 日志学会查看报错信息、传感器数据、任务状态建立“现象 - 日志 - 原因”之间的关联能力。第三步自己搭建一个简单的测试环境。不需要专业实验室家里一小块地面、几样障碍物、一台机器人和一台电脑就能完成大量基础测试。第四步找机会参与真实项目。可以是实习、外包项目也可以是自己动手拆机分析。重点是积累真实的整机测试经验尤其是缺陷定位和项目推进的经验。8.3 面试关注点面试的时候以下几类问题出现频率比较高。扫地机器人由哪些核心模块组成每个模块的作用是什么碰到机器人清扫到一半不走了你会怎么排查导航测试用例你会怎么设计如何验证 App 上的“清扫完成”是真的完成了如何评估一块木地板上的清扫效果回答这些问题的核心逻辑是先讲清楚“我会怎么做”再讲“为什么这么做”最后补充“如果遇到异常我会怎么处理”。能把这个逻辑讲清楚比背知识点更有说服力。关于行业环境可以理性看待。机器人测试岗位的薪资和城市、行业、个人实际能力都有关系不存在简单“拿下”一说。真正重要的是你能不能独立完成一条测试闭环从需求分析、方案设计、用例执行到缺陷定位、问题跟进、结论输出。这一整套能力无论在哪个测试岗位上都是长期通用的。 扫地机器人整机测试全攻略：从测试环境到自动化实践
最近不少做测试的朋友来问机器人测试怎么做尤其是扫地机器人整机测试这一块。大家可能觉得机器人测试门槛高其实把它拆开来看很多思路和互联网测试是相通的只是多了一些硬件、传感器和运动控制的概念。这篇文章就以扫地机器人整机测试为主线从测试环境、测试项拆解、用例设计、缺陷定位到自动化思路整理一套可以落到实际工作中的完整方案。如果你准备进入机器人测试岗位或者已经在做硬件测试但想系统梳理扫地机器人整机测试项这篇文章都可以作为一个参照。全文不会涉及具体厂商的机密数据所有案例和代码都是通用的工程实践可以直接迁移到你的测试项目中。1. 扫地机器人整机测试到底测什么1.1 从用户视角理解整机测试扫地机器人本质上是一个“会移动的家电”用户买回去之后最关心的不是某个传感器参数有多高而是几个非常朴素的问题能不能把地面扫干净、拖干净。能不能自己避开台阶、数据线、拖鞋。会不会卡住、迷路、乱撞。App 能不能正常建图、划区、预约。用一段时间之后会不会出现质量问题。整机测试要回答的正是这些问题。它不是在某个部件上做单点验证而是要把整台机器放到接近真实家庭的环境里模拟用户的使用行为去验证整机在功能、性能、可靠性、安全性、体验等多个维度上是否达到设计要求。所以扫地机器人整机测试的定义可以概括为在整机完整装配、固件正常烧录、App 可正常连接的前提下对机器人进行系统级、场景级、用户级的测试验证。1.2 整机测试与部件测试的区别很多刚从软件测试转过来的同学容易把整机测试和部件测试混在一起。这里做一个简单区分。部件测试关注的是“单个模块是否合格”。比如激光雷达的测距精度、陀螺仪的角速度漂移、电机的堵转保护、电池的充放电曲线。这些测试通常在部件实验室完成有标准测试夹具重复性好。整机测试关注的是“所有部件组合在一起后系统能不能正常工作”。比如激光雷达装在机器人上之后配合 SLAM 算法是否还能稳定建图电机转动时产生的振动会不会干扰陀螺仪数据拖布支架安装不到位会不会导致 App 误报水箱异常。换句话说部件测试解决“器件本身有没有问题”整机测试解决“整机系统能不能交付”。1.3 为什么整机测试越来越重要扫地机器人已经从“单机清扫工具”变成了“智能家居终端”它身上有激光雷达、ToF 传感器、超声传感器、IMU、摄像头、电机驱动、电池管理、Wi-Fi 模块、拖地水箱等多个子系统还要和 App 云平台配合工作。系统越复杂模块之间的交互问题就越多。很多问题在部件测试阶段无法暴露只有在整机长时间运行、多种场景切换、异常操作叠加的情况下才会出现。这也是扫地机器人整机测试岗位需求持续增长的原因。2. 测试环境与测试工具准备2.1 测试场地与物料扫地机器人整机测试不能只在办公桌上做需要搭建一个接近家庭环境的测试场地。一个相对标准的整机测试环境至少包括一块平整的测试区域面积建议不小于 10 平方米如果做全屋巡航和断点续扫测试20 到 30 平方米更合适。不同材质地面比如瓷砖、木地板、短毛地毯用于测试地面识别、清扫模式和越障能力。关门、开门两种状态用于测试定位与地图切换。固定障碍物包括墙壁、桌椅腿、门槛、推拉门轨道。动态障碍物包括拖鞋、数据线、宠物玩具、体重秤等常见家居物品。光线条件可调节比如开灯、关灯、傍晚弱光、强阳光直射用于验证视觉传感器和激光雷达在不同光线下的表现。粉尘与碎屑物料比如面粉、细沙、纸屑、猫砂、米粒、瓜子壳、头发丝、液体污渍用于清扫和拖地性能测试。这里要特别说明测试物料的粒径和材质需要根据产品定位来选择。比如定位“养宠家庭”的产品就要重点准备宠物毛发和猫砂场景定位“懒人全屋清洁”的产品就要覆盖干湿混合垃圾。2.2 工具链与版本说明整机测试通常需要以下工具链机器人整机样机建议准备多台因为部分可靠性测试会明显损耗样机。配套 App 的调试版本或正式版本。串口调试工具用于抓取机器人主控日志常见的有 PuTTY、MobaXterm、SecureCRT。ADB 工具用于连接机器人或 App 调试部分扫地机器人基于 Android 系统或具备 ADB 调试口。抓包工具用于查看 App 与云端的通信数据常见有 Charles、Fiddler、Wireshark。功耗仪、红外测温枪、噪声计、电子秤、测距卷尺等基础测量设备。录像设备用于记录测试过程中的异常现象尤其是复现问题时非常重要。版本方面机器人固件、App 版本、云端接口版本都可能随时迭代。测试前一定要确认被测设备的固件版本号、App 版本号、测试环境网络并且在测试报告中记录清楚。版本信息不需要照抄某个固定值而是要养成“每次测试都先记录版本”的习惯。2.3 数据采集基础环境拿到一台测试样机后第一步不是直接开测而是先确认能不能抓到日志。以常见的 Linux 主控或 Android 主控为例先用串口连接机器人的调试接口确认可以进入系统 shell。# 查看串口设备Linux/macOS 环境 ls /dev/ttyUSB* ls /dev/ttyACM* # 使用 minicom 或 screen 连接串口波特率常见 115200 sudo minicom -D /dev/ttyUSB0 -b 115200 # 或 sudo screen /dev/ttyUSB0 115200连接成功后通常可以做以下操作输入命令查看进程列表确认导航、清扫、传感器等进程是否在运行。进入日志目录查看或者导出运行日志。使用 printf 或 echo 向串口发送调试指令触发指定功能。日志抓取是后续定位问题的基础如果测试开始前没有确认日志通道遇到问题时会非常被动。3. 扫地机器人整机测试项拆解扫地机器人整机测试项比较多我把它归纳为五个大方向。3.1 功能测试功能测试是整机测试的基础主要验证产品的每一项功能是否符合需求定义。常见的功能测试项包括开关机与待机短按开机、长按关机、充电时自动开机、电量耗尽自动关机。清扫模式自动清扫、定点清扫、沿边清扫、划区清扫、全屋清扫。拖地功能拖布安装检测、水箱安装检测、出水量调节、拖地禁区设置。充电回充低电量自动回充、手动召回、断点续扫后回充、长时间找不到充电座。预约与定时App 设置定时任务验证机器人在设定时间自动启动。语音功能如果产品带语音助手需要验证语音指令识别、唤醒、离线指令。悬崖防跌落在桌面、楼梯口验证机器人不会掉落。功能测试看起来简单但执行时要特别关注状态组合。比如“预约清扫过程中用户手动暂停然后取消预约再次启动清扫”这种操作链才是整机测试真正容易发现问题的地方。3.2 清扫性能测试清扫性能是扫地机器人的核心指标也是用户感知最明显的部分。整机层面的清扫性能测试一般关注以下指标吸尘覆盖率在规定区域内机器人清扫完成后有效覆盖面积与可清扫面积的比值。除尘率清扫前后标准粉尘重量或面积的变化比例。单次清扫时长满电状态下完成指定区域清扫需要多久。边角清扫能力墙边、桌腿、直角角落的积尘残留情况。越障能力能否越过门槛、地毯边缘、电源线。防缠绕能力在地面布置头发、线缆观察滚刷是否被缠绕导致停转。尘盒密封性清扫结束后尘盒与风道连接处是否有漏灰。一个容易忽略的点是清扫性能测试必须控制变量。比如扫同一块区域每次摆放的垃圾量、位置、形态都要尽量一致否则测试结果没有可比性。比较好的做法是固定一张“标准房间测试地图”每次测试前清理场地再按同样规则布置垃圾。3.3 导航与避障测试扫地机器人如果扫不干净用户可能只是抱怨如果乱撞、迷路、卡住用户就会退货。所以导航与避障在整机测试中优先级非常高。导航避障相关的测试项包括建图精度机器人完成全屋探索后生成的地图与真实户型是否一致墙体是否平直房间分割是否准确。定位准确性机器人在地图中的位置与真实位置是否匹配长时间运行后是否出现位置漂移。路径规划效率相同区域清扫路径是否规整是否存在大量重复、遗漏。避障能力对拖鞋、体重秤、宠物粪便、数据线等低矮障碍物的识别和绕行表现。被困自救在桌底、床底、狭窄过道等场景被卡住后能否自动脱困或发出提醒。悬崖响应在台阶边缘机器人停止或转向的灵敏度。测试导航避障时建议把每一个场景都录像。因为导航问题是空间和时序相关的只看文字记录很难还原现场。3.4 安全与可靠性测试安全测试和可靠性测试决定产品能不能长期稳定使用这部分问题一旦发生往往是批量性的后果也比较严重。安全类测试项碰撞力度机器人撞击障碍物时的力度是否在安全范围尤其是老人和儿童家具。充电安全充电过程中电池温度、充电座温度是否正常是否有过充保护。噪音水平最大吸力模式下整机噪音是否在标准限值内。电气安全整机是否存在漏电风险电源适配器是否通过认证。阻燃要求主控板、电池区域是否使用阻燃材料。可靠性类测试项长时间运行连续运行多少小时或多少个清扫循环后功能是否正常。耐久测试滚刷、边刷、轮子、拖布支架在模拟耐久测试后是否磨损严重。跌落测试搬运、意外跌落情况下整机结构是否损坏。高低温环境在高温、低温环境下电池放电、充电是否异常。湿度与防水拖地后底部是否进水传感器是否受潮失灵。可靠性测试周期长、耗材多一定要在项目早期就排入测试计划否则等产品快上市了才做风险非常大。3.5 App 与联动测试现在扫地机器人很少脱离 App 单独使用App 侧的测试也属于整机测试范围。App 相关测试项配网与连接机器人配网成功率、配网耗时、配网失败后的恢复机制。实时状态App 中状态展示与实际机器人状态是否一致比如清扫中、暂停、回充、故障。地图管理地图加载、重命名、编辑、重置是否正常。远程控制手指方向键控制机器人移动的响应时延和准确性。固件升级整包升级、增量升级、升级失败后回滚机制。多设备管理一个 App 绑定多台机器人家庭共享成员权限是否正常。断网场景路由器重启、Wi-Fi 断开、切网后 App 与机器人的恢复表现。App 联动测试的核心在于“状态一致性”。机器人端的状态和 App 端的状态必须时刻同步只要出现一次“App 显示回充中但机器人还在原地清扫”的现象就是一个潜在客诉点。4. 从需求到用例整机测试用例设计方法4.1 测试用例要素与模板和软件测试一样扫地机器人整机测试也需要有明确的测试用例。一条完整的整机测试用例建议包含以下信息。用例字段说明示例用例编号唯一标识便于管理TCS-NAV-0001所属模块功能模块或测试项分类导航避障测试标题一句话描述测试场景冰箱与墙之间窄缝通过性测试前置条件测试开始前需要满足的条件机器人电量80%以上场地已布置窄缝测试步骤可执行的操作步骤1. 将机器人放置在窄缝前 2. 启动自动清扫 3. 观察机器人进入窄缝的行为预期结果符合需求的行为描述机器人可通过窄缝或检测到空间不足后自动转向不陷入卡死实际结果执行后的真实表现通过备注日志路径、视频编号、设备编号样机SNSN20250301日志路径/log/nav/20250301_01.tar.gz在这个模板基础上每个用例还可以增加“测试数据”“关联需求编号”“用例优先级”等字段。重点是每一条用例都要能追溯到需求否则测试没有依据。4.2 用例优先级与场景矩阵整机测试用例数量通常很大不可能每一条都在每个版本完整回归所以要对用例做优先级划分。P0核心功能和安全相关一旦失败就阻断发布。比如悬崖跌落、充电起火风险、无法开机。P1用户高频使用场景失败会影响体验。比如建图失败、回充失败、拖地不出水。P2低频场景或边界场景失败影响有限。比如定时任务在跨天场景下不执行。P3体验优化类属于建议项。比如提示音音量大小不合适。除了单条用例的优先级还建议做“场景矩阵”。因为整机测试更关注多个功能叠加之后的组合表现。比如组合场景低电量10% 开启拖地 断网 预约清扫启动。这种多条件叠加的场景单个功能测试时不会发生但用户真实使用时可能遇到。4.3 用例执行与记录用例执行看起来简单实际对整机测试工程师的要求非常高。执行时要注意严格按照前置条件准备环境特别是电量、场地布置、网络状态。每一步操作要留痕迹机器人上的操作、App 上的操作、环境的改变都要记录。发现异常不要立即重置环境先保留现场抓取日志录像拍照。执行完每一条用例后及时更新用例状态避免事后回忆。对于扫地机器人测试来说现场记录能力尤其重要。很多问题只能在特定位置、特定时间复现测试人员如果没有良好的记录习惯问题后续处理会非常困难。5. 高频问题定位与缺陷分析5.1 常见问题现象与原因对照扫地机器人整机测试中下面这些问题出现频率很高。问题现象常见原因初步排查思路清扫过程中突然停止App 无报错传感器数据异常或任务线程卡死查看主控日志确认是软件异常还是硬件掉线机器人找不到充电座充电座信号接收异常或地图定位漂移检查充电座是否被遮挡查看红外地标识别状态建图后地图倾斜或房间错位IMU 数据漂移或 SLAM 初始化时机器人被移动查看陀螺仪原始数据对比建图时机器人移动路径拖地拖不干净出水量不足或拖布贴合压力不够检查水泵出水量、拖布支架装配间隙App 显示离线实际和机器人连接正常云端长连接断开App 与云端状态不同步抓取 App 与云端接口数据查看 websocket 状态边刷把垃圾打飞边刷转速与行走速度不匹配对比高速、低速模式下的垃圾轨迹这些问题在测试中很难完全避免关键是遇到问题后能不能快速定位根因。定位能力是整机测试工程师和初级测试员拉开差距的核心。5.2 问题复现技巧机器人测试中的问题复现比纯软件测试要复杂因为它依赖物理环境。我的建议是记录问题发生的精确坐标。在测试场地地面上用贴纸做标记问题在哪里发生就记录哪个格子的坐标。保持环境不变化。发现问题后先不要移动机器人不要扫地不要收走障碍物原样拍视频。固化触发条件。找出问题触发的必要条件是什么比如“电量低于 20%”“地毯边缘”“强光直射激光雷达”。用最小化场景复现。先把问题简化到最少的条件组合比如只保留一个障碍物看问题是否还能复现。复现的价值在于给开发提供可操作的输入。如果测试人员只提“清扫时卡住”开发很难定位如果测试人员能给出“机器人在坐标 (120, 80) 附近剩余电量 30%地面有一根黑色数据线触发红外避障后反复横跳”开发就更容易找到算法里的问题。5.3 从日志和传感器数据定位问题日志是定位问题的第一手材料。下面是一个简单的 Python 脚本示例用于解析机器人导出的传感器日志提取指定时间段内的传感器数据。# 文件路径tools/parse_sensor_log.py 解析扫地机器人传感器日志的示例脚本 日志格式假设为 CSV字段如下 time, sensor_type, sensor_value import csv import sys from collections import defaultdict def load_sensor_log(file_path): data defaultdict(list) with open(file_path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: sensor_type row.get(sensor_type, ).strip() try: value float(row.get(sensor_value, 0)) except ValueError: value 0.0 data[sensor_type].append({ time: row.get(time, ).strip(), value: value, }) return data def query_range(data, sensor_type, start_time, end_time): 提取某个传感器在指定时间范围内的数据 result [] for item in data.get(sensor_type, []): if start_time item[time] end_time: result.append(item) return result if __name__ __main__: if len(sys.argv) ! 2: print(用法: python parse_sensor_log.py 日志文件路径) sys.exit(1) log_file sys.argv[1] sensor_data load_sensor_log(log_file) # 示例查看 IMU 和超声波传感器数据 for sensor in [imu_gyro_z, ultrasonic]: print(f传感器类型: {sensor}) for item in sensor_data.get(sensor, [])[:10]: print(f 时间: {item[time]}, 数值: {item[value]})这个脚本帮你快速筛选出不同类型传感器随时间变化的数据。实际项目中你可以根据主控日志格式调整解析逻辑。当开发需要查看某个时段的数据时这类小工具能节省大量人工翻日志的时间。6. 自动化测试在整机测试中的应用6.1 哪些环节适合自动化不是所有整机测试都适合自动化盲目自动化反而会增加维护成本。我比较推荐从下面几个环节开始App 配网、状态展示、远程控制这类操作适合用 App 自动化框架来跑。日志抓取和日志分类保存适合用脚本自动化。重复性回归用例比如开关机 100 次、回充 50 次可以结合硬件工装做自动化。传感器数据一致性检查适合用脚本解析和校验。不适合自动化的场景通常是强物理操作类比如布置宠物粪便、模拟毛发缠绕这些场景人为布置更接近真实。6.2 App 自动化测试示例扫地机器人 App 的自动化测试可以基于 Appium 或 Android 原生测试框架来做。下面是一个简化示例展示用 Python pytest Appium 控制 App 内点击“开始清扫”按钮并校验状态的过程。# 文件路径test_app_sweep.py 扫地机器人 App 自动清扫测试示例 需要提前安装 appium、pytest 和对应 driver import pytest from appium import webdriver def init_driver(): caps { platformName: Android, appPackage: com.example.robotapp, appActivity: .MainActivity, noReset: True, } return webdriver.Remote(http://localhost:4723/wd/hub, caps) pytest.fixture(scopemodule) def driver(): drv init_driver() yield drv drv.quit() def test_start_sweep(driver): # 进入主界面后找到“开始清扫”按钮并点击 start_btn driver.find_element(id, btn_start_sweep) start_btn.click() # 等待状态切换为“清扫中” driver.implicitly_wait(5) status_text driver.find_element(id, tv_status).text assert 清扫中 in status_text, f状态异常当前显示: {status_text} def test_stop_sweep(driver): # 点击“暂停/停止”按钮 stop_btn driver.find_element(id, btn_pause) stop_btn.click() driver.implicitly_wait(3) status_text driver.find_element(id, tv_status).text assert 已暂停 in status_text, f状态异常当前显示: {status_text}这段代码的主要作用是验证 App 点击指令后界面状态是否正确变化。真实项目中还需要处理弹窗、耗时等待、截图失败信息等细节。测试执行前必须用一台已经完成配网的机器人和一个可登录的测试账号。需要注意的是App 自动化只能证明 App 层面响应正常不能证明机器人真实开始清扫。要验证整机行为还需要在机器人侧通过电流变化、运行日志、传感器数据等做交叉确认。这是 App 自动化和整机自动化最大的区别。6.3 数据回放与回归机器人测试中还有一种很实用的自动化手段——传感器数据回放。借助仿真平台或数据回放工具把实际采集到的传感器数据回放给导航算法验证算法修改后是否仍然能正确处理同一段场景。这种方式的优点是不依赖实体机器人可以并行跑大量场景。回归速度快同一份数据可以反复回放。可比较性好算法修改前后的输出可以直接对比。它不能完全替代整机实测因为传感器数据和真实环境之间还有差异但作为回归手段非常有价值。7. 测试报告与项目推进经验7.1 测试报告的结构一份完整的扫地机器人整机测试报告至少要包含以下几个部分。测试版本信息固件版本、App 版本、云平台版本、样机编号。测试环境描述场地类型、地面材质、特殊障碍物布置。测试范围与用例统计本次执行了多少条用例P0/P1/P2 各多少条通过率多少。问题清单遗留问题、已关闭问题、阻塞问题。风险说明哪些问题可能影响发布时间、涉及哪个模块。测试结论建议通过、有条件通过或不通过。写测试报告时尽量用数据说话。比如“P0 用例 45 条通过 43 条通过率 95.6%”比写“基本通过”更有说服力。7.2 缺陷分级与流转整机测试的问题要按严重程度分级一般分为四类。致命缺陷可能导致安全事故、主控板烧毁、机器人完全无法工作。严重缺陷核心功能不能使用比如无法建图、无法返回充电座。一般缺陷功能可用但体验较差比如沿边清扫漏扫较大区域。轻微缺陷不影响功能但影响观感或细节体验比如提示音文字显示错误。Android 端或内部缺陷管理工具处理流程通常是测试人员提交缺陷 - 开发分析定位 - 修复后提交测试 - 测试回归 - 关闭。整机测试中缺陷复现频率很重要如果一条问题只出现一次一定要在提交时注明偶然性并尽量补充现场记录。7.3 测试准入准出建议扫地机器人项目的测试不可能无限期进行建议项目组提前约定测试准入准出条件。准入条件可以包括本轮测试固件已编译完成版本号清晰。已知致命问题已修复或已有明确绕过方案。测试样机数量和状态满足测试计划要求。准出条件可以包括P0 用例通过率 100%。P1 用例通过率达到 95% 以上没有未关闭的严重缺陷。遗留缺陷有明确的风险评估和排期。测试报告已输出测试结论已确认。如果你正在负责整机测试的排期建议把可靠性测试的时间留足这是最容易压缩也最容易出问题的板块。8. 想入行机器人测试应该补哪些技能8.1 技能地图很多同学关心机器人测试岗位怎么准备。结合行业常见要求我整理了一张技能地图。基础测试能力测试用例设计、缺陷生命周期、测试报告编写这是所有测试岗位通用的基础。软硬件结合知识理解传感器、电机、电池、充电座、Wi-Fi 模块的基本原理不需要会硬件设计但要能看懂硬件参数和异常现象之间的关系。系统与日志能力能使用串口、ADB 命令能看懂系统日志能快速提取关键信息。数据分析能力能用 Python 或 Excel 处理传感器数据做简单的统计分析和异常判断。自动化能力至少掌握一种自动化测试框架比如 Pytest、Appium能写简单的自动化脚本。场景化测试思维能站在用户实际使用场景设计测试用例而不是只盯着需求文档。对应岗位面试时考官通常不会问特别偏门的源码细节更关注你是否理解整机测试的流程和思路。8.2 学习建议如果你是从软件测试转过来建议按顺序补齐这几块经验。第一步先买或借一台扫地机器人把它当测试对象用起来。熟悉 App 的每个功能入口记录使用过程中的异常现象。这是成本最低、效果最好的入门方式。第二步尝试抓取和分析日志。无论是串口日志还是 App 日志学会查看报错信息、传感器数据、任务状态建立“现象 - 日志 - 原因”之间的关联能力。第三步自己搭建一个简单的测试环境。不需要专业实验室家里一小块地面、几样障碍物、一台机器人和一台电脑就能完成大量基础测试。第四步找机会参与真实项目。可以是实习、外包项目也可以是自己动手拆机分析。重点是积累真实的整机测试经验尤其是缺陷定位和项目推进的经验。8.3 面试关注点面试的时候以下几类问题出现频率比较高。扫地机器人由哪些核心模块组成每个模块的作用是什么碰到机器人清扫到一半不走了你会怎么排查导航测试用例你会怎么设计如何验证 App 上的“清扫完成”是真的完成了如何评估一块木地板上的清扫效果回答这些问题的核心逻辑是先讲清楚“我会怎么做”再讲“为什么这么做”最后补充“如果遇到异常我会怎么处理”。能把这个逻辑讲清楚比背知识点更有说服力。关于行业环境可以理性看待。机器人测试岗位的薪资和城市、行业、个人实际能力都有关系不存在简单“拿下”一说。真正重要的是你能不能独立完成一条测试闭环从需求分析、方案设计、用例执行到缺陷定位、问题跟进、结论输出。这一整套能力无论在哪个测试岗位上都是长期通用的。