《英雄聯盟》夏季賽總決賽今日開打！JDG對陣LNG首發名單來了 Knight：準備三連冠
8月5日消息，今日17:00，《英雄聯盟》2023LPL夏季賽總決賽將正式開打，由JDG對陣LNG。對兩支隊伍來說，這場比賽不僅要爭奪夏季賽冠軍，更要決定誰才是LPL賽區一
性能測試最開始的需求分析工作細致與否，與后面的性能測試結果息息相關。需求分析是一個繁雜的過程，它并非我們想象的那么簡單。做需求分析除了要對系統的業務非常了解，還需要有深厚的性能測試知識，這樣才能夠挖掘分析出真正的性能測試需求。
很多時候，性能測試的需求是比較模糊的，需要性能測試工程師去挖掘和分析。在工作中，作者經常被問到的一個問題是: 應該設置多少個JMeter線程去壓測? 還有不懂技術的客戶提出想要做性能測試，但是沒有提供指標，只說系統支持100萬用戶。這些都是我們日常工作中司空見慣的泛泛的需求
此時，我們可以通過“3步法”對產品進行正確的需求分析和用戶模型建立。
(1) 了解系統架構。首先我們需要與開發人員溝通，了解清楚系統的部署架構采用了哪些中間件、數據庫、容器、緩存等，以及它們之間的架構關系，并畫出對應的網絡拓撲圖和系統部署架構圖
(2) 了解業務模型。首先我們需要采用用戶行為分析，分析用戶使用產品的習慣，確定系統的典型業務及發生時間。很多大型系統的業務使用都有流量高峰。這類系統業務使用的流量高峰可能出現在天、一月、一年中的某個時間點上或時間段內。對于新浪、網易等門戶網站，在周一到周五的早上剛上班時，可能使用郵件系統的用戶比較多，而在中午休息時間瀏覽熱點新聞的用戶較多;對于一般的OA系統，早上閱讀公告的用戶較多，在其他時間可能沒有用戶使用系統或者僅有少量的用戶，比如秘書或領導使用系統起草和審批公文;對于電信繳費系統，在月末很可能會出現用戶集中使用繳費業務的情況。
然后是調研歷史統計數據，通過分析數據確定熱點模塊。如果產品已上線，可以統計和分析線上歷史數據。對于web類產品，我們可以獲取和分析獨立用戶數、頁面訪問量和最大在線用戶數;對于后臺類產品，則可以分析如Nginx的Access log，從而得出最大的訪問量對于數據庫類產品，我們還可以分析出熱點SQL等。如果產品未上線有同類產品參考，可以參考公司內同類產品或者同行的同類產品進行熱點模塊預估，雖然不能完全照搬，但可以根據業務增長數據進行統計分析，輸出用戶訪問熱點軌跡圖。
選取性能測試點是性能測試需求分析中非常重要的一個環節。面對一個功能繁雜的系統，要設計出有效的測試場景，最大程度上覆蓋系統的性能問題和瓶頸，需要較多的經驗積累。目前我們可以按照以下原則來進行性能測試點的選取:
(1)核心業務模塊，例如支付業務、核心算法;
(2)并發量較高的業務模塊;
(3) 邏輯較復雜的業務模塊
(4) 有復雜數據庫操作或事務的模塊;
(5) 有較頻繁的磁盤讀寫操作的模塊
然后根據不同類型的系統應用，選取的原則也可以進一步細分。
(1)依據業務數據統計中幾種典型業務的用戶使用數比例:
(2) 調用頻繁、占用空間大的數據庫表的交易，
(3) 占用最大存儲空間或其他資源的交易;
(4) 對磁盤、常駐內存的數據過度訪問的交易
(1) 讀 (查詢)、寫 (增刪改) 、讀寫 (增刪改查) 合的業務模塊;
(2)配置服務器的業務模塊；
(3)功能的實現方式，如同步和異步，輪詢和notify等:
(4) 分布式業務模塊，如單客戶端和多客戶端，單節點和多節點；
(5) 數據規模，如數據庫已存在大量記錄，存儲可用空間少:
(6)緩存，如對文件系統緩存和數據庫緩存的利用等;
(7)負載均衡，如多節點情況下是否負載均衡。
(1) 數據庫讀寫混合業務模塊;
(2) 數據庫之間數據同步
(3) SQL語句;
(4) 數據規模4
(1)單機能支撐的最大并發長連接數;
(2)并發一定數量的用戶時的消息推送情況，包括消息到達時間、消息丟失率等
梳理出來性能測試場景后，就需要進一步明確各個場景的測試指標，而大部分的產品經理給出的指標是不完整的，通常情況下可以結合采集的數據和二八定律進行具體量化，讓性能測試指標更明確。
下面舉個例子來說明性能測試指標量化方法。
例如，某互聯應用，預計推廣群體達500萬人，用戶使用應用的時間是每天早上8點至晚上8點，共12h。
（1）注冊用戶轉化率預估為5%，那么注冊用戶數為5000000x5%=250000
（2）高峰時段 (比如有活動時) 每日在線用戶活躍率預估為10%，那么活躍用戶數為250000x 10%=25000
（3）用戶常用下單到成功觸發20個請求，總請求量為25000x20=500000
（4）利用二八定律計算，得出的吞吐量為500000x0.8/(12x3600x0.2)=46.7個每秒
若是更新需求，如發布新產品，定時搶購優惠活動 (某日10點開始搶購，12點結束，共2h)。
（1）注冊用戶數為25萬不變
（2）高峰時段在線用戶在線率預估為20%，那么這2h的在線用戶數為250000x20%=50000
（3）用戶常用下單到成功觸發20個請求，總請求量為50000x20=1000000
（4）利用二八定律計算，得出的吞吐量為1000000x0.8/(2x3600x0.2)=555.6個每秒
由此可見，評估出來的TPS值和需求業務模型息息相關。
在性能測試的前期，通過上述“3步法”整理分析的詳盡程度將直接決定后續性能測試的有效性和準確性。
在評定服務器的性能時，應該結合TPS和并發用戶數，以TPS為主‘并發用戶數為輔來衡量系統的性能。如果必須要并發用戶數來衡量的話，則需要一個前提，那就是交易在多長時間內完成，因此只用并發用戶數來衡量系統的性能沒太大的意義。
本文鏈接：http://m.www897cc.com/showinfo-26-10405-0.html性能測試的需求分析
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 場景題：海量數據如何判重？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號