運用 CORBA 之分散式網路設備自動化整合檢測系統
張明裕
南台科技大學資訊傳播系
changmy@mail.stut.edu.tw
摘要
本文的目的在於實現一套分散式自動化網路
設備檢測系統，其運用 CORBA 分散式網路元件整
合運作的概念，結合了自動化網路設備檢測儀
(IXIA1600)來進行大量的網路設備成品之自動化
效能測試。本系統可以同時受理多個受測機台之測
試，把重複測試的工作完全自動化，以期大幅增進
網路設備效能測試之效率、減少所需測試時間、讓
產品在高生產率之下亦能兼顧產品的品質，使企業
網路得以穩定運作。
關鍵字: CORBA ，ORB， 一致性測試，網路通訊
協定檢測，網路設備效能測試
1. 簡介
近來由於企業網路(Enterprise Network)的快速
成長，使得網路設備 (Network Devices)如交換器
(Switches)，路由器(Routers)之市場需求量愈來愈
大。各網路設備製造商為確保自家產品在市場上的
競 爭 力 ， 對 於 產 品 的 品 質 (quality) 與 生 產 率
(Productivity)之要求將更加嚴格，在市場需求量快
速增加的趨勢下，如何讓產品在高生產率之下亦能
兼顧產品的品質？實機測試( Device Under Testing)
是保障產品品質最重要的關卡;它是在包含各個不
同的狀態下，根據以往經驗及實際需求所制定的規
格書，以網路通訊協定交通產生器(network traffic
generator)[1]產生個種不同的網路環境，來給予受
測機臺(IUT)最嚴厲的測試。這樣的測試可以讓測
試人員真正了解受測機臺的功能運作正常度以及
耐力承受極限。由此可知，如何使網路設備產品於
出廠前之軟硬 體和品質測試的工作符合時效性
(Time-critical Tasks)，遂成為一重要課題。
經由本文分析網路設備產品測試流程: (1) 網
路通訊協定在網路協定程式設計人員規劃和撰寫
之後，(2) 接著是測試人員實施測試工作，即執行
程式並且偵測程式錯誤(Debugging)，之後，(3) 測
試人員將偵測結果轉給程式設計人員作為修改程
式之依據，(4) 設計人員依據偵測結果來修改程
式。發現到產品測試過程將近 90%皆由人為操作，
其中待測設備之組態設定(Status Configuration)的
時間就已耗佔大半，於此尚有很大的改善空間。目
前再者，目前施測人員對於同時測試之受測機台數
目，亦有一定的限制，故在此距時效性的測試工作
上，可以思考更有效率的作法。
李昶清
南台科技大學資訊管理系
brizzez@ms4.url.com.tw
本文的目的，就是以 CORBA 網路元件為基礎
執行分散式網路測試，並且達到一致性測試[2]，
同時整合效能測試流程自動化[3]，如此測試的執
行工作可以不侷限在 server 本機，也可在各個 client
端實施。而且以物件導向為概念構成的系統方便測
試流程的建檔及維護。另外，本系統減少大部分不
必要的重複測試動作，只需要執行測試程式直到結
果全部輸出為止。進而節省測試人員的時間及人力
成本，並且真正測試出受測機臺的實際效能水準，
達到產品品質的有效保證。
本文測試的主題訂定為有防止廣播風暴功能
的交換機在廣播風暴下的執行效能，乃是因為大部
分的交換機是以處理網路通訊協定第二層的訊息
傳送為主，而 Layer2 的封包處理又以大量廣播封
包壅塞於交換機緩衝區為最難解決之問題。故吾人
以比較關閉及開啟交換機防止廣播風暴功能兩者
處理大量廣播封包下的執行效能為測試主題，將兩
者結果和 RFC 規格書的規格細項做比較，並且觀
察是否符合 RFC 的規格要求及測試人員本身對於
交換機韌體的標準要求。
本文與網路設備測試中心合作建置軟硬體自
動化測試，使用網路交通產生器 IXIA1600 內附的
通訊協定測試產生語言[4]，也就是 IXIA-API 中的
C++語言，來產生符合測試 RFC 規格書中對受測
裝置中通訊協定的測試標準。因為目前大部分的中
小企業仍以使用交換機(switch)為主，故這裡接受
測試的網路設備是交換機，尤其是著重屬於 OSI
網路通訊協定第二層的交換機(Layer2 switch)。
本論文的架構如下：首先將概述網路測試運作
流程，以及 CORBA 的簡介[5]。然後本文會詳述
分散式網路設備測試系統設計。並且針對自動化測
試的部份，實作出一個測試系統，並於第五章展示
出此系統的功能測試與效能測試的虛擬碼。最後，
我們會對 CORBA 之分散式網路設備自動化整合
檢測系統作出一個結論。
2. 網路設備自動化測試
2.1 網路測試概述
網路分為 3 個不同層次︰網路設備層、網路系
統層和網路應用層。網路測試也要對應這 3 個不同
的層次來進行。
2.1.1 網路系統測試
網路系統的規劃驗証測試主要有 2 個方式：軟
體模擬和實際模擬。
所謂軟體模擬就是在實際系統建立之前，用軟
體的方式建立網路系統的模型，類比實際網路的運
作，透過設置不同的參數，來分析要建立的網路系
統的傳輸量上下限、封包轉送時間、QoS(Quality of
Service) 等等。例如使用專用的網路測試設備對產
品進行測試，如專用的性能分析儀器 SmartBits
2000、IXIA 1600 等。本文即採用 IXIA1600 來作
為自動測試軟體發展平台。
組，全名為(Benchmarking Methodology)簡稱為
BMWG [6]，這個工作組的主要任務是為網路設備的
性能測試定義了一系列的標準術語和方法，如傳輸
率上下限、延遲率、封包遺失率、封包轉送率等等，
每一個名詞都有嚴格的定義，然後 BMWG 會更進一
步對在這些技術上建置的系統與作業流程提出建
議。並針對對這些建議加以描述成測試規格;再制
定對這些測試進行過程的完整方法;最後提出了對
測試結果及相關報告。並透過 RFC 公布。
2.2.2 RFC2544 及 RFC2889
實際模擬則是指建置一個較小的網路，採取加
重負載的辦法來測試其極限，以分析要建立的實際
網路是否能達到需求標準。網路系統性能的測試是
指透過對網路系統的被動監測和主動測量確定系
統中站點的可達性、網路系統的傳輸量上下限、傳
輸速率、頻寬利用率等等，並發現系統的連接和系
統配置的問題，確定網路瓶頸，發現網路問題。
2.1.2 網路應用程式測試
網路應用程式測試實際上是測試網路系統對
應用程式的支援程度，如 VoIP 功能，直接的問題
就是網路中的交換機和路由設備能否有效地支援
語音傳輸、能支持多大的語音傳輸流量、多少個語
音通道、是否支持 QoS 以及對其他功能的影響等。
2.1.3 網路設備測試
網路設備的測試主要包括功能測試、穩定性和
可靠性測試、一致性和互操作性測試以及性能測試
等幾個方面。網路設備功能的測試是要驗証產品是
否具備了設計方案中的每一項功能。可靠性和穩定
性的測試一般采取加重負載的辦法來評估和分析
設備在長時間、高負載情況下的營運能力。一致性
測試驗証產品的各項功能是否符合標準，互操作性
測試目的是考察一個網路產品是否能在由不同廠
家的多種網路產品互連的網路環境中很好地工
作。本文採用網路設備一致性測試。
2.2 網路設備測試規格標準
從 BMWG 製定的 RFC 及草案中，可以看出他們
的一個制定測試方法準則。一般先針對被測對象製
定一套專有名詞，然後用這套專有名詞對被測對象
定義測試的方法。
BMWG 最先製定了 RFC1242，在這個 RFC 中
對網路設備性能基準製定了一套術語，然後在與之
配套的 RFC 2544[7]中製定了對網路設備互聯基準
的測試方法。
RFC 2544 中討論並定義了一組可以用來反映
網際網路性能特性的測試，此外還描述了報告測試
結果的具體格式。
本文參考 RFC 2544 的網路設備具體測試方
法。針對所有被測的網路設備;稱為互聯網路設備
（Network Interconnect Device），做測試的系統性
描述，從被測設備與測試設備的設置，一直到測試
結果的記錄，都提出了完整的規格。
2.2.3 交換機測試項目
交換機作為企業網路的核心連接設備，它的性
能是保障企業網路速度的主要標準。本文使用網路
交通產生器 IXIA1600 對受測交換機之防止廣播風
暴功能做交換機性能中的 3 項主要指標進行測試。
進 行 性 能 測 試 的 主 要 依 據 是 RFC2544 和
RFC2889[7]，其中 RFC2889 是專門為測試交換機
所制定的測試規格。
2.2.3.1 Fully meshed throughput:
網路測試首先要遵從網路標準，例如對乙太網
交換機的測試，要全面驗証產品對 IEEE 802.3、
IEEE 802.3u、IEEE 802.3z、IEEE 802.1p、IEEE
802.1Q、IEEE 802.3x 等的支持。
2.2.1 BMWG
為了 使性能測試有 一個公平一 致的 評定準
則，IETF 專門有一個工作組，叫做標準方法工作
作為衡量交換機性能最重要的指標之一，I/O
效能的高低決定了交換機在沒有 Frame loss 的情
況下發送和接收封包的最大速率。在測試時，我們
在滿負載狀態下進行。該測試配置為一對一
(one-to-one)。
2.2.3.2 封包遺失率(Frame loss)
該測試決定交換機在持續負載狀態下應該轉
發，但由于缺乏資源而無法轉發的訊框的百分比。
訊框丟失率可以反映交換機在過載時的性能狀
況，相對於廣播風暴等不正常狀態下交換機的工作
情況 frame loss rate 具有明顯的差別。
2.2.3.3 封包轉送率(forwarding rates)
本文重要的精神之一就是自動化，如序論所
述，測試時間的節省，對於一個專業的網路設備測
試中心來說，是十分重要的，因為通常受測的網路
設備動軋上百台，如果自動化測試流程沒有建立，
相對的測試過程的時間及人力成本就要增加許
多，反之，如果測試流程以然完整建立，節省的成
本不言可喻。
該測試在測驗交換機在不丟訊框的情況下能
夠持續轉發數據訊框的數量。
3. CORBA 分散式網路元件
2.3 廣播風暴(broadcast storm)
3.1 CORBA 簡介
本文選用廣播風暴測試作為測試系統初期達
成測試目標，並擬以發送 ARP 封包作為廣播風暴
測試。
所謂廣播風暴(broadcast storm)[9]是指不希望
發生大量網路廣播封包，同時壅塞在要經由網路傳
送到所有的網路區段。一般而言，廣播風暴會因佔
用大部分的網路頻寬，造成網路訊息的逾時。 但
是 Layer 2 的 Switch 並無法有效的阻絕廣播域
(Broadcast Domain) ;如 ARP (Address- Resolution
Protocol)及 Win95/98 中大量使用的 NetBEUI 協定
均大量使用廣播封包。因此就算是 Layer 2 Switch
以 VLAN (Virtual LAN)的方式(虛擬網路)將經常要
通訊的群組構成一廣播域(Broadcast Domain)來試
圖降低 broadcast 封包對網路層的影響，但仍無法
完全避免廣播風暴問題(同一個 VLAN 間仍會產生
廣播風暴)。
為防止廣播風暴發生，影響整體網路效能，故
發展一種協定讓 Layer 2 的網路設備(Bridge、
Switch)不會因實體線路接成迴圈而造成影響，共
原理是應用最小擴張樹（Spanning Tree）的演算
法，將每一個 Layer 2 設備定 cost，先根據 cost 選
擇一個 Switch 為 Root，依演算法使整個網路設備
間不會造成迴路，並自動 block 造成迴路的接線，
如此一來，就能避免廣播風暴的產生。本文就是要
發展 Layer 2 的網路設備之防止廣播功能的自動
化測試程式。
2.4 通訊協定一致性測試
所謂通訊協定一致性測試是要測試出一個實
作出來的產品(implementation)是否與他原先依據
設計的規格(specification)相同，由於不確定建置完
成的軟體是否和通訊協定規格符合，故必須使用一
些方法驗證，而這個驗證的過程，就稱為通訊協定
一致性測試[10]。
本文要測試的通訊協定已經被寫成韌體並且燒
錄在交換機內部晶片。而一致性測試的內容及標準
是以 RFC2544 及 RFC2885 為測試準則。
2.5 自動化測試對測試效率的影響
OMG （Object Management Group ）由十一間
包 括 了 3Com 、 IBM 、 SUN 、 HP 、 DEC 、
Philips …等等公司在一九八九年合作開始而成立
的非營利性組織。CORBA的目的在推廣物件導向
（Object-Oriented ）之觀念及使用，並致力於加強
軟 體 的 可 攜 性 （ portability ） 再 利 用 性
（reusability ）、以及互通性（interoperability ）
等。
CORBA(Common Object Request Broker
Architecture)，顧名思義，是一種把程式的基本單
位看成物件，並且接受服務要求的概念[11]。基本
上 ， CORBA 為 三 層 式 (three-tier) ， 分 散 式
(distributed) ， 以 client-server 的 型 態 在 運 作 的 組
織，這樣的結構可以滿足以物件為單位而且分散在
網路各個地方隨時接受服務的請求。另外，請求服
務的物件和服務請求的物件的角色可以互換，讓
client和server立足點平等。
在CORBA的定義中，Server object的程式內容
必須使用Interface Definition Language (IDL) 編譯
之後包覆起來，client object亦同。CORBA在IDL
編 譯 的 同 時 client 會 產 生 stubs server 端 會 產 生
skeletons。Stub 為client 端有效地建立及發出要求
的 一 種 機 制 ， Stubs 將 Client 端 的 請 求 包 裝
（marshal ）成CORBA 的型式，之後再傳送給
ORB ，skeleton 是在CORBA 物件實作中接受要
求的機制，當要求抵達目的地物件時，server ORB
及skeleton 合作拆封（unmarshal ）此要求，將這
個要求還原成原來的格式，然後送給負責的物件處
理。這樣的好處是使各個物件之間溝通的語言可以
是相同的，如此可節省大量的程式開發時間，而且
可以同時進行多個服務運作 。換句話說，這是
CORBA最重要也是應用於本文的最大因素。
而各個物件之間的溝通要依靠一個非常重要的
物 件 服 務 請 求 的 中 介 機 制 ， 稱 為 ORB (Object
Request Broker)。ORB主要的工作是藉由提供client
端的要求讓server端了解其物件的位置和物件的實
作，執行的狀態及物件通訊機制。而ORB工作的方
式可分為static invocation和dynamic invocation兩
種，static invocation是透過編譯時期ORB提供相關
的interface 呼叫欲使用的server object， 而dynamic
invocation分為Dynamic Invocation Interface (DII)和
Dynamic Skeleton Interface (DSI)。DII允許client不
用編譯stub便可叫用要求，而DSI允許server在執行
時期再將叫用動態繫結即可。
3.2 CORBA 流程
如圖一所示:
1.Specify interface
IDL Interface
Operations
2. Compile
3.Native Language
Implementation
6.Native Language
Invoke methods
Methods
Native Language
Interface
7. Compile
4. Compile
Client
Server
IDL
Stub
8.Bind
IDL
skeleton
now available for activation。 以備被使用之可能。
(6)建置 client 端程式 Implement the client。並同時
撰寫需要叫用到之 server object 端的函式，在此
因為 CORBA 具有互相操作性(Interoperability)，
故 server object 端的 函式並不限 定必須使用
server 端的語言撰寫。
(7) 用IDL compiler編譯client端程式成執行檔並且
連結client端的stub。
(8) 執行client端程式， 他會使用 ORB 去 繫結
server object 其 中 包 含 物 件 參 照 (object
reference)。
(9) Client 端程式開始使用物件參照經由 ORB 叫用
server object 的函式。
4. 自動通訊協定檢測系統架構規格
4.1 系統開發環境
本測試系統開發環境以 IXIA 網路交通產生
器，Telix SALT-script，及 Layer2switch 為主，用
IXIA 的測試程式開發環境來開發效能及一致性測
試工作。
4.1.1 IXIA 網路交通產生器
9. Invoke
Object Request Broker
5.Register
Implementation
Repository
圖一 CORBA機制運作流程
(1) client端使用Interface Definition Language (IDL)
指定server interface。
(2) 用 IDL compiler 編 譯 撰 寫 完 成 的 IDL
description， 並產生和client端可程式之連接介
面，client端的stubs，及server端的skeletons 在進
行這個步驟的同時，亦可以把產生的interfaces
註冊到”已完成介面的容器”(interface repository)
裡以備未來有再度被使用之可能。
(3)建置server端程式。
(4)用IDL compiler編譯server端程式成執行檔並且
連結server端的skeletons 。此執行檔可以經由
CORBA接受其他函式的叫用。
(5)把建置好的 server 端在註冊到”已完成建置的
容器”implementation repository，並指定server名
稱， 擬定發出的指令launch command，啟動模
式activation mode， 以及被使用和處理的權限
and launch and access permissions。 The server is
本 文 運 用 網 路 交 通 產 生 器 IXIA- traffic
generator 為測試程式開發環境，它提供高效能，多
埠同時產生大量網路封包，並且可就結果輸出做分
析。以下為其功能概述:
(1) 16 Card Modules:共有 16 個插槽，每個插槽最
多可以容納四個埠，每一個埠為 10/100mbps 傳
輸量本文程式使用到 2 埠。
(2)封包傳輸種類:從 layer2~layer3 的各種封包傳
輸種類皆備，而封包傳輸形式分為 unicast，
broadcast，multicast 為主，本文使用 broadcast
封包傳輸形式。
(3) 作 業 系 統 平 台 : 作 業 系 統 支 援 windows95 ，
windows98 及 windows2000 ， 本 文 程 式 使 用
windows98 為作業系統平台。
(4) IXIA Explorer 應用軟體:IXIA Explorer 應用軟
體為架設在 IXIA1600，作為圖形使用者介面
(GUI)，方便測試人員用此介面做封包傳輸設定
以及接收測試結果(傳回封包數量)，本文使用此
介面來接收測試結果。
4.1.2 Telix
TELIX[12]是一種終端機介面的通訊軟體，使
用在 DOS 和 Windows 作業系統，它提供了整合
的通訊功能。一般此軟體會用在 BBS(Bulleting
Board System)撥接通訊上，或是 RS-232 的硬體
控制上，本文使用此軟體經由 RS-232 來作為交
換機的 console 介面，控制受測機臺韌體的運作。
使用 TELIX 主要是因為其中更包含了特殊的
script 語言，方便使用者依照自己的需求，設計自
動執行的巨集程式。而可以撰寫與通訊有關軟體，
並且內建大量的函數方便程式寫作的 SALT(Script
Application Language for Telix )就是本文會使用到
的語言工具之一。
APP&SALT
系統設計與實作
5.1 自動通訊協定檢測系統設計流程
首先描述此測試系統所需之軟體，及硬體設
備，併輔以圖形架構之規劃來了解完整自動測試的
流程概要，自動測試流程主題初期以測試交換機的
防止廣播風暴功能有無正常運作。
Protocol
Specification
Performanc
e Test
compiler
Perfomance
Test
Execution
Engine
IxHAL
Switch
Behavior
Sequence
Database
IxHAL
IxServer
HARDWARE
圖二 自動通訊協定檢測系統架構
Protocol/
Model
Behavior
Specification
Protocol/
Model
Behavior
Sequence
Transcorder
Test
Comparison
Machine
no
Fit to
standard
Update
Switch
Behavior
Sequence
from Client
Yes
Test
Result
Database
Test
Result
4.2 IXIA 系統架構
可參考圖二，其架構由上所述:
(1) C++APP:將建置完畢的測試序列檢測軟體架設
在 IXIA1600 網路交通產生器的最上層，以收取
整合之效用。
(2)Telix: 使 用 Telix 終 端 機 介 面 的 通 訊 軟 體 中
SALT-script 所附的鍵盤 I/O 動作的錄製功能。將
交換機功能操作流程鍵入鍵盤並且錄製下來成
為。slt 的 script 檔案，經過編譯之後，成為可執
行副檔名為。slc 的檔案，並且放在 C++主程式
的子目錄底下，以供程式呼叫使用。
(3)IxHAL:是用來接收上層應用程式的 C++程式語
言指令，並且轉換指令為硬體了解的機器命令語
言的應用程式介面。
(4)IxHAL:是協助將收取到的指令設定資訊暫存在
Buffer 內，直到接收到上層要轉換這些資訊到
IxServer，才會做自動傳輸的工作。
(5)IxServer:這是藉於控制網路交通產生器的電腦
和網路交通產生器本身的伺服器，用來控制兩者
之間的指令運作及資料流通。
(6) HARDWARE:也就是指 IXIA1600 硬體主體，協
助最終的測試產生的機器。
5. CORBA 之分散式自動化網路設備檢測
圖三 自動通訊協定檢測系統之功能模組與工
作流程示意圖
測試程式以防止網路廣播風暴功能關閉及開
啟兩種模式測試各個不同等級的訊框處理能力。接
下來便以虛擬碼的方式實現測試程式的演算法，以
玆了解;詳細流程由上圖三所示:
受測通訊協定規格:
包括邏輯測試(一致性測試)以及壓力測試
(pressure test)的受測的通訊協定可以先使用流程
圖的格式先行大略描述出來，藉此方式可以讓使用
者自己了解將要進行的測試的通訊協定的詳細規
格。
(1)通訊協定測試程序撰寫:可以用方才描述的規格
撰寫承 C++的程式並且要注意一定要使用 IXIA
提 供 的 API 函 式 庫 ， 以 及 結 果 比 較 的
STL(Standard- Template Library)中的”MAP<>”函
數[13]也要包含在標頭內以供編譯。
(2)編譯自動化測試程序:這裡使用 IXIA 所提供的
程式編譯器(compiler)來執行編譯，編譯過程中
須把將使用到的 SALT-script 先行使用 Telix 的編
譯器編譯完成之後，以供主程式使用。
(3)測試執行引擎:在測試執行階段，首先必須把產
生出來的測試序列轉換成為可在 IXIA1600 執行
的 C++程式碼，這個部分是剖析器(parser)的工
作，再來就轉換到 IXIA1600 的硬體部分，進行
測試序列正式執行的工作。
(4)通訊協定模組行為描述:另一方面，必須把實際
受測機台的所有行為詳細的條列出來，並且用
EFSM 的語法(c or psudo code)來表示，這樣的做
法才 以利下面的 通訊協定序列 資料轉換的 步
驟，並且儲存方式教不複雜。
(5) 測試比較機制:最重要的一致性測試的精髓所
在，也就是測試序列比對部分，必須要由這樣的
一個測試比較機制來執行，當比較結果不符合規
格要求時，就使用事先在 Client 端寫好的 Telix
的 SALT-script 的執行檔經由 CORBA 的 ORB 到
Server 端代替人工操作交換機的 console 介面待
自動操作調整完畢後再實施一次交換機防止廣
播風暴的效能測試及一致性測試，重複此步驟直
到達程規格要求的標準之後才跳出程式。這裡使
用
STL(StandardTemplate
Library) 中
的”MAP<>”函數資料結構來實施比較功能。
(6)測試結果產出:最後執行測試序列比較的結果將
展現於表格上面，並且儲存到資料庫裡以供參
考。
以此系統為基礎，發展多個完整測試流程對多台受
測 switch 作測試。另外，由於本系統係以 CORBA
分散式物件導向為概念構成，故所有撰寫完成的測
試元件皆可以清晰簡單的程序排列組合成千變萬
化的完整測試程序，對於測試人員的工作實在省力
不少，在測試經驗傳承及規格的建立更是助益良
多。
Client
program
把 CORBA 分散式元件概念和自動通訊協定
檢測機制整合應用可以增加下列優點，在自動化方
面，因為已經把所有可能需要人工操作的部分事先
以軟體程式妥善規劃完成，所以測試流程可以中途
不間斷，一氣呵成，比以前部分人工測試要來的快
速，簡化測試程序，並且節省測試時間，有效提昇
測試效率。 在控制流程方面，由於採用分散式元
件於網路上，對於測試程式的執行可以非常彈性
化，例如從最簡單的一個完整的測試流程對一台受
測 switch 到同時對多台受測 switch(測試機台數目
就是 Ixia 網路交通產生器 port 數目)。未來更可以
4. Response
Result
interface
1. Call
3.Update Switch
Behavior
Sequence
IDL
skeleton
IDL
Stub
Object
2. Invoke
5. To Client
5.2 CORBA 分散式元件應用於網路設備自動
化測試
根據 CORBA 的架構，我們可以在撰寫分
散式網路設備自動化測試的時候很方便的就應用
到物件導向的特性，本文首先要把 server 端的發展
成執行測試流程的主體程式，功用包括執行 (1)
switch 效能測試程式 (2) Telix 終端機軟體調整
switch 程式，並隨時接受 client 端的服務請求的參
數。另外，把 client 端的發展成定義測試流程的介
面並且按照下列測試流程作自動測試:使用 Telix 終
端機軟體調整 switch 待測功能參數switch 效能測
試是否符合標準再次使用 Telix 終端機軟體調
整 switch 待 測 功 能 參 數 | 輸 出 結 果 。 然 後 把
client-server 兩端的 interface 先用 IDL(interface
definition language)定義好，然後再由 interface 編譯
器 ( 這裡 使用 Inprise 公司的 VisiBroker) 編譯 出
server 端及 client 端的下層網路部分的程式;流程
概要如圖四所示。
IXIA-APTS
Object
Object Request Broker
圖四 CORBA 之分散式自動化網路設備檢測
機制運行架構
5.3 演算法及程式
這裡使用虛擬碼和編譯完成的 SALT-script
物件[12]為語言工具，以下為程式:
(01)# This package is required to have access to
(02)# the Ixia
commands
(03)package req IxHal
(04)
(05)global one2oneArray
(06)
(07)#port configuration
(08)set txPortList
{{1 1 1}}
;
(09)
(10)# High level API commands can use eather
(11)set rxPortList
{1，1，2}
;
(12)
(13)# port list format or global array
(14)set portList
(15)
{{1 1 1} {1 1 2}}
(16)# Take ownership of the ports
(59)#second on a 100mbs switch， ~148810
(17)ixTakeOwnership
(60)# frames will be transmitted. This number
$portList
(18)
(61)# must be an integer; minimum value is 1
(19)# Set ports to factory defaults
(62)# second.
(20)ixPuts "Setting ports to factory defaults..."
(63)ARP config -sequence
(21)if
[port
setFactoryDefaults
$chasId
$card
20
;
(64)
(22)$txport] {
(65)# duration of transmit during test， in seconds
(23)
(66)ARP config -type
errorMsg "Error setting factory defaults
(24)
on port $txport."
(25)
set retCode 1
echoreply(0)
(67)
(68)# Start capture on Rx port
(26)}
(69)ixPuts "Start capture..."
(27)
(70)if [ixStartCapture rxPortList] {
(28)# Writes port properties in hardware
(71)
(29)if {[ixWritePortsToHardware one2oneArray]}
(72)}
(30){
(73)
(31)
(32)
ixPuts "Error writing port to hardware"
set retVal 1
return -code error
(74)# Start transmission on Tx port
(75)ixPuts "Start transmit..."
(33)}
(76)if [ixStartTransmit txPortList] {
(34)
(77)
(35)# Checks the link state of the ports
(78)}
(36)if {[ixCheckLinkState
(79)
one2oneArray]} {
return -code error
(37) return -code error
(80)#Checks whether transmission is done on a
(38)}
(81)#group of ports
(39)
(82)if {[ixCheckTransmitDone txPortList] == 0} {
(40)logMsg "Configuring $chasId $card $txport
(83) return -code error
(41)--> $chasId $card $rxport"
(84)}
(42)
(85)ixPuts "Transmittion is complete."
(43)#Set default values percentage of total
(86)
(44)#packets sent to allow to be #lost before
(87)# Stop capture on ports
(45)#declaring
(88)ixPuts "Stop capture..."
packet loss
(46) ARP config -code 0
(89)if [ixStopCapture rxPortList] {
(47)
(90) return -code error
(48)# One frame size/frame rate test is called a
(91)}
(49)#trial. The user may choose to run one or
(92)
(50)#more trials; the average result of each trial
(93)#use map<> to do conformace test(result
(51)# will bepresented in the result file.
(94)#comparison); if result of comparison satisfy
(52)ARP config -id
(95)# the upboudary #then output else use the
1
;
(53)
(96)# SALT-script(config1.slc) to open the
(54)# total number of trials per frame size/frame
(97)#switch's function prevent from broadcast-
(55)#rate The approximate length of time frames
(98)# storm and then execute the the C++
(56)# are #transmitted for each trial is set as a
(99)# performance program again
(57)#'duration. The duration is in seconds; for
(100)map<Key，T.Compare.Allocator>
(58)#example ，
(101){if map<> result not satisfy 1.execute SALT
if the duration is set to one
(102) (2.execute the C++ performance program
(103)
if result not satisfy 1.execute SALT
(104)
2.execute the C++
(105)
performance test
(106)
program
.
(108)
.
(109)
.
(110)
else-->output)
(112)
[5] Segue Software “A CORBA Primer”
http://www.segue.com/html/s_solutions/pd
f/wp_corba_primer.pdf
[6] IETF, Benchmarking Methodology Working
Group(BMWG),
(107)
(111)
International Symposium on Software Testing and
Analysis.
http://www.ietf.org/html.charters/
bmwg-charter.html
else-->.
output}
(113)# Clear the ownership of the ports
(114)ixClearOwnership $portList
(115)
(116)# Log off user
(117)ixLogout
6. 結論
本文提出了一個以 CORBA 分散式網路元件整
合交通產生器 IXIA1600 為主的自動化網路設備測
試環境，不但結合了原有的效能測試的功能，且讓
測試流程控制可以不侷限於某主機，彈性高。另
外，測試程序的物件化讓測試程式之撰寫及維護容
易許多，以及加上了符合使用者導向的一致性測試
功能，讓測試人員能夠在短時間內以高效率的方式
取得該受測網路設備的效能數據及資訊。而且是自
動化操作，節省企業對於測試的時間成本至少 30%
以上。
在未來本系統雛形未盡完善之前，還有發展的
空間，主要有兩個方面。第一，在以 Telix 終端機
軟體來控制網路設備的自動化過程，本文是把各個
網路設備的操作執行狀況事先錄製完成的方式，在
主程式執行過程中再使用，但是亦可以程式產生器
的方式自動產生。第二，儲存在資料庫裡的數據及
資料可以發展成知識管理系統，使資料可以更有效
的被運用以增加此系統的附加價值。
7. 參考文獻
[1] IXIA, ”IXIA1600”, http://www.ixiacom.com/
[2] Rui-Chi Wang, ”Protocol Conformance Testing
Technology”, 無線通訊技術專輯, 第 79 期, pp.
17-24.
[3] W. Richards Adrion, Martha A. Branstad, and
John C. Cherniavsky, "Verification, Validation,
and testing of Computer Software", ACM
Computing Surveys, 14(2), pp. 159-192, June
1982.
[4]Debra J. Richardson, "Taos: Testing with analysis
and oracle support", Proceedings of the 1994
[7] BMWG, ”RFC2544”, IETF, pp. 3-4.
[8]. BMWG, ”RFC2889”, IETF, pp. 28-29.
[9] CISCO, ”Broadcast storm”, documentation,
http://www.cisco.com/univercd/cc/td/doc/product/l
an/14201220/1412
[10] Chung-Ming Huang, Ming-Yuhe Jang, and
Yuan-Chuen Lin, ”Executable EFSM-Based data
Flow and control flow protocol test sequence
generation using reachability analysis”, Journal of
the Chinese Institute of Engineers, Vol.22, No5, pp.
593-614, 1999.
[11] Yu Chi Chang, Chi Ping Chu ”Designing a
Pipe-Embedded-Component Software Assembly
Mechanism and its Supporting Tool in
CORBA
Environment”,
National
Central
Library ,2000
[12] Matthew H.Austern, ”Generic programming and
the STL”, Addison-Wesley, 2000.
[13] TSID, ”TELIX 技巧與實例應用 ” , GOTOP,
1994.