“选择大于努力”这句话经常在职业赛道的话题里被提到放在机器人测试方向上也确实有它的道理。相比纯功能测试、Web 测试而言机器人整机测试需要同时接触机械结构、嵌入式系统、传感器算法、APP 联动和云端服务知识面更宽岗位的不可替代性也更高。这篇文章不承诺谁学完就一定能拿到一个固定薪资数字而是把整理的一套扫地机器人整机测试方法完整分享出来包括测试环境如何搭建、整机测试项如何设计、真实测试用例长什么样、日志怎么抓、常见问题怎么排查。如果你是想进入测试行业的新手或者已经是测试工程师想转机器人测试方向都可以沿着这条路线去实践。1. 机器人测试到底是什么为什么值得关注1.1 机器人测试岗位的工作内容机器人测试不是简单地在 APP 上点几个按钮也不是把“机器人能否工作”这样笼统的问题交给测试人员就算完。它要求测试人员从一台设备上电开始验证硬件、软件、算法、APP、云端之间的完整链路。以扫地机器人为例测试工作会覆盖整机功能、传感与算法、可靠性、系统联调、兼容性、安规安全六大模块。这些测试项并非彼此孤立一个电池老化问题可能会导致回充失败一个传感器脏污可能导致地图漂移测试人员需要学会把现象和日志关联起来像一个“产品侦探”一样定位缺陷的大致方向。整机测试常见的工作内容包括整机功能测试清扫、拖地、回充、预约、遥控、暂停、断点续扫等。传感与算法测试激光雷达或视觉传感器、陀螺仪、沿墙、避障、脱困、覆盖率。可靠性测试连续清扫、长续航、重复回充、跌落、越障、过线。系统联调测试与 APP、语音助手、小程序、云端账户联动。兼容性与环境测试不同户型、不同地面、不同光线、不同 WIFI 环境。安规安全测试电池保护、堵转、发热、跌倒、儿童安全。这些测试项不是孤立存在的往往会交叉影响。例如一块电池电量不足时机器人是否还能正确回充覆盖率与清扫时间如何取舍这要求测试人员既能执行用例也要能分析现象、定位缺陷的大致方向。1.2 为什么要单独说扫地机器人整机测试扫地机器人是消费级机器人中出货量很大、验证链条很完整的方向。它既有成本约束又要有较好的体验测试项多、周期紧、缺陷影响直观。学会扫地机器人整机测试项之后去接触其他移动机器人、服务机器人、甚至 AMR很多测试思路是相通的。从职业角度看机器人测试岗位对多学科知识的要求更全面不是只会点点点而是需要写用例、去现场搭场景、读日志、抓串口、分析传感器数据。这也是这个岗位薪资整体上高于纯功能测试的原因之一。不过必须客观说技能和项目经验是主要变量不是学完一篇教程就能拿到固定薪资。把扫地机器人整机测试吃透再去看工业 AMR、商用清洁机器人很多方法可以直接迁移。本文将重点放在可落地的方法和流程上。2. 测试环境与工具准备2.1 硬件环境搭建一台扫地机器人整机测试至少需要准备如下环境待测样机最好有 2 到 3 台便于对照测试。充电座和适配电源每次测试前确认充电桩位置固定。测试场地建议是一个至少 20 平方米的房间包含客厅、卧室、过道、门槛、地垫、地毯、桌椅、线缆等。障碍物数据线、拖鞋、体重秤、小玩具、宠物粪便模拟物等常见家庭障碍。电量管理每次测试前记录电量统一充到 100% 或同一电量基线。计时器与秒表记录清扫时长、回充时长。如果要做自动化测试还需要准备一个稳定的充电口和断电重启装置方便循环测试。测试场地要尽量贴近真实家庭环境而不是空荡荡的会议室因为很多用户遇到的清扫、脱困问题都出现在杂物较多的空间中。2.2 软件工具链下面是测试过程中比较常用的软件工具Android SDK Platform Tools包含 ADB用来连接机器人内部 Android 系统或 APP 调试。串口工具SecureCRT、MobaXterm、Minicom、Python pyserial 都可以。日志抓取工具各厂商通常有自己的日志抓取服务也会使用 adb logcat。数据记录工具Excel 或在线表格用于测试用例记录。自动化测试框架pytest、unittest用于编写用例脚本。视频录制工具手机支架固定拍摄回放分析故障。版本说明不同厂商的扫地机器人使用的芯片、传感器、嵌入式系统差异较大工具版本需要根据项目实际情况调整。本文示例以常见环境为例重点演示测试思路和方法具体命令参数请以实际产品文档为准。2.3 常见测试仪器功率计或功耗仪测整机功耗、待机电流、充电功率。噪音计测清扫或拖地时不同档位的噪音值。光照计评估视觉传感器在暗光、强光下的测试条件。卷尺或激光测距验证清扫覆盖率与机器人定位误差。温湿度计保证测试环境一致。千分尺或测厚规测量过障能力相关的结构尺寸。这些仪器不需要一开始全部配齐。如果只是个人学习手机秒表、卷尺、普通手机录像就能完成大部分功能测试如果是企业级整机测试再逐步补充专业仪器。3. 扫地机器人整机测试项拆解3.1 功能测试项功能测试是最基础的验证层主要回答“机器人能不能按产品定义完成任务”。扫地机器人功能测试通常从整机状态和清扫控制两个维度展开。待机与启动方面需要覆盖短按开机、长按关机、断电重启、指示灯颜色与闪烁频率、语音提示音量等场景。这里的关键不是“开关有没有反应”而是“异常状态下是否给出正确提示”例如电量不足时开机能否直接回充故障后能否恢复。清扫功能方面自动清扫要看机器人的弓字形路径、分区顺序和边界处理定点清扫要看清扫范围与时间是否符合预期沿墙清扫要关注边刷与滚刷的配合拖地功能则要验证拖布安装识别、水箱漏水、水量档位。这些用例看起来简单但很考验测试人员的观察力比如同一个位置每次清扫路径是否一致墙边是否留出明显的漏扫带。回充功能方面要重点关注低电量回充、清扫完成回充、手动回充、回充失败重试、断电续充等场景。回充不是简单“回去了就行”充电极片是否准确对接、回充时是否会顶偏充电座、回充失败后是否重新规划都是真实用户高频反馈的问题。预约与定时、记忆与断点也是功能测试的重要部分。预约测试要关注时区、重复规则、跨天任务断点续扫则要验证清扫中断、暂停超时、断电恢复后的续扫逻辑。很多用户“扫到一半没扫完”的投诉根源都在这些场景没有覆盖完整。3.2 导航与定位测试项导航与定位是扫地机器人最核心的能力也是整机测试中最难标准化、最容易暴露问题的模块。定位用大白话说就是机器人要时刻知道“我在哪里”建图是知道“房间长什么样”路径规划是回答“下一步往哪走”避障和脱困则是应对“路上突然出现的东西”。建图精度测试建议在真实房间中进行先在 App 中确认生成的户型图结构是否完整再用卷尺或激光测距仪随机抽测几个房间边长记录地图尺寸与真实尺寸的偏差。定位稳定性测试需要让机器人连续清扫较长时间观察地图是否存在拖影、墙体偏移或重定位。避障能力测试要覆盖数据线、拖鞋、垃圾桶、宠物玩具、桌椅腿、低矮体重秤等典型障碍物。需要记录机器人检测到障碍物的距离、是否减速、是否发生碰撞、碰撞力度有多大。脱困测试则更苛刻可以把机器人卡到椅子腿、床底、窗帘边、门槛缝里观察它能否自行脱困超时后是否正确上报故障。回充路径测试要从多个不同位置发起回充统计回充成功率并观察回充路径是否经过狭窄区域、充电桩附近的转向是否准确。充电桩一旦被移动机器人能否重新找回充电桩也是一个重要测试点。3.3 性能与可靠性测试项性能和可靠性与用户体验直接相关。续航能力测试要统一从 100% 电量开始使用标准档位清扫记录清扫时长、清扫面积和剩余电量观察电量估算是否准确。覆盖率测试建议选定一个固定测试区域使用机器人地图轨迹与物理空间对比估算已清扫面积比例。越障测试要准备常见门槛条、地毯边缘、电线、滑轨等验证不同数量障碍物组合下的通过能力。如果机器人宣称支持 2cm 越障就需要在 1.5cm、2cm、2.5cm 多档位去验证边界。毛发缠绕是扫地机器人特有的痛点长头发和宠物毛发缠绕滚刷后要看机器人是否会自动反向旋转解决滚刷是否方便清理。长时间运行测试适合用自动化或半自动化方式执行安排机器人每天固定清扫多次连续运行几天甚至几周记录故障率、功能衰减、异响、电池衰减等数据。这类测试往往能在正式发布前暴露出很多偶现缺陷。噪音测试要记录静音、标准、强效三档下的噪音值并区分主机噪音和充电座提示音。不同地面材质对噪音影响很大测试报告中要注明测试地面。3.4 安全与安规测试项安全测试不能省。跌落保护测试要在楼梯口、电梯缝隙、高低差台阶等场景进行确认机器人不会从高处跌落。堵转测试要用手或障碍物卡住滚刷、边刷、轮子确认电机能及时报错停止不会烧毁。电池保护要覆盖过充、过放、高温、低温等场景这些通常需要配合电池测试设备。发热测试要用测温枪巡检机器人表面、充电极片、电池仓位置在长时间运行后温度不能超过安全限值。儿童保护要检查小部件是否容易脱落、移动部件是否有夹手风险。EMC 和安规认证一般由专业实验室完成但作为整机测试人员至少要会做基础预测试保留记录。3.5 互联与兼容性测试项现在扫地机器人已经离不开 APP 和云端。WIFI 连接要覆盖 2.4G/5G 频段、隐藏 SSID、WPA2/WPA3 加密、弱网环境、路由器重启后自动重连等场景。APP 控制测试要验证开始、暂停、回充、地图查看、定时清扫、虚拟墙设置等核心操作。OTA 升级要重点验证升级包下载、升级中暂停、升级失败重试、升级中掉电恢复、升级后版本校验。语音助手联调要覆盖主流语音平台并关注同一局域网下多设备共存的场景。多用户家庭共享、成员权限管理也需要纳入兼容性测试范围避免出现 A 用户修改设置后 B 用户状态不同步的问题。4. 实战扫地机器人整机功能测试流程4.1 设计测试环境与场景我一般先画一张场地草图用卷尺量出测试区域尺寸标注障碍物位置、充电桩位置、边界线。然后把机器人放回充电座充到 100% 电量。每次测试前先清空地图或恢复出厂设置保证起始状态一致。一个标准的测试房间可以参考客厅沙发、茶几、电视柜、地毯、拖线板。卧室床、床头柜、窗帘、拖鞋。厨房或过道门槛、地面水渍。阳台推拉门滑轨、高低差。测试时固定拍摄机位包含全局俯拍、机器人正面、充电桩视角三个角度方便复盘。环境记录尽可能详细包括当天天气、光线、地面材质、障碍物照片这些信息在缺陷复现时非常关键。4.2 编写测试用例示例下面是一个标准的“自动清扫-回充”测试用例可以直接复制到 Excel 或测试管理工具中用例编号测试模块测试标题前置条件测试步骤预期结果优先级TC-CT-001清扫控制自动清扫完成后自动回充电量≥80%地图已建立房间无较多杂物1. 点击开始清扫2. 等待清扫完成3. 观察机器人是否自动回充机器人完成全屋清扫地图标记已完成区域自动回充到充电座P0TC-CT-002清扫控制低电量自动回充电量≤20%机器人正在清扫1. 开始清扫2. 等待电量降至阈值3. 观察机器人是否停止清扫并回充机器人停止当前清扫任务语音提示低电量自动规划路径回充P1TC-NAV-001导航定位避让线缆障碍地面放置模拟数据线1. 开始自动清扫2. 观察机器人接近数据线时的动作机器人检测到线缆后减速或绕行不吸入、不缠绕、不推挤P1TC-CHG-001回充模块回充成功后续扫清扫约 5 分钟手动暂停并让机器人回充1. 手动触发回充2. 充满后等待机器人自动续扫充满后机器人自动离开充电座继续之前未完成的清扫任务P2测试用例管理里建议包含测试日期、测试人员、软件版本、机型、电量、WIFI 网络、测试结果通过/失败/阻塞、备注。这样后续复现缺陷时不会缺少上下文。设计测试用例时不要只写“点击开始清扫”这种单一步骤要把前置条件、环境状态、数据状态写清楚。很多问题不是功能本身坏了而是特定状态下没有正确处理所以“电量 20% 以下”“地图已建立”“上一次任务未完成”这类前置条件往往是触发缺陷的关键。4.3 使用 ADB 抓取机器人日志不少扫地机器人内置了 Android 系统或类似 Linux 系统开启开发者模式后可以连接 ADB。通过 ADB 抓取正在运行的 logcat 日志是分析缺陷最有效的手段之一。在 Windows 或 macOS 上先安装 Android SDK Platform Tools然后确认设备连接adb devices # 输出示例 # List of devices attached # 123abc device连接成功后清空缓存并开始抓取日志adb logcat -c adb logcat -v threadtime robot_log_20250101.log在机器人运行过程中让测试人员去复现问题复现完成后按 CtrlC 停止抓取。日志文件里会包含导航模块、传感器模块、APK 的异常信息。如果只关注某个进程可以过滤adb logcat -s NavigationService:D SensorManager:E补充说明不同机型可能不支持 ADB或者日志标签名不同。可以先运行adb logcat | grep -iE nav|sensor|motor查看大致内容再决定过滤关键字。如果机型不支持 ADB也可以使用厂商提供的日志工具或串口输出。日志留存一定要及时不要等故障发生后重启机器人再抓因为重启会丢失大部分运行时信息。如果机器人内部把日志写到了某个固定目录还可以用 adb pull 拉回本地adb pull /sdcard/RobotLog/ /tmp/robot_logs/具体路径需要向开发确认不同产品差异很大。4.4 串口读取传感器数据很多机器人主板上会提供调试串口通过 USB 转 TTL 模块连接后可以读取机器人实时打印的传感器数据比如轮子编码器、陀螺仪、激光雷达帧数据。这里提供一个 Python 串口小工具示例用来实时读取并保存串口日志# 文件路径serial_logger.py import serial import time import datetime def read_serial_log(port, baudrate, log_file, duration600): 读取指定串口数据并写入日志文件 :param port: 串口号例如 /dev/ttyUSB0 或 COM3 :param baudrate: 波特率例如 115200 :param log_file: 日志保存路径 :param duration: 采集时长单位秒默认600秒 try: ser serial.Serial(port, baudrate, timeout1) except serial.SerialException as e: print(f无法打开串口: {e}) return end_time time.time() duration with open(log_file, a, encodingutf-8) as f: while time.time() end_time: line ser.readline() if line: decoded line.decode(utf-8, errorsreplace).strip() timestamp datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) content f[{timestamp}] {decoded} print(content) f.write(content \n) ser.close() print(f日志已保存到 {log_file}) if __name__ __main__: # 请根据实际情况修改串口号、波特率和采集时长 read_serial_log(/dev/ttyUSB0, 115200, robot_serial.log, 120)运行方式python serial_logger.py这段代码会把串口收到的每一行数据加上时间戳写入日志文件便于后续和 ADB 日志、视频录像对齐时间线分析是传感器先异常还是运动控制先异常。串口日志通常都是开发定义的调试信息如果不熟悉数据含义可以先收集几天再请开发解释字段作用。4.5 使用 pytest 做简单接口测试扫地机器人通常有 APP 端接口比如绑定设备、开始清扫、查询地图。我们也可以把部分 API 测试自动化。以一个模拟接口为例# 文件路径test_robot_api.py import pytest import requests BASE_URL http://robot-api.test.example.com pytest.fixture def robot_token(): # 实际项目中需要先登录并获取token这里仅演示 resp requests.post(f{BASE_URL}/login, json{user: tester, password: ******}) assert resp.status_code 200 return resp.json().get(token) def test_start_clean(robot_token): headers {Authorization: fBearer {robot_token}} payload {device_id: ROBOT-001, action: start, mode: auto} resp requests.post(f{BASE_URL}/control, jsonpayload, headersheaders) assert resp.status_code 200 data resp.json() assert data.get(code) 0 assert data.get(message) success def test_start_clean_without_token(): payload {device_id: ROBOT-001, action: start} resp requests.post(f{BASE_URL}/control, jsonpayload) assert resp.status_code 401运行python -m pytest test_robot_api.py -v这样可以把比较规则化的网络接口回归自动化把人工重点放在导航、避障、用户体验等机器场景上。接口测试的难点在于测试数据和环境准备比如设备 ID、账号权限、测试机器人状态最好维护一套独立的测试环境避免影响真实用户。4.6 缺陷记录与测试报告缺陷记录建议包含缺陷编号、标题、发现版本、优先级、严重程度。复现步骤、预期结果、实际结果。环境信息机型、电量、WIFI、地图是否新建、测试场地。日志ADB 日志、串口日志、APP 日志。视频或图片附件最好有全局视角和机器人特写。初步判断模块导航、传感、运动、APP、机械、电源。测试报告至少包含测试范围、测试时间、软硬件版本。用例执行数、通过率、失败用例列表。缺陷统计按模块、严重程度、状态分布。风险项例如“电梯场景未验证风险中”。结论是否具备发布条件、遗留缺陷清单。一份清晰的测试报告不是简单贴一堆截图而是要让项目组一眼看到“当前版本能不能发还差哪些问题”。所以风险汇总和遗留缺陷清单比测试执行数量更受关注。5. 高频问题排查思路扫地机器人测试中很多缺陷看起来“像玄学”实际都有规律。下面列一些常见问题。5.1 定位漂移与地图错乱问题现象常见原因排查步骤解决思路地图拖影、墙体偏移激光雷达或视觉传感器脏污清洁传感器检查遮罩增加防污染结构或算法滤波地毯区域定位漂移传感器在地毯表面特征不足对比硬地面与地毯特征在算法特征库中增加纹理特征机器人被搬动后定位失败没有检测到搬动查看搬动检测日志开启陀螺仪或 IMU 搬动检测长时间运行后定位误差积累里程计标定不准确对比轮子直径、码盘数据定期标定轮子与 IMU5.2 避障失败或频繁碰撞避障失败前提要看传感器的安装位置和检测范围。常见原因包括传感器未识别低矮障碍物比如数据线、体重秤薄边。障碍物反光或深色物体检测不到。触发避障后速度过快制动距离不够。算法为了覆盖率允许适当碰撞。排查流程先看日志中传感器是否检测到障碍物。如果没有检测到属于传感器或感知问题。如果检测到了但依然碰撞属于规划控制问题。用同一障碍物反复测试 5 次以上确认是偶发还是必现。记录最小检测距离与碰撞力度。5.3 回充失败问题现象常见原因排查步骤解决思路找不到充电桩充电桩位置移动过确认充电桩是否保持在初始位置重新建图或重置地图对准充电桩但接触不良充电极片氧化或偏移清洁极片检查充电桩是否水平做结构公差修正回充时反复转圈充电桩附近特征相似查看传感器数据与地图在充电桩附近增加标识物电量过低关机后无法回充电池保护机制触发检查电池电压增加低电保护策略5.4 WIFI 连接不稳定WIFI 问题需要区分是机器人 WiFi 模块问题还是 APP 后台问题。排查顺序用手机在同一位置测试路由器信号强度。换一台手机创建热点让机器人连接判断是否路由器兼容问题。抓取机器人端 WIFI 日志和 APP 端错误日志。查看是否关闭了 2.4G 频段、是否开启了访客隔离。测试不同加密方式WPA2、WPA3。5.5 清扫乱走或漏扫清扫乱走通常意味着定位已经失效机器人不知道自己在哪。可能原因包括地图丢失、陀螺仪标定丢失、传感器被遮挡、地面打滑导致里程计错误。排查步骤建议为恢复出厂设置并重新建图排除地图损坏。手动遥控机器人直线前进观察是否走偏。如果走偏检查轮子编码器和陀螺仪数据。如果正常再自动清扫复现乱走 扫地机器人整机测试实战：从环境搭建到日志排查
“选择大于努力”这句话经常在职业赛道的话题里被提到放在机器人测试方向上也确实有它的道理。相比纯功能测试、Web 测试而言机器人整机测试需要同时接触机械结构、嵌入式系统、传感器算法、APP 联动和云端服务知识面更宽岗位的不可替代性也更高。这篇文章不承诺谁学完就一定能拿到一个固定薪资数字而是把整理的一套扫地机器人整机测试方法完整分享出来包括测试环境如何搭建、整机测试项如何设计、真实测试用例长什么样、日志怎么抓、常见问题怎么排查。如果你是想进入测试行业的新手或者已经是测试工程师想转机器人测试方向都可以沿着这条路线去实践。1. 机器人测试到底是什么为什么值得关注1.1 机器人测试岗位的工作内容机器人测试不是简单地在 APP 上点几个按钮也不是把“机器人能否工作”这样笼统的问题交给测试人员就算完。它要求测试人员从一台设备上电开始验证硬件、软件、算法、APP、云端之间的完整链路。以扫地机器人为例测试工作会覆盖整机功能、传感与算法、可靠性、系统联调、兼容性、安规安全六大模块。这些测试项并非彼此孤立一个电池老化问题可能会导致回充失败一个传感器脏污可能导致地图漂移测试人员需要学会把现象和日志关联起来像一个“产品侦探”一样定位缺陷的大致方向。整机测试常见的工作内容包括整机功能测试清扫、拖地、回充、预约、遥控、暂停、断点续扫等。传感与算法测试激光雷达或视觉传感器、陀螺仪、沿墙、避障、脱困、覆盖率。可靠性测试连续清扫、长续航、重复回充、跌落、越障、过线。系统联调测试与 APP、语音助手、小程序、云端账户联动。兼容性与环境测试不同户型、不同地面、不同光线、不同 WIFI 环境。安规安全测试电池保护、堵转、发热、跌倒、儿童安全。这些测试项不是孤立存在的往往会交叉影响。例如一块电池电量不足时机器人是否还能正确回充覆盖率与清扫时间如何取舍这要求测试人员既能执行用例也要能分析现象、定位缺陷的大致方向。1.2 为什么要单独说扫地机器人整机测试扫地机器人是消费级机器人中出货量很大、验证链条很完整的方向。它既有成本约束又要有较好的体验测试项多、周期紧、缺陷影响直观。学会扫地机器人整机测试项之后去接触其他移动机器人、服务机器人、甚至 AMR很多测试思路是相通的。从职业角度看机器人测试岗位对多学科知识的要求更全面不是只会点点点而是需要写用例、去现场搭场景、读日志、抓串口、分析传感器数据。这也是这个岗位薪资整体上高于纯功能测试的原因之一。不过必须客观说技能和项目经验是主要变量不是学完一篇教程就能拿到固定薪资。把扫地机器人整机测试吃透再去看工业 AMR、商用清洁机器人很多方法可以直接迁移。本文将重点放在可落地的方法和流程上。2. 测试环境与工具准备2.1 硬件环境搭建一台扫地机器人整机测试至少需要准备如下环境待测样机最好有 2 到 3 台便于对照测试。充电座和适配电源每次测试前确认充电桩位置固定。测试场地建议是一个至少 20 平方米的房间包含客厅、卧室、过道、门槛、地垫、地毯、桌椅、线缆等。障碍物数据线、拖鞋、体重秤、小玩具、宠物粪便模拟物等常见家庭障碍。电量管理每次测试前记录电量统一充到 100% 或同一电量基线。计时器与秒表记录清扫时长、回充时长。如果要做自动化测试还需要准备一个稳定的充电口和断电重启装置方便循环测试。测试场地要尽量贴近真实家庭环境而不是空荡荡的会议室因为很多用户遇到的清扫、脱困问题都出现在杂物较多的空间中。2.2 软件工具链下面是测试过程中比较常用的软件工具Android SDK Platform Tools包含 ADB用来连接机器人内部 Android 系统或 APP 调试。串口工具SecureCRT、MobaXterm、Minicom、Python pyserial 都可以。日志抓取工具各厂商通常有自己的日志抓取服务也会使用 adb logcat。数据记录工具Excel 或在线表格用于测试用例记录。自动化测试框架pytest、unittest用于编写用例脚本。视频录制工具手机支架固定拍摄回放分析故障。版本说明不同厂商的扫地机器人使用的芯片、传感器、嵌入式系统差异较大工具版本需要根据项目实际情况调整。本文示例以常见环境为例重点演示测试思路和方法具体命令参数请以实际产品文档为准。2.3 常见测试仪器功率计或功耗仪测整机功耗、待机电流、充电功率。噪音计测清扫或拖地时不同档位的噪音值。光照计评估视觉传感器在暗光、强光下的测试条件。卷尺或激光测距验证清扫覆盖率与机器人定位误差。温湿度计保证测试环境一致。千分尺或测厚规测量过障能力相关的结构尺寸。这些仪器不需要一开始全部配齐。如果只是个人学习手机秒表、卷尺、普通手机录像就能完成大部分功能测试如果是企业级整机测试再逐步补充专业仪器。3. 扫地机器人整机测试项拆解3.1 功能测试项功能测试是最基础的验证层主要回答“机器人能不能按产品定义完成任务”。扫地机器人功能测试通常从整机状态和清扫控制两个维度展开。待机与启动方面需要覆盖短按开机、长按关机、断电重启、指示灯颜色与闪烁频率、语音提示音量等场景。这里的关键不是“开关有没有反应”而是“异常状态下是否给出正确提示”例如电量不足时开机能否直接回充故障后能否恢复。清扫功能方面自动清扫要看机器人的弓字形路径、分区顺序和边界处理定点清扫要看清扫范围与时间是否符合预期沿墙清扫要关注边刷与滚刷的配合拖地功能则要验证拖布安装识别、水箱漏水、水量档位。这些用例看起来简单但很考验测试人员的观察力比如同一个位置每次清扫路径是否一致墙边是否留出明显的漏扫带。回充功能方面要重点关注低电量回充、清扫完成回充、手动回充、回充失败重试、断电续充等场景。回充不是简单“回去了就行”充电极片是否准确对接、回充时是否会顶偏充电座、回充失败后是否重新规划都是真实用户高频反馈的问题。预约与定时、记忆与断点也是功能测试的重要部分。预约测试要关注时区、重复规则、跨天任务断点续扫则要验证清扫中断、暂停超时、断电恢复后的续扫逻辑。很多用户“扫到一半没扫完”的投诉根源都在这些场景没有覆盖完整。3.2 导航与定位测试项导航与定位是扫地机器人最核心的能力也是整机测试中最难标准化、最容易暴露问题的模块。定位用大白话说就是机器人要时刻知道“我在哪里”建图是知道“房间长什么样”路径规划是回答“下一步往哪走”避障和脱困则是应对“路上突然出现的东西”。建图精度测试建议在真实房间中进行先在 App 中确认生成的户型图结构是否完整再用卷尺或激光测距仪随机抽测几个房间边长记录地图尺寸与真实尺寸的偏差。定位稳定性测试需要让机器人连续清扫较长时间观察地图是否存在拖影、墙体偏移或重定位。避障能力测试要覆盖数据线、拖鞋、垃圾桶、宠物玩具、桌椅腿、低矮体重秤等典型障碍物。需要记录机器人检测到障碍物的距离、是否减速、是否发生碰撞、碰撞力度有多大。脱困测试则更苛刻可以把机器人卡到椅子腿、床底、窗帘边、门槛缝里观察它能否自行脱困超时后是否正确上报故障。回充路径测试要从多个不同位置发起回充统计回充成功率并观察回充路径是否经过狭窄区域、充电桩附近的转向是否准确。充电桩一旦被移动机器人能否重新找回充电桩也是一个重要测试点。3.3 性能与可靠性测试项性能和可靠性与用户体验直接相关。续航能力测试要统一从 100% 电量开始使用标准档位清扫记录清扫时长、清扫面积和剩余电量观察电量估算是否准确。覆盖率测试建议选定一个固定测试区域使用机器人地图轨迹与物理空间对比估算已清扫面积比例。越障测试要准备常见门槛条、地毯边缘、电线、滑轨等验证不同数量障碍物组合下的通过能力。如果机器人宣称支持 2cm 越障就需要在 1.5cm、2cm、2.5cm 多档位去验证边界。毛发缠绕是扫地机器人特有的痛点长头发和宠物毛发缠绕滚刷后要看机器人是否会自动反向旋转解决滚刷是否方便清理。长时间运行测试适合用自动化或半自动化方式执行安排机器人每天固定清扫多次连续运行几天甚至几周记录故障率、功能衰减、异响、电池衰减等数据。这类测试往往能在正式发布前暴露出很多偶现缺陷。噪音测试要记录静音、标准、强效三档下的噪音值并区分主机噪音和充电座提示音。不同地面材质对噪音影响很大测试报告中要注明测试地面。3.4 安全与安规测试项安全测试不能省。跌落保护测试要在楼梯口、电梯缝隙、高低差台阶等场景进行确认机器人不会从高处跌落。堵转测试要用手或障碍物卡住滚刷、边刷、轮子确认电机能及时报错停止不会烧毁。电池保护要覆盖过充、过放、高温、低温等场景这些通常需要配合电池测试设备。发热测试要用测温枪巡检机器人表面、充电极片、电池仓位置在长时间运行后温度不能超过安全限值。儿童保护要检查小部件是否容易脱落、移动部件是否有夹手风险。EMC 和安规认证一般由专业实验室完成但作为整机测试人员至少要会做基础预测试保留记录。3.5 互联与兼容性测试项现在扫地机器人已经离不开 APP 和云端。WIFI 连接要覆盖 2.4G/5G 频段、隐藏 SSID、WPA2/WPA3 加密、弱网环境、路由器重启后自动重连等场景。APP 控制测试要验证开始、暂停、回充、地图查看、定时清扫、虚拟墙设置等核心操作。OTA 升级要重点验证升级包下载、升级中暂停、升级失败重试、升级中掉电恢复、升级后版本校验。语音助手联调要覆盖主流语音平台并关注同一局域网下多设备共存的场景。多用户家庭共享、成员权限管理也需要纳入兼容性测试范围避免出现 A 用户修改设置后 B 用户状态不同步的问题。4. 实战扫地机器人整机功能测试流程4.1 设计测试环境与场景我一般先画一张场地草图用卷尺量出测试区域尺寸标注障碍物位置、充电桩位置、边界线。然后把机器人放回充电座充到 100% 电量。每次测试前先清空地图或恢复出厂设置保证起始状态一致。一个标准的测试房间可以参考客厅沙发、茶几、电视柜、地毯、拖线板。卧室床、床头柜、窗帘、拖鞋。厨房或过道门槛、地面水渍。阳台推拉门滑轨、高低差。测试时固定拍摄机位包含全局俯拍、机器人正面、充电桩视角三个角度方便复盘。环境记录尽可能详细包括当天天气、光线、地面材质、障碍物照片这些信息在缺陷复现时非常关键。4.2 编写测试用例示例下面是一个标准的“自动清扫-回充”测试用例可以直接复制到 Excel 或测试管理工具中用例编号测试模块测试标题前置条件测试步骤预期结果优先级TC-CT-001清扫控制自动清扫完成后自动回充电量≥80%地图已建立房间无较多杂物1. 点击开始清扫2. 等待清扫完成3. 观察机器人是否自动回充机器人完成全屋清扫地图标记已完成区域自动回充到充电座P0TC-CT-002清扫控制低电量自动回充电量≤20%机器人正在清扫1. 开始清扫2. 等待电量降至阈值3. 观察机器人是否停止清扫并回充机器人停止当前清扫任务语音提示低电量自动规划路径回充P1TC-NAV-001导航定位避让线缆障碍地面放置模拟数据线1. 开始自动清扫2. 观察机器人接近数据线时的动作机器人检测到线缆后减速或绕行不吸入、不缠绕、不推挤P1TC-CHG-001回充模块回充成功后续扫清扫约 5 分钟手动暂停并让机器人回充1. 手动触发回充2. 充满后等待机器人自动续扫充满后机器人自动离开充电座继续之前未完成的清扫任务P2测试用例管理里建议包含测试日期、测试人员、软件版本、机型、电量、WIFI 网络、测试结果通过/失败/阻塞、备注。这样后续复现缺陷时不会缺少上下文。设计测试用例时不要只写“点击开始清扫”这种单一步骤要把前置条件、环境状态、数据状态写清楚。很多问题不是功能本身坏了而是特定状态下没有正确处理所以“电量 20% 以下”“地图已建立”“上一次任务未完成”这类前置条件往往是触发缺陷的关键。4.3 使用 ADB 抓取机器人日志不少扫地机器人内置了 Android 系统或类似 Linux 系统开启开发者模式后可以连接 ADB。通过 ADB 抓取正在运行的 logcat 日志是分析缺陷最有效的手段之一。在 Windows 或 macOS 上先安装 Android SDK Platform Tools然后确认设备连接adb devices # 输出示例 # List of devices attached # 123abc device连接成功后清空缓存并开始抓取日志adb logcat -c adb logcat -v threadtime robot_log_20250101.log在机器人运行过程中让测试人员去复现问题复现完成后按 CtrlC 停止抓取。日志文件里会包含导航模块、传感器模块、APK 的异常信息。如果只关注某个进程可以过滤adb logcat -s NavigationService:D SensorManager:E补充说明不同机型可能不支持 ADB或者日志标签名不同。可以先运行adb logcat | grep -iE nav|sensor|motor查看大致内容再决定过滤关键字。如果机型不支持 ADB也可以使用厂商提供的日志工具或串口输出。日志留存一定要及时不要等故障发生后重启机器人再抓因为重启会丢失大部分运行时信息。如果机器人内部把日志写到了某个固定目录还可以用 adb pull 拉回本地adb pull /sdcard/RobotLog/ /tmp/robot_logs/具体路径需要向开发确认不同产品差异很大。4.4 串口读取传感器数据很多机器人主板上会提供调试串口通过 USB 转 TTL 模块连接后可以读取机器人实时打印的传感器数据比如轮子编码器、陀螺仪、激光雷达帧数据。这里提供一个 Python 串口小工具示例用来实时读取并保存串口日志# 文件路径serial_logger.py import serial import time import datetime def read_serial_log(port, baudrate, log_file, duration600): 读取指定串口数据并写入日志文件 :param port: 串口号例如 /dev/ttyUSB0 或 COM3 :param baudrate: 波特率例如 115200 :param log_file: 日志保存路径 :param duration: 采集时长单位秒默认600秒 try: ser serial.Serial(port, baudrate, timeout1) except serial.SerialException as e: print(f无法打开串口: {e}) return end_time time.time() duration with open(log_file, a, encodingutf-8) as f: while time.time() end_time: line ser.readline() if line: decoded line.decode(utf-8, errorsreplace).strip() timestamp datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) content f[{timestamp}] {decoded} print(content) f.write(content \n) ser.close() print(f日志已保存到 {log_file}) if __name__ __main__: # 请根据实际情况修改串口号、波特率和采集时长 read_serial_log(/dev/ttyUSB0, 115200, robot_serial.log, 120)运行方式python serial_logger.py这段代码会把串口收到的每一行数据加上时间戳写入日志文件便于后续和 ADB 日志、视频录像对齐时间线分析是传感器先异常还是运动控制先异常。串口日志通常都是开发定义的调试信息如果不熟悉数据含义可以先收集几天再请开发解释字段作用。4.5 使用 pytest 做简单接口测试扫地机器人通常有 APP 端接口比如绑定设备、开始清扫、查询地图。我们也可以把部分 API 测试自动化。以一个模拟接口为例# 文件路径test_robot_api.py import pytest import requests BASE_URL http://robot-api.test.example.com pytest.fixture def robot_token(): # 实际项目中需要先登录并获取token这里仅演示 resp requests.post(f{BASE_URL}/login, json{user: tester, password: ******}) assert resp.status_code 200 return resp.json().get(token) def test_start_clean(robot_token): headers {Authorization: fBearer {robot_token}} payload {device_id: ROBOT-001, action: start, mode: auto} resp requests.post(f{BASE_URL}/control, jsonpayload, headersheaders) assert resp.status_code 200 data resp.json() assert data.get(code) 0 assert data.get(message) success def test_start_clean_without_token(): payload {device_id: ROBOT-001, action: start} resp requests.post(f{BASE_URL}/control, jsonpayload) assert resp.status_code 401运行python -m pytest test_robot_api.py -v这样可以把比较规则化的网络接口回归自动化把人工重点放在导航、避障、用户体验等机器场景上。接口测试的难点在于测试数据和环境准备比如设备 ID、账号权限、测试机器人状态最好维护一套独立的测试环境避免影响真实用户。4.6 缺陷记录与测试报告缺陷记录建议包含缺陷编号、标题、发现版本、优先级、严重程度。复现步骤、预期结果、实际结果。环境信息机型、电量、WIFI、地图是否新建、测试场地。日志ADB 日志、串口日志、APP 日志。视频或图片附件最好有全局视角和机器人特写。初步判断模块导航、传感、运动、APP、机械、电源。测试报告至少包含测试范围、测试时间、软硬件版本。用例执行数、通过率、失败用例列表。缺陷统计按模块、严重程度、状态分布。风险项例如“电梯场景未验证风险中”。结论是否具备发布条件、遗留缺陷清单。一份清晰的测试报告不是简单贴一堆截图而是要让项目组一眼看到“当前版本能不能发还差哪些问题”。所以风险汇总和遗留缺陷清单比测试执行数量更受关注。5. 高频问题排查思路扫地机器人测试中很多缺陷看起来“像玄学”实际都有规律。下面列一些常见问题。5.1 定位漂移与地图错乱问题现象常见原因排查步骤解决思路地图拖影、墙体偏移激光雷达或视觉传感器脏污清洁传感器检查遮罩增加防污染结构或算法滤波地毯区域定位漂移传感器在地毯表面特征不足对比硬地面与地毯特征在算法特征库中增加纹理特征机器人被搬动后定位失败没有检测到搬动查看搬动检测日志开启陀螺仪或 IMU 搬动检测长时间运行后定位误差积累里程计标定不准确对比轮子直径、码盘数据定期标定轮子与 IMU5.2 避障失败或频繁碰撞避障失败前提要看传感器的安装位置和检测范围。常见原因包括传感器未识别低矮障碍物比如数据线、体重秤薄边。障碍物反光或深色物体检测不到。触发避障后速度过快制动距离不够。算法为了覆盖率允许适当碰撞。排查流程先看日志中传感器是否检测到障碍物。如果没有检测到属于传感器或感知问题。如果检测到了但依然碰撞属于规划控制问题。用同一障碍物反复测试 5 次以上确认是偶发还是必现。记录最小检测距离与碰撞力度。5.3 回充失败问题现象常见原因排查步骤解决思路找不到充电桩充电桩位置移动过确认充电桩是否保持在初始位置重新建图或重置地图对准充电桩但接触不良充电极片氧化或偏移清洁极片检查充电桩是否水平做结构公差修正回充时反复转圈充电桩附近特征相似查看传感器数据与地图在充电桩附近增加标识物电量过低关机后无法回充电池保护机制触发检查电池电压增加低电保护策略5.4 WIFI 连接不稳定WIFI 问题需要区分是机器人 WiFi 模块问题还是 APP 后台问题。排查顺序用手机在同一位置测试路由器信号强度。换一台手机创建热点让机器人连接判断是否路由器兼容问题。抓取机器人端 WIFI 日志和 APP 端错误日志。查看是否关闭了 2.4G 频段、是否开启了访客隔离。测试不同加密方式WPA2、WPA3。5.5 清扫乱走或漏扫清扫乱走通常意味着定位已经失效机器人不知道自己在哪。可能原因包括地图丢失、陀螺仪标定丢失、传感器被遮挡、地面打滑导致里程计错误。排查步骤建议为恢复出厂设置并重新建图排除地图损坏。手动遥控机器人直线前进观察是否走偏。如果走偏检查轮子编码器和陀螺仪数据。如果正常再自动清扫复现乱走