企业官网建设流程全解析

最近不少做测试的朋友来问机器人测试怎么做，尤其是扫地机器人整机测试这一块。大家可能觉得机器人测试门槛高，其实把它拆开来看，很多思路和互联网测试是相通的，只是多了一些硬件、传感器和运动控制的概念。这篇文章就以扫地机器人整机测试为主线，从测试环境、测试项拆解、用例设计、缺陷定位到自动化思路，整理一套可以落到实际工作中的完整方案。

如果你准备进入机器人测试岗位，或者已经在做硬件测试但想系统梳理扫地机器人整机测试项，这篇文章都可以作为一个参照。全文不会涉及具体厂商的机密数据，所有案例和代码都是通用的工程实践，可以直接迁移到你的测试项目中。

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 测试用例要素与模板

和软件测试一样，扫地机器人整机测试也需要有明确的测试用例。一条完整的整机测试用例建议包含以下信息。

在这个模板基础上，每个用例还可以增加“测试数据”“关联需求编号”“用例优先级”等字段。重点是每一条用例都要能追溯到需求，否则测试没有依据。

4.2 用例优先级与场景矩阵

整机测试用例数量通常很大，不可能每一条都在每个版本完整回归，所以要对用例做优先级划分。

• P0：核心功能和安全相关，一旦失败就阻断发布。比如悬崖跌落、充电起火风险、无法开机。
• P1：用户高频使用场景，失败会影响体验。比如建图失败、回充失败、拖地不出水。
• P2：低频场景或边界场景，失败影响有限。比如定时任务在跨天场景下不执行。
• P3：体验优化类，属于建议项。比如提示音音量大小不合适。

除了单条用例的优先级，还建议做“场景矩阵”。因为整机测试更关注多个功能叠加之后的组合表现。比如：

组合场景：低电量（10%）+ 开启拖地 + 断网 + 预约清扫启动。这种多条件叠加的场景，单个功能测试时不会发生，但用户真实使用时可能遇到。

4.3 用例执行与记录

用例执行看起来简单，实际对整机测试工程师的要求非常高。

执行时要注意：

• 严格按照前置条件准备环境，特别是电量、场地布置、网络状态。
• 每一步操作要留痕迹，机器人上的操作、App 上的操作、环境的改变都要记录。
• 发现异常不要立即重置环境，先保留现场，抓取日志，录像拍照。
• 执行完每一条用例后，及时更新用例状态，避免事后回忆。

对于扫地机器人测试来说，现场记录能力尤其重要。很多问题只能在特定位置、特定时间复现，测试人员如果没有良好的记录习惯，问题后续处理会非常困难。

5. 高频问题定位与缺陷分析

5.1 常见问题现象与原因对照

扫地机器人整机测试中，下面这些问题出现频率很高。

这些问题在测试中很难完全避免，关键是遇到问题后能不能快速定位根因。定位能力是整机测试工程师和初级测试员拉开差距的核心。

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", encoding="utf-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(scope="module") 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 上的“清扫完成”是真的完成了？
• 如何评估一块木地板上的清扫效果？

回答这些问题的核心逻辑，是先讲清楚“我会怎么做”，再讲“为什么这么做”，最后补充“如果遇到异常我会怎么处理”。能把这个逻辑讲清楚，比背知识点更有说服力。

关于行业环境，可以理性看待。机器人测试岗位的薪资和城市、行业、个人实际能力都有关系，不存在简单“拿下”一说。真正重要的是你能不能独立完成一条测试闭环：从需求分析、方案设计、用例执行，到缺陷定位、问题跟进、结论输出。这一整套能力，无论在哪个测试岗位上，都是长期通用的。