流量測試＋傳統性能測試，幫你高效保證系統質量

首先，這是一篇沒有圖片的文章。。。

相信我們進行性能測試的時候，都遇到過這樣的問題：

1.你的性能測試方案是什麼樣的？

2.我們現在系統整體的性能狀況如何

3.為什麼你會設計這樣的方案（如並發、迭代、思考時間、各種指標）

4.你設計的這個方案假使過了，能保證生產不能出問題么？

很難回答，是吧。因為你很難知道你這個方案是否真的能符合實際情況，就是滿足了生產環境實際的情況。

如果我們真的能通過預測來滿足每一次性能測試，歷史上也就不會出現那麼多著名的因為性能無法承載而宕機的事情了。

基於問題，我們發現，這個其實並不一定是我們設計的方案不對，而是我們就很難真實預測生產環境實際的情況，那麼我們應該怎麼做。

目前最主流的性能測試（針對系統承載）無非就兩種：

1.基於目標分析、場景分析後的傳統性能測試

2.基於流量回放的全鏈路性能測試

那麼這2種性能測試具體適合什麼場景？我們應該怎麼將他們2個結合以便取得更好的效果，從而真正保證系統的性能和穩定性。我們可以一起來看看。

基於目標分析、場景分析後的傳統性能測試

適合場景：

1.從0 - 1的構建項目

2.用戶量少，流量回放所收集到的用戶請求量少，涉及系統面廣度不足

3.部分項目類型有一段時間內承載量提升巨大的可能，如電商，在一段時間內進行大促，此時流量就和之前經驗已經不一樣

詳細分析：

假定我們現在做的是新項目，還沒有上線，我們怎麼做到基於流量回放的性能測試呢？所以，此時我們就需要用傳統的性能測試手段，從需求分析、目標確定、方案確定、用例編寫、測試執行、性能問題、性能調優、測試執行。經歷一整套的性能測試流程，完整後上線。

這裡面如果有人問，說：你們這個還是按照設想來設計的，怎麼具體保證？沒錯啊，誰知道未來能發生的事情，所以大部分的這種階段下的性能測試，我個人都會將目標設定的稍微高出原本的既定目標。高出太多也不行，承載不住，經常失敗，耽誤時間。

那麼我們說說如何有效的獲取測試數據，不管是功能還是性能，或者其他性能測試，獲取測試數據的大致方式無外乎3種：

1.項目已經上線，可以基於實際情況分析獲取準確的數據

2.項目未上線，但是有可以對標的參照，獲取對標物的數據

3.項目未上線，而且也無可參考，那麼就只能基於需求、基於用戶自己構造數據了

所以，在上述這樣的情況下，我們就適合使用傳統的性能測試來保證系統上線一段時間斷內的穩定性。

發布後，儘快完成流量回放及生產環境監控的建立，便於獲取更加準確的用戶數據。

基於流量回放的全鏈路性能測試

適合場景：

1.項目已經發布

2.用戶量已經成規模，且用戶類型已經成型（這部分指的是，如果我們的系統針對不同的類型有不同的場景提供，那麼單一類型量的增加，可能造成無法全面覆蓋）

3.已經落地流量回放並且是一定時間以上的流量收集（流量收集的時間長短，將極大的影響覆蓋面的廣度是否足夠）

詳細分析：

假定我們的項目已經上線運作一段時間，且用戶量已經取得不錯的成效，那麼面對未來可能的增長，或者成倍數的層長，此時最簡單有效，也是最節省人力的就是流量回放了。

獲取一段時間內的生產環境的實際流量，在測試環境中2倍，3倍甚至5倍的進行擴展，來觀察系統是否足以支撐，這樣的性能測試，是最「真實」的。

當然，這裡面我們要注意一個問題，就是某一段時間內的流量回放代表的是當時的情況，以我們上文中說的電商大促，此時的流量回放就會不足以應付情況，那麼還是要進行適當的傳統性能測試來保證整體質量。

其次，流量回放本身帶給我們的不僅僅是性能的測試，當然還有功能上的，甚至流量回放 + 傳統介面測試，也共同保證了介面層面的整體質量，非常有效。

最後，再補充下性能測試的幾點注意事項：

1.性能調優及後續的性能測試，要保證測試環境、數據和之前性能測試相同，避免因這個原因導致出現不同的情況，從而影響分析的有效性

2.傳統性能測試和流量回放的性能測試，都應該進行數據的妥善保管，從而有效的重複利用

3.不管是哪種性能測試手段，性能測試人員都應該加強性能測試的整體能力。包括：問題定位、性能分析、場景分析、數據分析等等

另外，由於我們整體講解的是針對系統級別或者Server級別的性能測試，前端的性能測試（Web、App）的同樣重要，這個本文中並未涉及到具體的開展思路

後續我們會針對此文，首先給大家分享下，傳統性能測試下的數據收集，更加適用於我們項目已經上線，但未有效建立起流量回放（這並不是測試一個部門的事情）下時，我們如何做

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！