基于IPMI技術的嵌入式軟件測試策略

/ 上海市軟件評測中心

0 引言

自從Dell、HP、Intel和NEC于1998年共同提出了IPMI技術標準后，為各個服務器廠商又提供了一種新的專用管理工具，它有助于對不同種類服務器系統實施管理，使交叉平臺的管理成為可能。

IPMI（智能平臺管理接口）技術標準從1998年提出至今，它的應用日益廣泛，對以IPMI技術為標準的相關軟件產品的可靠性提出更高的要求，即對IPMI Firmware（智能平臺管理接口固件）需要進行嚴格的測試。由于目前相關的測試軟件比較缺乏或者存在局限性，因此有必要制定一種基于IPMI技術的測試策略，設計適合于IPMI Firmware在嵌入式軟件系統中的測試框架，實現對IPMI Firmware的功能測試。本文以SAN Macro DRAC5項目為例。

1 相關技術的概述

1.1 IPMI技術架構

IPMI技術是一項應用于服務器管理系統設計的標準，用戶可以利用IPMI技術監視服務器的物理健康特征，如溫度、電壓、電扇工作狀態、電源供應等，為系統管理、系統恢復提供信息。利用IPMI接口標準對不同類型服務器系統硬件實施的有效管理，使不同平臺的集中管理成為可能。圖1為智能平臺管理接口架構示意圖[1]。IPMI技術不管服務器的狀態如何，都可以提供遠程監測、管理和恢復功能。

圖1 智能平臺管理接口架構示意圖

1.2 BMC(基板管理控制器)以及接口

IPMI定義了用于接口連接嵌入在服務器平臺中的一種服務處理器的協議。這種服務處理器叫做BMC，它安裝在服務器主板或刀片服務器、電信平臺的機架上。在IPMI管理平臺中，BMC是核心控制器，系統管理軟件對每個被管理器件的管理，都是通過與BMC通信來實現的。BMC通過串行總線連接到主處理器以及母板的其他器件。

從圖1中可知，BMC通過個別的界面來管理整個系統，如系統狀態監測及事件過濾、電源管理、記錄事件發生時間及系統回復控制，并且透過網絡或串行端口來告知管理人員。另外，它提供了IPMB（智能平臺管理總線）的總線來和外部的管理控制器互相溝通。通常一個基本的BMC所提供的接口有以下幾種[1]：

（1）系統接口（System Interface）

IPMI定義了系統軟件用于把IPMI消息傳遞到BMC的3個標準的系統接口，即KCS (鍵盤控制器樣式)、SMIC (系統管理接口控制)和BT(塊傳輸)。

（2）I2C/IPMB接口

通常一個BMC會有幾組I2C（兩線式串行總線）和外圍的傳感器等溝通，以讀取系統監測值以及記錄相關數據。另外也可外接一些GPIO（普通用途的輸入輸出端口）控制器來擴充系統的監測功能。IPMB則是必須存在的一組界面，用來和外部控制單位溝通。

（3）Serial/Modem（串行/調制解調器）接口

它主要有三種連接模式：Basic（基本）模式、PPP（點對點協議）模式及Terminal（終端模式），三者即可讓管理者通過文字模式解譯IPMI平臺上的狀態或簡單地下達IPMI命令。

（4）LAN （網絡）接口

BMC可經由LAN的界面讓管理者接收傳送IPMI信息。若使用共享的LAN控制器，當服務器系統被鎖定或關機時BMC仍能順利將其激活。越來越多的應用軟件運用這個接口使軟件和遠程的BMC溝通。

2 基于IPMI技術的測試策略和方法

2.1 IPMI Firmware在嵌入式軟件系統中的測試策略

在嵌入式領域目標系統的應用系統日趨復雜，目前的嵌入式軟件測試一般采用Host-Target（主機-目標機）或者是交叉測試。由于測試系統平臺的多樣性，目前還沒有通用性框架適合于嵌入式軟件的測試。雖然IPMI技術的應用日益廣泛,但是當前有關IPMI Firmware的測試工具又很缺乏，所以給測試帶來諸多困難。

對于一般商用軟件的測試，嵌入式軟件測試有其自身的特點和測試困難。不同的嵌入式軟件系統應該有不同的測試方法，而軟件的測試策略又不是一成不變的，應根據特定的嵌入式軟件的特性，制定出一種行之有效的測試策略，所以嵌入式軟件的測試都應結合自身實際情況，選定合理測試策略和方案。根據嵌入式軟件系統的測試特點，主要針對DRAC5和BMC間的IPMI Firmware的傳輸特點，建立一種行之有效的測試策略：

（1）準備相關的測試硬件和軟件，建立一個適合于DRAC5和BMC之間IPMI Firmware測試環境，依據嵌入式軟件測試特點,建立一個跨平臺的測試環境。

（2）依據嵌入式軟件的測試特點和IPMI技術標準的特點，在不同的測試階段，通過分析、比較，確定最終采用的測試方法。

（3）基于IPMI技術標準以及其功能性和不同的測試階段技術性的要求，設計出適合的嵌入式軟件的自動測試框架，確定適合DRAC 5和BMC之間IPMI Firmware軟件自動化測試用例的測試腳本，達到測試的目標，最終實現基于IPMI技術特性的自動化測試。

2.2 建立IPMI Firmware的測試模型

軟件測試的模型，現在常用的有V模型，W模型，X模型和H模型。W、X模型都是對V模型的補充。V模型把開發活動看成是從需求開始到編碼結束的串行活動，只有上一階段完成后，才可以開始下一階段的活動，不支持迭代、自發性以及變更調整[3]。

H模型強調測試是獨立的，只要測試準備完成，就可以執行測試。對于大型的復雜軟件系統，軟件開發人員每次創建一個新的版本后，測試執行隨即進行。可以說這種模型是一個測試周期的充分體現。在San Marco項目中將采用這種測試模型，每當開發人員創建出一個新的版本后，隨即進入執行測試階段。圖2 顯示基于嵌入式系統的H模型。

圖 2 嵌入式測試的H模型

3 基于IPMI技術自動化測試方案

3.1 建立IPMI Firmware測試平臺

一般商用軟件的測試，嵌入式軟件測試有其自身的特點和測試困難。任何人或組織進行嵌入式軟件的測試都應結合自身實際情況，選定合理測試策略和測試方法[4]。針對IPMI Firmware在嵌入式軟件系統中的功能測試，IPMI自動化測試方案主要集中在IPMI Firmware單元測試、集成測試和壓力測試。

3.1.1 單元測試

由于IPMI技術有其特殊性，建立一個不同于host-target的多測試平臺環境，它為用戶提供不同的Channel（通道）實現IPMI的相關功能，所以測試不能單純地在主機平臺完成，根據IPMI在不同的Channel，在主機或目標環境下進行測試。遵循的原則是：

（1）將程序的一組IPMI命令或一個模塊作為一個獨立的測試單元；

（2）生成IPMI的測試用例（包括測試輸入，標準輸出，測試操作指令等）；

（3）在不同的Channel包括LAN、KCS 和Serial/Modem，驗證各個測試用例的正確性；

（4）IPMI操作指令的測試結果與標準（參照IPMI 說明書）輸出的對比；

（5）將不吻合的測試結果進行分析、記錄、分類和通報。

3.1.2 集成測試

在不同的Channel下的各個單元測試模塊被組合起來，通過集成自動化測試程序對它們進行測試，以檢查這些單元之間的接口是否存在問題。

（1）通過不同的Channel，將所有的測試模塊通過集成自動化測試程序驗證IPMI功能的正確性。

（2）Dell將IPMI Firmware移植到DAC5嵌入式Linux環境內，所以對DRAC5和BMC之間的IPMI Firmware的集成測試尤為重要，主要通過（例如通過BMC發送一個Serial Over LAN（局域網上遠程串口）的功能，BMC將此命令直接傳遞給DRAC5的IPMI Firmware處理）相關的集成測試程序驗證其正確性。

3.1.3 壓力測試

壓力測試是系統測試的一部分，為了確保嵌入式軟件系統的穩定性，在不同的測試平臺下，通過可重復的負載測試,了解IPMI Firmware在嵌入式軟件系統下性能的可靠性、穩定性，以減少因IPMI性能的問題給系統帶來瓶頸。在選定的壓力值范圍內，各種性能指標在標準指定的范圍內無泄露、無系統崩潰、無性能故障等，以提高嵌入式軟件在目標環境中的質量。

（1）選擇經過單元測試的，且容易出錯的一組或多組IPMI命令，在不同的Channel下持續進行壓力測試，確保其IPMI功能的準確性。

（2）選擇經過單元測試的，且穩定可靠的一組或多組IPMI命令，通過不同Channel組合，持續進行穩定性測試。

3.2 基于IPMI技術的自動化測試方法與策略

3.2.1 自動化測試必要性

常用IPMI命令有幾百條，IPMI Firmware測試不僅需要具備非常專業的知識，同時需要輸入大量測試數據，測試工作十分復雜并易出錯。如果用人工來完成測試，每次的測試結果還會因為人為的原因帶來很大差異，所以十分需要運用自動化的測試軟件來替代人工的測試，保證測試結果的正確性。因此，在單元測試、集成測試和系統的壓力測試中引入自動化測試方案顯得由為重要。

3.2.2 測試框架選擇

（1）ICTS

ICTS（IPMI一致性測試系統) 是基于FTF （固件測試框架）架構下開發的關于IPMI自動化測試框架[5]。它主要針對符合Intel 主板標準、相關IPMI命令集的自動化測試。它不支持其他OEM廠商（例如Dell、HP等）的目標平臺下，相關IPMI 特殊功能的測試和驗證，所以ICTS有它的局限性。工作的下一目標是基于ICTS的框架下，開發出通用的、對IPMI Firmware進行功能驗證的自動化測試工具。

（2）IPMI Firmware的測試框架選擇

IPMI Firmware應用的開發過程是一個軟硬件互相協調、互相反饋和互相測試的過程, 有別于Windows（視窗）軟件系統的開發，它一般需要一個交叉編譯和調試的環境，即編輯和編譯軟件在主機上進行(如在個人臺式機Windows操作系統上)，編譯好的軟件需要下載到目標機上運行(如在一個目標機上的嵌入式Linux系統下)，主機和目標機建立起通信連接，并傳輸調試命令和數據。由于主機和目標機往往運行著不同的操作系統，而且處理器的體系結構也彼此不同，這就提高了IPMI應用開發和測試的復雜性。針對IPMI Firmware的基本功能測試、同步測試、OOB（帶外數據）的命令轉發機制測試、OEM（原始設備制造商）命令測試等，就需要開發適用于特定需求的自動化測試系統。

3.2.3 KFC Firmware的測試方法

KFC（Kernel Firmware Checker內核固件檢驗）是基于ICTS架構之上的KFC腳本驅動的自動化系統，也是利用ICTS對Firmware進行測試的控制中心。KFC測試系統采用上文介紹的Host-Target策略,San Macro Project在不同的測試環境中（主要研究在KCS、IPMB、Serial/Modem和LAN Channel）實施模塊測試、集成測試、系統測試及壓力測試等。

（1）KFC測試架構圖

圖3給出了用于KFC OOB（Out Of Band）測試系統主要的模塊，其中KFC和ICTS是最主要的模塊，KFC是整個測試系統的控制中心，它控制著每一個模塊，并且使這些模塊在這個系統中順利地運轉。ICTS用來處理所有的測試信息和數據，以及把這些命令請求封裝通過以太網或串行通信端口傳輸到目標平臺，同時也處理所有的接口信息以及分析測試結果。

Dell Montreal計算機的底板和DRAC上都嵌入Firmware，另外DRAC接管了所有通過LAN/Serial Channel的命令請求，只有當它檢測到某一條命令需要轉發到服務器上的BMC處理時，BMC才會對這條命令進行響應。如圖3所示，在Drac5 與BMC之間是通過I2C進行通信的。

圖3 KFC自動化測試框架示意圖

Parser（解析器）是該KFC測試系統的重要組成部分，定義了一套解析測試腳本的語法規則，它主要解析測試腳本的語法是否正確，只要在語法檢測無誤后，KFC測試系統才會真正執行測試腳本。

對于系統接口，由于通過系統總線直接把命令發給BMC，所以處理方式簡單很多。

（2）KFC Firmware測試過程及流程

基于KFC驅動IPMI Firmware測試過程流程和對應的數據流程，用戶通過寫測試腳本來定制需要的測試外，也需要指定一些附加的測試信息，比如填充必要的配置參數。KFC測試系統的測試輸出需要和IPMI技術規范及OEM需求相比較。一般來說，如果BMC返回的Completion Code（補充碼）不是0x00的話，可能該測試用例沒有通過。反之如果從BMC返回的Response Data（應答數據）與預期的相一致的話，則認為該測試用例通過。

3.2.4 KFC Firmware測試的實現

（1）IPMI命令功能測試

ICTS 自帶了測試用例來對SMS（系統管理軟件）、IPMB、LAN、Serial（串行口）、SMB（服務器消息塊）等接口的測試，用戶可以利用Cmdtool（命令工具）來發送單條命令以獲取需要的信息。

圖4所示是在Serial Terminal（串口終端）模式下通過Cmdtool窗口依次執行get device id, get lan configuration parameter命令來分別獲取設備信息，IP（網際協議）地址以及MAC（介質訪問控制）后BMC正確的應答。

注：如果這些命令的Completion Code 不是0x00，則表示BMC處理這些命令有誤，需要進一步檢查造成的原因。

圖4 獲取設備、遠程訪問卡等信息

（2）單元模塊測試

采用單元測試自動化功能和消息模塊相關的一系列IPMI命令，對IPMI Firmware分別進行測試，既驗證了IPMI命令的正確性，也為集成測試打好基礎。在不同的測試階段，應用不同的Channel對測試會產生不同的結果，從而能通過更多的方式來驗證IPMI Firmware在嵌入式軟件系統中功能的可靠性。

上面列出單元測試程序的處理過程：首先選擇一個被測的模塊和接口, 執行和調用相關的被測腳本以及處理腳本的語法解析程序 (KFC以及相關的Engine)，將測試腳本所需的返回值與IPMI相關的標準輸出比較，完成模塊最終的測試結果。

（3）模塊集成測試

KFC測試系統中的Testall.tcl是對IPMI所有模塊集成測試程序。圖5顯示集成測試自動化程序的主要流程。一些復雜的測試用例的組合對測試的結果的正確性（例如DRAC5和BMC的IPMI Firmware通信同步的集成測試）顯得尤為重要。

圖5 集成測試自動化流程

（4）壓力測試

對某一個或幾個命令連續不斷地在不同條件下自動的測試, 用以提高嵌入式軟件系統的性能和效率。以下顯示的是通過SMS接口重復執行相關IPMI命令后的測試分析結果：

（5）支持測試結果的輸出

KFC將測試的結果以log文件格式輸出, 以便開發人員查閱。它記錄了發送消息的命令，以及BMC的Response Data，然后在每一個塊的后面依次記錄了Channel，模塊，命令名，測試用例和測試結果 (如圖6)。

圖 6 智能平臺管理接口測試結果日志文件

4 結語

本文主要針對IPMI Firmware在嵌入式軟件的測試策略和自動化的測試架構進行研究。根據嵌入式軟件和IPMI Firmware的特點，對嵌入式軟件系統的測試策略進行了改進。

基于IPMI Firmware在嵌入式軟件系統中的功能測試，分析和比較各種測試方法，確定最終采用的基于ICTS框架下,設計出適合于IPMI技術多平臺的嵌入式軟件自動化的測試架構。

[1]Intel, Hewlett- Packard, NEC, Dell.Intelligent Platform Management Interface Specification Second Generation v2.0[S].2004.

[2]AVCT Company.San Marco DRAC5 Linux環境搭建 (version 2.0)[S].2005.

[3]朱少民.軟件測試方法和技術[M].北京：清華大學出版，2005.[4]Bart Broekman ， Edwin Notenboom.嵌入式軟件測試[M].張君施譯，北京：電子工業出版社，2004.

[5]A00330-002.Intel Company.Intelligent Platform Management Interface (IPMI) Conformance Test Suite (ICTS) User's Guide (version 0.11)[R].2004.