性能測試中如何設計真實的負載呢？
性能測試中有一個很重要的環節，那便是設計良好的負載。對於許多互聯網企業，都採用緩存架構，那麼對於這類型的測試，或者說運行時間越久，性能越好的應用，該如何模擬真實的負載呢？
或者換個方式，您在性能測試中，如何去模擬真實的負載，非思考時間類的。
性能測試模擬真實負載是比較困難的。性能測試與真實環境的對比，通常有這樣一些點：
1.客戶端展現。如果是Web應用，客戶端使用瀏覽器展現的，則一些的壓力測試工具都不具備展現的功能，也就是說，只是模擬發送http請求到接收請求，而瀏覽器對html內容進行渲染的時間，是無法模擬的，這很可能是真實環境體驗現測試結果不相同的地方。客戶端展現要與真實環境相同，必須單獨進行前端性能的分析。
2.網路速率。性能測試時通常在區域網環境中，而真實的網路用戶來自於全國甚至世界各地，其網路情況不一致，而且有很大的偶然性。除了對壓測工具所在的機器進行一些網路限速之外，很難完全模擬到真實的網路負載情況。
3.軟硬體配置。軟體配置比較容易做到與真實環境一致，但硬體配置通常比較難做到。像線上使用的一些負載均衡機器或者路由設備比較昂貴，不可能在測試環境採用完全一樣的拓撲和集群，當然這些對測試結果影響通常可以分析到，不會有很大偏差，但這是一個無法完全與線上保持相同的點。
4.數據分布。數據分布要做到與線上一致有3個難點，1是對新應用而言，根本沒有線上數據，因此無從模擬，只能手動造數據，所以無法跟線上一致；2是即使是老的功能，線上數據因為商業機密等原因也未必能直接拿來作為測試數據；3是用戶的訪問路徑，這點很難與線上做到一致。功能測試尚不能覆蓋掉所有的用戶操作路徑，何況性能測試？
以上四點，都是問題。因此性能測試很多情況下只能作為參考，用來發現明顯的性能問題。如果要做到100的準確，還是要做線上的即時監控才行。
這裡介紹一下之前一次對騰訊某直播APP的測試經驗。
直播類的應用對於伺服器的要求要高過一般的應用，直播類的應用對伺服器有這些挑戰。
1、更大的數據量
視頻數據和文本數據完全是兩個量級的概念，假設一個直播房間有5000人，視頻1s的數據60K，那麼就需要5000*60=300000KB=292.97MB，基本已經達到了2-3三個手游的大小了，而這只是一個房間產生的流量。今年4月劉濤入駐直播領域，創造了同時在線人數17萬，總收看人數71萬的數據，如果按照這個數量，伺服器就會產生9.73Gbps的帶寬，而當前某著名網路直播APP日活躍用戶超過了800W，伺服器將承受458Gbps的帶寬壓力，
2、更高的並發量
不同於普通應用和遊戲，直播類應用的使用時間段非常的集中，一般來說，社交類的直播app時間集中在晚飯後時間至睡前20點~23點，遊戲類App活躍時間集中在下班後18~20點間，秀場類App集中在13點和18(午休及下班時間)，因此在這短短几小時之間，會湧入大量的用戶，一次大V的直播通常就會造成百萬級的用戶登錄，APP需要有詳盡的限流、分流和負載均衡策略，保證伺服器不會被衝垮。
3、更真實的用戶登錄場景
直播應用與普通應用相比，交互的功能異常多，除了直播視頻流的伺服器壓力之外，還要包括用戶消息推送、聊天、禮物、支付以及統計系統帶來的數據交互壓力，伺服器進行需要識別不同的業務欄位，才能精確判定用戶的行為是否成功完成，從交互頻率的角度上來說，直播類的應用，與其說更像應用，不如說更像遊戲。
4、更低的延遲
直播需要一個很強的即時性，如果主播的行為和用戶的評論無法同步的時候，會給用戶非常不好的體驗，如果一個用戶發現其他用戶在歡呼鼓掌，但是屏幕中的主播什麼動靜都沒有的時候，這個直播應用基本可以不要再用了，因此直播類應用不僅需要面對更大的數據量和更高的並發，還要保證更低的延遲。通常可以要保證伺服器的處理數據速度要快，要有足夠強大的帶寬；另外則是通過P2P演算法保證數據分享的合理性，保證伺服器的數據和P2P的數據可以達到平衡。
直播前的伺服器準備
直播應用下的伺服器成本，與將要承受的流量情況息息相關，不同的直播應用，交互的頻度、深度不同，就會產生不同的帶寬壓力。我們一起來算一筆帳，為直播應用準備伺服器，大概需要多少錢？
首先，我們要買一個伺服器。買多大的伺服器呢？伺服器的帶寬要滿足直播應用的帶寬需求，
在這裡，科普一下帶寬是怎麼看的：
帶寬通常使用的單位是bps（bits per second），8 bits通常等於1Byte，100Mbps在換算成我們熟悉的文件大小的時候，要除以8，也就是在100Mbps的帶寬下，每秒鐘可以下載12.5MB的文件，那麼一般來說，直播應用需要多少帶寬呢？見下圖：
直播應用一般使用的解析度是360p，720p以及1080p三種，為了看得清晰一些，一般人們都會選擇720p，那麼在720p的清晰度下，直播應用需要1024kbps的帶寬，也就是每秒傳遞的數據大小為1024/8=128KB。簡單來說，如果在APP中打開直播，使用了720p的解析度，一個用戶每秒鐘需要傳輸128KB的數據（當然實際情況中直播應用還有消息推送，送禮，支付等行為，直播畫面解析度、壓縮比等區別，實際會消耗更多的數據）。
那麼，直播類應用現在需要承載多少用戶呢？
以目前最紅火的幾大直播平台為例，鬥魚 TV 的在線人數可以超過1000 萬，戰旗 TV 在在線人數約500 萬左右，龍珠在線人數約 400 萬左右，虎牙在線人數約100萬，直播平台的帶寬成本通常是帶寬峰值月結的形式，如果當月最高同時在線人數是200W，也就是每秒要傳輸的數據量高達244GB，那麼理論上消耗的帶寬就是2T左右，一個月的開銷就在4000W人民幣左右。
對於直播應用來說，伺服器最難處理的環節就是視頻流量和用戶交互等高頻率高帶寬的場景，用戶的行為是難以預測的，經常會出現突發性的暴漲，一般在進行活動的時候，流量可能是平時的幾十倍。2016年7月11日，PAPI醬的一次直播帶來了超過2000W用戶的訪問，這對於大多數的直播應用來說，伺服器的成本都是難以承擔的。這也是為什麼越來越多的直播應用開始尋求雲伺服器的支持，目前的雲服務商有騰訊雲，阿里雲，百度雲，金山雲等，彼此之間在硬體上的類型差別越來越小。
因此直播應用在上線前需要對多樣化的用戶操作進行針對性的測試，註冊，聊天，禮物，支付等行為都需要進行不同介面的測試。
這時候，利用市場上現有的壓測平台是一個非常好的選擇。騰訊的WeTest團隊WeTest伺服器性能|壓力|負載測試 高並發，實時性能報表，專家級性能優化建議【騰訊WeTest】就在做伺服器性能測試的產品，下面簡單介紹一下團隊在這次測試中做的事情。
測試的思路
一般來說，對於活動中的功能節點，測試過程中通常關注兩點：
1、 單介面壓測，提前暴露核心模塊的問題
2、 多介面架構問題，場景壓測盡量模擬真實用戶行為，使得壓測結果更有說服力
測試的執行
1、單介面壓測——步步為營，逐漸迭代
單介面壓測的原理很簡單，就是不斷的對某個功能介面不斷加壓，直到發現出現問題的那個極限就可以，在WeTest伺服器性能測試上，操作如下：
1）點擊壓測產品首頁中的快捷入口：HTTP直壓。模式選擇簡單模式，名稱和描述可以自己填寫。（圖中示例起始人數50人，每隔60秒增加50人，加到200人為上限）
2）新建一個客戶端請求，介面壓測包括讀寫介面，讀介面基本是GET請求，寫介面基本是POST請求。GET請求使用url請求參數，POST請求使用x-www-form-urlencoded方式傳遞參數，在這裡方法選擇GET，填寫想要測試的URL。
3）編輯一下測試模型，增加一個場景名，單介面測試只測試一個功能介面，因此模式選擇「單場景」，壓力百分比設置為100%。
通過這樣的壓測方式，不斷增加伺服器壓力，直到找到瓶頸位置，騰訊WeTest為該直播APP實現了2W/s的並發量，滿足了其並發需求。
2、多介面壓測——真實模擬，定位問題
多介面壓測的主要邏輯，就是通過構建不同的功能介面，模擬用戶的真實行為，從而幫助開發者定位介面問題。
該直播的測試方式是通過GET請求調用一個功能介面，通過這個功能介面隨機產生不同行為邏輯的機器人，模擬真實的QQ用戶，然後通過POST請求執行具體的業務行為，從而發現功能之間會產生的邏輯問題。該直播測試團隊讀介面基本是GET請求，寫介面基本是POST請求。GET請求使用url請求參數，POST請求使用x-www-form-urlencoded方式傳遞參數
在騰訊WeTest伺服器性能測試上，我們可以進行如下操作：
1）首先，通過GET請求，讀取一個用戶的「登陸態」，通過這個功能介面隨機產生不同行為邏輯的機器人，模擬真實的QQ用戶；然後通過POST請求依次執行具體的業務行為，從而發現功能之間產生的邏輯問題。
2）在測試場景中輸入場景名，該直播測試的是「登錄-進入房間-點贊」這樣三個操作，然後「模式」選擇「上下文」，點擊「壓測場景」，選擇調用不同的功能介面。
目前騰訊WeTest伺服器性能測試支持了同時接入8個場景，更多的場景也可以更貼近的模擬真實用戶的行為場景。
可以嘗試一下。鏈接如下：
WeTest伺服器性能|壓力|負載測試 高並發，實時性能報表，專家級性能優化建議【騰訊WeTest】
學會把複雜的業務分成若干個小的流程或功能點，有針對性的進行測試。
絕對真實的場景不是模擬出來的測試不可能跟真實一樣，貼近即可。重要的是測試結果要有意義，不要壓力不夠，也不要壓力過度超過了最高的性能要求。通常測試麻煩在覆蓋足夠多種用例，還有用例之間比例恰當。加壓力沒它複雜，跟據需要増加就行了。
有時候要設計一些特殊場景比如緩存未載入或突然失效，看看這時候能不能抗住期望的壓力。不行的話再想想如何避免這樣場景或改善這樣場景下的抗壓能力。
具體改如何設計和實施整個過程呢？這裡劃分了幾個環節：
［1］場景確定與壓測腳本準備
用戶在註冊時需要提交用戶的姓名、手機號和手機驗證碼，之後提交申請即可，所以實際上用戶申請註冊只調用了一個API介面來完成（介面地址：http://www.此處馬賽克.com/api_11.php?m=Usera=updataUserInfo），這是一個比較簡單的場景。
［2］施壓模式
既然是容量探測，所以我們整體的施壓過程是一個梯度漸進的過程，一般不會上來就是一條直線。
［3］壓測點分布
傳統壓力測試工具主要在內網中產生壓力，壓力的規模受限於物理機器及License數量，造成準備周期過長及成本過高等問題。而雲壓測提供可靠的分散式壓測伺服器（壓測點），充分利用雲端的計算資源，從而突破了這個限制。
壓測點就是發起壓力的主機，因為使用了雲服務的雲主機（AWS、Ucloud和阿里雲）以及雲智慧部署在全國IDC核心機房的伺服器，所以我們做到了基本的全國覆蓋
［4］壓測時間設定
如果是用戶線上的系統，根據系統訪問的情況，一般我們會建議用戶在凌晨進行壓測，此時能夠保證對用戶的影響最小，也能保證正常用戶訪問導致對壓測結果的干擾最小。
［5］壓測數據分析
在基本的參數確定之後，我們就可用根據事先預定的時間來執行壓測任務了，雲壓測能夠進行秒級的數據採集和實時統計分析、能夠隨時調整壓力。隨著壓力的逐步上升，能夠動態呈現系統的性能數據。在逐步加壓的過程中，如果性能急劇下降或大量出錯，就沒有必要繼續執行壓測任務。此時可以終止任務，也可以下調壓力，確保對整個壓測過程的把控。執行測試任務時，為測試腳本準備的大量模擬數據，這些數據與腳本中的變數關聯，能夠在某個時段內產生盡量真實的測試結果。在壓測寶網站Web/APP性能測試、壓力測試工具 可以方便得通過導入excel文件來創建測試數據
直到來到知乎上，才知道，自己所做的性能測試是怎麼一回事，在我們的項目中，從來沒有涉及到關於緩存架構這樣的考慮，但在開始創立我們這個項目組的時候，一定會有這方面的一個解釋，到現在為止，做過的一些項目，我們都會有一個最高壓力的要求。
推薦閱讀：