在進行性能則試前，需要完成性能測試的搭建工作，一般包括硬件環境、軟件環境及網絡環境，可以要求配置和開發工程師協助完成，但是作為一個優秀性能測試工程師，這也是你的必備技能之一。
性能測試環境與功能測試環境的區別
那么性能測試環境與功能測試環境有什么不同呢？性能測試對測試環境的干凈、獨立性要求更高，更為嚴格。對於一個相對較規范的公司，都會建立其獨立的研發環境、測試環境、線網環境（最終運行軟件的環境）。
（
這里多扯一點，系統可以分為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使用手冊來看更好。