*openUBMC 支持Raid卡固件升级详细设计说明书*

<table>
    <tr>
        <td>所属SIG组:</td>
        <td>hardware</td>
    </tr>
    <tr>
        <td>落入版本:</td>
        <td>26.03</td>
    </tr>
    <tr>
        <td>设计人员:</td>
        <td>李东辉</td>
    </tr>
    <tr>
        <td>日期:</td>
        <td>2026/1/30</td>
    </tr>
</table>


**Copyright © 2025 openUBMC Community**

您对&quot;本文档&quot;的复制，使用，修改及分发受木兰宽松许可证, 第2版协议(以下简称&quot;MulanPSL2&quot;)的约束。
为了方便用户理解，您可以通过访问<https://license.coscl.org.cn/MulanPSL2>了解MulanPSL2的概要 (但不是替代)。
MulanPSL2的完整协议内容您可以访问如下网址获取：<https://license.coscl.org.cn/MulanPSL2>。

**改版记录**

<table>
    <tr>
        <th>日期</th>
        <th>修订版本</th>
        <th>修订描述</th>
        <th>作者</th>
        <th>审核</th>
    </tr>
    <tr>
        <td>2026/1/22</td>
        <td>1.0</td>
        <td>完成详细设计文档</td>
        <td>xxx</td>
        <td>xxx</td>
    </tr>
</table>

**List of abbreviations**  **缩略语清单** ：

<table>
    <tr>
        <th>Abbreviations 缩略语</th>
        <th>Full spelling 英文全名</th>
        <th>Chinese explanation 中文解释</th>
    </tr>
    <tr>
        <td>CRC</td>
        <td>Cyclic Redundancy Check</td>
        <td>循环冗余校验</td>
    </tr>
    <tr>
        <td>SHA</td>
        <td>Secure Hash Algorithm</td>
        <td>安全哈希算法</td>
    </tr>
    <tr>
        <td>SM3</td>
        <td>ShangMi 3</td>
        <td>国密SM3哈希算法</td>
    </tr>
    <tr>
        <td>SNMP</td>
        <td>Simple Network Management Protocol</td>
        <td>简单网络管理协议</td>
    </tr>
    <tr>
        <td>Redfish</td>
        <td>Redfish</td>
        <td>一种用于管理和监控服务器硬件的RESTful API标准</td>
    </tr>
    <tr>
        <td>WEBREST</td>
        <td>Web RESTful API</td>
        <td>基于Web的RESTful接口</td>
    </tr>
</table>

[TOC]

# 1.功能分析
## 1.1 功能背景
<!-- 描述该需求的来源或背景，比如：支撑XXX功能、XXX优化等；以及该需求对用户（含组件）带来什么具体价值，如果没有该需求，对用户（含组件）带来什么损失； -->
当前自研RAID卡固件升级通常依赖OS侧工具或SP工具，需要重启系统，对业务产生影响、运维成本高、效率低。</br>
本需求通过BMC带外通道提供RAID卡固件热升级能力，使运维人员可通过北向接口发起升级、查询进度/结果。</br>
带外热升级功能避免使用带内接口，省去客户申请权限步骤，且热升级不影响业务，提高维护效率，降低维护成本。</br>

## 1.2 功能描述
<!-- 描述该需求交付的整体功能，主要实现XXX功能，解决XXX问题，明确方案如何实现 -->
实现对RAID的带外固件升级能力，覆盖升级准备、升级执行、升级完成及可选的生效等阶段。</br>
北向固件管理适配。</br>

方案概述：
1.复用现有升级框架，通过固件管理处理不同的升级阶段，发送信号驱动RAID卡的升级流程（Prepare/Process/Finish）。</br>
2.platform.sr配置新增硬盘固件类型对象`FirmwareComponentInfo_Raid`</br>
```
"FirmwareComponentInfo_Raid" : {
    "ComponentID" : 13,
    "ComponentIDEx" : 218103809,
    "Name" : "Raid"
}
```
该对象会通过自发现上报到固件管理，表示当前机型支持RAID卡固件升级，如果不配置，升级RIAD卡固件包时，固件管理会认为是不支持的固件类型，不会触发升级流程。</br>
3.固件管理会通过ComponentID/ComponentIDEx匹配到下发升级类型， FirmwareType = 'Raid', 但是Storage可以管理不同厂商的RAID卡，</br>
因此要在SR中配置：</br>
```
"ControllerFirmware_1" : {
    "ComponentID": 13,
    "ComponentIDEx": 218103809
}
```
通过"ControllerFirmware_1"和"FirmwareComponentInfo_Raid"的ComponentID/ComponentIDEx匹配，就能限制升级目标厂商的RAID卡固件。</br>
4.Prepare阶段：检查升级条件是否满足，获取hpm包中的配置信息(用于和ControllerFirmware_1中的ComponentID/ComponentIDEx匹配)</br>
5.Process阶段：通过Prepare阶段获取的配置信息，判断哪些RAID卡可升级，然后调用底层C代码进行传包升级。升级完会立即激活。
6.Finish阶段，没有有效动作，只是反馈升级完成。</br>

## 1.3 功能场景
1)场景触发条件及对象：运维人员、开发人员在需要升级Raid卡固件版本时使用
2)使用时间及频度：不频繁，通常在固件版本更新或故障修复时使用

## 1.4 功能列表
<!-- 描述该需求交付的功能列表，内容包括：列出功能详细描述，标题、描述。 -->
| 功能编号 | 功能标题 | 功能描述 |
| ------- | ------- | -------- |
| 1 | 支持带外对1880 Raid卡进行固件升级 | 升级配置相关处理； 新增升级信号处理；升级RAID卡固件注册升级；北向适配； |
| 2 | 支持1880 Raid卡固件的升级和激活 | RAID卡传包接口实现；RAID卡固件激活接口实现； |
| 3 | 支持Raid卡固件文件上传 | Web界面支持上传固件文件，支持文件格式校验 |
| 4 | 支持固件文件完整性校验 | 支持CRC32、SHA256、SM3等多种哈希算法校验 |
| 5 | 支持固件升级流程 | 实现固件下载、校验、升级、验证的完整流程 |
| 6 | 支持升级进度显示 | 实时显示升级进度百分比，提供升级状态反馈 |
| 8 | 支持北向接口显示Raid卡固件版本信息 | 通过SNMP、Redfish、WEBREST等北向接口查询Raid卡固件版本信息 |

# 2.功能设计
## 2.1 总体方案分析
<!-- 描述该方案的总体设计（注：相关输出方案可同步刷新到各组件仓） -->
### 2.1.1 方案详细设计

评审接口：https://discuss.openubmc.cn/t/topic/4256

#### 2.1.1.1 方案概述
<!-- 描述该方案的整体实现，内容包括：涉及的关键点，实现策略等 -->
1.storage组件会提前注册监听信号(Prepare/Process/Finish)。</br>
2.将RAID卡的固件构建为通用hpm格式的升级包，通过北向触发升级。</br>
3.固件管理组件解析hpm包，根据plateform.sr配置，下发升级信号Prepare，下发信息：FirmwareType=Raid。</br>
4.storage组件收到Prepare信号，如果是Raid类型，则处理该信号，否则忽略。</br>
5.storage处理Prepare信号，返回处理结果给固件管理。如果成功，则固件管理会下发升级信号Process。</br>
6.storage组件收到Process信号，如果是Raid类型，则处理该信号，否则忽略。</br>
7.storage组件在Process阶段判断哪些RAID可以进行固件升级，实现传包，升级等操作，返回成功，固件管理会下发升级信号Finish。</br>
8.storage组件在Finish阶段没什么操作，就直接返回成功。</br>
9.固件管理组件收到Finish阶段成功反馈之后，在北向显示升级完成。</br>
update.cfg配置文件关键参数：</br>
```
[Firmware1]
ComponentID=13
ComponentIDEx=218103809
```
#### 2.1.1.2 北向接口显示Raid卡固件版本信息方案概述
<!-- 描述北向接口显示版本信息的整体实现，内容包括：涉及的关键点，实现策略等 -->
1.在Controller对象更新流程中，判断是否为支持固件升级的Raid卡，如果是则注册FirmwareInfo对象到FirmwareInventory</br>
2.当Raid卡固件版本变更时，更新对应的FirmwareInfo对象信息</br>
3.当Raid卡拔出时，取消注册对应的FirmwareInfo对象（实际不支持该场景，必须AC才能拔出Raid卡）</br>
4.通过北向映射器配置，使得FirmwareInventory中的FirmwareInfo对象可以通过SNMP、Redfish、WEBREST等北向接口查询</br>

#### 2.1.1.3 开发视图
<!-- 开发视图面向系统开发及软件管理，描述系统代码结构，构建结构的视图，主要解决系统技术实现和开发的问题，它依托逻辑视图，描述代码、构建结构 -->
```mermaid
classDiagram
    class controller_firmware_object {
        + ComponentID
        + ComponentIDEx
    }

    class controller_upgrade {
        + on_upgrade_prepare(...)
        + on_upgrade_process(...)
        + on_upgrade_finish(...)
        + is_controller_upgrading
        + upgrade_controller_count
        + upgrade_list
        + cfgs
    }

    class I_raid_upgrade {
        + upgrade_ctrl_process(...)
        + get_upgrade_percent()
        + set_upgrade_percent_zero()
    }

    controller_upgrade --> controller_firmware_object
    controller_upgrade --> I_raid_upgrade
```

#### 2.1.1.4 升级运行视图
<!-- 运行视图面向系统运行，描述系统启动过程、运行期交互的视图，主要解决系统运行期交互，描述各可执行交付件在运行期的交互关系 -->
```mermaid
sequenceDiagram
    participant WebInterface
    participant 固件管理
    participant Storage

    WebInterface->>固件管理: 调用升级接口，触发升级
    固件管理->>固件管理: 校验是否支持升级Raid卡固件
    固件管理->>Storage: 触发升级Prepare信号
    Storage->>Storage: 判断是否满足升级，将hmp中update.cfg中的内容保存在本地：cfgs表中
    Storage->>固件管理: 返回成功
    固件管理->>Storage: 触发升级Process信号
    Storage->>Storage: 根据cfgs中的配置以及管理的Raid卡对象，判断哪些Raid卡可升级，保存在本地：upgrade_list
    Storage->>Storage: 调用接口：upgrade_ctrl_process进行升级操作，get_upgrade_percent更新升级进度
    Storage-->>固件管理: 返回成功
    固件管理-->>Storage: 触发升级Finish信号
    Storage-->>固件管理: 返回成功
    固件管理-->>WebInterface: 显示升级成功
```

### 2.1.2 内部依赖分析
<!-- 是否涉及与其他组件接口依赖，如果涉及需要确认当前是否已完成，是否匹配当前需求开发诉求 -->
依赖SML库提供的控制器操作接口

依赖固件管理组件（firmware_mgmt）的FirmwareInventory对象接口：
- Add接口：用于注册FirmwareInfo对象，通过method_misc的retry_register_firmware_info方法调用，带重试机制（重试3次，间隔5秒）
- 无更新接口，需要通过mdb.get_cached_object获取FirmwareInfo对象后直接赋值更新Version属性

依赖storage组件内部的client模块提供的接口：
- PFirmwareInventoryFirmwareInventoryAdd：调用FirmwareInventory的Add接口
- SubscribeUpdateServiceUpdateServiceUpgradePrepareSignal：订阅UpgradePrepare信号
- SubscribeUpdateServiceUpdateServiceUpgradeProcessSignal：订阅UpgradeProcess信号
- SubscribeUpdateServiceUpdateServiceUpgradeFinishSignal：订阅UpgradeFinish信号

### 2.1.3 外部依赖分析
<!-- 是否涉及与平台SDK的依赖关系 -->
依赖Raid卡固件能力支持固件升级功能

### 2.1.4 北向接口分析
<!-- 需要分析当前功能是否有以下接口影响，如果有影响，则需要具体的补充影响点。其中注意点如下：
（1）如果有新增IPMI接口，请排查代码中IPMI命令注册的过滤字段，是否完全和IPMI命令的定义一致？
（2）新增一个接口时，需要咨询SIG组是否还有其他的接口受影响 -->
| 特性 | SNMP | CLI | WEB | KVM_VMM | IPMI(RMCP/RMCP+) | HMM | Redfish |
| ---- | ---- | ---- | --- | ------ | ---------------- | --- | ------- |
| 支持Raid卡固件升级 | 涉及 | 不涉及 | 涉及 | 不涉及 | 不涉及 | 不涉及 | 涉及 |
| 支持北向接口显示Raid卡固件版本信息 | 涉及 | 不涉及 | 涉及 | 不涉及 | 不涉及 | 不涉及 | 涉及 |

**各北向接口详细说明：**

1. **WEB接口**：
   - 接口路径：`UI/Rest/BMCSettings/UpdateService`
   - 方法：Get
   - 说明：新增Raid卡固件版本信息展示

2. **SNMP接口**：
   - 接口路径：`/snmp/1.3.6.1.4.1.{{SnmpOemIdentifier}}.11.50/firmwareDescriptionTable/Readonly`
   - 方法：Get
   - 说明：显示Raid卡FirmwareType需新增枚举值（24）代表Raid卡固件类型，需要更新资料和MIB文件

3. **Redfish接口**：
   - 接口路径：`/redfish/v1/UpdateService/FirmwareInventory`
   - 方法：Get
   - 说明：需要Members中新增Raid卡固件信息的@odata.id和对应uri

### 2.1.5 兼容性分析
<!-- 当前的功能对现有在网的功能是否有影响，具体的影响点进行分析之后输出影响分析表格 -->
对于不支持固件升级的Raid卡，不进行FirmwareInfo注册，不影响现有功能。
对于已支持固件升级的Raid卡，新增FirmwareInfo注册功能，不影响现有Controller对象的功能。
FirmwareInfo的持久化类型为TemporaryPer，BMC复位时数据会清除，Controller对象重新走自发现流程时会重新判断是否需要注册FirmwareInfo对象。

### 2.1.6 定制化接口分析
不涉及

### 2.1.7 导入导出分析
<!-- 如果支持导入导出的配置，则需要分析导入导出的schema。 -->
不涉及

### 2.1.8 传感器分析
<!-- 如果需要新增传感器，则需要提前登记和评审新增的传感器要素。新增传感器评审需要上SIG-Interface进行评审 -->
不涉及

### 2.1.9 精准告警事件分析
<!-- 如果需要新增事件，则需要提前登记和评审新增的时间要素 -->
不涉及

### 2.1.10 系统锁定分析
<!-- 对外的接口或者命令是否支持系统锁定 -->
升级过程中建议锁定系统，避免其他操作干扰

### 2.1.11 用例场景分析
<!-- 以表格的形式输出该需求涉及的用例场景 -->

| 用例编号 | 用例描述 | 前置条件 |执行步骤 | 预期结果 |
| --- | --- | --- | --- | --- |
| 1 | 正常升级流程验证 | BMC正常运行；自研RAID卡在位；准备好匹配的hpm包 | 1.北向触发升级； | 升级流程完成，进度到100%，状态为Completed；Raid卡版本更新 |
| 2 | 固件管理，web界面存在Raid卡的版本卡片 | BMC正常运行；自研RAID卡在位； | 1.查看web状态 | web页面正常显示版本卡片 |
| 3 | 固件管理，redfish界面显示Raid卡的版本信息 | BMC正常运行；自研RAID卡在位； | 1.redfish接口访问 | redfish接口正常显示 |
| 4 | os下电，验证正常升级 | BMC正常运行；自研RAID卡在位； | 1.北向出发升级 | 升级报错，不满足升级条件 |
| 5 | 升级过程其他Raid卡操作 | BMC正常运行；自研RAID卡在位； | 1.北向出发升级；2.触发其他Raid卡操作 | Raid卡其他操作失败 |
| 6 | 升级双Raid卡操作 | BMC正常运行；自研RAID卡在位； | 1.北向出发升级；| Raid卡升级成功 |
| 7 | 升级过程，os下电 | BMC正常运行；自研RAID卡在位； | 1.北向出发升级；2.升级中os下电； | 不允许下电 |
| 8 | 重复升级相同版本 | 上传与当前版本相同的固件 | 1.上传相同版本；2.触发升级 | 激活过程失败，不允许同版本激活|
| 9 | 支持固件升级的Raid卡插入后注册FirmwareInfo | BMC正常运行，支持固件升级的Raid卡在位 | 1.插入支持固件升级的Raid卡；2.等待Raid卡识别完成；3.通过SNMP/Redfish/Web接口查询FirmwareInventory；4.检查对应Raid卡的FirmwareInfo是否存在；5.对比FirmwareInfo的Version与Raid卡FirmwareVersion是否一致 | FirmwareInventory中存在对应Raid卡的FirmwareInfo对象，Version字段与Raid卡实际固件版本一致 |
| 10 | 不支持固件升级的Raid卡不注册FirmwareInfo | BMC正常运行，不支持固件升级的Raid卡在位 | 1.插入不支持固件升级的Raid卡；2.等待Raid卡识别完成；3.通过SNMP/Redfish/Web接口查询FirmwareInventory；4.检查FirmwareInventory中是否存在该Raid卡的FirmwareInfo | FirmwareInventory中不存在该Raid卡的FirmwareInfo对象 |
| 11 | Raid卡固件版本更新时同步更新FirmwareInfo | 已插入支持固件升级的Raid卡，FirmwareInfo已注册 | 1.记录当前Raid卡固件版本；2.对Raid卡进行固件升级操作；3.等待升级完成；4.通过SNMP/Redfish/Web接口查询FirmwareInventory；5.检查对应Raid卡的FirmwareInfo的Version字段 | FirmwareInfo的Version字段更新为升级后的新版本号 |
| 13 | 通过SNMP查询Raid卡固件版本信息 | 已插入支持固件升级的Raid卡，FirmwareInfo已注册 | 1.通过SNMP客户端工具访问OID：1.3.6.1.4.1.{{SnmpOemIdentifier}}.11.50/firmwareDescriptionTable；2.查看返回的固件列表；3.查找Raid卡对应的固件信息项；4.检查FirmwareType字段和Version字段 | 返回的固件列表中包含Raid卡固件信息，FirmwareType为24，Version为Raid卡实际固件版本 |
| 14 | 通过Redfish查询Raid卡固件版本信息 | 已插入支持固件升级的Raid卡，FirmwareInfo已注册 | 1.通过Redfish客户端访问/redfish/v1/UpdateService/FirmwareInventory；2.查看Members列表；3.查找Raid卡对应的FirmwareInfo URI；4.访问该URI获取详细信息；5.检查Version字段 | Members列表中包含Raid卡的@odata.id，访问对应URI返回Raid卡固件详细信息，Version为Raid卡实际固件版本 |
| 15 | 通过WEBREST查询Raid卡固件版本信息 | 已插入支持固件升级的Raid卡，FirmwareInfo已注册 | 1.通过Web浏览器或REST客户端访问UI/Rest/BMCSettings/UpdateService；2.查看返回的固件列表；3.查找Raid卡对应的固件信息；4.检查Version字段 | 返回的固件列表中包含Raid卡固件信息，Version为Raid卡实际固件版本 |
| 16 | BMC复位后FirmwareInfo重新注册 | 已插入支持固件升级的Raid卡，FirmwareInfo已注册 | 1.通过命令触发BMC复位；2.等待BMC重启完成；3.等待Raid卡重新识别完成；4.通过SNMP/Redfish/Web接口查询FirmwareInventory；5.检查Raid卡的FirmwareInfo是否存在及Version是否正确 | BMC复位后，FirmwareInventory中重新生成Raid卡的FirmwareInfo对象，Version为Raid卡实际固件版本 |
| 17 | FirmwareInfo的Id唯一性验证 | BMC正常运行，支持固件升级的Raid卡在位，有多个Raid卡槽位 | 1.同时插入多个支持固件升级的Raid卡；2.等待所有Raid卡识别完成；3.通过SNMP/Redfish/Web接口查询FirmwareInventory；4.记录所有Raid卡FirmwareInfo的Id字段；5.检查Id是否有重复 | FirmwareInventory中每个Raid卡的FirmwareInfo对象的Id唯一，无重复 |
| 18 | OS复位后FirmwareInfo保持 | 已插入支持固件升级的Raid卡，FirmwareInfo已注册，OS正常运行 | 1.记录复位前FirmwareInventory中Raid卡的FirmwareInfo信息；2.触发OS复位（warm reset）；3.等待OS重启完成；4.通过SNMP/Redfish/Web接口查询FirmwareInventory；5.对比复位前后FirmwareInfo信息 | OS复位后，FirmwareInfo对象保持不变，Version与复位前一致 |
| 19 | 整机AC后FirmwareInfo重新注册 | 已插入支持固件升级的Raid卡，FirmwareInfo已注册 | 1.记录AC前FirmwareInventory中Raid卡的FirmwareInfo信息；2.对整机进行AC下电；3.对整机进行AC上电；4.等待BMC和系统启动完成；5.等待Raid卡重新识别完成；6.通过SNMP/Redfish/Web接口查询FirmwareInventory；7.检查Raid卡的FirmwareInfo是否存在及Version是否正确 | 整机AC后，FirmwareInventory中重新生成Raid卡的FirmwareInfo对象，Version为Raid卡实际固件版本 |

## 2.2 非功能质量属性设计
### 2.2.1 扩展性分析
<!-- 考虑后续新增类似功能可以很好地扩展 -->
不涉及

### 2.2.2 重用性分析
<!-- 是否为通用处理方式、接口，如果是得考虑重用性 -->
不涉及

### 2.2.3 可测试性分析
<!-- 此需求如何验证，是否可直接验证，or通过XXX功能覆盖验证，or需要单独怎加测试接口验证 -->
1.通过Web界面或者北向接口进行升级测试
2.开发会提供Raid卡固件打包出来的hpm文件，Raid卡原始固件为：packet_raid.img

### 2.2.4 资料分析
<!-- 是否涉及资料修改 -->
需要同步修改snmp, web, redfish内部文档，新增Raid卡固件版本信息展示

### 2.2.5 资源使用分析
<!-- 新增线程、内存分配、模型属性名长度是否合理，CPU占用率是否会激增，Flash中新增文件是否合理（频繁读写Flash会大幅缩短emmc寿命）；是否涉及消息队列，如果涉及请检查是否存在某些场景下消息队列会满导致消息丢失，例如大量消息发送到队列且处理消息需要耗费较长时间的场景。 -->
1.升级过程中需要临时存储固件文件，占用Flash空间
2.升级过程中CPU占用率会有短暂提升
3.不涉及消息队列

### 2.2.6 可靠性分析
| 编号 | 场景 | 问题描述 | 可靠性影响 | 建议解决方案/需求 | 备注 |
| --- | --- | --- | --- | --- | --- |
| 1 | OS下电 | 升级依赖OS上电，OS下电时通信中断 | 升级无法进行/中断 | Prepare阶段校验OS电源状态，OS未上电则返回"不满足升级条件"；升级过程OS下电需要防护 | 未实现 |
| 2 | 未匹配到升级包对应的Raid卡 | 非目标Raid卡，不支持升级 | 升级无法进行 | Prepare阶段返回失败 | 已实现 |
| 3 | 升级中控制器异常 | 控制器重置/掉线 | 任务失败/资源泄漏 | 任务超时与异常捕获；释放资源；升级或生效针对硬盘层面都有重试机制 | 已实现 |
| 4 | BMC复位（升级进行中） | 任务上下文丢失，但已升级硬盘表持久化 | 任务中断 | 已升级成功待生效的硬盘只有在给固件管理注册生效对象后才进行复位持久化，该场景复位起来后仍可生效，如果注册生效对象前复位则此次升级失败 | 已实现 |
| 5 | 整机AC（升级进行中） | 系统全断电 | 任务中断 | AC导致任务失败 | 未实现 |

### 2.2.7 安全性分析
| 安全合规项 | 是否涉及 | 现有的防护措施 |
| --- | --- | --- |
| 访问控制（通道、文件权限、用户权限、查询权限、配置权限、接口权限） | 涉及 | 升级操作需要管理员权限 |
| 敏感数据 | 涉及 | 固件文件使用加密传输 |
| 日志（操作日志、维护日志、安全日志、运行日志） | 涉及 | 记录升级操作日志 |
| 文档 | 不涉及 |  |
| 加密及算法 | 涉及 | 支持SHA256、SM3哈希算法 |
| 新增关键资源（密钥、证书、关键配置）备份、恢复 | 不涉及 |  |
| 新增对外接口入参校验 | 涉及 | 校验文件路径、控制器索引等参数 |
| 新增开源及三方软件引入 | 涉及 | 使用OpenSSL库进行哈希计算 |

# 3.功能实现
<!-- 通过表格、流程图、简明文字描述提供，力求容易看懂、容易实现，详细描述细节。 -->
## 3.1 支持Raid卡固件升级
### 3.1.1 功能实现设计
###### 3.1.2 功能详细设计
如 2.1.1.3 章节所示

### 3.1.3 开发者测试
<!--
增加模块接口：以活动图/流程图等形式明确模块内处理流程，针对模块处理流程中的分支进行覆盖
修改模块接口处理流程：覆盖修改影响流程分支
-->
#### 3.1.3.1 单元测试
<!-- UT，主要是功能单元测试，测试对象是功能单元接口。UT测试设计要从黑盒（功能）角度设计，从输入(I)、处理（B)、预期输出(O)的角度进行用例分析设计，测试覆盖率仅作为反馈，用于分析哪些功能场景没有覆盖到，从而指导测试设计优化并补充测试用例 -->

| 组件名 | 用例类型 | 测试用例描述 | 用例名称 | 预置条件 | 操作步骤 | 预期结果 |
| --- | ---| --- | --- | ---| --- | --- |
| Storage | UT | 测试升级模块初始化 | test_init | 打桩正常环境 | 1.调用初始化接口 | 升级模块属性为无效值 |
| Storage | UT | 测试固件类型非Raid | test_on_upgrade_prepare_not_raid_firmware | 打桩正常环境 | 1.打桩FimwareType不为Raid | 返回升级错误  |
| Storage | UT | 测试SMBIOS状态不正确 | test_on_upgrade_prepare_smbios_not_ready | 打桩正常环境 | 1.打桩SMBIOS状态异常  | 返回升级错误  |
| Storage | UT | 测试电源状态不正确 | test_on_upgrade_prepare_power_not_on | 打桩正常环境 | 1.打桩电源状态异常  | 返回升级错误  |
| Storage | UT | 测试controller firmware对象不存在 | test_on_upgrade_prepare_no_controller_firmware | 打桩正常环境 | 1.打桩controller firmware对象不存在  | 返回升级错误 |
| Storage | UT | 测试没有支持OOB的控制器 | test_on_upgrade_prepare_no_oob_support | 打桩正常环境 | 1.打桩没有支持OOB的控制器  | 返回升级错误  |
| Storage | UT | 测试已经升级中重复升级 | test_on_upgrade_prepare_already_upgrading | 打桩正常环境 | 1.打桩已经升级；2.调用升级接口 | 返回升级错误  |
| Storage | UT | 测试FileChown失败 | test_on_upgrade_prepare_chown_failed| 打桩正常环境 | 1.打桩FileChown失败 | 返回升级错误  |
| Storage | UT | 测试正常升级场景 | test_on_upgrade_prepare_success | 打桩正常环境 | 1.打桩正常升级条件；2.调用升级接口 | 返回成功  |
| Storage | UT | 测试非Raid卡固件升级校验 | test_on_upgrade_process_not_raid_firmware | 打桩正常环境 | 1.打桩FirmwareType不为Raid；2.调用升级接口 | 返回升级错误  |
| Storage | UT | 测试没有需要升级的Raid卡 | test_on_upgrade_progress_no_upgrade_list | 打桩正常环境 | 1.打桩没有Raid卡；2.调用升级接口；|返回升级错误 |
| Storage | UT | 测试Process成功场景 | test_on_upgrade_process_success | 打桩正常环境 | 1.打桩正常升级条件；2.调用升级接口 | 返回成功  |
| Storage | UT | 测试Finish阶段非Raid卡类型| test_on_upgrade_finish_not_raid_firmware | 打桩正常环境 | 1.打桩Finish接口固件类型非Raid| 返回升级错误 |
| Storage | UT | 测试Finish成功场景 | test_on_upgrade_finish_success | 打桩正常环境 | 1.打桩正常升级条件；2.调用升级接口 | 返回成功 |
| Storage | UT | 测试完成升级流程 | test_full_upgrade_flow | 打桩正常环境 | 1.打桩正常升级条件；2.调用升级接口| 返回成功 |
| Storage | UT | 测试混合OOB支持场景 | test_mixed_oob_support | 打桩正常环境 | 1.打桩多个Raid，有的支持OOB有的不支持 | Prepare阶段返回成功 |
| Storage | UT | 测试完成升级流程 | test_full_upgrade_flow | 打桩正常环境 | 1.打桩正常升级条件；2.调用升级接口| 返回成功 |
| Storage | UT | 测试准备阶段找不到固件版本 | test_on_upgrade_prepare_no_version_found | 打桩正常环境 | 1.打桩Raid卡无效Version；2.调用升级接口| Prepare返回成功 |
| Storage | UT | 测试资源清理功能 | test_clear_resources_on_error | 打桩正常环境 | 1.打桩升级异常；2.调用升级接口| 资源正常清理为无效值 |

#### 3.1.3.2 集成测试
<!-- IT，主要是组件/模块内的集成测试，测试对象是模块/组件接口。IT测试设计将模块/组件当作黑盒测试，IT测试用例中禁止对组件/模块内部代码打桩，如果确实有少量场景难以构造，可以考虑在测试框架中统一打桩并提供接口供测试用例调用构造场景。
说明：API测试属于IT，其测试对象是微服务接口。
PCST，是指PC上的服务集成测试，测试对象是功能需求。PCST测试设计，要覆盖正常功能、异常功能和交叉功能，采用灰盒 -->
不涉及