簡介
如果不進行合理的規劃，對J2EE應用程序進行性能測試將會是一項令人望而生畏且有些混亂的任務。因為對于任何的軟件開發流程，都必須收集需求、理解業務需要，并在進行實際測試之前設計出正式的進度表。性能測試的需求由業務需要驅動，并由一組用例闡明。這些用例可以基于歷史數據（例如，服務器一周的負載模式）或預測的近似值。弄清楚需要測試的內容之后，就需要知道如何進行測試了。
在開發階段前期，應該使用基準測試來確定應用程序中是否出現性能倒退�；鶞蕼y試可以在一個相對短的時間內收集可重復的結果。進行基準測試的最好方法是，每次測試改變一個且只改變一個參數。例如，如果想知道增加JVM內存是否會影響應用程序的性能，就逐次遞增JVM內存（例如，從1024 MB增至1224 MB，然后是1524 MB，最后是2024 MB），在每個階段收集結果和環境數據，記錄信息，然后轉到下一階段。這樣在分析測試結果時就有跡可循。下一小節我將介紹什么是基準測試，以及運行基準測試的最佳參數。
開發階段后期，在應用程序中的bug已經被解決，應用程序達到一種穩定狀態之后，可以運行更為復雜的測試，確定系統在不同的負載模式下的表現。這些測試被稱為容量規劃測試、滲入測試(soak test)、峰谷測試(peak-rest test)，它們旨在通過測試應用程序的可靠性、健壯性和可伸縮性來測試接近于現實世界的場景。對于下面的描述應該從抽象的意義上理解，因為每個應用程序的使用模式都是不同的。例如，容量規劃測試通常都使用較緩慢的ramp-up（下文有定義），但是如果應用程序在一天之中的某個時段中有快速突發的流量，那么自然應該修改測試以反映這種情況。但是，要記住，因為更改了測試參數（比如ramp-up周期或用戶的考慮時間(think-time)），測試的結果肯定也會改變。一個不錯的方法是，運行一系列的基準測試，確立一個已知的可控環境，然后再對變化進行比較。
基準測試
基準測試的關鍵是要獲得一致的、可再現的結果�？稍佻F的結果有兩個好處：減少重新運行測試的次數；對測試的產品和產生的數字更為確信。使用的性能測試工具可能會對測試結果產生很大影響。假定測試的兩個指標是服務器的響應時間和吞吐量，它們會受到服務器上的負載的影響。服務器上的負載受兩個因素影響：同時與服務器通信的連接（或虛擬用戶）的數目，以及每個虛擬用戶請求之間的考慮時間的長短。很明顯，與服務器通信的用戶越多，負載就越大。同樣，請求之間的考慮時間越短，負載也越大。這兩個因素的不同組合會產生不同的服務器負載等級。記住，隨著服務器上負載的增加，吞吐量會不斷攀升，直到到達一個點。
圖1.隨著負載的增加，系統吞吐量的曲線（單位：頁面/秒）
注意，吞吐量以穩定的速度增長，然后在某一個點上穩定下來。
在某一點上，執行隊列開始增長，因為服務器上所有的線程都已投入使用，傳入的請求不再被立即處理，而是放入隊列中，當線程空閑時再處理。
圖2. 隨著負載的增加，系統執行隊列長度的曲線
注意，最初的一段時間，執行隊列的長度為零，然后就開始以穩定的速度增長。這是因為系統中的負載在穩定增長，雖然最初系統有足夠的空閑線程去處理增加的負載，最終它還是不能承受，而必須將其排入隊列。
當系統達到飽和點，服務器吞吐量保持穩定后，就達到了給定條件下的系統上限。但是，隨著服務器負載的繼續增長，系統的響應時間也隨之延長，雖然吞吐量保持穩定。
文章來源于領測軟件測試網 http://www.kjueaiud.com/