保證性能測試與真實生產環境的一致性，具體從以下三個方面來看：
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使用手冊來看更好。