4. 测试框架选型：主流框架对比与决策矩阵

框架选型这事儿，我见过太多团队一上来就拍脑袋。有人觉得 Robot Framework 关键字驱动很酷，有人迷信 pytest 的简洁，还有人坚持嵌入式就得用 C 写的框架。说实话，没有银弹。选错了框架，后面自动化维护成本能让你哭出来。

这一章，咱们把三个主流框架掰开揉碎，看看它们到底适合什么场景。最后我会给一个决策矩阵，你直接套用就行。

4.1 三大框架速览

先看一张总览表，心里有个底：

特性	Robot Framework	pytest	Unity / CMock
语言	关键字驱动（Python/Java 扩展）	纯 Python	C
适用层级	系统测试、验收测试	单元测试、集成测试、系统测试	单元测试、模块测试
报告能力	原生 HTML/XML 报告，非常漂亮	插件丰富（allure、junitxml）	简陋，需自行加工
硬件依赖	通常需要硬件在环（HIL）	可纯软件模拟，也可对接硬件	可在目标板或模拟器上运行
学习曲线	中等（关键字语法需适应）	低（Python 基础即可）	低（C 语言基础）
社区生态	丰富，有专门的嵌入式库	极丰富，第三方插件海量	嵌入式领域专精，但生态较小

4.2 Robot Framework：关键字驱动的系统测试利器

Robot Framework 最大的特点就是「可读性」。测试用例写出来像自然语言，业务人员都能看懂。我在一个车载项目里用过它，测试经理直接拿着报告去跟客户汇报，省了我不少解释的功夫。

但要注意，它不适合做底层单元测试。为什么？因为关键字封装有开销，跑一个简单断言要经过好几层解析。在嵌入式目标板上，这种开销可能是致命的。

4.3 pytest：Python 生态的瑞士军刀

pytest 是我个人最常用的框架。它轻量、灵活，fixture 机制简直是嵌入式测试的救星。你想想看，一个 fixture 就能搞定硬件初始化、资源分配、清理回收，比 C 语言里手动 malloc/free 优雅太多了。

pytest 在嵌入式领域的典型用法是：

• 在宿主机上跑模拟器测试（比如用 QEMU 模拟 ARM 环境）
• 通过串口/网络控制目标板，执行测试并采集结果
• 结合 ctypes 或 cffi 直接调用 C 库函数做单元测试

# pytest 配合串口做嵌入式测试的典型结构
import pytest
import serial

@pytest.fixture
def device():
    # 初始化串口连接
    ser = serial.Serial('/dev/ttyUSB0', 115200, timeout=1)
    yield ser
    ser.close()  # 测试结束自动清理

def test_led_on(device):
    device.write(b'LED_ON\n')
    response = device.readline()
    assert b'OK' in response

4.4 Unity / CMock：嵌入式单元测试的硬核选择

Unity 是专门为嵌入式 C 语言设计的单元测试框架。它极其轻量，核心代码只有两个文件。CMock 是它的搭档，用于自动生成 mock 函数。说白了，就是帮你把模块间的依赖「架空」，单独测试每个函数。

我记得第一次用 Unity 是在一个 STM32 项目上。当时要测试一个 PID 控制算法，但算法依赖 ADC 和 PWM 驱动。用 CMock 生成 mock 后，我可以在 PC 上模拟各种输入，验证算法逻辑是否正确。这比在开发板上反复烧录调试快太多了。

// Unity 测试用例示例
#include "unity.h"
#include "pid_controller.h"

void setUp(void) {}
void tearDown(void) {}

void test_pid_compute_should_return_zero_when_error_is_zero(void) {
    float output = pid_compute(0.0f, 100.0f);
    TEST_ASSERT_FLOAT_WITHIN(0.001f, 0.0f, output);
}

void test_pid_compute_should_saturate_at_max(void) {
    float output = pid_compute(50.0f, 100.0f);
    TEST_ASSERT_FLOAT_WITHIN(0.001f, 100.0f, output);
}

int main(void) {
    UNITY_BEGIN();
    RUN_TEST(test_pid_compute_should_return_zero_when_error_is_zero);
    RUN_TEST(test_pid_compute_should_saturate_at_max);
    return UNITY_END();
}

4.5 选型决策矩阵

说了这么多，到底怎么选？我整理了一个决策矩阵，你根据项目实际情况打分就行。每个维度 1-5 分，得分最高的框架就是你的首选。

决策维度	权重	Robot Framework	pytest	Unity/CMock
测试层级（单元→系统）	高	3（偏系统）	5（全层级）	4（偏单元）
硬件依赖程度	高	2（依赖重）	4（灵活）	5（原生支持）
团队技术栈	中	3（需学关键字）	5（Python 普及）	4（C 语言基础）
报告与可视化	中	5（原生优秀）	4（插件丰富）	2（需自建）
执行效率	高	2（有开销）	4（轻量）	5（极轻量）
社区与生态	低	4	5	3

打分的时候，我建议你重点关注「测试层级」和「硬件依赖程度」。这两个维度直接决定了框架能不能在你的项目里跑起来。比如一个裸机 MCU 项目，Unity/CMock 几乎是唯一选择。而一个 Linux 嵌入式系统，pytest 的灵活性就体现出来了。

4.6 框架选型流程图

下面这张图是我自己总结的选型流程，你可以照着走一遍：

4.7 我的最终建议

别纠结「哪个框架最好」，要问「哪个框架最适合我的项目」。我见过有人用 Unity 写系统测试，结果 mock 文件比测试代码还多。也见过有人用 Robot Framework 测一个简单的 LED 闪烁，光搭建环境就花了两天。

如果你实在拿不准，我有个笨办法：每个框架花半天时间，写一个最简单的「点亮 LED」测试。哪个框架让你在半天内跑通，就用哪个。实践出真知，比看一百篇对比文章都管用。