壓力測試是确立系統穩定性的一種測試方法，通常在系統正常運作範圍之外進行，以考察其功能極限和隐患。與功能測試不同，壓測是以軟體響應速度為測試目标的，尤其是針對在較短時間内大量并發使用者的通路時，軟體的抗壓能力。
至于為什麼産品或業務系統在通過功能測試後還需要進行壓力測試，原因很簡單，因為它重要，為什麼重要？衆所周知，響應速度是使用者體驗的核心名額之一。 smartbear 資料表明，如果 amazon 的加載時間延長1秒，那麼一年就會減少16億美元的營收。使用者與網站互動的過程中，如果加載時間超過3秒，57% 的使用者會流失。可見，通過壓測來優化産品體驗和性能是多麼的重要。
傳統的壓測方法通常的做法需要準備大量的環境，如測試的壓力機，安裝測試工具，錄制測試腳本，對伺服器不斷施加“壓力”，通過這種方式來确定系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級别的測試，這個階段我們稱之為壓測1.0。
壓測1.0時代的主流壓測工具有 loadrunner ， silkperformer ， ratinal ， qa load ， jmeter 等等， loadrunner 為傳統壓測1.0時代最主要的代表産品。
圖1.傳統的壓測現狀
傳統的測試方法下很難去做到對整個系統去做一次大型的壓力測試，這種情況下隻能把每個系統獨立開來，對他進行性能測試，然後對整個核心系統去做分析，确定系統的短闆，對短闆進行壓力測試。
通常需要用預估的方式，業務部門估算今年的交易額，應用部門估算，網絡部門估算，基礎架構部門估算。最後的結果就是如果需要1000台伺服器，那麼就準備1500台。如果需要5 g 的 cdn 帶寬，那麼就準備7.5 g 。幾乎所有資源都多準備50%。
壓測1.0時代的壓測缺點很明顯。
測試過程緩慢，周期過長
并非聚焦于全球客戶的體驗
非常昂貴的授權費用及硬體投入
為實驗室測試而設計，對生産或線上環境無能為力
不能針對當今複雜的應用及架構提供實時的回報
基于雲計算的全鍊路壓力測試我們稱之為雲壓測，這個階段我們叫壓測2.0。雲壓測通過遍布雲端的壓力模拟伺服器，來制造“真實使用者通路”，這個過程可以覆寫到真實交易系統的全鍊路，全業務測試系統，并且革命性的使用雲資源這種輕屬性資産，對幾乎來自全世界網際網路和移動網際網路的壓力進行測試。雲壓測模拟測試完全還原真實使用者網絡通路狀況。
圖2.“雲壓測+ apm ”進入壓測2.0時代
當産生壓測需求時，我們布置在各主流雲廠商（aws、阿裡雲、azure、青雲、騰訊雲、金山雲、ucloud等等）的壓測虛機自動下發壓測腳本，進行雲端托管式部署雲端壓測機啟動，對使用者系統進行壓測。同步壓測，同步産出壓測資料。
利用雲計算優勢，當需要進行模拟大規模使用者通路時，隻要多開雲主機就能實作，需要模拟100萬的使用者通路，再開100台雲主機。
壓測2.0時代有點同樣明顯。
迅速部署
實時統計
真實世界的規模和模拟
分布式的使用者
高效且持續
除去了硬體投入
壓測1.0時代的 loadrunner vs 雲壓測
比較次元
loadrunner
雲壓測
采用技術
研發于90年代，基于c
生于21世紀，基于 java 及大資料
測試建立
需要 c 程式設計，測試門檻較高
全可視化操作，上手快
部署方式
純内網，基于實體伺服器
内外網兼顧，雲，虛機，實體機
部署時間
長，幾周或幾個月
很短，數分鐘或數小時，測試更頻繁
部署費用
昂貴，硬體，人員，時間，其他
便宜，壓側端可全雲托管，按小時分鐘計費
測試規模
小，一般不超過2000并發規模
可大可小，從100到1千萬
統計報表
很有限，非實時，依賴後期資料處理
tb級實時彙聚顯示，即測即發現問題
圖5.雲壓測 + apm 典型應用場景
與壓測1.0時代隻關注于後端性能不同，雲壓測關注前端和後端性能，從前端的不同實體位置、不同營運商鍊路、寬帶、窄帶、帶寬、 cdn 、防火牆、負載均衡，到後端的應用軟體、資料庫、硬體資源、系統配比等，雲壓測在測試環境中還原真實業務環境。
雲壓測和 apm 結合，全鍊路全業務接口壓力測試，全面覆寫前後端所有環節真正實作端到端性能優化解決方案，全方位提升使用者體驗。