相信我們進行性能測試的時候，都遇到過這樣的問題：
1、你的性能測試方案是什么樣的？
2、我們現在系統整體性能狀況如何？
3、為什么你會設計這樣的方案（如並發、迭代、思考時間、各項指標）
4、你設計的這個方案假使過了，能保證生產環境不出問題嗎？
很難回答，是吧。因為你很難知道你的這個方案是否真的能符合實際情況，即滿足生產環境實際的情況。
如果我們真的能通過預測來滿足每一次性能測試，歷史上也就不會出現那么多著名的因為性能無法承載而宕機的事情了。
基於問題，我們發現，其實並不一定是我們設計的方案不對，而是我們很難真實預測生產環境實際的情況，那么我們應該怎么做呢？
目前最主流的性能測試（針對系統承載）無非就兩種：
1、基於目標分析、場景分析后的傳統性能測試；
2、基於流量回放的全鏈路性能測試；
那么這兩種性能測試具體適合什么場景？我們應該怎么將它們兩個結合以便取得更好的效果，從而真正保證系統的性能和穩定性？我們可以一起來看看。
一、基於目標分析、場景分析后的傳統性能測試
適合場景：
1、從0 - 1的構建項目；
2、用戶量少，流量回放所收集到的用戶請求量少，涉及系統面廣度不足；
3、部分項目類型有一段時間內承載量提升巨大的可能，如電商，在一段時間內進行大促，此時流量就和之前經驗不一樣了。
詳細分析：
假定我們現在做的是新項目，還沒有上線，怎么做到基於流量回放的性能測試呢？所以，此時我們就需要用傳統的性能測試手段，從需求分析、目標確定、方案確定、用例編寫、測試執行、性能問題、性能調優、測試執行。經歷一整套的性能測試流程，完整后上線。
這里面如果有人問，說：你們這個還是按照設想來設計的，怎么具體保證？沒錯啊，誰知道未來能發生的事情，所以大部分的這種階段下的性能測試，我個人都會將目標設定的稍微高出原本的既定目標。高出太多也不行，承載不住，經常失敗，耽誤時間。
那么我們說說如何有效的獲取測試數據，不管是功能還是性能，或者其他性能測試，獲取測試數據的大致方式無外乎3種：
1、項目已經上線，可以基於實際情況分析獲取准確的數據；
2、項目未上線，但是有可以對標的參照，獲取對標物的數據；
3、項目未上線，而且也無可參考，那么就只能基於需求、基於用戶自己構造數據了；
所以，在上述這樣的情況下，我們就適合使用傳統的性能測試來保證系統上線一段時間段內的穩定性。
發布后，盡快完成流量回放及生產環境的監控，便於獲取更加准確的用戶數據。
二、基於流量回放的全鏈路性能測試
適合場景：
1、項目已經發布；
2、用戶量已經成規模，且用戶類型已經成型（這部分指的是，如果我們的系統針對不同的類型有不同的場景提供，那么單一類型量的增加，可能造成無法全面覆蓋）；
3、已經落地流量回放並且是一定時間以上的流量收集（流量收集的時間長短，將極大的影響覆蓋面的廣度是否足夠）。
詳細分析：
假定我們的項目已經上線運作一段時間，且用戶量已經取得不錯的成效，那么面對未來可能的增長，或者成倍數的增長，此時最簡單有效，也是最節省人力的就是流量回放了。
獲取一段時間內的生產環境的實際流量，在測試環境中2倍，3倍甚至5倍的進行擴展，來觀察系統是否足以支撐，這樣的性能測試，是最“真實”的。
當然，這里面我們要注意一個問題，就是某一段時間內的流量回放代表的是當時的情況，以我們上文中說的電商大促，此時的流量回放就會不足以應付情況，那么還是要進行適當的傳統性能測試來保證整體質量。
其次，流量回放本身帶給我們的不僅僅是性能的測試，當然還有功能上的，甚至“流量回放+傳統接口測試”，也共同保證了接口層面的整體質量，非常有效。
最后，再補充下性能測試的幾點注意事項：
1、性能調優及后續的性能測試，要保證測試環境、數據和之前性能測試相同，避免因這個原因導致出現不同的情況，從而影響分析的有效性；
2、傳統性能測試和流量回放的性能測試，都應該進行數據的妥善保管，從而有效的重復利用；
3、不管是哪種性能測試手段，性能測試人員都應該加強性能測試的整體能力。包括：問題定位、性能分析、場景分析、數據分析等等。
需要學習資料的小伙伴可以加我的QQ群:747981058備注好信息，小號勿擾。