前阵子和一个做测试的朋友聊天他说自己每天的工作已经练成了肌肉记忆提测、搭环境、跑回归、提 bug、催开发版本发布前再来一轮全量回归。效率越来越高心里却越来越没底。因为这份熟练没有形成壁垒新人半年就能追上AI 工具还在不断把用例生成和回归执行变得更廉价。他开始认真琢磨嵌入式测试不是一时冲动而是发现招聘市场里懂硬件、懂系统、能做软硬件联合验证的测试人才明显比纯业务测试稀缺得多。我给他的判断很简单软件测试“卷到失业”这个说法有些夸张但确实有一类测试岗位正在快速贬值那就是低门槛、高替代性、离系统底层很远的通用型业务测试。而嵌入式、机器人、芯片测试本质上是另一条路它不是在同一个池子里抢位置而是把测试能力迁移到更靠近硬件、更靠近系统底层的地方。这条路不等于“不卷”但它的稀缺性来自于复合能力。这篇文章不打算给你画一张“三个月上岸”的大饼而是想把这件事拆开来看软件测试的卷到底卷在哪嵌入式方向的测试有什么不一样以及一个普通业务测试要补齐哪些能力才可能完成这次迁移。1. 软件测试的“卷”本质是通用型测试能力在贬值1.1 业务测试的熟练很难变成职业壁垒先说一个没那么好听的事实基础业务测试岗位的供给已经明显大于需求。原因有三个。第一测试用例设计的方法论已经很成熟边界值、等价类、场景法、因果图这些知识到处都能学到稀缺性很低。第二测试平台和 AI 工具正在快速吃掉最基础的执行工作越来越多的公司可以用自动生成用例、自动比对结果、自动输出报告的方式替代一部分重复性手工验证。第三软件行业本身的增速在放缓当新增业务变少存量业务的测试需求也会趋于稳定。这三件事叠在一起就造成了一个结果一个只做“点点点”和“写用例”的通用型测试工程师经验积累一年和五年在市场上能体现出的差异并不大。你不是不努力而是努力的方向同质化太严重了。有人会问那测试开发岗呢测试开发确实门槛更高但它卷的是另一套东西框架开发、平台建设、工具链、CI/CD 集成。如果你已经在这条路上积累了多年那不需要非要转嵌入式。真正容易被困住的是技术栈偏业务、偏功能验证、工具链条薄弱的测试群体。1.2 但测试思维没有被淘汰只是需要重新“接上地气”这里我想把话说清楚测试思维的底层能力一点都没有过期。用例设计能力、缺陷敏感度、边界意识、风险判断、回归策略、问题复现能力这些在任何测试岗位上都是核心资产。问题不在于这些能力没用而在于它们和什么样的被测对象绑定。当你测试的对象是一个 App 的界面流程你的经验价值会被平台化工具快速稀释。当你测试的对象是一块单片机系统、一个 ROS2 机器人节点、一段嵌入式 Linux 驱动甚至一颗芯片时同样的用例设计能力就会变得稀缺很多。因为能写这类测试用例的人本来就少能理解硬件行为和系统时序的人更少同时具备这两种能力的人薪资和岗位稳定性自然会不一样。所以与其说测试行业在衰退不如说“通用型测试能力”正在经历一次重新定价。离系统底层越近的测试能力溢价越高。2. 嵌入式、机器人、芯片测试和你原来的测试有什么不一样2.1 被测对象从“界面/接口”变成了“软硬件一体系统”纯软件测试的输入输出通常是数据、界面状态、接口响应、文件或数据库记录。你在 UI 上点一个按钮预期弹出一个弹窗你调用一个接口预期返回一段 JSON。这套逻辑非常直接。到了嵌入式测试输入输出一下变得“物理化”了。一个单片机系统输入可能是传感器电压、按键电平、外部中断信号、通信总线上的数据帧输出可能是 GPIO 电平、PWM 波形、串口字符、LCD 显示、电机转动、继电器动作。你要验证的不再只是一段逻辑是否正确而是“软件逻辑 硬件电路 外部环境”三者共同作用下的整体行为是否正确。这意味着测试人员至少要看懂原理图上几个关键信号知道被测系统的供电域、参考电压、地线、复位电路、通信接口大概是怎么回事。不要求你会设计硬件但你不能对硬件完全没概念。一个常见的尴尬场景是测试发现传感器数据偶发跳变开发查了半天软件没有 bug最后发现是电源纹波干扰了 ADC 参考电压。如果测试人员完全没有硬件感知这类问题很容易被误判成软件缺陷或者在两个团队之间踢皮球。2.2 问题定位路径更长现象在应用层根源可能在驱动层甚至硬件层这是嵌入式测试和纯软件测试一个非常核心的区别同样是“有问题”纯软件测试的问题链通常很短从界面到后端逻辑很快能定位到模块而嵌入式系统的问题链可能横跨好几个层次。举一个典型例子一块 STM32 开发板上接了一个温湿度传感器串口每 200ms 输出一次数据。测试发现读数每隔几十秒会出现一次明显跳变超出正常范围。排查路径可能这样展开先怀疑应用层滤波是不是滑动滤波窗口太小没有滤掉毛刺。再查通信协议时序I2C 读取时是不是被中断打断了导致读到不完整数据。再看驱动层DMA 和中断配置是否有冲突。然后用示波器看电源纹波发现传感器供电在系统启动大电流外设时出现跌落。最后定位到根因PCB 布局和供电回路设计问题软件代码只是背锅。这个例子说明嵌入式测试的问题定位更像沿着一条“信号链路”从应用层往底层走每一层都有可能导致现象需要排除法慢慢收窄。这对测试人员的知识面要求远高于纯软件测试。2.3 这一簇岗位有很多细分方向先想清楚去哪里常说的“嵌入式测试”其实是一个家族而不是一个岗位。我大概梳理成几层嵌入式应用/固件测试偏软件主要验证单片机固件逻辑、状态机、参数计算常用 Unity、CMock 等单元测试框架。嵌入式系统测试涉及嵌入式 Linux、驱动、文件系统、启动流程、外设通信需要 Linux 基础。机器人系统测试面向 ROS2 系统涉及分布式节点通信、话题消息、行为树、仿真环境、实时性和资源占用。物联网测试面向 WiFi/BLE/4G 通信、云端上报、本地控制链路硬件会和云服务交互。芯片测试更硬核一些常见的是 ATE 量产测试、设计验证测试DV、应用测试需要理解规格书、参数边界、测试方案设计甚至测试程序开发。每一个方向的侧重点都不一样。进入之前最好先想清楚自己的兴趣和基础选择一个入口而不是把“嵌入式测试”当成一个整体去准备。后面我会给一个自下而上的学习顺序。3. 转行路径把已有经验迁移过来再补三块短板3.1 先盘点哪些能力能直接迁移转行最容易出现的误区是把自己当成一个零基础小白从二极管三极管开始学。其实不用。你过往测试经验里至少有四样东西可以直接迁移测试用例设计方法论边界值、等价类、场景分析在嵌入式测试里同样适用。缺陷报告和跟踪习惯嵌入式项目同样需要规范的 bug 描述、复现步骤、日志附件。脚本化和自动化思维Python、Shell 脚本在嵌入式测试里非常常用很多日志分析、串口监控、自动化上报流程都能用脚本完成。质量判断和风险评估知道什么时候该发布、哪些问题可以缓、哪些必须阻塞这个经验在任何领域都值钱。所以你要做的不是“丢弃之前的测试经验”而是把它们从纯软件的场景重新映射到软硬件一体的场景中去。3.2 学习顺序很重要先单片机再系统再细分方向如果从零开始准备我建议按这个顺序来不要跳级C 语言 单片机最小系统。单片机是嵌入式系统最基础的计算单元。先找一块开发板跑通点灯、按键、中断、定时器理解 GPIO、时钟树、寄存器操作。51 单片机便宜STM32 更贴近工业主流ESP32 自带 WiFi/BLE适合物联网方向。第一块板子不必纠结能买到且资料多的就行。常用外设接口。UART、I2C、SPI、ADC、PWM这五个接口是嵌入式系统最常见的“输入输出通道”也是测试时最容易出问题的地方。每个接口都最好能用一个实际传感器或模块跑一遍比如用 I2C 读传感器、用 SPI 刷屏幕、用 ADC 采集电压。嵌入式 Linux 和 ROS2 基础。这一层适合往系统级和机器人方向走的人。先不要碰内核源码先在板子上把系统跑起来学会看启动日志、管理进程、操作文件系统再了解 ROS2 的节点、话题、服务、参数这些基本概念。测试框架与自动化。这里才是把“测试”和“嵌入式”接起来的地方。常见的做法是用串口日志作为测试输出用脚本做自动化比对用 Unity/CMock 做固件单元测试用 GitLab CI 或 Jenkins 做持续集成。如果做 ROS2 方向还需要学习 launch 测试、集成测试的方式。选择细分方向。基础链路打通后再决定是深入嵌入式应用测试、嵌入式 Linux 测试、机器人测试还是芯片测试。这时候你已经有足够的判断力知道哪个方向适合自己。这个顺序的核心逻辑是先用最少的成本建立起“软件控制物理信号”的体感然后再一层层往上叠系统和网络知识。没有第一步的体感直接学 ROS2 很可能会云里雾里。3.3 环境准备不用一次买齐但要有一块能反复折腾的板子硬件学习最怕的不是不会而是怕你不肯动手。准备一套最小环境其实不需要花太多钱一块开发板新手可以选 STM32 系列也可以选 ESP32。一个 USB 转串口模块用于看日志一般开发板会自带。杜邦线、面包板、LED、按键、电位器。一个常用传感器模块推荐 DHT11/DHT22 温湿度传感器或 NTC 热敏电阻模块。一个可调电源或稳压模块用来模拟供电波动对系统的影响。一台安装了 Linux 虚拟机或双系统的电脑后面做嵌入式 Linux 会用到。示波器暂时可以不买。前期用万用表和串口日志足够等真正需要看波形了再考虑。很多人一上来就囤一堆板子结果每块都没吃透。我更建议先买一块把点灯、按键、中断、ADC、I2C、串口日志这些基础实验全部跑一遍再决定要不要扩展。3.4 明确边界哪些人不适合这样转嵌入式测试不是所有人的“上岸”答案。有几种情况需要冷静评估完全抗拒写代码。嵌入式测试比纯业务测试对代码能力的要求更高即使不做开发你也需要读懂 C 语言固件、写脚本、配置测试环境。完全没有硬件兴趣。如果你看到原理图、数据手册就头疼这个方向会非常痛苦。期待“轻松不加班”。嵌入式测试的复杂度决定了它不是一份偷懒的工作只是忙的方向更有积累。只剩一两个月就要转岗。嵌入式知识体系庞大除非有很强的学习和项目环境否则很难速成。如果这几点你都不沾那这个方向确实值得投入。4. 第一个完整嵌入式测试项目从“能跑”到“可测”4.1 项目选择做一个小而完整的信号链路学习过程中最大的坎不是单个实验不会跑而是没有一个“完整项目”把所有知识串起来。我的建议是第一个项目不要做机器人不要做带云端的物联网系统就做一个信号链路完整的采集/显示/报警系统。比如基于 STM32 的温湿度监测系统输入NTC 热敏电阻或数字温湿度传感器。处理单片机读取数据做滤波和阈值判断。输出LCD 显示当前温度串口打印详细日志超过阈值时点亮 LED 或控制继电器。为什么推荐这个项目因为它的功能边界非常清晰输入可控、输出可见非常适合做测试设计。你可以人为改变传感器输入加热、吹风、调整电位器观察系统输出是否符合预期。这是嵌入式测试的一个核心能力构造输入条件验证系统行为。4.2 测试用例要落到“如何构造输入”纯软件测试的用例可以写“输入一个特殊字符串预期接口返回错误码”。嵌入式测试的用例设计则要更具体必须考虑“如何让被测系统进入这个状态”。以温控报警系统为例可以设计这样的用例用例分类用例描述如何构造输入预期结果正常范围温度在 25℃ 且缓慢变化让传感器处于室温附近LCD 显示正确无报警阈值边界温度恰好等于报警阈值通过加热或环境控制逼近阈值报警逻辑在边界的表现符合设计阈值回差升温报警后降温到阈值附近加热后自然冷却报警是否立即解除还是需要低于阈值若干度输入异常传感器短路或断路拆掉传感器接线或短接信号线系统是否进入错误处理状态而不是死机供电波动电压跌落用可调电源降低输入电压系统是否复位、数据是否异常长时间运行连续运行 24 小时让系统一直上电定期记录日志是否存在内存泄漏、看门狗复位、数据漂移重启恢复断电重启拔插电源重新上电配置是否丢失是否有错误的报警残留每一行用例都要能明确回答“我怎么让系统处于这个状态”。这个思路一旦建立起来面试时讲项目就会很有说服力。4.3 用串口日志搭一个简单的“测试观测台”在硬件测试里最便宜的观测手段就是串口。我建议从第一个项目开始就养成在代码里加测试日志的习惯。一个非常粗糙但实用的做法是写一组简单的断言宏把测试输出打印到串口通过串口工具或脚本收集结果。#define TEST_ASSERT(cond, name) \ do { \ if (cond) { \ printf([PASS] %s\n, name); \ } else { \ printf([FAIL] %s, line %d\n, name, __LINE__); \ } \ } while(0) // 在测试报告中统计 int test_count 0; int test_pass 0; void test_temperature_display(void) { float temp read_temperature(); TEST_ASSERT(temp 0 temp 100, temperature range check); test_count; }这个示例不是要你照抄而是说明一个思路嵌入式测试的“测试工具”往往不是现成的框架而是你自己围绕被测系统搭出来的可观测性工具。打印什么日志、在哪个节点打印、日志格式怎么设计这些都需要测试人员参与设计而不是等开发写完再来看结果。4.4 一个典型排查链路温度偶发跳变做嵌入式测试几乎一定会遇到“偶发问题”。这类问题最容易让新手慌因为不总是复现看起来像玄学。但实际排查是有顺序的。拿“温度偶发跳变”这个例子来说先看现象跳变是周期性还是随机一次跳变持续多久和什么操作有关查应用层滤波算法是否合理数据转换有没有符号问题显示刷新策略是否正确查协议层传感器读取时序是否符合数据手册通信总线上是否有其他设备干扰会不会被中断打断查硬件层传感器供电是否稳定参考电压干净吗地线是否可靠传感器引线是不是太长查环境因素系统附近有没有大电流负载启停电机、继电器、电源适配器会不会引入电磁干扰排查的关键是先确认“现象在哪一层出现”而不是一上来就猜是“程序写错”。这也是嵌入式面试里很常见的考察点你遇到一个偶发问题怎么一步步缩小范围。5. 简历、面试和项目经验怎么把自己卖出去5.1 简历定位不是“测试转嵌入式”而是“具备嵌入式测试能力的测试工程师”转行的人最容易犯的错误是把简历标题写成“嵌入式测试工程师”然后罗列一堆名词熟悉 STM32、了解 ROS2、会 I2C/SPI、懂 Linux。这些词从业务测试嘴里说出来面试官本能会怀疑“你到底做过多少”。更好的策略是简历定位写成具备嵌入式系统测试经验的测试工程师擅长软硬件联合验证和问题定位。项目描述不要只写功能要写测试视角的完整链路。一个可参考的写法项目背景基于 STM32 的温湿度监测系统包含采集、显示、报警、通信功能。测试范围固件逻辑、传感器通信、ADC 采样、LCD 显示、报警阈值、异常输入、供电波动、长时间稳定性。测试方法黑盒功能测试 白盒日志审查设计边界值、异常输入、断电重启等用例编写 Python 脚本采集串口日志并自动比对结果。发现并定位的问题传感器读值偶发跳变通过分层排查定位到电源纹波影响 ADC 参考电压推动硬件调整供电方案后解决。项目沉淀搭建了一套基于串口日志的轻量级测试框架固件迭代时可自动回归核心用例。这个描述里没有堆砌名词但每一个词都表示你真的做过、想过、解决过问题。5.2 面试官更关心什么嵌入式测试面试通常不会只问你会不会写用例。更常见的问题是你用什么方法判断一个嵌入式系统的“正常”你如何在不开完整 UI 的情况下验证固件逻辑你遇到一个偶发问题复现不了怎么办传感器读数异常你的排查顺序是什么你怎么理解 I2C 时序如果设备不 ACK你会怎么查你做过的项目里最难定位的问题是什么这些问题背后面试官真正想了解的是你的“系统级测试思维”而不是“测试技巧”。你有没有动手摸过硬件遇到问题有没有清晰的排查链路能不能用测试专业术语描述硬件相关现象这些都是短期内可以训练出来的。5.3 没有真实项目经验怎么补如果现在还没条件接触实际岗位项目我的建议是自己把项目做出来并留下过程记录。具体做法买一块板子做一个完整的信号链路小项目写完固件以后不急着高兴而是把自己切换到测试角色。给这套系统写测试计划、设计测试用例、搭串口日志观测台、模拟异常输入、做断电重启、做长时间运行、记录问题、定位问题、修改验证。整个过程的产物可以整理成一篇技术博客代码传到 Gitee 或 GitHub面试时直接展示。很多“没有经验”的人就是通过这种方式拿到机会的。关键不是项目多高级而是你有没有完整跑过“设计用例→执行→发现问题→定位→解决→回归”这个闭环。面试官一眼就能看出你是真的做过还是只看过视频和文章。5.4 一份合理的转行时间预期如果白天还在上班每天只能挤出下班后的时间我建议给自己 3 到 6 个月的学习周期。前两个月打基础C 语言、单片机、常用外设完成第一个小项目。第三、四个月做测试化改造把项目当成“被测系统”搭测试框架、设计用例、模拟异常、做回归。第五、六个月往细分方向扩展想走机器人方向就深入 ROS2想走物联网方向就加无线通信和云端联调想走芯片测试方向就开始看规格书和 ATE 的概念。不要相信“一个月上岸”的速成故事。嵌入式测试是一个需要知识沉淀的方向它不像刷面试题那样可以短期突击。但反过来一旦入了门它的职业半衰期会明显长于纯业务测试。6. 把“上岸”理解成“能力升级”而不是“逃离”6.1 转行的本质是给既有能力加一个复合变量很多人把转行想成“抛弃旧技能学习新技能”但其实最值钱的恰恰是“旧技能 新技能”的组合。一个只懂单片机的人不一定能设计出高质量的测试方案一个只懂测试的人在嵌入式系统面前又容易两眼一抹黑。而一个既懂测试方法论、又懂硬件和系统基本逻辑的人就成了那个能把“质量”和“硬件”连接起来的人。这就是复合能力带来的稀缺性。测试 C 语言 单片机已经比纯业务测试有竞争力测试 嵌入式 Linux 脚本自动化选择面更宽测试 ROS2 仿真环境可以往机器人测试走测试 芯片规格 ATE 流程则通向硬核的芯片测试方向。你不是在“转行”你是在往“测试能力金字塔”的上层走。6.2 越靠近底层职业半衰期越长有一个判断可以分享如果你发现一个岗位主要依赖“年抛型知识”比如每半年变一次的框架、平台、工具那它的职业半衰期往往较短如果你发现一个岗位依赖的是“规律型知识”比如信号链路、时序、总线协议、寄存器、底层 OS 行为那它的价值会沉淀很多年。嵌入式、机器人、芯片测试正好大量依赖这些规律型知识。你花时间搞懂 I2C 时序和电源纹波问题三年后依然有效但如果你花大量精力背某款 App 的界面跳转逻辑三年后那个功能可能已经下线了。这不是说嵌入式测试不变化。AI 相关的嵌入式部署、大模型在边缘端的落地、新的机器人中间件都会不断出现。但这些新东西仍然建立在“理解底层系统行为”的基础上。底层理解越深学习新工具就越快。6.3 一个可复用的行动框架最后把整个转行路径收敛成一个框架方便你对照执行先盘点迁移能力写下你现有测试经验里哪些是通用能力用例设计、缺陷报告、自动化脚本、风险判断这些不需要重学。再补三块短板硬件基础单片机、外设接口、系统基础嵌入式 Linux、ROS2 基础、测试工程化串口日志、自动化、CI。做一个完整项目闭环选一个小而完整的信号链路项目从开发到测试化改造亲手完成一次“用例设计→执行→定位→解决→回归”。把项目变成可展示的经验整理成博客、开源代码、调试笔记作为面试中的“证据链”。持续积累跨层定位案例每次排查完一个问题哪怕很琐碎都记录一下问题现象、排查路径、最终根因。这些案例会构成你最独有的能力资产。边界也要说清楚这套路径适合愿意动手、愿意补硬件和代码知识、对“找问题”这件事本身有兴趣的人。它不适合追求轻松的人也不适合等着“救世主方法论”的人。所有转行的本质都不是换一个风吹不到的角落而是把自己变成一个更难被替代的人。那天聊到最后朋友问那我现在最该先干什么我说先别急着买开发板。先把你手上最常见的电子产品拆开看一眼找到里面最大的那颗芯片看懂它周围有几个电容、几个电阻、一条排线接到哪。等你对“软件命令最终要控制一个物理信号”这件事有了体感再决定要不要买板子。从软件测试转向嵌入式、机器人、芯片测试真正重要的不是简历上多几个关键词而是你能不能在“软件逻辑”和“物理世界”之间建立一条稳定的理解路径。一旦这条路通了测试这件事就会从“重复劳动”重新变成“探索未知”。