1. 调度器测试哲学：为什么测试比代码更重要？测试金字塔在嵌入式领域的应用

说实话，我见过太多嵌入式工程师把精力全花在写调度器代码上，测试嘛，随便跑两个用例就完事了。结果呢？一上硬件就崩，一跑压力就挂。我自己也踩过这个坑——有一次花了两周写了一个看起来很漂亮的任务调度器，结果在产线测试时，三个任务同时抢占一个临界资源，系统直接死锁。从那以后，我彻底改变了看法：测试不是代码的附属品，测试才是调度器真正的灵魂。

1.1 为什么测试比代码更重要？

你想想看，调度器代码本身其实不难写。无非就是任务控制块链表、上下文切换、时间片轮转这些套路。但难的是——你怎么证明它在所有边界条件下都正确？

我在项目中遇到过这样一个案例：一个同事写的调度器，单任务跑得好好的，双任务也正常，但一旦加到8个任务，偶尔会出现某个任务永远得不到执行的情况。代码逻辑上完全看不出问题，最后靠构造了一个"饥饿测试"用例才复现出来。你看，代码本身不会告诉你它有问题，只有测试会。

说白了，调度器是系统的"心脏"。心脏出问题，整个系统就完了。所以我对测试的态度是：宁可多花一倍时间写测试，也不让一个可疑的调度器上线。

1.2 测试金字塔在嵌入式领域的应用

测试金字塔这个概念，最早是Mike Cohn在《Succeeding with Agile》里提出的。经典的金字塔分三层：底层是单元测试，中间是集成测试，顶层是端到端测试。但在嵌入式领域，尤其是单片机调度器测试中，这个金字塔需要做一些调整。

我习惯把嵌入式调度器的测试金字塔画成这样：

1.3 三层测试的具体内容

下面我结合自己的经验，说说每一层在调度器测试中具体怎么做。

底层：单元测试

单元测试是金字塔的基石。在调度器测试中，单元测试覆盖的是最小的可测试单元——每个函数、每个数据结构操作。我一般会为以下模块编写单元测试：

测试模块	测试内容	典型用例数
任务控制块管理	创建、删除、查找、状态切换	20-30
就绪队列操作	入队、出队、优先级排序、空队列处理	15-25
上下文切换	寄存器保存/恢复、栈指针切换	10-15
定时器管理	启动、停止、溢出处理、精度验证	15-20
同步原语	信号量、互斥锁、事件标志组	25-35

中层：集成测试

集成测试关注的是模块之间的交互。调度器的集成测试，说白了就是验证"多个任务在一起工作时会不会打架"。我重点测这几个场景：

• 任务优先级抢占：高优先级任务就绪时，能否正确抢占低优先级任务
• 同优先级时间片轮转：多个同优先级任务能否公平获得CPU时间
• 资源竞争与死锁：多个任务争用同一资源时，系统是否还能正常工作
• 中断与任务的交互：中断服务程序中触发任务调度，会不会导致上下文混乱

我曾经遇到过一个问题：两个任务通过信号量同步，其中一个任务在释放信号量后立即被更高优先级的任务抢占，导致另一个任务永远拿不到信号量。这种问题，单元测试根本发现不了，只有集成测试才能暴露出来。

顶层：端到端测试

端到端测试是最接近真实运行环境的测试。我会把调度器跑在实际硬件上，模拟真实的应用场景：

• 同时运行8-16个任务，每个任务执行不同的功能（传感器采集、通信处理、显示刷新等）
• 引入随机的外部中断，模拟真实世界的不可预测性
• 长时间运行（24小时以上），观察系统是否出现任务饿死、内存泄漏、定时器漂移等问题

1.4 测试投入的分配策略

很多工程师问我：测试到底该花多少时间？我的建议是：单元测试占60%，集成测试占30%，端到端测试占10%。为什么这么分配？

你看，单元测试执行快、定位准、覆盖率高。一个单元测试用例跑完只需要几毫秒，出了问题马上能定位到具体函数。而端到端测试跑一次可能要几个小时，出了问题还得花大量时间排查。所以把大部分精力放在底层测试上，性价比最高。

我个人的经验数据是这样的：

测试层级	投入时间占比	发现缺陷占比	修复成本
单元测试	60%	70-80%	低
集成测试	30%	15-25%	中
端到端测试	10%	5-10%	高

你看，单元测试投入了60%的时间，却能发现70-80%的缺陷。而端到端测试投入10%的时间，只能发现5-10%的缺陷。这个投入产出比，你应该能看出该怎么分配精力了吧？

1.5 测试先行：从设计阶段就开始写测试

最后我想说一个观点：测试不应该在代码写完之后才开始，而应该在设计阶段就同步进行。我现在的做法是：在设计调度器的API接口时，先把测试用例写出来。比如我设计了一个task_create()函数，我会先写它的测试用例：

// 测试用例：task_create 正常创建
void test_task_create_normal(void) {
    task_t task;
    int ret = task_create(&task, "test_task", TASK_PRIORITY_NORMAL, task_func, NULL);
    assert(ret == TASK_OK);
    assert(task.state == TASK_READY);
    assert(task.priority == TASK_PRIORITY_NORMAL);
}

// 测试用例：task_create 参数异常
void test_task_create_invalid_param(void) {
    int ret = task_create(NULL, "test", TASK_PRIORITY_NORMAL, task_func, NULL);
    assert(ret == TASK_ERR_INVALID_PARAM);
}

// 测试用例：task_create 优先级越界
void test_task_create_priority_overflow(void) {
    task_t task;
    int ret = task_create(&task, "test", TASK_PRIORITY_MAX + 1, task_func, NULL);
    assert(ret == TASK_ERR_PRIORITY_INVALID);
}

这样做的好处是：测试用例反过来会帮你把API设计得更清晰、更健壮。如果你发现某个测试用例很难写，那往往说明API设计本身有问题。