【51CTO.com快譯】所謂制定性能測試規劃，并不單純只是整理出一篇指導文檔，而應深入考量以確保能夠通過最少的執行步驟回答關于系統性能的種種問題。

首先，我們有必要了解測試結果需要用于回答哪些問題。以下是部分常見示例：

• 壓力測試：系統能夠承受且提供可接受用戶體驗的***并發用戶數量是多少？拐點在哪里？
• 負載測試：在當前系統負載場景下，應用程序表現如何？是否能夠實現進一步改善？
• 持久性測試：在運行一段時間后，系統工作效果如何？（有時我們需要每晚重啟服務器，直到找出解決性能逐步下降的根本原因。）
• 峰值測試：如果正常運行的系統被突如其來的峰值壓垮，我們需要多長時間才能完成系統恢復？

另外，在性能測試規劃當中，我們還應當對自身能力進行考量：

團隊是否準備好應對此類突發狀況？或者還需要進行額外培訓？

我們能夠以怎樣的速度找到性能問題的解決辦法？

我們已經具備哪些物理資源？不具備的部分存在怎樣的獲取難度？

帶著這些問題，我們即可有針對性地對系統進行審查，并思考如何加以改進。

為了控制篇幅，今天我們只專注于其中一項議題：在明確了預期負載后，我們該如何運行準確的對應負載場景？

性能測試規劃：并發用戶數量

這里需要再次強調：我們無法在測試起步時即模擬全部并發用戶。在這種情況下，一定會同時出現多種問題，而我們很難弄清其真正根源。因此大家應當以迭代方式不斷提升負載強度，并在過程中觀察所出現的問題。

• 示例：負載測試

現在，我們假定需要測試當前系統能否支持1000名并發用戶。

1.首測：1用戶，無并發。我們將此作為基準，當然大家也可以選擇5用戶或者10用戶，但請確保具體數字遠低于預期水平。

2.二測：200并發用戶（或者預期負載的20%）。現在我們將能夠得到大量信息，其將最終決定測試過程是否順利。

在初始測試時，我們首先解決重要問題與默認配置（連接池數或者Java堆大小等），借此了解如何將響應時間與基準水平進行比較。在分析與故障排查完成后，我們再次重復這一測試，直到得出可接受的時間。

根據實際結果，我們考慮在第三次測試中使用40%負載強度（以20%作為基礎增量）還是50%（接下來為75%和100%）進行實驗。無論如何選擇，我們都能在過程中了解到系統的響應時間變化，并掌握其隨負載提升所產生的變化。

在本示例中，我們將20%作為增量。另外，我們會重復測試直到在各種負載強度下達到符合預期的SLA，之后再進行新一輪增量。

• 示例：壓力測試

在第二項示例中，我們希望利用壓力測試找到系統的性能拐點。這意味著我們要增加用戶數量并分析其是否會同步帶來通量增加。一旦并發量增加但通量不變，則意味著我們到達了拐點，這時系統已經達到飽和狀態。

這里我們***采取所謂探索性能測試，即假設拐點一定存在于1000并發用戶以內的區間。

目前各類負載模擬工具皆可隨時間推移進行負載量提升，例如在開始測試時為0并發用戶，到1小時時則為1000并發用戶。如此一來，我們即可觀察系統通量何時發生下降。假設拐點出現在約650并發用戶，則我們可以進一步細化以確定準確的拐點位置。

• 示例：持久性測試

在持久性測試中，我們在可接受條件下運行一項恒定負載，例如在***容量的50%到70%之間。當然，具體情況視您的實際系統場景而定。

一般來講，此類測試應在壓力或負載測試之后進行，用以發現其它類型的問題（例如內存泄漏與掛起連接等）。如果有時間，大家可以延長測試周期以發現更多問題。

• 示例：峰值測試

正如之前提到，峰值測試的意義在于了解系統能夠以怎樣的速度實現恢復。在這里，我們可以嘗試設置1分鐘的流量峰值，而后降低負載，觀察系統能否正確響應或者將請求暫時掛起。

當然，大家也可以先嘗試建立小型峰值，而后再逐步加大強度以研究系統的實際反應。需要強調的是，相關模擬請盡可能與用戶行為的分析結論相對應，特別是基于相關日志信息。

總結

性能測試規劃的具體設計取決于您希望從中回答的實際問題，但其共同點在于，我們需要盡可能減少測試次數、優化測試成本并提升收益。因此，迭代式增量（用于負載、持久性與峰值測試）以及細粒度（用于壓力測試）方法無疑值得大家加以嘗試。

 

原文標題：How to Make a Performance Test Plan

原文作者：Federico Toledo 

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】