HRTOS性能测试与 Worst-Case Analysis 有什么区别？

最近 HRTOS 4.0 准备增加一套 Worst-Case Analysis（最坏情况分析）测试。

可能有人会问：

HRTOS 以前不是已经做过性能测试了吗？为什么还要重新做？

实际上，两者虽然测试对象有大量重合，但目的并不一样。

简单来说：

性能测试关注“系统通常有多快”，Worst-Case Analysis 关注“系统最慢会到什么程度”。

这也是我这次重新建立测试体系的主要原因。

一、原来的性能测试主要解决什么问题？

以前 HRTOS 的性能测试，主要关注系统整体性能。

例如：

• 任务切换时间

• 中断响应时间

• 时间片

• CPU 占用率

• 任务运行效率

• 长时间运行稳定性

• 高负载情况下的系统表现

这些测试的目的主要是回答：

HRTOS 的性能怎么样？

例如：

任务切换：约 0.4 ms
时间片：约 11 ms
CPU：约 XX%

这些数据能够很好地反映 HRTOS 的运行效率。

同时，长期压力测试还可以验证：

系统长时间运行是否稳定？

因此，原来的性能测试对于 HRTOS 来说仍然非常重要。

二、Worst-Case Analysis关注的问题不一样

Worst-Case Analysis 并不是简单地重新测一遍性能。

它更加关注：

在不利条件下，系统的最大时间开销是多少？

例如任务切换。

普通性能测试可能得到：

400 μs
410 μs
398 μs
405 μs
…

那么我们可能会说：

任务切换大约需要 0.4 ms。

但 Worst-Case Analysis 会进一步追问：

有没有出现过更大的值？

例如：

400 μs
410 μs
398 μs
405 μs
…
467 μs

那么这次测试真正关心的就是：

467 μs 是什么条件下产生的？

以及：

在规定测试条件下，最大观测值是多少？

这就是两种测试思维上的区别。

三、一个关注平均，一个关注最大

可以简单理解成：

性能测试
↓
平均值 / 典型值
↓
系统通常有多快

Worst-Case Analysis
↓
最大观测值
↓
系统最慢会到什么程度

当然，实际性能测试并不一定只统计平均值，Worst-Case Analysis 也不会完全忽略典型值。

但两者的核心关注点确实不同。

对于普通应用软件来说，平均性能往往非常重要。

但对于实时系统来说：

最大延迟往往比平均延迟更加重要。

四、为什么实时系统特别关心 Worst Case？

假设有两个系统。

系统 A

100 μs
102 μs
101 μs
103 μs
100 μs

平均值大约 101 μs。

系统 B

50 μs
60 μs
55 μs
70 μs
500 μs

系统 B 的很多时候甚至比系统 A 更快。

但是如果某个控制任务要求：

必须在 200 μs 内完成。

那么系统 B 就存在明显的问题。

因为它偶尔可能出现：

500 μs

因此对于实时系统来说：

“平均很快”并不意味着“实时性很好”。

真正需要知道的是：

最坏情况下会不会超出时间约束。

五、两者测试方法也不完全一样

原来的性能测试更加偏向：

运行程序
↓
获取数据
↓
计算平均/典型性能
↓
与其他系统比较

而 Worst-Case Analysis 更强调：

明确测试条件
↓
构造不利场景
↓
大量重复执行
↓
记录最大值
↓
分析最大值产生条件

因此测试设计会更加关注：

• 不同任务状态

• 不同优先级

• 不同中断条件

• 不同系统负载

• 资源竞争

• 调度路径

• 临界区

• 中断嵌套

也就是说：

不仅测“正常情况”，还要主动寻找“不正常但合法”的情况。

六、原来的压力测试和 Worst-Case 也不同

这一点也很容易混淆。

HRTOS 以前已经进行过较长时间的压力测试。

例如：

高 CPU 占用
+
大量任务
+
大量触发
+
长时间运行

主要验证的是：

系统会不会出问题。

例如：

• 死机

• 重启

• 状态异常

• 资源泄漏

• 调度异常

而 Worst-Case Analysis 更关注：

在这些压力条件下，时间行为最大会到哪里。

所以：

压力测试：
系统会不会坏？

Worst-Case：
系统最慢会到什么程度？

两者是互补关系。

七、这次为什么还要加入 Stress？

正是因为单项测试不能完全代表真实系统。

例如：

单独测试任务切换：

任务切换
↓
测量

可能非常稳定。

但真实系统可能同时存在：

任务
+
中断
+
调度
+
消息
+
信号量
+
资源竞争

因此这次的 Stress 测试会作为综合场景。

它的意义不是单纯追求：

CPU 占用率越高越好。

而是观察：

多个系统机制同时运行时，时间行为是否仍然稳定。

八、为什么使用 GPIO + 逻辑分析仪？

这次测试还有一个明显区别：

更加重视外部、直接的时间测量。

测试程序通过 GPIO 标记被测区间：

WCA_BEGIN();

/* 被测试代码 */

WCA_END();

然后使用逻辑分析仪直接观察 GPIO 的脉宽。

这样得到的是：

真实硬件上的实际时间。

而不是仅仅依赖软件计数器。

这对于 8051 这种资源非常有限、硬件行为相对透明的平台来说，是一种非常直接的测试方法。

九、Worst-Case Analysis并不是“绝对最坏情况证明”

这里还需要明确一个边界。

这次 HRTOS 做的是：

Measured Worst-Case

也就是：

在明确的硬件、编译器、系统配置和测试条件下，通过大量实际测试得到的最大观测值。

它并不等于：

数学意义上的绝对 WCET 证明。

真正的绝对 WCET 分析，需要更加复杂的程序路径分析、硬件模型以及形式化方法。

因此这次 HRTOS 的目标非常明确：

不做过度复杂的理论包装，而是先把真实硬件上的时间边界测出来。

十、两套测试最终会形成什么关系？

我认为以后 HRTOS 的测试体系可以逐渐形成：

HRTOS Test
│
┌───────────┴───────────┐
│ │
Performance Test Worst-Case Analysis
│ │
典型性能/运行效率 最大时间开销
│ │
长期稳定性 时间确定性
│ │
└───────────┬───────────┘
│
综合验证

性能测试告诉我们：

HRTOS 平时表现怎么样。

Worst-Case Analysis 告诉我们：

HRTOS 在不利条件下表现怎么样。

压力测试则进一步告诉我们：

HRTOS 长时间运行会不会出现问题。

三者放在一起，才构成比较完整的工程验证体系。

十一、为什么我现在才做这件事情？

因为 HRTOS 现在已经进入了一个不同的阶段。

早期开发阶段更加重要的是：

功能有没有？

然后是：

性能怎么样？

再往后：

稳不稳定？

而现在 HRTOS 4.0 的核心功能已经基本定型，我更希望开始回答：

这个系统的行为边界到底在哪里？

因此现在做 Worst-Case Analysis，我认为比继续无休止地增加功能更加有意义。

十二、从“做功能”转向“做深度”

这也是 HRTOS 目前比较重要的一个变化。

以前开发一个 RTOS，可能会不断增加：

• Shell

• 驱动

• 组件

• API

• 示例

• 新功能

但到了一个阶段以后，继续增加功能并不一定意味着系统真正变强。

真正值得做的是：

已有功能
↓
性能验证
↓
稳定性验证
↓
边界验证
↓
数据沉淀
↓
长期维护

因此这一次 Worst-Case Analysis，本质上并不是给 HRTOS “增加一个功能”。

而是在：

给已经完成的内核增加一套更加深入的工程验证。

结语

如果把两者用一句话概括：

性能测试回答“它有多快”，Worst-Case Analysis回答“它最慢会到哪里”。

对于普通软件，这两者的区别可能没有那么明显。

但对于 RTOS，特别是希望不断向“硬实时”概念靠近的系统来说，这个区别非常重要。

HRTOS 4.0 现在并不准备继续无限扩张。

下一阶段更重要的事情，是：

把已经完成的东西测清楚、记录下来、验证充分，然后长期维护。

这可能比继续增加一个新的功能更加有价值。

从“能跑”到“跑得快”，再到“知道最慢会到哪里”，也是一个 RTOS 从功能型系统走向工程型系统的过程。