測試：根據業務提出效能測試來規避風險
開發：覺得某些頁面載入慢
運維：對某個系統的服務能力提出效能評估
產品：線上效能問題反饋
使用者：提出某些硬性的效能要求
關鍵性評估:有以下一項就要進行效能測試
涉及財產、生命、安全的系統。如：支付系統、電商系統、金融業務系統、醫療健康評估系統
首次投產的大型系統、具有大量使用者使用的核心業務（如：查票、搶票、支付）
系統核心資料庫、業務邏輯、軟硬體公升級
歷史版本存在重大非功能缺陷or風險較大的未評估項
系統公升級後，業務量、使用者量、節點增長30%以上
系統架構發生重大變化的場景
效能嚴重bug修復後，是否會對正式環境造成不利
介面的響應速度達到300ms以下。
介面成功率達到99.5%以上。
在100個併發使用者的高峰期，系統的基本功能，處理能力至少達到10tps
這個系統能否支撐200萬的vu（每天登入系統的人次） vu----virtual user(虛擬使用者)
"不成文"的效能需求指標：
80/20原則：又稱帕累託效應，比如，某一些系統一天中80%的訪問量集中在20%的時間內。
下面來分析某移動支付的需求：
按照2023年日交易筆數的目標為1000萬筆：
如何得到每秒的交易筆數？
一： 嚴格的根據2/8原則 ，80%的訂單集中在20%的時間生成。
集中訂單交易數： 10000000*80%=8000000筆
每秒生成的訂單數：8000000/17280=462.9筆/秒
二：另外的200w交易筆數請求分布在另外的23個小時內，因為考慮到半夜之後基本沒什麼請求量，假設另外的200w次請求分布在10:00-24:00，那麼我們另外乙個指標是 2000000/14/3600 = 39.68 （穩定支援這樣的tps）
峰值場景設計： 設計符合業務場景的高壓力場景，比如大量併發集中在半小時-1小時內
穩定場景設計: 8-10小時的長時間穩定壓力場景
效能瓶頸壓測場景： 逐步增加壓力，尋找業務請求瓶頸（適用於沒有業務指標，技術優化類）
秒殺類超大併發場景設計: 測試秒殺場景
要測試的物件不是憑空想象出來，而是經過分析與系統資料收集得到。以下取幾個典型的壓力點:
被測的系統應該是最重要的最基本的功能，也是使用者使用最頻繁的功能。
測試用例的產生需要考慮以下幾方面：
1.測試頁面和業務邏輯，也就是業務對應的功能點
注意，效能測試的測試用例也需要專一性，也就是對應單個測試功能點。
因為我們監控的是每個事物的響應時間，功能點需要單一。
為排除網路原因，請在區域網進行效能測試。
2.壓力持續時間
壓力持續時間指的是給伺服器施加多長時間的壓力。
這個時間，我們會結合測試場景，對壓力時間做一定的控制。
如果測試的是高峰場景，時間一般最少為1個小時；
如果測試的是穩定性場景，時間一般最少要求8小時；
3.併發數
不要混淆併發和tps的關係。
併發數指的是同時有多少使用者（執行緒）在對伺服器施加壓力，是量化的給伺服器的壓力；而tps指的是伺服器每秒鐘能夠處理的事物數，是伺服器處理能力的體現。即施加的併發數伺服器並不一定一秒響應完，兩者定義不同。
number of threads(users)：用於設定執行緒數，即使用者數
ram-up period(in seconds)：用於告知jmeter要在多長時間內建立全部的執行緒。ramp-up的值預設為0，代表立即建立所有執行緒，即同時併發。
loop count：用於設定迴圈次數
效能測試 效能需求分析
乙個真實的需求 測試某系統切換成https協議之後效能的下降情況 需求分析 1 對比 http https 2 求出http協議下的效能 3 求出https協議下的效能 4 求出兩者的差異 5 確定效能指標 tps 6 測試報告裡體現 tps的變化 測試策略 1 基準測試 1.1http作為基準 1...
效能測試入門教程 效能測試第一步 需求調研
有不少同學一聽說要做效能專案，馬上就熟練的開啟了loadrunner開始錄起了指令碼，然後做的過程中遇到各種問題，在網上各種問，指令碼要不要做關聯呢？測試的時候需不需要加集合點？引數化資料選擇多少條呢。講真，這些問題別人也沒辦法回答啊，這些問題都取決於具體業務和需求，需要從需求中挖掘，並沒有乙個固定...
效能需求分析
通過技術的手段模擬大量使用者同時訪問被測應用，觀察 記錄和分析系統的各項效能指標的過程。評估系統的效能瓶頸，系統的最大使用者負載能力 1 能夠有效評估系統的效能指標，用於系統的效能評估2 能夠識別系統的效能瓶頸，協助效能調優3 能夠指導突發流量承載方案的制定4 能夠用於系統運維成本的預算 測試 根據...