軟件壓力測試是一種基本的質量保證行為，它是每個重要軟件測試工作的一部分。軟件壓力測試的基本思路很簡單： 不是在常規條件下運行手動或自動測試，而是在計算機數量較少或系統資源匱乏的條件下運行測試。 通常要進行軟件壓力測試的資源包括內部內存、CPU 可用性、磁盤空間和網絡帶寬。壓力測試涵蓋，性能測試，負載測試，并發測試等等，這些測試點常常交織耦合在一起。

壓力測試中存在的問題

(What) 什么是壓力測試

軟件壓力測試是一種基本的質量保證行為，它是每個重要軟件測試工作的一部分。軟件壓力測試的基本思路很簡單： 不是在常規條件下運行手動或自動測試，而是在計算機數量較少或系統資源匱乏的條件下運行測試。 通常要進行軟件壓力測試的資源包括內部內存、CPU 可用性、磁盤空間和網絡帶寬。

壓力測試涵蓋，性能測試，負載測試，并發測試等等，這些測試點常常交織耦合在一起。

壓力測試存在那些問題

我歸納一下又幾點：

1. 操作系統默認安裝，在未做任何優化的情況下實施壓力測試
2. 未考慮磁盤IO對軟件的影響
3. 未考慮網絡帶寬對軟件的影響
4. 網絡軟件測試，沒有考慮到TCP特點
5. 各種超時參數優化
6. 測試客戶端未優化
7. 并發理解有誤
8. WEB服務器，數據庫，等等服務器未優化

如果上面幾項沒有做優化，壓力測試數據基本沒有任何參考價值，任何一項沒有優化，都會導致你的壓力測試數據出現偏差。 下面我來逐條說明：

1. 操作系統問題 操作系統是大眾化軟件，出廠優化都是面向大眾，不可能為某個領域做單獨優化。所以我們第一步需要優化操作系統。 Linux 系統優化內核參數，Windows 系統優化注冊表等等。

2. 磁盤IO 這是最容易出現瓶頸的地方，常常是CPU還沒有達到極限，磁盤已經不堪重負。

3. 網絡IO 與磁盤IO相同

4. TCP連接 幾乎所有 B/S, C/S 軟件都是采用多線程，或者多進程技術。這種技術有個特點，開發者將程序設計為線程可自動伸縮模式，開啟進程后會啟動少量線程，當連接不斷提高后，線程數逐漸增加，隨著線程運行結束后，線程逐漸減少。 這樣的設計會更有效地利用硬件資源，在程序空閑時將硬件資源讓給其他進程。少有軟件設計為開啟服務獨占資源。 這樣測試軟件做壓力測試，不能一次并發很多請求，而是要采用逐漸增加的方式，否則第一次測試會有一部們并發不能及時響應，導致測試數據偏差。另外也你可以多做幾次壓力請求（讓多線程工作起來），從第三次開始記錄測試數據，忽律前面兩次的測試數據。

提示：另一個問題是TCP連接復用，這也是一個重要配置想。如果這項沒有配置，我想測試出的數據也會有偏差

1. 超時參數 超時參數在壓力測試中是非常重要的參數，例如從WEB到數據庫連接超時是60秒，如果有一個SQL查詢超過300秒，那么后面的請求會持續排隊等待，當連接數達到數據庫的最大連接時，接下來的所有請求都是失敗的。 通常我們的WEB服務器超時不會超過30秒，有時我設置為10秒，一旦出現超時，寧可讓該連接Timeout，不要讓他影響整體服務。

2. 客戶端 很多網絡軟件需要從客戶端發出壓力測試請求，所以客戶端的優化也是必須的，否則客戶端壓力出不去，服務端壓力進不來。

3. 并發 很多人認為并發，就是同一時間內的最大連接數，這是錯誤的。如果你寫過多線程程序，就會發現多線程運行時又規律的。是順序排隊運行的，根本不是同時運行的。 所以并發是指，相對時間內能完成的連接總和，例如，每秒并發，每分鐘并發等等，通常我們已秒為單位。 我們目前使用的操作系統叫分時操作系統，這種系統的特點就是可能實現多用戶，多任務。操作系統將進程排隊（優先級）輪詢運行，只不過這個操作太快了，使你認為多個進程在同時運行。

4. 服務器優化 主要B/S軟件壓力測試，WEB，緩存，數據庫等等服務器，都需要逐一優化到最佳狀態

(Why) 為什么做壓力測試

如果在軟件設計階段都將這些問題元素都考慮進去，同時開發階段嚴格執行。那么開發出些軟件幾乎不用做這個勞人傷神的壓力測試。

所以在軟件設計階段就要考慮，靈活性，擴展性，可靠性與性能，還要考慮高可用與負載均衡。

同時軟件優化伴隨開發，持續集成，持續測試，持續部署。

(Where) 在哪里做壓力測試

有些軟件需要封閉的環境測試，不能在共享資源的環境中做測試。所以你有必要做Vlan隔離，甚至獨立的路由器與交換機在封閉網絡中測試。

(When) 什么時間做壓力測試

任何時間都可能做壓力測試，為什么我將“時間”重點提出呢？目前受地球自轉影響，經常閏秒，你不的不考慮這個問題。

(Who) 壓力測試過程參與人員

1. 運維部門
2. 開發部門
3. 測試部門

(How) 如何做壓力測試

下面我們舉一些例子，講述壓力測試方法，限于篇幅不可能面面俱到，我僅僅是給你提供思路。

測試前你需要一些監控工具，事實監控服務器的資源變化。

例如 Web 服務器壓力測試，測試場景是 nginx ：

worker_processes  8;            處理器數
    worker_rlimit_nofile 65530;     允許最多打開文件數
    worker_connections  4096;       最大連接數數為
    keepalive_timeout  65;          開啟復用連接
    gzip  on;                       壓縮傳輸數據

怎么測試呢？你要活得最大化性能嗎？還是相對性能？我們通常需要的是滿足需求就好的相對性能，而不是最大化性能。為什么呢？因為要活得最大化性能是要做出很多配置犧牲的，例如關閉日志，禁止訪問時間等等。

按照上面的配置你的測試用例應該是，每次并發4000 請求 8000~10000 次， 你不能并發8000 請求 4000 這樣測試。很是很多人常常犯的錯誤，所以測試者需要連接系統的配置參數，不能盲目使用數字實驗。

上面我說過線程的開啟時隨著請求，逐漸增加的，所以首次發起測試數據是不準確的，通過pstree命令可以看到線程數量。等第三次以后線程逐漸增加到4096個，并且之前開啟的TCP可以復用，這時測試的結果比較有說服力。

延伸閱讀《Netkiller Web 手札》《Netkiller Testing 手札》《Netkiller Linux 手札》

作者

陳景峰，昵稱 Netkiller, 英文名 Neo 《Netkiller 系列 手札》電子書的作者，讀者QQ群：128659835，個人網站：http://netkiller.github.io/