前言
前面几篇文章主要记录了 Yuan RTOS 的任务调度、软件定时器和 IPC 机制。功能写出来之后，还需要做一些基本测试，至少要确认常见路径能跑起来，而且长时间运行不会出现明显异常。
这篇文章记录一下目前做过的初步测试，包括资源占用、队列收发测试方法和长时间运行结果。
完整代码请访问我的Github仓库，网址为：yuan-rtos。
值得注意是本文的测试结果只代表当前版本和当前测试条件，后续代码修改、编译选项变化、BSP 示例变化都可能导致结果不同。
测试平台
当前主要测试平台如下：
- MCU：
STM32F103C8T6 - 内核：
Cortex-M3 - 编译器：
arm-none-eabi-gcc 15.2.1 - BSP：
bsp/stm32f1c8 - 系统 tick：
1000Hz - 配置：默认配置，无功能裁剪
串口日志通过 socat 读取，并使用 ts 添加时间戳，类似如下：
sudo socat -u /dev/ttyACM0,b115200,raw,echo=0 STDOUT | ts '[%Y-%m-%d %H:%M:%.S]' | tee uart.log
这样可以同时在终端观察输出，并把日志保存到文件中，方便后续统计。
资源占用
先记录一下资源占用。README 中使用“相较于不使用 Yuan RTOS 的基线程序”的增量口径进行了测试。
测试条件如下：
- 平台：
STM32F103C8T6 - 编译器：
arm-none-eabi-gcc 15.2.1 - 配置：默认配置，无功能裁剪
优化等级 -Os 下：
| 场景 | RAM 增量 | ROM 增量 |
|---|---|---|
| 仅内核 | 640B | 2476B |
| 快速上手程序 | 1752B | 3216B |
优化等级 -O3 下：
| 场景 | RAM 增量 | ROM 增量 |
|---|---|---|
| 仅内核 | 640B | 3976B |
| 快速上手程序 | 1752B | 4704B |
可以看到，对于这个项目来说，-O3 主要增加的是 ROM 占用，RAM 基本不变。
当前用于队列长时间测试的 BSP 固件，使用 arm-none-eabi-size 看到的结果如下：
text data bss dec hex filename
14144 12 14988 29144 71d8 rtos.elf
这里的 bss 比较大，主要和 BSP 示例中创建了多个任务栈、多个队列缓冲区有关。也就是说，这个数字不能简单看成内核本身的资源占用，而是“当前测试程序整体”的资源占用。
初步测试方法
目前比较主要的测试是队列长时间收发测试。
测试程序创建了 5 组队列，每组对应一个发送任务和一个接收任务。发送任务周期性递增发送整数，接收任务从队列读取整数，并统计自己已经接收了多少次。
接收任务会检查并打印类似下面的信息：
[INFO] queue 0 : count = 1000, receive = 1000
[INFO] queue 1 : count = 2000, receive = 2000
[INFO] queue 2 : count = 3000, receive = 3000
其中：
queue表示队列编号count表示接收任务已经成功接收的次数receive表示从队列中收到的整数值
发送任务从 1 开始递增发送，因此在正常情况下，接收端的 count 和 receive 应该一直相等。
为了减少串口输出压力，不是每次接收都打印，而是按不同队列设置不同打印间隔：
queue 0：每 1000 次打印一次queue 1：每 2000 次打印一次queue 2：每 3000 次打印一次queue 3：每 4000 次打印一次queue 4：每 5000 次打印一次
这样既可以观察多个队列是否都在工作，也不会让串口输出过于频繁。
检查思路
日志保存后，可以从几个角度检查：
- 是否存在
ERR、WARN、assert、Fault等异常关键字 - 是否出现重复
Start，如果有则可能发生了复位 - 每一行中
count是否等于receive - 每个队列的打印步长是否符合预期
- 每个队列的计数是否单调递增
- 最后 5 个队列是否都能推进到相同的接收次数
我使用脚本对日志进行了统计。核心不是脚本本身，而是确认日志中有没有出现“计数不一致、跳变、倒退、任务停止输出”等现象。
最终结果
这次日志文件为 test/uart.log，记录时间如下：
first=2026-04-21 11:55:48.689349
last=2026-04-21 23:44:47.151256
lines=97134
也就是说，测试程序连续运行了接近 11 小时 49 分钟。日志中只有一次 Start，没有发现重复启动迹象。
队列日志统计结果如下：
total_parsed=97133 mismatch=0
queue 0 lines=42540 jumps=0 last_count=42540000 last_receive=42540000
queue 1 lines=21270 jumps=0 last_count=42540000 last_receive=42540000
queue 2 lines=14180 jumps=0 last_count=42540000 last_receive=42540000
queue 3 lines=10635 jumps=0 last_count=42540000 last_receive=42540000
queue 4 lines=8508 jumps=0 last_count=42540000 last_receive=42540000
这里可以看到：
mismatch=0，说明没有发现count != receive- 每个队列的
jumps=0，说明打印步长符合预期 - 5 个队列最终都推进到了
42540000 - 没有出现明显的计数倒退或跳变
从这个结果看，当前队列的基本收发、阻塞、唤醒、超时相关路径没有暴露出明显问题。
当然，这个测试不能证明 RTOS 已经完全没有 bug。它只能说明在当前 BSP、当前负载和当前运行时间下，队列相关的主路径表现稳定。后续还需要继续补充更多测试，比如：
- 信号量超时测试
- 互斥量优先级继承测试
- 任务删除与阻塞状态交互测试
- 中断接口测试
- 极限队列容量测试
- tick 溢出附近的定时器测试
总结
目前 Yuan RTOS 的初步测试主要覆盖了资源占用和队列长时间运行。
资源占用方面，内核本身增量较小，当前长测 BSP 的 RAM 占用主要来自任务栈和队列缓冲区。
功能测试方面，队列长时间运行接近 12 小时，最终没有发现数据错位、跳变、复位或异常日志。这个结果不能代表完全可靠，但至少说明当前实现已经具备继续扩展和继续测试的基础。