所謂制定性能測試規劃，并不單純隻是整理出一篇指導文檔，而應深入考量以確定能夠通過最少的執行步驟回答關于系統性能的種種問題。
首先，我們有必要了解測試結果需要用于回答哪些問題。以下是部分常見示例：
壓力測試：系統能夠承受且提供可接受使用者體驗的最大并發使用者數量是多少？拐點在哪裡？
負載測試：在目前系統負載場景下，應用程式表現如何？是否能夠實作進一步改善？
持久性測試：在運作一段時間後，系統工作效果如何？（有時我們需要每晚重新開機伺服器，直到找出解決性能逐漸下降的根本原因。）
峰值測試：如果正常運作的系統被突如其來的峰值壓垮，我們需要多長時間才能完成系統恢複？
另外，在性能測試規劃當中，我們還應當對自身能力進行考量：
團隊是否準備好應對此類突發狀況？或者還需要進行額外教育訓練？
我們能夠以怎樣的速度找到性能問題的解決辦法？
我們已經具備哪些實體資源？不具備的部分存在怎樣的擷取難度？
帶着這些問題，我們即可有針對性地對系統進行審查，并思考如何加以改進。
為了控制篇幅，今天我們隻專注于其中一項議題：在明确了預期負載後，我們該如何運作準确的對應負載場景？
性能測試規劃：并發使用者數量
這裡需要再次強調：我們無法在測試起步時即模拟全部并發使用者。在這種情況下，一定會同時出現多種問題，而我們很難弄清其真正根源。是以大家應當以疊代方式不斷提升負載強度，并在過程中觀察所出現的問題。
示例：負載測試
現在，我們假定需要測試目前系統能否支援1000名并發使用者。
1.首測：1使用者，無并發。我們将此作為基準，當然大家也可以選擇5使用者或者10使用者，但請確定具體數字遠低于預期水準。
2.二測：200并發使用者（或者預期負載的20%）。現在我們将能夠得到大量資訊，其将最終決定測試過程是否順利。
在初始測試時，我們首先解決重要問題與預設配置（連接配接池數或者java堆大小等），借此了解如何将響應時間與基準水準進行比較。在分析與故障排查完成後，我們再次重複這一測試，直到得出可接受的時間。
根據實際結果，我們考慮在第三次測試中使用40%負載強度（以20%作為基礎增量）還是50%（接下來為75%和100%）進行實驗。無論如何選擇，我們都能在過程中了解到系統的響應時間變化，并掌握其随負載提升所産生的變化。
在本示例中，我們将20%作為增量。另外，我們會重複測試直到在各種負載強度下達到符合預期的sla，之後再進行新一輪增量。
示例：壓力測試
在第二項示例中，我們希望利用壓力測試找到系統的性能拐點。這意味着我們要增加使用者數量并分析其是否會同步帶來通量增加。一旦并發量增加但通量不變，則意味着我們到達了拐點，這時系統已經達到飽和狀态。
這裡我們最好采取所謂探索性能測試，即假設拐點一定存在于1000并發使用者以内的區間。
目前各類負載模拟工具皆可随時間推移進行負載量提升，例如在開始測試時為0并發使用者，到1小時時則為1000并發使用者。如此一來，我們即可觀察系統通量何時發生下降。假設拐點出現在約650并發使用者，則我們可以進一步細化以确定準确的拐點位置。
示例：持久性測試
在持久性測試中，我們在可接受條件下運作一項恒定負載，例如在最大容量的50%到70%之間。當然，具體情況視您的實際系統場景而定。
一般來講，此類測試應在壓力或負載測試之後進行，用以發現其它類型的問題（例如記憶體洩漏與挂起連接配接等）。如果有時間，大家可以延長測試周期以發現更多問題。
示例：峰值測試
正如之前提到，峰值測試的意義在于了解系統能夠以怎樣的速度實作恢複。在這裡，我們可以嘗試設定1分鐘的流量峰值，而後降低負載，觀察系統能否正确響應或者将請求暫時挂起。
當然，大家也可以先嘗試建立小型峰值，而後再逐漸加大強度以研究系統的實際反應。需要強調的是，相關模拟請盡可能與使用者行為的分析結論相對應，特别是基于相關日志資訊。
總結
性能測試規劃的具體設計取決于您希望從中回答的實際問題，但其共同點在于，我們需要盡可能減少測試次數、優化測試成本并提升收益。是以，疊代式增量（用于負載、持久性與峰值測試）以及細粒度（用于壓力測試）方法無疑值得大家加以嘗試。
作者：核子可樂譯
來源：51cto