3、单元测试核心概念：单元测试的目标、被测单元（函数/模块）的界定、测试用例设计原则（等价类、边界值、判定表）
单元测试是嵌入式软件测试体系中最底层、执行频率最高、反馈速度最快的测试活动。它直接面向源代码中的最小可测单元，在开发阶段即发现缺陷，避免缺陷向集成阶段和系统阶段扩散。对于嵌入式系统而言，单元测试还承担着验证硬件寄存器操作、中断处理逻辑、状态机转换、通信协议帧解析等底层行为正确性的职责。本章将系统梳理单元测试的目标、被测单元的界定方法，以及等价类划分、边界值分析和判定表这三种核心测试用例设计原则，并结合嵌入式场景给出可落地的操作指引。
3.1 单元测试的目标：不止于“验证函数正确”
单元测试的核心目标可以从四个层面理解。第一层是行为验证：确认被测单元在给定输入下产生预期输出，包括返回值、全局变量修改、输出参数写入、硬件寄存器操作等。第二层是缺陷预防：在代码合入主干之前发现逻辑错误、边界处理遗漏、状态转换异常等问题，此时修复成本最低。第三层是设计反馈：如果某个函数难以编写单元测试，往往意味着耦合度过高、职责不单一或接口设计不合理，这倒逼开发者优化代码结构。第四层是回归保障：在嵌入式项目迭代中，修改一个驱动函数可能影响多个调用方，单元测试套件可以在数秒内完成回归验证。
在嵌入式环境中，单元测试的目标还有特殊延伸。例如，验证对硬件寄存器的读写时序是否正确、中断服务函数中的共享变量访问是否安全、低功耗模式切换后外设状态是否恢复等。这些目标要求测试用例不仅关注函数返回值，还要通过模拟硬件层（如使用函数指针替换寄存器操作）来验证行为序列。
3.2 被测单元的界定：函数、模块与状态机
被测单元的界定是单元测试的起点。在嵌入式C语言项目中，最常见的被测单元是函数。但并非所有函数都适合作为独立单元，界定标准包括：单一职责（函数只做一件事）、可独立编译（不依赖未定义的全局变量或外部硬件）、可观测性（输入输出可控制、可检查）。对于模块级单元（如一个外设驱动文件），通常将其拆分为多个可测试的函数，再通过桩函数（Stub）隔离硬件依赖。
状态机是嵌入式系统中常见的被测单元形态。例如，一个按键扫描模块包含空闲、消抖、按下、长按等多个状态。界定状态机单元时，需要将状态转换条件和动作封装为可调用的接口，测试用例则围绕“当前状态 + 触发事件 → 下一状态 + 执行动作”来设计。
| 被测单元类型 | 界定标准 | 嵌入式典型示例 | 测试关注点 |
|---|---|---|---|
| 纯函数 | 无全局依赖，输入输出确定 | CRC16校验、温度线性化计算 | 数值正确性、边界输入 |
| 带全局变量函数 | 全局变量可被测试桩控制 | 系统Tick计数器、日志缓冲区写入 | 全局状态初始化、并发访问 |
| 硬件操作函数 | 通过函数指针或宏隔离寄存器 | GPIO初始化、UART发送字节 | 寄存器写入顺序、超时处理 |
| 状态机模块 | 状态枚举+事件输入+动作输出 | 按键扫描、通信协议解析 | 非法状态转换、事件丢失 |
i2c.c）直接作为被测单元。文件内多个函数相互调用、共享静态变量，会导致测试用例之间相互干扰。正确做法是：以函数为最小单元，对文件内部静态函数通过 #include 方式或条件编译暴露给测试代码。
3.3 测试用例设计原则：等价类划分
等价类划分的核心思想是：将输入域划分为若干子集，每个子集中的任意值对被测单元的行为影响等价。测试时从每个等价类中选取一个代表值即可。等价类分为有效等价类（满足需求规格的输入）和无效等价类（不满足需求规格的输入）。
在嵌入式场景中，等价类划分需要结合数据类型和物理意义。例如，一个ADC采样值处理函数，输入为12位无符号整数（0~4095）。有效等价类可划分为：0（最小值）、2048（典型值）、4095（最大值）；无效等价类包括：-1（有符号溢出）、4096（超出范围）、0xFFFF（位宽截断）。对于浮点输入，还需考虑NaN、Infinity等特殊值。
操作流程如下：第一步，识别输入条件（参数、全局变量、外部状态）；第二步，根据需求规格划分等价类；第三步，为每个等价类编号并设计代表值；第四步，补充无效等价类测试用例，验证错误处理逻辑。
uint8_t calc_battery_percent(uint16_t adc_value)，需求规定：adc_value 范围 0~4095，对应电量 0%~100%，线性映射。等价类划分如下：
- 有效等价类：adc_value = 0（→0%）、2048（→50%）、4095（→100%）
- 无效等价类：adc_value = 4096（应返回错误码或饱和处理）、0xFFFF（位宽异常）
3.4 测试用例设计原则：边界值分析
边界值分析是等价类划分的补充，它关注输入域的边界点及其邻近值。经验表明，大量缺陷集中在边界附近，如 if (count >= MAX_COUNT) 中 MAX_COUNT 的处理、循环变量的上下限、数组索引的越界等。边界值分析的基本方法是：对于每个边界，取 min-1、min、min+1、max-1、max、max+1 六个值（若边界为开区间则调整）。
在嵌入式系统中，边界值分析尤其重要，因为硬件资源有限，数组长度、缓冲区大小、定时器计数值等都有严格上限。例如，一个环形缓冲区写入函数 int ringbuf_write(ringbuf_t *rb, uint8_t data)，缓冲区容量为 64。边界值测试应覆盖：写入前长度为 0（空缓冲区）、63（满前一个）、64（满）、65（溢出尝试）。同时还要考虑写入指针回绕（wrap-around）的场景。
边界值分析的实施步骤：第一步，从需求或代码中提取所有边界条件（数值范围、循环次数、索引上下限）；第二步，对每个边界生成边界值集合；第三步，结合等价类划分，将边界值用例与等价类用例合并去重；第四步，特别关注“相等”和“越过”两种情况（如 <= 与 < 的区别）。
if (temp > 100) 时，只测 temp=100 和 temp=101，却遗漏了 temp=99（恰好不触发）和 temp=100（恰好触发）的边界语义。正确做法是同时覆盖 99、100、101 三个值。
3.5 测试用例设计原则：判定表
判定表用于处理多条件组合的场景，它能够系统地列出所有条件组合及其对应的动作。判定表由四个部分组成：条件桩（所有可能的条件）、动作桩（所有可能的操作）、条件项（条件取值的组合）、动作项（在特定组合下执行的动作）。在嵌入式系统中，判定表非常适合描述协议解析、模式切换、异常处理等复杂逻辑。
例如，一个电机控制模块根据三个条件决定动作：温度是否超限（T）、电流是否超限（I）、使能信号是否有效（E）。动作包括：正常运行、降功率运行、紧急停止。使用判定表可以穷举 2³=8 种组合，避免遗漏“温度正常但电流超限且使能无效”这类组合。
判定表设计步骤：第一步，列出所有条件（通常为布尔或枚举类型）；第二步，计算条件组合总数（若每个条件有 n 个取值，组合数为 n 的乘积）；第三步，填充动作项，确定每个组合对应的预期行为；第四步，合并相同动作的列（规则化简）；第五步，将化简后的每一列转化为一个或多个测试用例。
| 条件/动作 | 规则1 | 规则2 | 规则3 | 规则4 | 规则5 | 规则6 | 规则7 | 规则8 |
|---|---|---|---|---|---|---|---|---|
| T（温度超限） | Y | Y | Y | Y | N | N | N | N |
| I（电流超限） | Y | Y | N | N | Y | Y | N | N |
| E（使能有效） | Y | N | Y | N | Y | N | Y | N |
| 动作：正常运行 | ✓ | |||||||
| 动作：降功率 | ✓ | ✓ | ||||||
| 动作：紧急停止 | ✓ | ✓ | ✓ | ✓ | ✓ |
上表展示了电机控制的判定表。规则4（T=Y, I=N, E=N）表示温度超限且使能无效，此时应紧急停止；规则7（T=N, I=N, E=Y）是唯一正常运行的条件。通过判定表，测试人员可以确保每种条件组合都被覆盖，且动作逻辑无歧义。
3.6 三种设计原则的协同使用与实战复盘
在实际项目中，三种设计原则并非孤立使用，而是相互补充。等价类划分提供基础覆盖，边界值分析聚焦边界缺陷，判定表处理条件组合。推荐的使用流程是：先用判定表梳理复杂逻辑的条件组合，再用等价类划分简化每个条件的取值域，最后用边界值分析补充边界用例。
以一个实际的嵌入式项目为例：某车载T-Box的CAN报文解析模块，需要解析ID为0x123的报文，包含3个信号：车速（0~250 km/h，步进1）、发动机转速（0~8000 rpm，步进1）、档位（P/R/N/D）。测试设计过程如下：
- 判定表分析：档位有4种取值，车速和转速为连续值，因此判定表主要针对档位与异常标志的组合（如档位无效、车速超限、转速超限）。
- 等价类划分：车速划分为0、125、250三个有效等价类，以及251、0xFFFF两个无效等价类；转速类似。
- 边界值分析：车速边界为0、1、249、250、251；转速边界为0、1、7999、8000、8001。
- 测试执行：共设计32个用例，其中判定表覆盖8种档位组合，等价类覆盖12个代表值，边界值覆盖12个边界点。测试发现2个缺陷：车速为251时未触发超限报警（边界判断错误）；档位为无效值0x3时未进入默认处理分支（判定表遗漏）。
3.7 常见误区与总结
在单元测试实践中，以下误区需要特别警惕。第一，“测试驱动开发（TDD）万能论”：嵌入式项目中硬件依赖和编译环境复杂，TDD并不总是适用，但“先写测试再写实现”的思路在纯逻辑模块中仍然有效。第二，“覆盖率至上”：行覆盖率100%并不代表逻辑正确，关键分支和条件组合的覆盖更为重要。第三，“忽视桩函数质量”：如果桩函数的行为与真实硬件不符，测试结果将失去意义。第四，“测试代码与产品代码耦合”：测试用例应独立于实现细节，否则产品代码重构时测试用例会大量失效。
总结本章核心要点：单元测试的目标是行为验证、缺陷预防、设计反馈和回归保障；被测单元的界定应遵循单一职责、可独立编译、可观测性原则；等价类划分、边界值分析和判定表是三种基础且高效的测试用例设计方法，需根据被测单元的逻辑特征灵活组合使用。在嵌入式环境中，还需额外关注硬件依赖隔离、寄存器副作用和中断时序等特殊问题。