不是專職做壓力測試這行當的，只能是以自己的經驗來以外行人的眼光來說說壓力測試，壓力測試并不僅僅是個壓力測試的過程，而是一個相當系統和復雜的工程，我認為壓力測試是為了讓系統達到所期望的運行效果以及承受所期望的壓力，這也就要求壓力測試應該幫助性能調優團隊，為其提供一定程度的指導，在這里我不將壓力測試和性能調優分的那么清楚了，在我看來，壓力測試過程包括了：明確壓力測試的目標、制定壓力測試方案、進行壓力測試、分析壓力測試結果、尋找瓶頸并進行調優以達到目標，在這篇blog中來細看下這幾個過程以及常用的方法。
明確壓力測試的目標
通常來說（注意是通常），壓力測試的目標有這么幾點：
1、評測系統是否滿足壓力支撐的要求
要評測系統是否滿足壓力支撐的要求，同樣要做的就是需要明確定義系統需要支撐多大的壓力，例如：
機器的配置：CPU、內存、硬盤、etc.
網絡條件：100M
操作系統：Linux core: 2.6
當并發數為10用戶時，系統應能在20ms內響應完畢（這個時候的TPS為500），系統的load需在2以下；當并發數為100用戶時，系統應能在50ms內響應完畢（這個時候的TPS為2000），系統的load需在4以下；當并發數為200用戶時，系統應能在80ms內響應完畢（這個時候的TPS為2500），允許其中有千分之一的出錯率，系統的load需在6以下，在壓力測試的過程中，只要其中的任何指標未達到，均可判定系統尚未達到壓力的目標。
實際的壓力測試的這個指標會比我這里舉的例子復雜很多，例如還需要考慮網絡流量、內存消耗、IOPS、連接數等等。
這里面壓力測試隱藏的目標是為容量規劃提供一定的指導，例如目前的系統在某種配置的情況下單臺機器能承受的最大并發數為100用戶，那么如果系統的高峰壓力是1000的話，如果系統支撐無損水平擴展的話就意味著需要10臺這類配置的機器，這一步同樣是經過測試的。
2、預估系統上線運行的狀況
畢竟通常壓力測試環境和線上的環境是會有很大的不同的，壓力、數據量、硬件環境等，基本上只能是根據線下的環境的情況進行一定比例的對比后計算來預估，這里面很重要的是要預估系統上線后正常情況下的表現狀況、一定的增長比率后的運行狀況以及風險點（例如當并發用戶數增長到多少時、系統load到多少時可能會出現問題）。
這一個目標我覺得非常難達到，但隨著經驗，我相信是可以做到的，如果能做到這種效果的話是會有很大的幫助的。
以上這個兩個目標基本是壓力測試都要達到或希望達到的，而具體有可能會因為系統的業務的具體情況會制定其他不同的目標。
制定壓力測試方案
這步是壓力測試整個過程中最難的步驟之一，為了能夠測試出系統是否符合壓力支撐的要求以及評估上線的表現，通常我們會希望搭建出和生產環境完全相同的環境，但這就是最麻煩的一點了，基本上是不太可能的，因此通常能采取的方法會是：
1、做等比例的縮放
按照生產環境的情況做一定比例的縮放，例如生產環境的數據量為1億條，那么測試環境等比縮放到5000w條，生產環境的處理速度的情況...；
2、更差環境、更高壓力的測試
采取比生產環境更差的機器配置、網絡環境來進行測試，例如ebay的要求是能夠承受10x的壓力。
3、仿真測試
據資深人士而言，仿真測試要做到基本是不太可能的，仿真測試首先要求的是收集到生產環境中的運行狀態的數據，然后在測試環境中編寫程序來做到模擬生產環境運行的效果，這個難度基本是非常高的。
我自己現在做壓力測試更多采取的做法是以上三種方法的合集。
在確定了測試方法后，就基本可以確定壓力測試的環境了，環境確定好后需要做的是壓力測試的案例或場景了，在壓力測試的案例中需要涵蓋正常場景以及異常的場景，正常場景是非常容易做出來的，只是需要根據生產環境收集的數據（例如不同級別的用戶比例通常是7:2:1）或預估的數據來搭建相應的測試案例，異常場景則是比較復雜的，需要考慮很多的因素，例如數據庫出現異常、網絡出現異常等，這里我覺得通常的做法是畫出正常場景的處理流程，然后劃分交互邊界的信任邊界，對于所有的第三方交互都認為是不可信任，例如不能信任調用數據庫是一定會快的，或一定會成功的，在異常場景中應涵蓋這些信任邊界的異常狀況的測試，這些對于高可用性的系統而言是非常重要的，幾個9的成敗就在此了，^_^，當然，高可用性又是個更復雜的話題，不在這里講。
在壓力測試方案中還需確定的是考評的指標，通過會包括：tps、系統load等等。
進行壓力測試
相對來講，在有了壓力測試方案后，這一步并不是什么太復雜的事情，只是需要選擇一個和壓力測試方案比較符合的工具來執行，例如jmeter、loadrunner等，當然，這些工具相對來說也是比較復雜的，而且之間的差距也是比較大的，至少目前來看，jmeter和loadrunner的差距還是不小的，尤其是需要進行高壓力的測試時。
分析壓力測試結果
這步同樣是壓力測試中很難的一步，在這一步需要做出的根據壓力測試的結果分析出系統的具體表現情況，判定系統是否能夠滿足壓力指標。
以loadrunner產生的分析結果圖而言，通常需要分析以下圖：
1、Total Transactions per Second
這張圖中顯示了系統在進行壓力測試過程的TPS的變化情況，從這張圖中我們可以看到系統的TPS的情況，通常來講，隨著用戶數的增加，TPS應該是呈一定比率的增長的，等增長到一定程度后會達到瓶頸，甚至開始下降，這也是TPS的瓶頸值了，這張圖可以幫助我們評估系統的TPS是否符合要求。
另外，在這張圖中，我們可以看到系統從什么時候開始出現出錯的transactions，從而判斷出錯率是否在可接受的范圍。
2、Transaction Response Time Under Load
這張圖非常的重要，借助這張圖我們可以分析隨著用戶數增加的情況下，系統的劣化狀況，最佳狀況當然是一條直線，但這基本是不可能的，畢竟資源是有限的，需要判斷的是劣化的程度是否為可接受范疇。
另外就是需要關注數據中90%的用戶的響應時間的狀況，如果少量用戶響應慢是可接受的話，那么有可能在之上指標不達標的情況下仍然滿足了壓力指標。
3、Unix Resources
這張系統load圖自然是非常的重要，借助這張圖大致可以判斷系統隨著用戶數的增長消耗的資源的變化情況，這對于調優以及容量規劃而言是很重要的，但還是得取決于應用本身，:)。
loadrunner還提供了其他方面很多的圖，可以根據考評的要求來自行進行分析。
尋找瓶頸并進行調優以達到目標
這步不屬于壓力測試范疇，但還是在這里稍微講講，畢竟壓力測試結束后如果系統沒達標的話就必須進行這步了。
尋找瓶頸，這自然是非常難的事了，通常系統達不到要求的狀況都會是隨著用戶的增長，響應時間劣化的過于厲害，在這樣的情況下首先得觀察系統硬件資源的變化情況，如果是硬件資源耗盡的話，需要查查為什么資源被耗盡，假設最后判斷確實需要耗費這么多的硬件資源的話，也許需要考慮增加硬件資源或是水平擴展，否則的話可能需要從軟件層面相應的優化系統了，這樣的話可以進入下一步了。
如果不是硬件資源的限制的話，得在系統中從頭到尾設置時間跟蹤filter，從而判斷響應時間劣化的原因，看看是系統中哪些步驟造成的，這個是細致活了，有可能要查非常久。
其實這里說的還是相當的簡單了，在尋找瓶頸的過程中是個非常繁瑣的過程，需要不斷的嘗試，硬件的增加、OS的調優、jvm的調優以及軟件系統本身的調優等等，這些很多時候需要的是經驗，因此某知名人士曾經說過如何尋找瓶頸和調優，其中依靠的一點就是直覺，^_^。
當然，在尋找瓶頸的過程中，可以借助os的工具、java的工具（例如gc打印、jprofiler等）來進行查找。
（ps: 不過感覺很多情況下都是應用本身造成的性能瓶頸，在寫程序時稍不注意用錯一個數據結構都有可能會導致比較大的問題，所以我現在查找瓶頸的時候更多的還是先從軟件本身下手，只是軟件性能要做到提升通常來付出較大的代價，這個時候需要權衡）
調優基本上要求對硬件、OS、JDK、數據庫甚至軟件的實現方式等都要有非常深入的理解，至少要能做到判斷出瓶頸因素，然后找相應領域的專家來解決，因此要求是非常高的。
關于性能調優的知識體系這里有篇不錯的文章：
http://www.cnblogs.com/jackei/archive/2008/06/27/1231307.html
話題太大了，寫到最后發現基本上還是有些泛泛而談了，后面會針對這里的每一步來做更為細致的實例的講述吧，不過畢竟是外行人，肯定有很多不對的地方，歡迎大家指正、拍磚。