明確壓力測試的目標
通常來說（注意是通常），壓力測試的目標有這么幾點：
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的差距還是不小的，尤其是需要進行高壓力的測試時。
文章來源于領測軟件測試網 http://www.kjueaiud.com/