人類的進化史和發展史，就是一個不斷創造和使用工具的歷史。工具是人類想象力的物理呈現，也是社會進步的巨大助力。對于測試而言，工具同樣不可或缺，甚至于如果想判斷某個廠商的測試水平是處于“蠻荒時代”還是已經進化到了“現代社會”，觀察其使用的測試工具就能知道個大概。事實上，很多測試項目，尤其是性能和穩定性測試項目，必須借助測試工具才能完成;驗證業務的大規模部署能力，沒有工具的支撐更是不可想象。舉個簡單例子，對一個可以同時接入4000個PPPoE的設備進行測試，如果沒有測試工具，就只能搭建一個4000個客戶端的環境，這在實踐中幾乎不可實施，更何況類似測試項目會很多，而且每個版本都需要重復測試。

一、測試工具

伴隨著網絡技術的爆發式發展，種類繁多的測試工具也被開發出來，根據其主要功能，大致可以分為下面幾類*(*注：現在的測試工具都比較復雜，不一定能完全嚴格分類，比如Chariot和Avalanche都能提供強大的流量產生功能，又是很好的業務模擬工具)。

流量發生工具：主要用于生成大規模網絡流量，測試設備的轉發平面功能。這類工具有的是直接安裝在主機上的軟件，如Chariot;也有的是專用硬件，比如Spirent和IXIA等專業廠商提供的測試儀器;

協議仿真工具：主要對信令協議進行仿真，測試設備的控制平面功能。比如路由協議仿真，MPLS相關協議仿真，認證接入協議仿真等測試工具;

業務模擬工具：主要是對應用層協議和客戶業務進行模擬，測試設備的應用和業務承載能力。一般的L4-L7的測試儀器和工具都提供了強大的業務模擬能力，比如Avalanche，BPS等測試儀器和Chariot軟件;

攻擊類工具：包括黑客工具、Fuzzing和Vulnerability類測試工具，測試設備的安全性和攻擊防范能力。典型的有Mu Dynamics、Codenomicon、BIFFIT、SAINT、NESSUS、nMAP以及SYN flood 等DDOS工具;

平臺類工具：一般提供的是一個二次開發平臺，有完善的集成開發環境，支持多種適合用于測試的高級計算機語言(如Perl、TCL、Python等)，可進行復雜的二次開發，集成了為適應測試而封裝和抽象的Lib庫，甚至提供一些已經經過實踐檢驗的自動化測試套件，并且可以通過外部接口調用其它測試儀器和工具。類似微軟的Visual Studio開發環境，只不過它是為開發服務，前者是為測試服務。平臺類工具投入巨大，主要為了滿足廠商建設自己獨特的測試能力體系的需要，一般由廠商自行開發與維護。H3C構建了這類平臺，稱為通用測試平臺(VTP，Versatile Test Platform)。

一般來說，對于成熟的協議或應用測試，都有優秀的商業測試儀器和測試工具，可以滿足80%以上的測試需求。但對于最新的協議和應用，或者特定客戶的非標準定制需求，就要求廠商具備一定的測試工具自主開發能力。以H3C為例，在802.1x協議剛開始在國內應用時，在大量用戶同時接入設備的條件下，設備會較大概率出現軟件崩潰。于是，測試團隊自行開發出一個模擬大量802.1x用戶接入的工具，最終很快就發現并解決了問題，而具備類似功能的商業802.1x測試工具，大約時隔兩年后才在市場上出現。

H3C對于測試儀器和測試工具在優化測試效率、提高測試水平、提升產品質量方面的重要性深有體會。在這方面的投入很大。一方面，大量采購了業界先進的商業測試儀器和工具，如Spirent、IXIA、BPS和Veriwave等公司的測試儀器和測試軟件。另一方面，通過專門的測試平臺團隊也獨立開發了眾多的測試工具和軟件，為商業測試軟件覆蓋不到的測試需求提供支持，確保H3C能以最快的速度推出最新特性。該團隊開發的測試工具目前已經形成系列并成為測試工程師的重要助力，如多客戶端模擬系列工具，路由協議系列測試工具，一致性系列測試工具，綜合業務模擬系列工具等。該團隊開發的通用測試平臺則構建了一個公司級的自動化測試框架，提供了完善的GUI，CLI自動化測試解決方案，為H3C的全系列產品測試提供服務。

二、測試自動化

測試工具和測試自動化，兩者是一對孿生兄弟。測試工具的目的就是為了代替部分繁瑣的手工測試操作，或完成手工測試不可能完成的測試活動，實現一定程度的測試自動化。測試自動化的發展進化和測試工具的進步密不可分，隨著測試工具的進步和完善，很大一部分測試工作已經可以做到無人值守，實現完全意義上的自動化?；仡欁詣踊瘻y試技術的發展歷史，大致可以分為三代。

第一代，以工具為中心的自動化

時間：90年代中期之前

這一代自動化使用的測試工具，以捕捉/回放(Capture/Replay)工具最為典型，即捕獲用戶的鼠標和鍵盤操作，并記錄下來，下次測試時可以回放這些操作，重復上次的測試。這些工具一般也提供簡單的腳本功能，測試人員還可以根據需要對記錄的腳本進行修改，比如增加循環操作以及一些簡單的判斷條件等，以強化測試。不過因為腳本語言簡單，腳本功能往往只是其中的點綴。如QARun，WinRunner，就是這種工具的典型代表。這代測試自動化技術有很大的局限性：

自動化程度有限。每種工具都有自己獨特的腳本語言，但又不是一個全功能的腳本語言，能自動化的操作有限，構不成一個完整的自動化解決方案，不同工具的腳本無法共享;

對SUT(System Under Test)的變化適應性較差。如果SUT的GUI有了變化，錄制的腳本幾乎不能再用，這在軟件總是不斷改進和變化的時代幾乎是致命的缺陷。

第二代，以腳本為中心的自動化

時間：90年代末至21世紀初

這是自動化的個人英雄主義時代。一些測試團隊在這個階段已經認識到采用統一腳本語言的重要性，并找到了適合測試工作的、功能完備的腳本語言，在團隊中大力推行。但因為經驗有限，缺乏良好的頂層設計，測試自動化主要依靠測試工程師的主觀能動性，八仙過海、各顯神通，每個人都是腳本工程師，測試腳本大量產生。

這代自動化雖然有了統一的腳本語言，測試工程師之間也可以進行少量的腳本共享。但總體而言，是各自為戰，風格不同，質量參差不齊。和個人測試環境密切關聯的個人自動化成果難以充分轉化為有效的團隊平臺積累。不過，這個階段培養了大量的技術熟練的測試自動化工程師，為下個階段打好了人員和技術基礎。

第三代，以平臺為中心的自動化

時間：21世紀初至今

在第二代自動化摸索幾年后，有眼光的測試管理者和出色的測試工程師，都認識到這種野蠻生長產生的腳本在可維護性、可重用性、拓撲適應性方面都存在很大問題，不能真正形成持續有效的團隊積累。于是，自動化測試的頂層設計被提上日程：構建一個出色的自動化測試平臺;腳本基于邏輯拓撲進行開發，在執行時才映射到物理拓撲;把常用測試操作抽象為Action word并實現，作為通用類庫供所有測試工程師使用;制定腳本的開發，驗收，維護規范，保證腳本的一致性、通用性和可維護性?；谶@個測試自動化平臺開發的腳本，才真正可轉化為有效的團隊積累。

以H3C的測試自動化發展為例，在1999年之前，只是利用簡單的捕捉和回放測試工具，基于這些工具編寫簡單的腳本，屬于第一代自動化。1999-2002年期間，測試平臺團隊引入了適應通信設備測試的TCL語言，開發了通用測試平臺，但統一的ATF(Auto Testing Framwork)尚未成熟，處于第二代自動化階段。2003年，H3C測試團隊發布了ATF，并啟動Testbladev1/v2腳本體系的開發，這標志著H3C的測試自動化進入了第三代，并在實踐中不斷優化?；赩TP和ATF，H3C已經實現了80%以上的功能測試的自動化，并提供了多個性能測試、壓力測試及持久性測試的自動化測試套件。

三、展望：第四代自動化測試技術

那么是否會有第四代自動化測試技術? 回答是肯定的。下一代自動化技術必然是以網絡為中心的測試自動化，也可以稱之為以云為中心的測試自動化。所有的測試設備(真實的、虛擬的)、測試儀器以及測試主機，通過一個測試自動化管理系統進行統一管理，呈現在測試工程師面前的將是一個測試設備云。測試工程師可以遠程登錄到測試自動化管理系統，通過任務管理系統提交自己的自動化測試任務，只需要描述清楚測試任務所需要的設備類型、設備連接的鏈路類型，需要執行的測試套，系統即會按規則在測試云中進行搜索和計算，得出什么時間能提供滿足本次測試任務所需要的測試執行環境，測試工程師可以預約這個時間之后的任意時間運行自動化任務，并準時收到自動化測試結果。

第四代自動化測試技術相對第三代，將在可管理性、易用性以及設備利用率方面有質的飛躍，但仍然必須以穩定可靠的測試平臺以及完善的測試腳本體系做為測試執行的基礎，這意味著第三代測試自動化不可跨越。否則，所謂的云測試就是無源之水。

四、結束語

測試自動化極大的提高了測試效率，使測試工程師可以從簡單重復的機械操作中解放出來，把更多精力投入到更有創造性的測試設計，以及更復雜的測試執行中去。但我們也必須認識到測試自動化的局限性。首先，自動化只是對已有測試設計的機械重復，不會超出已有的測試認知。其次，復雜測試場景下，影響測試結果的因素非常廣泛，依靠機器進行判別很難行得通，還是必須由人來完成。

這些局限因素決定了自動化測試不可能完全替代手工測試。不過，測試工具和自動化技術在復雜環境模擬和業務模型構造上的作用，永遠無可替代，所以，即使是手工測試，一樣也離不開測試工具和測試自動化技術。可以說，測試工具和測試自動化的進步推動著整個測試行業的發展。