效能測試知多少—測試環境搭建

　　

　　在進行效能則試前，需要完成效能測試的搭建工作，一般包括硬體環境、軟體環境及網路環境，可以要求配置和開發工程師協助完成，但是作為一個優秀效能測試工程師，這也是你的必備技能之一。

 

效能測試環境與功能測試環境的區別                                               

 

　　那麼效能測試環境與功能測試環境有什麼不同呢？效能測試對測試環境的乾淨、獨立性要求更高，更為嚴格。對於一個相對較規範的公司，都會建立其獨立的研發環境、測試環境、線網環境（最終運行軟體的環境）。

（

　　這裡多扯一點，系統可以分為C/S架構的系統與B/S架構的系統，C/S架構的系統又可以分為兩種，第一種是基本不用與伺服器串連的，比如我們用到的java虛擬機器JVM，photo shop平面處理軟體，我們可以開啟軟體更新功能，這時軟體向伺服器發請求，查目前的版本是否是伺服器端發布的最新版本，然後，提示用例是否需要更新或下載最新版本的軟體。當然，我們也可以關閉更新功能或不檢測更新。那麼這個軟體一樣可以在電腦上運行。對於這類軟體，我的主要測試環境就是使用者的電腦。不同硬體設定、不同作業系統下對軟體一系列，從安裝使用到卸載。除了驗證軟體與硬體和系統的相容性能，還需要驗證與其它軟體是否相容。

　　第二種類型的C/S軟體要時刻與伺服器與串連，比如我的線上網遊，QQ聊天工具等。從軟體的啟動就需要與伺服器進行串連，對於此類軟體，我們測試環境的重點依然是使用者電腦，但伺服器端必須也有一個相對應的測試環境支撐。

　　對於B/S的系統，我們測試環境的重點就要由使用者電腦轉為伺服器端了，因為系統的所有功能都是由伺服器端傳遞給使用者的，所以需要驗證伺服器傳遞來的功能是否可用，以及功能的容錯能力等。

）

　　再回到測試環境的問題上，對於一些企業為了節約資源，進行功能測試的測試環境，一台伺服器可以運行多個系統，通過技術手段可以使系統之間是不會相互影響的（以前公司就是一台伺服器上跑多個tomcat）。因為功能測試的重點大於系統對用戶端發來的請求是否可以進行正確的處理。

　　那麼效能測試為什麼對系統的環境要求乾淨、獨立呢？效能測試是要對整個系統啟動並執行軟體硬體環境進行測試的，如果某環境下運行多個系統，就很難判斷其中的某個環境對資源的佔用情況。

 

 

效能測試環境包含內容                                                                          

 

一般web應用系統分為3層架構（在系統架構一章中有介紹）

* 表現層（web伺服器）

* 商務邏輯層（應用伺服器）

* 資料層（資料庫伺服器）

 

效能測試環境包含內容：

硬體：伺服器、用戶端、交換器等。

軟體：資料庫、中介軟體、被測系統、作業系統等。

網路：有線/無線/寬頻、網路通訊協定等。

 

 

如何保證測試環境與真實生產的一致性                                             

 

保證效能測試與真實生產環境的一致性，具體從以下三個方面來看：

1、硬體環境，包括伺服器環境、與網路環境

　　如伺服器的型號以及是否和其它應用程式共用此伺服器，是否在叢集環境下，是否通過BIGIP進行負載平衡，客戶使用的硬體設定情況，使用的交換器型號，網路傳輸速率。

 

2、軟體環境

版本一致性

　　包括包括作業系統、資料庫、中介軟體的版本，被測系統的版本。

配置一致性

　　系統（作業系統/資料庫/中介軟體/被測試系統）參數的配置一致，這些系統參數的配置有可能對系統造成巨大的影響。所以，除了保證測試環境與真實環境所使用的軟體版本一致，也要關注其參數的配置是否一致。

 

3、使用情境的一致性

基礎資料的一致性

　　包括預測的業務資料量，以及資料類型的分配。很簡單的一個列子，一個系統的資料庫只有10條資料和一條資料庫裡幾千萬條資料，我們在對其進行效能測試時，得到的效能指標可能會有非常大的差別。

　　為了保證每次測試環境的更加一致性，磁碟的使用方式以及磁碟的片段情況也會或多或少的影響的效能。

使用模式的一致性

　　盡量類比真實情境下使用者的使用方式，其實，我們在做效能測試前期的需求分析，其主要目的也就是為了更真實的類比使用者的使用方式。

 

 

效能測試環境的實施策略                                                            

 

　　上面講測試環境與生產環境保持一致所需要注意的內容。其實在實際的測試中，我們很難搭建出與生產環境完全一致的一個測試環境，除非我們暫停生產環境使用者於進行效能測試，這往往是不可能。一方面某些生產環境是不允許被暫停，另一方面也為生產環境的安全性考慮。

　　效能測試環境並不像功能測試環境，為了節省資源可以一台伺服器上運行多個系統。由於效能測試的特殊性，整個測試環境需要在嚴格的獨立監控下管理，在很多情況下，我們很難申請到足夠的且一致的資源（說白了就是老闆是否願意出錢給你買伺服器搭建系統）。對於一個並未上線的項目，其生產環境的配置也屬於暫訂狀態，效能測試的目的就是為了確定具體生產環境的硬體設定。這個時候更不可能用過高的配置來搭建效能環境（除非現成的環境放著不用）。

我們一般通過兩種策略來搭建效能測試環境（預估方式均有誤差）

 

1、通過建模的方式實現低端硬體對高端硬體的類比

　　通過配置測試來計算不同配置下的硬體效能和系統處理能力的關係，從而推匯出滿足系統效能的真實配置情況，這種類比需要精確的建模，模型的採樣點越多，那麼得到的結果越精確，從而將在低端配置下的效能指標通過該模型轉化為高端配置下的最終預計效能指標。

　　例如：搭建一個低端環境，首先需要對這個環境的CPU和記憶體進行單獨的效能基準測試，同過在不同的配置的效能測試，得到一個基準資訊列表，當然，在進行這個效能測試的過程中，我們要確定硬體是系統的瓶頸。如果只用一個CUP，在效能測試過程中，其使用率很低，但得到的效能資料都非常底，這起碼說明CUP不是系統的平靜，這種情況下就無法得到想要的基準值。

　　如，在一顆CPU情況下，運行100個使用者且CUP使用率接近飽和（100%）。在增加至兩顆CUP的情況下，可以運行190個使用者且UPU使用率接近飽和（100%），以此做記錄，那麼我們就可以推算出運行800個使用者需要多少顆CUP。

　　如果你在實際應用中使用的CUP型號及其頻率並非完全一樣，這個時候可以使用EVEREST工具計算每種CUP的得分，對其效能進行評估。

　　記憶體也可以使用此方法進行測試推導，這裡需要我們多進行實驗，對硬體的效能以及對整個項目的結構都要做深入的瞭解，以便盡量減少誤差。

 

2、通過叢集的方式計算

　　對於較大的系統來說，單台伺服器的處理能力是有限的，通常都會採用叢集的方式來進行負載平衡，完成對海量請求的處理。雖然無法獲得整體叢集的測試環境，但是可以對叢集上的一個節點進行效能測試，得出該節點的處理能力，再計算每增加一個節點的效能損失，同樣也可以能過建模的方式得到大型負載平衡情況下的預計效能指標。

　　例如:首先在單台伺服器上獲得具體的效能指標，每台伺服器能夠承受500使用者並發，平均TPS為60，回應時間為2秒，接著，添加負載平衡策略，再次測試負載策略下的資料損耗。得出資料後添加1台負載平衡伺服器，測試在兩台伺服器下每台伺服器的效能指標，以此類推，可以得到下表：

　　隨著負載平衡伺服器的添加，平均每台伺服器的處理能力會逐漸穩定，從而瞭解在什麼情況下需要多少台負載平衡伺服器。

　　對於測試環境的搭建，建議產生專門的文檔進行管理，並進行組態管理，確保對測試環境做到基準控制。

 

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

　　這個效能測試系列以理論與效能測試的整體講解為主，市面上的大部分書籍藉著效能測試的表皮在講效能測試工具loadrunner，那我何不找份loadrunner使用手冊來看更好。

如果你感覺此文對你有所協助，請推薦下或留言鼓勵批評。後面將分享更多的內容。^_^