测试用例只有一个General Boot Testing，需要传递具体的测试参数进行测试。用例不涉及具体的测试场景。
设计理念
采用状态机驱动的设计模式：
当前状态 → [执行启动操作] → 目标状态 → [验证] → 循环/结束
每个启动操作在boot_table.json中都有明确定义：
start：执行该操作前机器必须满足的状态（前置条件）end：执行该操作后期望达到的状态（后置验证）
两种执行模式
| 模式 | 参数 | 行为 |
|---|---|---|
| 列表模式 | boot_list | 从列表中随机选择一个符合条件的启动操作执行 |
| 栈模式 | boot_stack | 按栈顺序依次弹出执行（后进先出） |
General Boot Testing
│
┌────────────┴────────────┐
│ │
boot_stack boot_list
│ │
while stack > 0 for max_num_tests
│ │
pop 一个 每轮重新选择
│ │
指定顺序执行 根据当前状态过滤候选
│
random.choice
│
执行一个 Boot
测试框架会检查当前机器状态，选择start条件匹配的操作执行。
如果两者都为空，测试会直接失败并报错
测架构试架构
obmc_boot_test.robot (测试用例)
↓
obmc_boot_test_resource.robot (资源文件)
↓
obmc_boot_test.py (Python 核心逻辑)
↓
boot_data.py (启动表管理)
↓
data/boot_table.json (启动操作定义)
可选参数
| 参数 | 默认值 | 说明 |
|---|---|---|
stack_mode | normal | normal=顺序执行，skip=跳过不操作 |
max_num_tests | 0 | 最大测试次数，0 表示无限循环 |
power_on_timeout | 14 mins | 开机超时时间 |
power_off_timeout | 2 mins | 关机超时时间 |
boot_fail_threshold | 0 | 失败阈值，超过则返回非零 |
boot_table_path | data/boot_table.json | 自定义启动表路径 |
quiet | 0 | 1=减少日志输出 |
debug | 0 | 1=开启调试输出 |
测试示例
tox -e e2ps23 -- -v "boot_stack:RF SYS GracefulRestart" extended/obmc_boot_test.robot
如果服务器初始状态是上电状态，就会直接软关机，如果是下电状态，会先上电再执行RF SYS GracefulRestart
tox -e e2ps23 -- -v "boot_list:RF SYS GracefulRestart" -v "max_num_tests:3" extended/obmc_boot_test.robot
boot_list决定候选 Boot 操作，max_num_tests决定最多执行多少轮；每一轮是否真正执行指定操作，还取决于当前系统状态是否满足该操作的前置条件。若不满足，框架可能先使用默认 Boot 操作完成状态转换。
所以上述命令有可能执行2次或者3次重启，取决于初始状态。如果max_num_tests是1，就可能执行0-1次，因为初始状态如果不满足会先执行Redfish Power On 消耗测试次数。
tox -e e2ps23 -- -v "boot_list:Redfish Power Off:Redfish Power On" -v "max_num_tests:30" extended/obmc_boot_test.robot
关键字扩展
例如特定的BMC 平台，有一个 OpenBMC upstream 没有的操作
BMC watchdog reset就可以实现对应的关键字，然后加入到boot_table.json中，这样framework 就能够把它当成一个标准 boot type
 调度算法深度解析 —— 优先级数组、位图优化与活跃 / 过期双队列)