/ 上海市軟件評測中心

0 引言

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

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

1 相關(guān)技術(shù)的概述

1.1 IPMI技術(shù)架構(gòu)

IPMI技術(shù)是一項應(yīng)用于服務(wù)器管理系統(tǒng)設(shè)計的標(biāo)準(zhǔn)，用戶可以利用IPMI技術(shù)監(jiān)視服務(wù)器的物理健康特征，如溫度、電壓、電扇工作狀態(tài)、電源供應(yīng)等，為系統(tǒng)管理、系統(tǒng)恢復(fù)提供信息。利用IPMI接口標(biāo)準(zhǔn)對不同類型服務(wù)器系統(tǒng)硬件實施的有效管理，使不同平臺的集中管理成為可能。圖1為智能平臺管理接口架構(gòu)示意圖[1]。IPMI技術(shù)不管服務(wù)器的狀態(tài)如何，都可以提供遠(yuǎn)程監(jiān)測、管理和恢復(fù)功能。

圖1 智能平臺管理接口架構(gòu)示意圖

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

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

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

（1）系統(tǒng)接口（System Interface）

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

（2）I2C/IPMB接口

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

（3）Serial/Modem（串行/調(diào)制解調(diào)器）接口

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

（4）LAN （網(wǎng)絡(luò)）接口

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

2 基于IPMI技術(shù)的測試策略和方法

2.1 IPMI Firmware在嵌入式軟件系統(tǒng)中的測試策略

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

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

（1）準(zhǔn)備相關(guān)的測試硬件和軟件，建立一個適合于DRAC5和BMC之間IPMI Firmware測試環(huán)境，依據(jù)嵌入式軟件測試特點,建立一個跨平臺的測試環(huán)境。

（2）依據(jù)嵌入式軟件的測試特點和IPMI技術(shù)標(biāo)準(zhǔn)的特點，在不同的測試階段，通過分析、比較，確定最終采用的測試方法。

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

2.2 建立IPMI Firmware的測試模型

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

H模型強(qiáng)調(diào)測試是獨立的，只要測試準(zhǔn)備完成，就可以執(zhí)行測試。對于大型的復(fù)雜軟件系統(tǒng)，軟件開發(fā)人員每次創(chuàng)建一個新的版本后，測試執(zhí)行隨即進(jìn)行?？梢哉f這種模型是一個測試周期的充分體現(xiàn)。在San Marco項目中將采用這種測試模型，每當(dāng)開發(fā)人員創(chuàng)建出一個新的版本后，隨即進(jìn)入執(zhí)行測試階段。圖2 顯示基于嵌入式系統(tǒng)的H模型。

圖 2 嵌入式測試的H模型

3 基于IPMI技術(shù)自動化測試方案

3.1 建立IPMI Firmware測試平臺

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

3.1.1 單元測試

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

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

（2）生成IPMI的測試用例（包括測試輸入，標(biāo)準(zhǔn)輸出，測試操作指令等）；

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

（4）IPMI操作指令的測試結(jié)果與標(biāo)準(zhǔn)（參照IPMI 說明書）輸出的對比；

（5）將不吻合的測試結(jié)果進(jìn)行分析、記錄、分類和通報。

3.1.2 集成測試

在不同的Channel下的各個單元測試模塊被組合起來，通過集成自動化測試程序?qū)λ鼈冞M(jìn)行測試，以檢查這些單元之間的接口是否存在問題。

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

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

3.1.3 壓力測試

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

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

（2）選擇經(jīng)過單元測試的，且穩(wěn)定可靠的一組或多組IPMI命令，通過不同Channel組合，持續(xù)進(jìn)行穩(wěn)定性測試。

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

3.2.1 自動化測試必要性

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

3.2.2 測試框架選擇

（1）ICTS

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

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

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

3.2.3 KFC Firmware的測試方法

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

（1）KFC測試架構(gòu)圖

圖3給出了用于KFC OOB（Out Of Band）測試系統(tǒng)主要的模塊，其中KFC和ICTS是最主要的模塊，KFC是整個測試系統(tǒng)的控制中心，它控制著每一個模塊，并且使這些模塊在這個系統(tǒng)中順利地運轉(zhuǎn)。ICTS用來處理所有的測試信息和數(shù)據(jù)，以及把這些命令請求封裝通過以太網(wǎng)或串行通信端口傳輸?shù)侥繕?biāo)平臺，同時也處理所有的接口信息以及分析測試結(jié)果。

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

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

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

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

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

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

3.2.4 KFC Firmware測試的實現(xiàn)

（1）IPMI命令功能測試

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

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

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

圖4 獲取設(shè)備、遠(yuǎn)程訪問卡等信息

（2）單元模塊測試

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

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

（3）模塊集成測試

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

圖5 集成測試自動化流程

（4）壓力測試

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

（5）支持測試結(jié)果的輸出

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

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

4 結(jié)語

本文主要針對IPMI Firmware在嵌入式軟件的測試策略和自動化的測試架構(gòu)進(jìn)行研究。根據(jù)嵌入式軟件和IPMI Firmware的特點，對嵌入式軟件系統(tǒng)的測試策略進(jìn)行了改進(jìn)。

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

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

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

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

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