软件测试确实是当前被 AI 工具渗透最明显的工作之一尤其是用例生成、回归执行、日志分析这类重复度高的环节。但如果你只看“替代”两个字容易忽略测试领域内部正在发生的另一个变化嵌入式、物联网、机器人方向的新测试需求在增加。尤其是人形机器人从原型走向量产的过程中芯片级测试、嵌入式系统测试、ROS2 系统联调正在成为软件测试人员可以转向的新方向。这篇文章不是劝你立刻转行而是把“AI 替代软件测试”这个话题拆开看AI 到底替代了什么留下了什么为什么人形机器人芯片测试这个方向值得关注以及如果要转Linux、ROS2、物联网、单片机这条链路该怎么准备。1. AI 在测试里真正替代了什么又留下了什么1.1 最先被工具接管的测试工作先说实话AI 对软件测试的冲击不是未来时而是现在时。很多以前需要人工完成的活儿现在工具能自动搞定。第一个是测试用例生成。以前写用例要对着需求文档一条条梳理现在把接口文档或需求描述喂给大模型工具它能生成一批覆盖正常流程、参数边界、异常输入的用例。虽然不能直接用但作为初稿能省不少时间。第二个是回归执行。UI 自动化、接口自动化框架已经成熟配合 AI 定位页面元素、自动修复脚本回归效率比以前高很多。以前每周花一天跑回归现在可能只需要半天盯结果。第三个是缺陷初筛。日志分析、崩溃堆栈归类、截图对比这些工作AI 工具处理得很快。一个崩溃日志从几百条记录里定位到关键堆栈用脚本加模型辅助几分钟就能出结论。第四个是测试报告。把测试结果、覆盖率、失败用例、缺陷等级汇总成一份报告用模板加数据填充完全可以自动化。这类工作有一个共同特点规则明确、重复执行、结果可判断。AI 做起来非常顺手。如果你过去几年主要在做纯手工点击、照着模板写用例、跑完回归填表格那确实会感受到明显压力。1.2 AI 暂时接不住的测试工作但测试工作里还有很大一部分是 AI 接不住的至少目前接不住。需求歧义判断就是典型例子。当产品需求本身有矛盾或者需求和真实用户场景冲突时测试人员要决定该不该测、测到什么程度、哪些问题必须提出来。这个判断依赖对业务的理解也依赖对用户场景的敏感度不是从需求文字里能直接推出来的。边界和异常设计同样难自动化。AI 可以生成“输入为空、超长字符串、非法格式”这类常规边界用例但涉及状态机切换、中断打断、异常恢复、断电重启这样的场景它缺少对物理系统和真实环境的理解。尤其是嵌入式系统很多异常不是输入引起的而是时序、电源、外部干扰造成的。风险优先级判断也是人的活。哪些缺陷必须修复哪些可以带病发布需要结合用户影响、业务目标和开发成本来权衡。AI 能告诉你这个缺陷的复现步骤和出现频率但没法替你承担这个判断责任。还有问题根因定位。AI 能告诉你哪个用例失败了但无法替你去嵌入式设备上判断是寄存器配置错误、时序竞争、还是硬件电压不稳。这种跨层的根因分析恰恰是测试最有价值的环节。所以更准确的理解是AI 在重新分配测试人员的工作内容而不是消灭测试职能。重复的执行工作减少分析、设计、跨层验证的要求反而提高了。2. 为什么嵌入式人形机器人芯片测试会成为新的需求点2.1 人形机器人对“稳定”的要求远超普通软件人形机器人这个赛道热度一直很高很多团队在从原型走向量产验证。这个阶段最缺的不是算法工程师而是能验证系统在真实环境下稳定运行的人。为什么芯片测试在这个方向里这么关键因为人形机器人的安全性和可靠性要求远高于普通消费软件。普通 App 崩溃了可以重启用户最多抱怨一句。但人形机器人在执行行走、抓取、协作任务时如果主控芯片出现一个临时计算错误、一个通信误码、一个未响应的中断可能导致电机控制异常、姿态失衡轻则任务失败重则损坏设备。所以在人形机器人团队里芯片级测试不是可选环节而是从芯片选型、板级设计到系统集成都要参与的质量保证工作。过去只在军工、航天、汽车电子里重点关注的可靠性测试现在开始进入机器人领域。这个变化对测试人员来说是一个典型的增量市场。老赛道在压缩新赛道在扩张而且扩张速度比培养人才的速度快。2.2 芯片测试和软件测试的差异芯片测试和软件测试的差别可以先用一张表看清楚维度软件测试芯片/嵌入式系统测试测试对象代码逻辑物理器件 固件 系统行为输入数据/请求电平、时钟、指令、外部事件输出返回结果信号、功耗、执行时序、控制动作主要关注点功能、性能、兼容性功能、时序、功耗、温度特性、信号完整性缺陷复现通常容易复现偶发问题多受外部干扰影响大自动化方式脚本驱动接口/UI需要硬件工装、测试台架、串口/总线控制日志来源应用日志、服务日志芯片寄存器、内核日志、总线抓包、示波器波形软件测试的对象是逻辑输入是数据输出是结果。芯片测试的对象是物理器件除了逻辑错误还要关注电压和功耗。低功耗模式切换时会不会出现电压跌落、唤醒时间是否符合规格这些问题在软件测试里根本不存在。时钟和时序也很关键。高频通信时数据采样是否正确总线仲裁有没有竞争中断嵌套会不会丢失事件这些需要测试人员理解芯片手册和系统调度逻辑。温度特性同样重要。不同温度下芯片工作频率会不会漂移散热设计是否满足长时间高负载运行这些问题需要结合环境测试来验证。还有引脚和信号完整性。信号质量、噪声、串扰这些通常要用示波器看波形。对纯软件背景的测试人员来说这是一块需要补齐的知识但没有想象中那么难。2.3 为什么说“会软件又会硬件”的人少这个方向真正的门槛不在某个单独领域而在交叉。大多数软件测试工程师不熟悉电路看到原理图就头大。大多数硬件工程师又不习惯测试金字塔、自动化脚本、缺陷生命周期管理。人形机器人芯片测试刚好卡在两者中间要懂芯片规格能看原理图和寄存器手册要会写测试脚本能搭自动化测试流程还要能用 ROS2 做系统级验证能把单个芯片的测试结果和整个机器人系统的表现关联起来。这种交叉能力不是培训两周就能补齐的。它需要同时具备软件工程思维、嵌入式系统知识和基本的硬件判断力。正因为供给少需求又在涨这个方向才值得关注。3. ROS2 在机器人测试里的实际位置3.1 ROS2 是什么测试人员需要先理解什么如果你从没接触过 ROS2第一次听到这个名字可能以为它是个操作系统。其实 ROS2 是机器人领域常用的开源软件框架全称叫 Robot Operating System但它并不是传统意义上的操作系统而是跑在 Linux 上的一组通信库、工具和功能包。ROS2 里的核心概念不多测试人员不需要从头实现但必须能看懂。节点是 ROS2 的最小运行单元一个节点就是一个可执行程序负责一个相对独立的功能。一个机器人系统里可能有传感器节点、控制节点、导航节点、决策节点。话题是节点之间异步通信的通道采用发布/订阅模式。比如 IMU 节点持续发布姿态数据控制节点订阅这个话题获取数据。服务是请求/响应式通信适合“问一次、答一次”的场景比如调用一个服务查询当前电池电量。动作是带反馈的长任务通信适合执行一个需要较长时间并持续反馈进度的任务比如让机械臂移动到某个位置。参数是节点运行时可以调整的配置项比如 PID 参数、通信频率、阈值设置。对测试人员来说ROS2 的价值在于它把机器人的软硬件模块解耦成了可以单独验证的单元同时提供了一整套诊断工具。3.2 ROS2 测试里最常用的几个操作建议把 ROS2 的命令行工具当成测试工具箱而不是开发工具。下面这些是验证系统行为最常用的操作。查看节点列表和话题列表ros2 node list ros2 topic list订阅某个话题看消息内容ros2 topic echo /imu/data查看话题发布频率ros2 topic hz /imu/data录制和回放数据包ros2 bag record -a ros2 bag play bag_directory可视化传感器数据和机器人模型rviz2在实际测试中这些命令组合起来可以做很多事。比如人形机器人的 IMU 会持续发布姿态数据测试时先订阅这个话题确认消息格式正确、频率在预期范围内。然后人为停掉传感器节点看控制节点会不会进入安全保护逻辑系统日志会不会记录异常。这种测试在传统软件测试里没有对应物但它完全可以沿用测试的思维准备环境、执行操作、观察结果、记录日志、判断是否通过。实操建议第一次接触 ROS2 时不要在 Windows 上死磕。直接准备一个 Linux 环境用一台闲置电脑装 Ubuntu或者在开发机上用虚拟机。ROS2 的版本必须和 Ubuntu 版本匹配装之前先查对应关系否则依赖冲突会浪费很多时间。ROS2 版本与 Ubuntu 版本的常见对应关系ROS2 版本Ubuntu 版本Humble HawksbillUbuntu 22.04 LTSIron IrwiniUbuntu 22.04 LTSJazzy JaliscoUbuntu 24.04 LTS安装后先跑一个 talker/listener 的示例节点确认话题通信正常再继续后面的内容。这个动作就像软件测试里的冒烟测试先证明环境能跑通再讨论怎么测。4. 从单片机到物联网平台整条测试链路怎么拆4.1 一条典型链路人形机器人不是单块芯片在工作而是一个典型的分布式嵌入式系统。拆开看大概是这么几层。传感器层负责采集数据比如摄像头、IMU、关节角度传感器、力传感器。主控计算层负责跑算法和机器人控制逻辑通常是一颗算力较强的 SoC。微控制器层负责电机控制、PID 调节、IO 操作可能分布在每个关节的驱动板上。通信总线把组件连起来常见的有 CAN、SPI、I2C、UART。再往上还有物联网接入层负责远程诊断、数据上报、OTA 升级。测试人员面对的不再是“前端调接口”这一件事而是整条链路的每个环节。传感器没数据、总线丢包、主控算力不够、电机响应慢、云端指令延迟任何一个环节出问题最终表现都可能是一样的机器人动作异常。测试的价值就在于能定位到底哪一层出了问题。4.2 嵌入式开发的测试关注点嵌入式系统测试和桌面软件测试的关注点完全不同。梳理几个核心方向。启动过程测试。上电后到系统就绪需要多久有没有异常复位启动日志里有没有警告或错误。这个通常用串口日志加计时脚本来验证。内存和 Flash 测试。嵌入式系统内存有限内存泄漏、栈溢出、Flash 写入寿命都是常见问题。跑一个长时间稳定性测试监控内存占用和 Flash 写入次数比死磕代码更高效。中断响应测试。高优先级事件能不能及时响应会不会丢失中断。比如电机堵转时保护中断必须在规定时间内触发。通信稳定性测试。长时间运行 CAN 总线、SPI、UART 数据有没有丢包、错帧、重传。这个需要测试脚本持续采集错误计数。功耗验证。不同任务状态下比如待机、运行、通信、休眠电流变化是否符合设计要求。这对机器人这种自带电池的设备很关键。固件升级测试。升级包不完整怎么处理升级中断后能不能回滚升级完成后配置能否保持不变。这些测试靠手工做不现实必须写自动化脚本。测试人员如果懂一点单片机开发理解这些流程会快很多。你不需要自己写底层驱动但至少要知道 GPIO、ADC、UART、SPI 这些外设大概是什么能读懂简单的主循环和中断处理逻辑。4.3 物联网测试的核心场景人形机器人的远程监控、数据回传、OTA 升级都离不开物联网链路。物联网测试的核心场景和嵌入式测试不一样它更关注设备和平台之间的通信行为。设备接入场景包括首次连接、重新连接、断网重连。尤其要验证断网后设备的行为是静默等待、自动重连、还是进入本地降级模式。数据上报场景关注字段完整性、时间戳准确性、上报频率一致性。设备上报的数据如果偶尔缺字段到云端很难发现必须用脚本做字段级校验。指令下发场景关注云端控制指令到达设备的延迟、设备执行结果是否回传。对机器人来说远程急停指令的延迟是安全指标必须单独测。异常恢复场景弱网、断电、服务器重启时设备行为是否可控。设备会不会在服务器恢复后自动重新连接并补齐关键数据。多设备并发场景大批设备同时接入时平台稳定性、带宽占用、消息队列会不会堆积。物联网协议里MQTT 应该优先掌握。它的核心模型是发布/订阅设备作为客户端连接 broker然后发布消息或订阅主题。测试时可以用命令行工具模拟消息的发布和订阅验证云端和设备端的处理逻辑。测试时不要一上来就开最大并发。先用一台设备和一条消息确认收发链路正常再逐步增加设备数量和消息频率这样出现问题时能快速定位是协议问题、平台问题还是脚本问题。5. 想往这个方向走实际怎么准备5.1 技能清单从软件测试往嵌入式、机器人测试方向转不需要成为全栈工程师但需要建立一条清晰的主线。语言方面C 语言是嵌入式开发的核心至少要能读懂基本语法、指针、结构体、中断回调函数。Python 用于写测试脚本和数据分析比 C 更容易上手。Shell 用于 Linux 下的文件操作、日志抓取和定时任务。操作系统方面Linux 基本命令、文件系统、进程管理、系统日志要熟练。很多嵌入式设备跑的是嵌入式 Linux测试人员要在命令行下完成大量操作。通信协议方面UART、SPI、I2C、CAN 是嵌入式常用的至少要理解它们各自的应用场景、速率和接线方式。MQTT 是物联网的核心协议最好能自己写一个简单的收发示例。ROS2 方面重点掌握节点、话题、服务、bag 录制回放、rviz2。不需要深入算法但要能完成系统集成测试。测试方法方面需求分析、用例设计、自动化框架、持续集成这些软件测试的功底不能丢。嵌入式测试同样需要测试用例、问题追踪和验收标准。硬件基础方面能看懂原理图的关键部分会读芯片手册认识常见电子元器件。会用万用表是加分项会用示波器就更好了。5.2 学习路径建议第一步用 Linux。把主力开发环境切到 Ubuntu或者至少学会在虚拟机上熟练使用命令行。第二步选一块开发板。不用追求高端常见的 STM32 系列或者性价比高的开发板都可以。先把 GPIO 点亮一个 LED 跑通然后接一个传感器比如温湿度传感器或 IMU把数据读出来。第三步跑通一个小项目。把传感器数据通过串口打印出来再用 Python 脚本读取串口并做简单校验比如检查数据格式、更新频率、数值范围。第四步接触 ROS2。安装完成后先跑通官方的示例节点然后用 rviz2 查看仿真机器人模型再尝试订阅一个仿真传感器的数据。第五步把测试思维套进去。写一个脚本定时检查 ROS2 话题是否正常发布记录异常生成报告。这基本上就是一个最简单的机器人系统测试框架了。5.3 建议的第一个项目很多人一上来就想做完整的人形机器人这完全不现实。人形机器人的关节驱动、平衡控制、感知融合任何一块都够学半年。更好的做法是从一个很小的闭环开始。建议做一个“环境监测节点”用一块开发板读取环境温度或湿度数据通过 MQTT 上报到本地服务器再写一个脚本定时检查数据是否完整、频率是否稳定。人为断开网络验证设备能不能自动重连。这个项目覆盖的知识点非常完整。单片机开发负责传感器读取和数据处理物联网协议负责数据上报服务器端负责接收和存储测试脚本负责自动化验证日志记录负责问题定位。做完这个项目你至少能理解嵌入式系统和物联网测试的完整流程。如果还想进一步接触机器人方向可以把传感器的数据包装成 ROS2 话题用 rviz2 做可视化。这样就把嵌入式开发、物联网、ROS2 三个方向串起来了。5.4 常见坑点自己在学习和测试过程中踩过一些坑也看别人踩过列几个常见的。不要在开发板正在写 Flash 的时候随便拔电可能导致固件损坏。操作固件升级或烧录时先确认电源稳定。串口乱码优先检查波特率是否匹配其次检查 USB 转串口芯片是否正常第三检查接线和地线。很多串口问题不是代码问题是物理连接问题。Linux 下访问 USB 串口经常遇到权限问题。把当前用户加入 dialout 组或者用 udev 规则配置端口权限能省不少事。ROS2 版本和 Ubuntu 版本不匹配是安装阶段最常见的问题。装完一堆依赖后还是报错大部分原因是版本对应关系不对。装之前先查官方支持矩阵。测试脚本里不要硬编码串口设备名。在 Linux 下USB 串口的设备名可能因为插拔顺序变化建议根据 USB 设备 ID 自动匹配或者用 udev 固定命名。低功耗测试不能直接看开发板自带的 LED 判断状态要用电流表或专门的功耗测试工具。LED 只说明 MCU 没死说明不了功耗是否达标。6. 从软件测试转到这个方向要调整的不只是技能6.1 不要把自己定位成“测别人产品的人”传统软件测试里测试人员通常在需求确定之后介入按测试计划执行。但在嵌入式、机器人、芯片方向这种角色定位行不通。原因很简单很多质量问题是需求阶段就埋下的。处理器的算力是否够用、总线带宽能不能覆盖所有传感器的数据量、低功耗模式切换时传感器要不要断电、通信协议选择是否合理这些问题如果等到测试阶段才发现返工成本非常高。所以进入这个方向后测试人员必须尽早参与方案评审。你要在硬件选型讨论时提出可测试性要求在系统架构设计时考虑测试点如何预留在软件设计阶段就明确日志规范和错误处理策略。这个转变不是技能问题是思维方式问题。6.2 测试的角色会从“执行者”变成“质量定义者”软件测试领域有一个明显趋势测试人员在从“执行者”变成“质量定义者”。在机器人系统里这个趋势更明显。以前需求文档写好用例设计好测试人员照着执行就行。现在很多机器人团队连测试标准都还没有。什么样的姿态误差可以接受通信时延超过多少毫秒算异常长时间运行后内存占用增长多少算泄漏这些都需要测试人员参与定义。当你能定义这些标准的时候你就不再是一个可以随时被外包替换的执行角色。这也是为什么 AI 能替代执行型测试工作但很难替代质量定义工作的原因。6.3 接受“慢”和“不确定”嵌入式系统测试和普通软件测试的节奏很不一样。普通软件测试跑一个用例几秒钟就能看到结果嵌入式系统经常是“看起来正常但不知道有没有问题”。偶发丢包、时延抖动、低概率重启这些问题可能连续跑几天才复现一次。如果没有日志、没有现场信息根本无从排查。所以做这个方向要接受“慢”。长时间运行测试、反复复现、控制环境条件都是日常工作。你得学会用统计思维判断系统连续运行 72 小时出现 2 次异常到底能不能放行。这个判断标准不是拍脑袋定的而是根据故障影响、发生概率、安全等级综合决定的。另外要多保留现场信息。串口日志、总线抓包、传感器数据、电源波形、环境温度这些信息在问题排查时比什么都重要。宁可日志多一点也不要事后后悔没记录。其实回到最开始的问题AI 替代软件测试这个话题真正的判断不是“测试没前途了”而是“测试的方式在变”。执行型工作在被 AI 工具消化分析型、交叉型、定义型的工作反而在增加。嵌入式人形机器人芯片测试这个方向恰好集齐了交叉、分析、定义这三个关键词。如果你有软件测试的功底又愿意补嵌入式、ROS2、物联网这些知识这个方向值得认真看一看。建议从 Linux 环境和一块开发板开始先把第一轮小循环跑通再决定要不要深入。