對網路產品的效能測試中的一些想法和看法。

2021-04-25 07:17:36 字數 1716 閱讀 3828

網路產品的效能指標主要是由rfc2544 和rfc3511中所提出的。

主要包括:吞吐量、延遲、背靠背、丟包率、每秒新建鏈結、每秒事務處理、有效吞吐量(http吞吐量)還有最大併發數。

其中吞吐量、延遲、背靠背和丟包率是由rfc2544中所定義的,是屬於2-3層的測試,測試中所使用的是udp的資料型別。而另其它測試是由rfc3511中所定義的,是屬於4-7層的測試,測試中以tcp資料型別為主。

在2-3層的測試中,rfc2544定義的是最基本的測試專案。客戶也可以根據自身的需求來改進或擴充套件適合自己的測試方法,如:混合包的吞吐量、nat的吞吐量、l2tp的測試等等。

在4-7層的測試中,rfc3511也是定義其最基本的測試專案。客戶也可以根據自身的需求來改進或擴充套件測試方法,特別是應用層的測試。如:ftp的吞吐量、smtp的建立速率、telnet建立速率等。

但隨著網路產品的日益發展,rfc2544、rfc3511中定義的指標不能完全反映出網路產品的效能優劣。

我個人認為。在衡量一款網路產品的效能優劣。應該是全方位。除最基本的效能指標外,還應考試產品在功能上的效能。

比如。如果某款產品有vpn的功能。那麼除了上述的幾個指標外,還應該測試vpn的效能。

包括vpn吞吐量、vpn的每秒新建隧道數和vpn最大隧道數。

如果某款產品有動態路由的功能。那麼也應該測試動態路由的效能。包括路由表容量、路由收斂時間、抖動下的延遲等。

如果這款產品有ips或utm的功能,那麼病毒檢測、深度分析、內容過濾、郵件檢測的效能也應進行考慮。。

網路產品分類較多,如閘道器類產品、路由產品、交換產品等。根據產品的定位不同,測試重點也盡相同。我個人認為,除基本測試專案外,產品定位不同,測試專案也應有所改變。

閘道器類產品應把攻擊防禦做為測試重點。路由產品應把路由的效能做為重點,交換產品應把2-3層的測試做為重點。

以現在的網路產品來看,rfc2544的測試指標幾乎所有的廠商都可以輕鬆達到預期。那麼我們應該把測試重點放在網路層或應用層的測試中去。

---------------------------------------

在進行應用層的測試中,測試方法比較靈活。雖然測試同乙個指標,但可以根據關注點的不同,來編寫不同的測試方法 。下面我舉個小例子。

測試專案 有效吞吐量(http吞吐量)

測試儀器 ixia400t alm_8t_1g板卡

第一種,如果我們關注有效吞吐量的效能指標,那些我們可以採用一條鏈結來進行測試。 

第二種,如果我們關注在一定的鏈結下的有效吞吐量的效能指標,那些我們需要建立一定數量的有效鏈結,並且每條鏈結中,都進行有效吞吐量的測試。

在第一種測試方法中,是rfc3511中定義的標準測試方法。這種測試方法只採用了乙個鏈結。而第二種測試方法,是在rfc3511基礎之上,擴充套件了此測試方法。這種測試方法採用了多個鏈結併發進行資料傳輸。這種測試方法對裝置的壓力相對較大。但鏈結個數與吞吐量的效能之間存在一定的關係,鏈結越多,吞吐量較小。反之亦然。如何去控制鏈結個數,這就需要測試需求中所定義的了。關注自身的需求去定義測試方法,從而可以更好的反映網路產品的軟體與硬體之間的效能。

之所以提出這些的想法。是因為4-7層的效能測試靈活程度非常的大。雖然是同乙個測試專案,但根據測試的注意點不同,方法的不同,測試結果也不盡相同。換句話說,就是無法真實的反映出網路產品的效能。所以,我提出,在衡量乙個網路產品的效能時,特別是4-7層的測試時,不能只看測試結果,也應該了解其測試的關注點、測試的方法等。只有這樣,我們才能了解其產品在4-7中的效能。

以上為小弟愚建。如有不當,還請各位大俠糾正指出。非常感謝!

對做「網際網路產品」的一些想法

其實我的工作是自動化測試,但在工作中不斷和產品及開發人員打交道,對做產品逐漸有了自己的一些想法,在此整理一下思路。1 產品是什麼?產品就是針對使用者需求的解決方案。這句話很淺顯,但它帶出了 需求 二字,說實在,現在我還沒有能力悟透這兩個字 在現實世界,極少使用者會跟清楚描述需求,這種情況在做通用產品...

對做「網際網路產品」的一些想法

其實我的工作是自動化測試,但在工作中不斷和產品及開發人員打交道,對做產品逐漸有了自己的一些想法,在此整理一下思路。1 產品是什麼?產品就是針對使用者需求的解決方案。這句話很淺顯,但它帶出了 需求 二字,說實在,現在我還沒有能力悟透這兩個字 在現實世界,極少使用者會跟清楚描述需求,這種情況在做通用產品...

對產品初期測試的一些認識

對於乙個剛弄出來的新產品雛形,會有很多這樣那樣的問題,比如很多功能點沒有按照既定的需求加以細化 很多流程只是粗略的調通,在系統聯調時會有很多調不通的問題。一般都是由於專案週期有限,為了能盡量按期完成指定的目標,我們會盡快的讓產品早點切入到測試中,一邊測試,一邊修復bug,甚至讓一些小的功能點在測試過...