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