3、单元测试概念与原则：测试金字塔、测试隔离、可重复性、断言与覆盖率基础

TinyML 开发与传统的嵌入式或云端开发有一个显著差异：模型推理的输入是传感器原始数据（如加速度计读数、麦克风 PCM 采样、摄像头帧），输出是经过前处理、模型计算、后处理之后的分类结果或回归值。任何一个环节的微小改动（如归一化系数调整、量化参数变化、后处理阈值修改）都可能让模型行为发生漂移。单元测试正是为了在问题扩散之前，以最小粒度锁定每个函数、每个模块的正确性。本章将围绕测试金字塔、测试隔离、可重复性、断言与覆盖率这五个核心概念展开，帮助你在资源受限的 TinyML 工程中建立一套务实、高效的测试策略。

上图展示了本章五个核心概念之间的逻辑关系：测试金字塔决定了你在哪一层投入最多的测试精力；测试隔离与可重复性保证了每个测试用例的独立性和稳定性；断言是验证行为正确性的具体手段；覆盖率则帮助你发现测试盲区。在 TinyML 场景中，这五个概念需要结合嵌入式资源约束（内存、Flash、CPU 频率）进行裁剪和适配。

3.1 测试金字塔：从底层到顶层的策略布局

测试金字塔由 Mike Cohn 提出，其核心思想是：底层单元测试数量最多、运行最快、维护成本最低；越往上，测试数量越少、运行越慢、维护成本越高。在 TinyML 项目中，金字塔的形态需要针对嵌入式特点做调整。

3.1.1 金字塔各层职责

在 TinyML 中，单元测试通常运行在 x86 宿主机上，通过交叉编译工具链将目标代码编译为宿主机可执行文件。这样做的优势是：无需硬件即可快速验证算法逻辑，且可以利用宿主机丰富的调试工具（如 gdb、valgrind）。但需要注意，宿主机与目标板的浮点行为、内存对齐、字节序可能存在差异，因此单元测试通过后仍需在目标板上做冒烟测试。

3.2 测试隔离：让每个用例独立运行

测试隔离是指每个测试用例在运行时，不依赖其他测试用例的执行结果、不依赖外部系统状态、不共享可变全局变量。在 TinyML 中，由于资源受限，开发者往往倾向于使用全局缓冲区或静态变量来节省内存，这给测试隔离带来了挑战。

3.2.1 隔离的层次

• 数据隔离：每个测试用例使用独立的输入数据副本，避免修改共享缓冲区。
• 状态隔离：被测函数内部使用的静态变量、全局状态需要在 setUp/tearDown 中重置。
• 依赖隔离：通过依赖注入或链接期替换（link-time substitution）将传感器驱动、日志模块等替换为测试桩（stub）。

例如，假设后处理函数中使用了全局变量 g_threshold 作为分类阈值。在测试用例 A 中将其修改为 0.6，如果测试用例 B 未重置该值，则 B 的行为会受 A 影响。解决方法是：在测试框架的 setUp() 中显式初始化所有相关全局变量，或者将阈值作为函数参数传入。

// 反模式：依赖全局状态
float g_threshold = 0.5f;
int classify(float score) {
    return score > g_threshold ? 1 : 0;
}

// 可测试模式：阈值作为参数
int classify(float score, float threshold) {
    return score > threshold ? 1 : 0;
}

3.3 可重复性：消除不确定性

可重复性是指同一测试用例在相同条件下多次运行，结果始终一致。TinyML 测试中的不确定性来源主要有：随机数生成（如 dropout 模拟、数据增强）、浮点运算的非确定性（不同编译器优化级别）、时间相关的行为（如超时判断）、外部传感器噪声。

3.3.1 实现可重复性的方法

1. 固定随机种子：在测试中显式调用 srand(42) 或使用固定种子初始化伪随机数生成器。
2. 使用确定性算法：避免在单元测试中依赖多线程或异步回调，改用同步执行。
3. 黄金文件对比：将预期输出保存为静态数据文件（如 expected_output.h），测试时逐字节或逐元素比较。
4. 容差比较：对于浮点结果，使用误差或相对误差阈值，而非直接 == 比较。

3.4 断言：验证行为正确性的核心手段

断言是单元测试中最直接的验证工具。一个断言检查一个逻辑条件，如果条件为假，则测试失败并报告详细信息。在 TinyML 测试中，常用的断言框架包括 Unity（C 语言）、CppUTest（C++）、Google Test（C++，但资源开销较大）。

3.4.1 断言类型与适用场景

编写断言时，应遵循“一个测试用例只验证一个行为”的原则。例如，测试前处理函数时，不要同时断言输出长度和输出值，而是拆分为两个独立用例。这样在失败时能快速定位问题。

3.5 覆盖率：衡量测试充分性的标尺

覆盖率用于衡量测试用例对代码的覆盖程度。常见的覆盖率指标包括：行覆盖率（statement coverage）、分支覆盖率（branch coverage）、条件覆盖率（condition coverage）和函数覆盖率（function coverage）。在 TinyML 中，由于代码量相对较小（通常几千行），覆盖率工具（如 gcov、lcov）可以高效运行。

3.5.1 覆盖率指标对比

在 TinyML 项目中，建议将行覆盖率目标设为 80% 以上，分支覆盖率设为 70% 以上。对于前处理中的边界条件（如数组越界、除零、饱和运算），应重点补充测试用例。

3.6 实战案例：为前处理函数编写单元测试

假设我们有一个 TinyML 关键词识别（KWS）项目，前处理函数负责将 16kHz 的 PCM 音频数据转换为 40 维 MFCC 特征。该函数包含：预加重、分帧、加窗、FFT、Mel 滤波器组、对数运算和 DCT。我们选择其中两个子函数进行单元测试：pre_emphasis() 和 mel_filter()。

3.6.1 案例背景与约束

• 目标平台：Cortex-M4，无 FPU（浮点单元），使用定点数模拟浮点。
• 宿主机：x86 Linux，使用 gcc 编译，Unity 测试框架。
• 约束：测试代码不能依赖任何硬件外设，所有输入数据通过数组传入。

3.6.2 初始现象与目标

在集成测试阶段，发现模型推理结果不稳定：同一段音频在不同时间运行得到不同分类结果。初步定位为前处理中的预加重系数 alpha 在全局变量中被意外修改。目标：通过单元测试锁定 pre_emphasis() 的行为，确保其不依赖全局状态。

3.6.3 测试设计与执行

// pre_emphasis.h
void pre_emphasis(const int16_t *input, int16_t *output, uint32_t len, int16_t alpha_q15);

// 测试用例
void test_pre_emphasis_identity_when_alpha_zero(void) {
    int16_t input[4] = {100, 200, 300, 400};
    int16_t output[4];
    pre_emphasis(input, output, 4, 0); // alpha=0 时输出等于输入
    TEST_ASSERT_EQUAL_INT16_ARRAY(input, output, 4);
}

void test_pre_emphasis_constant_signal(void) {
    int16_t input[4] = {1000, 1000, 1000, 1000};
    int16_t output[4];
    pre_emphasis(input, output, 4, 3276); // alpha=0.1 的 Q15 表示
    // 预期: output[0]=1000, output[1]=1000-1000*0.1=900, ...
    TEST_ASSERT_EQUAL_INT16(1000, output[0]);
    TEST_ASSERT_EQUAL_INT16(900, output[1]);
    TEST_ASSERT_EQUAL_INT16(900, output[2]);
    TEST_ASSERT_EQUAL_INT16(900, output[3]);
}

执行结果：第一个用例通过，第二个用例失败。分析发现，pre_emphasis() 内部使用了静态变量保存上一次的样本值，导致第二次调用时状态残留。修复方法：移除静态变量，改为由调用者传入上一个样本值。

3.6.4 结果对比与复盘

复盘经验：在 TinyML 中，静态变量是测试隔离的头号敌人。设计前处理函数时，应优先使用纯函数风格（所有状态通过参数传递），或者将状态封装在结构体中由调用者管理。此外，覆盖率数据帮助我们发现 mel_filter() 中的边界条件（如滤波器索引越界）未被测试，补充用例后避免了潜在的数组越界问题。

3.7 常见误区与总结

• 误区一：认为单元测试只适用于 PC 端软件，嵌入式代码无法测试。实际上，通过良好的模块化设计，大部分算法代码可以在宿主机上测试。
• 误区二：过度追求 100% 覆盖率。在 TinyML 中，某些硬件相关代码（如寄存器操作）难以在宿主机上覆盖，应通过集成测试或硬件在环测试补充。
• 误区三：忽略浮点容差。由于宿主机和目标板的浮点实现差异，直接使用 == 比较浮点结果会导致测试不稳定。
• 误区四：测试用例之间共享数据。例如，多个测试用例共用同一个输入缓冲区，一个用例修改后影响其他用例。