接近更真實
——關於網路測試環境的困惑與反思
■ 吳疌
作為運營商的一名測試人員，筆者參加過很多個測試專案。但似乎大多數的測試都不是令人心情愉快的過程，尤其是大型測試中常會出現令人頭疼的問題，使得廠商的技術人員和測試工程師十分沮喪和疲憊。那麼，為什麼曾在研發實驗室裡測試多次的裝置在第三方實驗室的驗證性測試時還會出現難以解決的問題呢？
工程師的困惑
面對測試過程中出現的種種問題，筆者一直在想：是不是我們的測試要求過高了？答案是否定的。因為，從現在看來，測試的要求是很普通的，如果有足夠的時間和強大的測試工具，那麼測試的要求肯定會比現在要高很多，而測試過程也會更加嚴格，當然這也意味著會有更多、更煩人的問題和更漫長的夜晚。
那麼，是現在的裝置功能太複雜了？的確，現在的裝置功能越來越強大，測試也隨之變得複雜，但是複雜的測試就一定意味著會出現各種問題嗎？
在與廠商技術人員的交流中，筆者發現他們也有著同樣的困惑：測試的專案越多，測出來的問題就越多，但測試週期卻在相對縮短，增加測試人員卻得不到效率的提公升，一切看上去似乎都在向不好的方向發展，那究竟問題出在哪兒呢？
尋覓最佳的測試方案
在外部原因很難給出乙個滿意答案時，我們不妨試著研究一下現有的測試方法。結果發現: 目前的困境在很大程度上是由測試方法和測試環境之間的衝突所造成的，而這種衝突在短時間內則是難以消除的。
那麼，想像中的最佳測試方案是什麼樣的呢？如果以發現缺陷的效率來評價乙個網路測試方案的話，它應該必須具備如下特性：
重複性——客觀的測試必定是可重複的。在完全相同的測試環境下，每次測試的結果都應該是一致的，或是在誤差範圍之內的。為了提高測試的重複性，測試人員更容易傾向於乙個穩定的測試環境和基本不變的測試方法，對於引進新的測試手段或對測試環境進行大的改動都心存芥蒂，因為新東西常會帶來新問題。但是，當產品在第三方實驗室中測試時，測試的環境和方法可能會有很大的不同，如果廠商的測試人員忽略了這些差異，就極有可能在測試中被搞得焦頭爛額。
隔離性——指的是在進行某項測試時，測試環境中的各個裝置和裝置的配置應該只和該項測試有關，非被測裝置的效能不會對測試結果造成影響，非被測裝置之間的相容性和互操作過程不會影響最後的測試結果。隔離性反映的是隔離故障點的效率，這和檢查問題時常用的「逐個擊破，層層深入」的原理很相似。例如，在進行rip測試時，測試環境中不會存在其他的路由協議，否則會對問題的定位造成困難。因此，測試過程往往是乙個專案做完後再做另乙個專案，或者分組在不同系統中做不同的專案，同時在乙個系統內測試的專案少之又少，而且出現問題時多數人的第一反應就是配置有問題，需要清空配置或是重新啟動。
控制性——指的是在測試時，測試環境中的所有裝置都是可控制和監測的。如果測試環節中存在無法修改的引數或者是無法檢視配置和運**況的裝置，那麼尋找問題的過程顯然會辛苦幾倍。在第三方實驗室中相容性和互操作性是非常重要的測試專案，而廠商的測試環境中第三方裝置一般不多。所以在進行如mpls/vpn裝置互通性測試時，乙個測試環境中即使同時只存在兩個廠商的裝置，對雙方的技術人員來說都是乙個巨大的考驗，因為他們面對的是乙個完全陌生的裝置。此外，在進行「全黑」測試時（即測試過程自始至終都不允許廠商技術人員對裝置進行操作或監控），常會使廠商的技術人員緊張，因為日常的測試經驗使得他們對控制性非常看重，一旦失去了對裝置的控制心中便很容易沒了底。反過來講，大量的配置命令和眾多需要監控的引數或報警資訊對測試人員也是一種考驗，在單元測試或單模組測試時不太會出現這種情況，而在整體測試時卻會經常發生，可見過多的控制資訊也會造成控制性的降低。
總之，廠商實驗室中的網路世界是乙個相對理想的世界。實驗室的裝置不多，測試人員對整個測試環境十分了解，因此實驗室中的測試有著高重複性、高隔離性、高控制性的特點。測試人員分工明確，針對不同的單元有著不同的測試方案，而將整個系統進行徹底黑盒測試的機會不多。而第三方實驗室的環境更接近於真實的網路，測試環境複雜、手段多樣，經常對裝置進行系統的整體性測試，相對於廠商的測試環境其重複性、隔離性、控制性都降低了不少。而這些因素恰恰是導致那些在廠商實驗室中表現完美的裝置在第三方測試後從天鵝變成了醜小鴨的原因。這個看似不合理的結論反映了網路測試中乙個日趨激烈的矛盾——現有的測試手段無法在乙個日趨複雜的測試環境中提供高效的測試方案。
網路測試的5件利器
事實上，隨著技術的發展，實驗室與真實網路之間的距離正在不斷加大。真實的網路是乙個極其複雜而又充滿隨機性的世界，要使實驗室中的網路環境更加真實就必須在測試中引入概率分布和統計平均的機制，例如imix; 就必須做到同時進行多個測試專案，考察多個指標，並對結果進行綜合分析; 就必須在測試環境中新增多個其他裝置來驗證被測裝置的相容性；就必須在進行功能和效能測試時同時進行管理性和安全性測試等等。
在這樣的測試環境裡，網路中的資料流是以統計重複來傳送的；而眾多的網元和網路中執行的眾多協議使得隔離性降低，其後果就是隔離故障點所花費的時間直線上公升；再加上有可能要對多個裝置進行操作才能模擬乙個測試環境，而測試中需要監控的引數也可能會有很多，如果這些全靠人工操作效率勢必很低。
反觀我們目前的測試手段，連自動測試都很難做到，幾乎是赤手空拳，怎麼能應付更真實、也更「低效」的測試方案呢？根據多年測試中積累的經驗，筆者總結出了在更接近真實的測試環境下提高網路測試的效率的5件利器（具體內容見下）。雖然它們現在看起來有點兒超前，但對於乙個網路測試來說，這些的確是缺一不可的。 ■
出色的測試管理系統
為了提高對測試的重複性，必須要能很方便地管理測試環境中各種配置檔案，並對每次測試的資料、日誌、報告等進行系統的管理。這在單元測試中實現起來並不困難，而在複雜的環境下進行複雜的測試時若沒有乙個出色的測試管理系統則是難以想像的。
高效的測試監控和
資訊過濾系統
為了在乙個複雜的測試環境下尋找問題點，必須對測試環境中各個裝置的多項引數進行監控，而在大量資料分析時擁有乙個好的過濾機制無疑是從另乙個方面提高了測試的隔離性和控制性。
靈活的測試軟體
再強大的測試軟體也有無用武之地的時候，所以我們需要更加靈活的測試軟體，不僅是靈活的引數配置，還要能按照我們要求進行測試，並能自動配置網路中的各種裝置。為測試指令碼提供更強大的api，在現有的測試軟體上增加「巨集」的功能，提供實時的測試結果分析，這些對於測試人員來說都是十分必要的。
通用的測試描述語言
如何描述整個測試環境？如何說明整個測試流程？不要認為答案會很簡單。想像一下你在執行gvrp和lacp的三層交換機上進行基於vlan組播測試的環境吧！這不是乙個網路拓撲圖和幾個**就能解決的事情。未來的測試會比這複雜許多，如果沒有通用而準確的測試描述語言，溝通將變得十分困難。
優秀的測試人員
傳統的測試和接近真實網路的系統性整體測試有很大的不同，後者對測試團隊提出了很高的要求。測試團隊中的每乙個人不僅要有紮實的基礎知識和優秀的分析能力，還必須對整個測試體系有著清晰和一致的認識。因為，在非常複雜的測試環境中查詢問題的難度是很大的，發生任何的人工失誤都會極大地影響測試效率。
效能測試環境與真實環境的對比
效能測試模擬真實負載是比較困難的。效能測試與真實環境的對比，通常有這樣一些點 1.客戶端展現。如果是web應用，客戶端使用瀏覽器展現的，則一些的壓力測試工具都不具備展現的功能，也就是說，只是模擬傳送http請求到接收請求，而瀏覽器對html內容進行渲染的時間，是無法模擬的，這很可能是真實環境體驗現測...
實驗室測試模擬真實網路環境方法
我們的專案，可能會涉及到各種網路環境，比如通過家庭寬頻接入 通過手機接入，這些環境相對於我們測試時候使用的網路環境要複雜的多，如何模擬現網可能出現的各種網路情況，使得我們的程式，在各種環境下都能夠正常的執行，是我們需要解決的難題。1具體操作 模擬延遲傳輸 tc qdisc add dev eth0 ...
關於開發環境 測試環境 生成環境的基本概念
color red 開發環境 color 開發環境是程式猿們專門用於開發的伺服器，配置可以比較隨意，為了開發除錯方便，一般開啟全部錯誤報告。color red 測試環境 color 一般是轉殖乙份生產環境的配置，乙個程式在測試環境工作不正常，那麼肯定不能把它發布到生產機上。color red 生產環...