一、自動化測試背景
隨着如今 5G 網絡的廣泛應用，網絡系統的規模和復雜度日益提升，對於網絡 設備的要求越來越高，網絡設備的測試也面臨新的挑戰。
在設備的研發階段，測試人員對於設備每個功能點往往需要做很多測試以驗證 其完善性。不同的值要代入不同的場景進行測試。如果采用手工方式，一個測試用 例大概需要十幾分鍾甚至更長時間。而對於成百上千個測試用例來說，其工作量巨 大。，如果測試過程中出現錯誤，則需要反復調試，測試周期會更長。
在設備的Th產階段，也需要對產品進行驗證測試，以確保網絡設備的Th產質量。 在這個過程中，產量、效率、質量等因素都需要考慮。測試人員既要保證測試結果 准確可靠，又要盡可能提高測試效率。而Th產線上的測試人員相較於研發部門的測 試工程師，其測試能力有限，對於較復雜的測試項，往往存在困難。
除了研發階段和Th產階段外，在網絡設備Th命周期的其他很多環節也與測試息 息相關，同樣面臨各式各樣的挑戰。測試自動化成為應對該挑戰的解決方案。企業 通過將大規模的復雜測試自動化，減少人工操作，實現人機之間的高效配合，從而 提升測試效率乃至縮短產品研發及制造等環節的時間，使產品更快面世。
信而泰基於網絡測試領域多年的實踐經驗，結合客戶需求，針對不同的測試場 景，可以提供不同的解決方案。對於測試用例數量多，重復性測試的場景，可以提 供基於腳本自動化測試方案；對於代碼編寫能力薄弱的測試人員，可以提供無代碼 自動化測試方案；對於要將自動化測試集成到測試平台的場景，可以提供自動化集 成測試方案；對於缺乏網絡基礎知識和代碼開發能力的客戶，可以提供定制自動化 測試方案。本文將一一進行說明。
二、基於腳本自動化測試
2.1 測試場景
對於網絡設備來說，會進行大量的迭代測試來保證產品功能和性能，這也是每 個產品質量保證不可或缺的一步。當網絡設備的硬件更新時，需要進行性能測試， 確保新的硬件不會對性能造成負影響；當網絡設備開發新的功能時，需要進行功能 測試，保證功能沒有 Bug，設備可以正常使用；當發布新的軟件版本時，需要進行 回歸測試，確認新版本軟件沒有引入問題。每種情況都會涉及到大量測試用例，而 這些都還只是網絡設備測試的一部分。比如交換機的 ACL 測試，要測試交換機是 否可以正確將報文與 ACL 規則進行匹配，過濾出特定的報文。交換機的 ACL 包括 permit/deny 兩種動作，表示允許/拒絕；還定義了極其豐富的匹配項，例如，二 層以太網幀頭信息（如源 MAC、目的 MAC、以太幀協議類型），三層報文信息
（如目的地址、協議類型），以及四層報文信息（如 TCP/UDP 端口號）等。假如 要測試 10 個涉及源 MAC 的 ACL，10 個涉及目的地址的 ACL，10 個涉及 TCP 端口 號的 ACL，並不是測試 30 次，而是需要將源 MAC、目的地址和 TCP 端口號組合 起來，測試 1000 次，這個工作量就不是簡單的翻倍，而這僅是交換機功能測試中 的一項。
這一類測試存在的問題主要是：
1、測試用例數量多。測試用例涵蓋的內容極其豐富，包括網絡設備的功能和 性能，需要逐一進行測試；
2、測試用例重復執行。測試用例不是測試一次就完成了，同一個軟件版本可 能就會測試多次，而一個網絡設備，可能會發布幾十個版本。
3、手工測試時間周期長。用手工的方式來進行測試工作，在一定的時間內能 進行測試工作是有限的，不可能 24 小時都在進行測試；
4、存在人工失誤的可能性。人在執行測試操作的時候難免會出現一些錯誤， 如果未能及時發現，就會對測試結果和測試質量產Th影響。
2.2信而泰解決方案：提供 Tcl/Python API
對於上述情況，信而泰 Renix 平台提供 Tcl/Python API，便於測試人員進行自 動化腳本的編寫，實現從手工方式到自動化測試的切換。根據測試用例，測試人員 調用相應的 API 進行測試腳本的編寫，通過機器來執行測試步驟，完成網絡設備的 自動化測試。另外，Renix 平台還提供 GUI to Tcl/Python 的功能，能夠快速將客戶 在圖形界面配置和操作，另存為可執行的 Tcl/Python 腳本。
如下圖，是一個自動化測試系統，主要對被測設備、測試設備、管理設備和測 試系統之間的網絡連接進行說明。自動化測試管理系統通過運行測試腳本，由管理 網絡控制 BigTao 測試儀對 N 台交換機進行測試。
方案的優勢在於：
1、可以多個測試用例串行/並行測試。測試人員可以多個測試用例串行測試， 當測試資源不沖突的情況下，還可以多個測試用例並行測試，提高測試效率；
2、可以多台被測設備並行測試。在測試資源充足的條件下，測試人員可以多 台被測設備並行測試，進行批量測試，在有效時間內可以完成更多台設備的測試， 測試效率得以提高；
3、無間斷測試，縮短測試的周期。通過機器運行腳本執行測試步驟，在測試 人員的休息時間或者非工作日，依然可以測試，做到 24 小時無間斷測試，增加有 效測試時間，縮短測試的周期；
4、降低測試資源的投入。同等數量的測試用例，手工測試需要 4 人月，但是
自動化測試替代人工操作之后，可能只需要 1 人月，甚至更少工作量，可以節省不 少人力財力；
5、挺高測試結果的一致性。由於測試是自動執行的，每次測試步驟和測試配 置也是固定的，測試結果的一致性可以得到保障，不存在人為原因導致的結果誤 差。
接下來會從 Tcl/Python API 的作用和功能、GUI To Tcl/Python 的使用、API 的架構和 API 幫助文檔這幾個方面進行介紹，更好熟悉和理解 API 的使用。
2.2.1Tcl/Python API
應用程序接口（API）作為自動化測試的基礎，測試條件的預置、測試步驟的 設計與開發、測試結果的判斷和輸出，都需要測試儀提供的 API 來支持。而目前， Tcl/Python 作為熱門的自動化測試開發語言， Renix 也提供了相應的 Tcl/Python API，用於控制信而泰測試儀表，來完成測試對象創建、對象屬性配置和修改。
手工測試時，測試人員通過客戶端軟件連接測試儀，進行測試資源預約、流量 建立、啟動測試、停止測試和保存測試結果。這些在圖形界面的每一個操作都可以 通過相應的 API 去實現。測試人員需要做的就是選擇相應的 API，完成自動化腳本 的編寫，最后執行腳本，完成自動化測試。
通過 API 對信而泰測試儀的控制，可以實現對網絡設備的基礎流量測試、性能 測試和協議仿真測試。基礎流量測試，如二層流量、IP 流量、TCP/UDP 流量、自 定義報文流量等；性能測試，如吞吐量測試、時延測試、丟包率測試、背靠背測試、 路由表容量測試、MAC 地址學習速率測試等；協議仿真測試，如 IGMP 協議測試、 VLAN 功能測試、OSPF 協議測試、ISIS 協議測試、BGP 協議測試、PIM-SM 測試、 802.1X 協議測試等。
有個問題需要注意，由於自動化語言每個版本之間會存在差異，如 Tcl8.4 版本 支持 TclX，而 Tcl 8.6 版本則不支持，所以目前 Renix 支持的情況如下：
Tcl API 支持的版本：Tcl/ITcl 8.4 和 Tcl/ITcl 8.5；
Python API 支持的版本：Python3.6*；
Renix 軟件支持的操作系統：Windows Server 2012、Windows 7 及以上 下圖是 Tcl 自動化腳本的示例，是用來測試儀表自環的兩個端口的性能是否有
丟包或者存在亂序包。腳本設計思路：初始化 API—>占用端口—>配置流量—>訂
閱統計—>啟動測試—>停止測試—>分析統計—>判斷結果。 導入需要用到的模塊。
創建和占用測試端口 Port1、Port2。
配置流量的收發端口，配置流量的源和目的 MAC 地址。
創建和訂閱 Stream Block 的統計。
開始測試，發送所有流量，10s 之后，停止測試。
根據獲取到的統計結果進行分析，檢查兩條流量收發的包數是否相等；檢查兩 條流量是否有丟包；檢查兩條流量是否有亂序包。
根據分析的結果，做出判斷，測試是 Pass 還是 Fail。
2.2.2GUI to Tcl/Python
GUI（Graphical User Interface）就是指圖形用戶界面，又稱圖形用戶接口是 指采用圖形方式顯示的計算機操作用戶界面，本文特指 Renix 客戶端界面。GUI To Tcl/Python 目的在於將客戶在 GUI 界面的配置和操作轉化為可執行的自動化測試腳 本。以 GUI to Python 為例，功能的好處在於：測試人員在 GUI 界面的所有配置 為.xcfg 文件；非配置類的操作，如開始打流、停止打流、保存數據以及判斷規則 等操作可以通過智能腳本去添加；這些操作和命令的調用代碼就通過該功能自動編 寫保存為 test.py 文件；腳本開發人員也可在Th成的腳本文件添加或修改測試步驟， 並可獲取統計並分析統計結果給出測試結論。
如下圖，就是通過 GUI to Python 功能保存的測試腳本，保存之后是一個 test.py 的腳本文件和 test.xcfg 的測試儀配置文件，測試時只要運行腳本文件即可。 腳本測試思路：加載配置文件—>上線測試端口—>訂閱統計—>啟動測試—>停 止測試—>分析統計—>判斷結果。
2.2.3API 的基本架構
自動化測試的根本就是通過 API 去實現對測試儀的控制，Renix API 的設計是 采用面向對象的思想。像測試儀的管理 IP、端口號、槽位號等屬性，有相應的類去 實現控制。端口作為測試最基礎的資源，在端口類的基礎上也衍Th出各種各樣子類， 像建立流量、端口物理屬性配置、報文捕獲等類，兩者之間屬於繼承關系。另外如 開始發流、停止發流、建立協議仿真等行為，Renix API 也提供了相應的類對其進 行控制。
整體來說，Renix API 采用面向對象的思想，命令簡單，結構清晰；API 的數據 模型采用樹狀的繼承關系；可由基本 API 加上相關命令參數完成對對象的操作；相 同的命令控制不同的板卡，應用於不同的測試場景，腳本的可重用性高。
如下圖，是 API 的樹形結構說明：
Sysentry：整個對象層次結構里的根對象，會自動創建，不需要在代碼里顯示
創建，但是可以通過代碼修改它的屬性；
Smart Scripter：智能腳本。用於對智能腳本控制的接口，創建完成之后可以 通過該接口對智能腳本的運行狀態進行控制；
Port：Port 對象是 1 個邏輯實體對象，必須在代碼里面顯示創建，且要映射到
占用的信而泰測試儀上的物理端口才能使用；
ResultView：統計視圖。必須在代碼里顯示創建，通過訂閱查詢器方式獲取相 應的流或者協議的統計數據；
Interface：接口對象是一個邏輯接口，通過配置 Interface 的 MAC、IP 等信息， 與端口或協議進行綁定，進行測試
Stream Block：流量對象用來對測試流量進行配置和編輯的，根據不同的需求， 構造不同的業務流量進行測試
Capture：抓包捕獲對象是同 Port 對象關聯的，控制的是端口的捕獲狀態，以 及對捕獲屬性的相關操作
Protocol：用於對相關協議的控制，根據使用的協議調用相應的協議對象，對 協議參數進行配置以及協議狀態的控制
2.2.4API 幫助文檔
眾所周知，幫助文檔為了測試人員更好的熟悉和掌握 API 的使用，Renix API 的幫助文檔不僅有詳細的說明（包括 API 的作用、API 的上層節點的說明和 API 相 關屬性和參數的介紹），而且對於每個 API，有使用樣例參考，Tcl 和 Python 語言 的 Demo 都有 。對於剛開始接觸 Renix API 的測試人員來說，可以更加快速的上手 和測試。
如下圖，是幫助文檔對於 StreamTemplate API 的說明。它的 Upper Node 是 Port，意味着需要先建立 Port 這個對象，才能使用這個 API。API 參數主要有 Name、Enable、ROMTag、HostMesh 和 State 等，並且對參數的值的范圍、默 認值和輸入、輸出進行說明。
如之前提到的，幫助文檔提供 Tcl 和 Python 兩種語言的用例使用參考。
三、無代碼自動化測試
3.1 場景
對於網絡設備制造廠商來說，和研發人員相比，產線測試人員的技術比較有限， 代碼能力比較薄弱，有的甚至是完全不懂編程，所以在測試時大多通過手工方式進 行測試。比如對於 PON 設備的丟包測試，測試人員需要手工連接測試儀，建立流 量，手動開始/停止測試，測試完成之后還需要手動記錄測試結果，而通常這類測 試需要循環測試，記錄平均值。
此類測試痛點就很明顯： 一、測試時間是有限。和研發測試階段相比，產線測試的時間預留的比較短，
可能是 1 個小時，有的甚至更少；
二、測試種類設備數量多。測試設備的數量都不是簡單的一台，都是一個批次 一個批次很多台設備進行測試；
三、反復性的測試。產線上的測試都屬於比較基礎的測試，需要反復執行，以 確保產品質量
四、產線測試效率較低。假如以手工的方式進行測試，一個人一台設備一台設 備進行測試，這樣的測試效率是很影響產品出貨量；
五、測試人員可能缺乏代碼編程能力。對於產線測試人員的代碼功底，用腳本 進行自動化測試是很大的挑戰。
3.2 信而泰解決方案：提供 Smart Scripts
針對於此類情況，信而泰提供智能腳本工具（Smart Scripts）功能，來完成無 代碼的自動化測試。測試人員根據測試用例的步驟，編輯智能腳本的相關命令，進 行圖形化編程。如下圖，通過在命令編輯器里面添加相應命令，可以對添加的命令 進行上移/下移/刪除，完成之后就可以進行測試，包含的開始、停止、暫停和刪除 等按鈕可以實現對測試狀態的控制。
方案的優勢在於：
一、圖形化編程。整個自動化測試可以是圖形化操作，整個過程不用寫一行代 碼，就能完成自動化測試；
二、靈活控制測試步驟。通過 Smart Scripts 就可以靈活的控制測試流程，包 括循環、異常跳出和結果判斷等都是可以實現的；
三、快捷Th成測試例。通過智能腳本編輯器，按照測試步驟，添加相關命令， 達到測試目的，快捷完成測試用例測試。
3.2.1智能腳本工具（Smart Scripts）
智能腳本工具是無代碼的自動化測試用例編寫和執行的解決方案。通過智能腳 本可以運行並查看自定義測試和基准測試（RFC2544、RFC2889、RFC3918 和非對 稱測試）的狀態。
通常的手工測試，如果是要循環對被測設備打流，需要一次次點擊開始/停止 按鈕，假如要進行數據分析的話，需要人為對測試結果進行比較。智能腳本提供的
循環語句、條件語句和判斷語句，在循環測試和結果判斷等場景中，有很好的應用。
在很大程度上節省測試的時間，也更加快捷的得出測試結論。 智能腳本編輯器擁有強大的命令功能，包括 8 大類：硬件類、控制類、流量類、
協議類、統計類、抓包類、工具類、其它基本命令。其中每一大類都包含豐富的操
作命令。
硬件類（Hardware）：主要用於對測試資源的管理，支持的命令有連接/斷開
/關閉/重啟機箱、預約/釋放端口、端口上線/下線/自協商； 控制類（Control）：主要用於控制運行腳本的流程，包括 Break 、Continue 、
Else 、Else If 、Goto 、Group 、If 、Loop 和 While；
流量類（Stream）：主要是與流量相關的操作命令，包括導入流、發送指定 流、發送所有流、停止流、停止所有流、選擇流量接收端口、啟動流的 ARP/ND 學習和停止流的 ARP/ND 學習；
協議類：包括 Access 協議、Carrier Ethernet 協議、Routing 協議和 Switch 協
議。其中 Access 支持的協議有 DHCPv4、DHCPv6 、Dot1x、IGMP、L2TP、MLD 和 PPPoe。Carrier Ethernet 支持的協議有 802.1ag 、802.3ah 。Routing 支持的協 議有 BFD 、BGP、IS-IS、OSPFv2、OSPFv3、PIM 和 RIP 。Switch 支持的協議有 OVSDB。而每一種具體的協議又包括多種操作命令，比如 BGP 協議里的操作命令 包括建立/斷開 BGP 連接、通告/撤銷 BGP 路由等。其它協議里的各種操作命令也 是類似的；
統計類（Result）：主要是與統計結果相關的操作命令，包括有多頁統計結果 時執行翻頁操作、清除所有統計視圖的結果和清除指定統計視圖的結果；
抓包類（Capture）：是關於捕獲報文的操作命令，包括所有端口或指定端口 上開始抓包、在所有端口或指定端口上停止抓包、終止捕獲下載、下載 pcap 數據 到指定的路徑；
工具類（Tool）：支持的命令主要包括 Sleep、驗證統計值以確定命令成功或 失敗、添加注釋、在指定的目錄下執行指定的命令和等待條件為真才執行；
其它基本命令（Core）：支持的命令主要包括開始/停止學習 ARP、保存結果、 保存配置文件、收集日志信息、開啟/停止相應接口協議和所有接口開啟/停止協議 測試，等等。
除此之外，在命令編輯器里面還可對命令進行刪除、添加、上移、下移、命令 進行添加成組和命令進行循環等操作。通過對智能腳本里的不同命令進行組合來實 現客戶復雜測試需求。如下圖，是使用智能腳本工具來進行 OSPF 協議震盪測試。 先是上線端口，然后進行 APR 的學習，ARP 學習成功之后就開啟 OSPF 協議，保 存相關測試結果，之后進行撤銷 LSA 和通告 LSA 的操作，循環 12 次，通過此自動 化測試來測試路由震盪。
四、自動化集成測試
4.1 場景
對於網絡設備制造商或者運營商，其使用的測試儀表不止一個廠家，但是對他 們而言，不管是出於測試平台的維護還是自動化腳本的編寫，都只能是通過一個自 動化平台上去使用，運行一套自動化腳本，不可能存在多元化。當然，有的甚至會 將測試儀集成到自動化測試系統中，將網絡設備的測試作為系統中的一部分，豐富
自動化測試系統的功能。因為很多的自動化語言之間是的兼容性都比較差，就會出
現測試系統是一種語言，測試儀表又是另外一種語言，兩者之間如果需要結合的話 就存在一定困難。
此類情況痛點：
一、每個測試儀表廠家 API 存在差異。每個儀表廠商都有一套成熟的 API，互 相之間不可能兼容，引入新的測試儀表，原有的自動化測試腳本會調用不成功。
二、測試儀表的 API 與測試系統兼容性差。測試系統所使用的編譯語言與 API
使用的語言自動化測試語言可能存在差異，相互之間不能夠調用。
4.2 信而泰解決方案：提供高層 API 和 API 二次開發
針對於此類情況，信而泰可以基於基礎的 Renix API，提供高層 API 和 API 的 二次開發，便於完成自動化測試。高層 API 的開發，需要客戶的配合，只有提供測 試系統所需的 API 函數名稱、功能和參數等相關信息，才能更好完成高層 API 的封 裝。這樣一來，就可以多家測試儀表廠商，使用同樣的測試腳本進行測試。同樣的， API 二次開發也是需要和客戶進行交流，在明確客戶需求的前提下，針對客戶所需 的 API 在基礎的 API 上進行二次開發。
如下圖，很直觀的表明高層 API 和 API 二次開發最重要的目的：提高與自動化 測試系統的兼容性。
方案的優勢在於：
一、高層 API 結構簡單，層次清晰，方便用戶對常用的測試場景進行快速配置；
二、底層 API 變動時，通過修改高層封裝內部實現方式，確保測試腳本兼容；
三、高層 API 的這種結構從客戶角度上來說，消除了各家測試儀器廠商指令的 差異；
四、腳本通用性很高，不必為每種儀表重復開發相同功能的測試腳本； 五、API 的二次開發，提高測試儀表與自動化測試系統的兼容性。
4.2.1高層 API
高層 API 是根據給定的測試功能需求對測試儀表繁瑣的 API 調用進行封裝，向 測試人員提供結構清晰、易於理解的控制使用儀表的接口。 對於測試人員來說， 高層 API 采用面向對象的方式，結構清晰，相比較於底層 API 需要掌握的復雜的對 象及參數配置要求，高層 API 可以通過可讀性強的 API 命名規則和參數配置，方便 測試人員調用，可以更快捷、高效地實現自動化測試。
下圖是對於 connect 這個高層 API 的介紹，包括這個 API 的目的是為了初始化 測試資源；API 的使用概述，用到的函數；最后就是對於每個函數的詳細說明。
4.2.2API 的二次開發
API 的二次開發是指在底層 API 的基礎上，在可執行的條件下，信而泰可以提 供代碼級的支持，可以基於客戶的測試系統所用的自動化語言開發一致的 API 接口， 便於集成到測試系統當中。API 的二次開發可以很好的解決與客戶測試系統兼容性 的問題，目的就是去適配客戶的測試系統。相比較修改測試系統和二次開發的工作 量，可以有效減少客戶重新開發測試系統的工作量，並且也不會影響測試系統其余 的測試功能。
下圖是 C# API 二次開發資料中對於 StreamAPI 使用方法的說明。StreamAPI 是用於管理流的類。 例如：添加，編輯，刪除，復制，粘貼，重復等對流量的操 作都可以通過 Stream API 來實現
五、定制自動化測試
5.1 場景
對於有些公司或者科研院所來說，可能僅僅是因為項目原因，才會涉及到網絡 設備的自動化測試。不管是對網絡設備測試的認識還是自動化測試，基礎知識可能 比較欠缺，無法完成網絡設備自動化的測試。
此類情況的痛點
一、對於網絡設備測試完全是屬於零基礎，不知道從何下手； 二、手工測試起來繁瑣復雜，操作困難，而且需要掌握相關的網絡知識； 三、 缺乏代碼開發能力，無法完成自動化腳本的編寫。
5.2 信而泰解決方案：提供自動化定制服務
針對於此類情況，信而泰可以提供整套自動化測試服務，包括從確認測試需求、 制定測試方案、編寫測試腳本、定制開發自動化軟件測試到Th成測試結果。完整的 自動化測試服務，大大節省了客戶在測試上所耗費的時間和人力成本。
此類方案的優勢在於： 一、定制化服務：提供專屬的自動化測試服務 二、高性價比：引入競爭、降低采購成本； 三、國產自主：國產儀表，自主可控，軟件自主研發
四、技術支持快速高效：7*24 小時技術服務，更有研發團隊對代碼級進行支 持。
如下圖，是自動化測試測試服務流程圖：
5.2.1確定測試需求
需要明確客戶的需求，只有將測試需求確定下來，才能夠更准確的開展自動化 工作，信而泰才能提供更好的測試服務。主要的溝通內容包括以下幾個方面：和客 戶溝通測試需要滿足的要求，測試環境的要求，指標的要求等；需要達到的目的， 是要測試網絡設備性能，還是對功能進行測試；要清楚客戶需要呈現的結果，是對 於網絡設備整體的測試，體現出網絡設備的性能指標和功能的滿足度，還是只是對 網絡設備部分功能和性能進行測試。下圖就是客戶可能涉及到的相關需求。
5.2.2制定測試方案
明確測試需求之后，就需要制定測試方案。先是自動化測試語言的選擇，信而 泰提供的 Python/Tcl API 是否就可以滿足客戶的測試需求，需不需要進行二次開 發；哪些測試用例需要進行測試；呈現給客戶的結果是怎么樣的形式，在軟件界面 直接顯示結果，還是通過測試報告的形式；是否需要開發自動化測試軟件；整體測 試功能的計划等等，這些都是需要在測試方案中體現出的。下圖是對於交換自動化
測試的工作計划表，對測試的整體情況進行把控，需要測試的用例、交付的時間等。
5.2.3編寫測試腳本
測試腳本的編寫在自動化測試工作中尤為重要，會占用開發人員比較多的時間。 每一項測試用例都對應一個測試腳本，開發人員的工作可以看做是將測試用例的步 驟用腳本語言進行翻譯，完成自動化腳本編寫，通過機器去一步一步執行測試。另 外，對測試結果通過或者失敗的判斷也是腳本中很關鍵的部分，測試結果的 Pass
或者 Fail 就是通過腳本中的判斷條件去決定的，所以邏輯清晰明了的判斷條件，更
有利於測試人員對於網絡設備性能指標和功能滿足度的測試。 如下圖是編寫的部分測試用例。對於每個功能點和性能點都有腳本進行測試。
像 RIPv2 的涉及的功能點比較多，所以會有多個腳本去對其進行測試。
如下圖是編寫的測試腳本。腳本編寫的思路一般先是對於常用變量的初始化， 包括機箱的 IP，測試時長，測試流量的源和目的 MAC 等；接着就是對於占用測試 資源；然后是建立測試流量，根據不通測試用例建立不同的業務流量；然后是訂閱 統計之后，開始進行發流測試，等待流量發送完成之后停止測試；最后就是獲取統 計結果數據，對結果進行判斷
5.2.4開發自動化測試軟件
開發自動化測試軟件。可以實現對被測設備（交換機）和測試儀進行統一的管 理，包括下發被測設備的配置、綁定被測設備和測試儀端口等操作。很多手工測試， 都需要測試人員先對被測設備進行配置，然后才能操作測試儀表進行測試。
自動化測試軟件可以實現對測試腳本的批量管理。選擇腳本所在的文件夾，測
試腳本自動被索引出來，將需要測試的腳本與測試端口進行綁定之后，就可以進行 批量測試。多個腳本可以串行測試，在測試資源不沖突的情況下，還可以實現多線 程測試，多個測試腳本並行測試，測試效率更加高效。
自動化測試軟件還具備失敗重跑的功能，對於成功和失敗的測試腳本都有統計， 並且在測試界面還有相關測試步驟的體現，當測試過程中出現 Fail 之后，可以很直 觀的看到測試失敗的原因
自動化軟件可以實現對測試結果的匯總，Th成測試報告。Th成的測試報告格式
是 Word、Excel 和是其余格式。並且報告里面的內容可以根據客戶的需求進行定 制化設計。報告的標題、測試人員等內容也都是可以進行修改的。
Word 報告：報告中通過 3 個方面記錄測試結果，第一是測試概要，描述此次 測試的相關情況；第二是測試結果描述，包括測試結論（匯總）、通過的測試用例、 未通過的測試用例和改進及建議，記錄測試的相關結果；第三是詳細測試用例執行 情況，記錄每個測試用例的名稱、用例內容、執行過程和執行結果。
如下圖，是一次防火牆測試的 Word 報告，在此次測試中總共測試 8 個腳本，
6 個用例測試通過，2 個用例測試失敗，測試通過和失敗的用例分開記錄在報告中。 在詳細測試用例執行情況，記錄第一個測試用例的名稱是 1_default.tcl，用例內容： 測試默認禁止原則，執行過程中的 log 記錄，以及執行結果是 Pass，Pass 的判斷 就是 Port1 不能 Ping 同 Port2，Port 收不到 Ping 包。
Excel 結果報告：報告對測試結果進行匯總，包括 Pass 的腳本數量，Fail 的腳
本數量，通過率，總執行時間，以及每個腳本的名稱、測試目的、測試步驟、預期 結序、測試結論等等都會在報告中進行記錄。
如下圖，是一次防火牆測試的 Excel 結果報告，總共測試 6 個測試用例，6 個 用例測試成功，0 個用例測試失敗，總共的測試時長為 11 分鍾 28 秒，並且每個腳 本的目的、步驟、預期結果、測試結論等都記錄在報告中。