通過技術的手段模擬大量使用者同時訪問被測應用，觀察、記錄和分析系統的各項效能指標的過程。
評估系統的效能瓶頸，**系統的最大使用者負載能力
1）能夠有效評估系統的效能指標，用於系統的效能評估2）能夠識別系統的效能瓶頸，協助效能調優3）能夠指導突發流量承載方案的制定4）能夠用於系統運維成本的預算
測試：根據業務提出效能測試來規避風險
開發：覺得某些頁面載入慢
運維：對某個系統的服務能力提出效能評估
產品：線上效能問題反饋
使用者：提出某些硬性的效能要求
關鍵性評估：有一項就要進行效能測試
涉及財產、生命、安全的系統。如：支付系統、電商系統、金融業務系統、醫療健康評估系統
首次投產的大型系統、具有大量使用者使用的核心業務（如：查票、搶票、支付）
系統核心資料庫、業務邏輯、軟硬體公升級
歷史版本存在重大非功能缺陷or風險較大的未評估項
系統公升級後，業務量、使用者量、節點增長30%以上
系統架構發生重大變化的場景
效能嚴重bug修復後，是否會對正式環境造成不利
一般性評估：超過60分，則有必要進行效能測試
是否有公升級，且公升級內容中包含了外部系統對接介面、支付介面、web service呼叫介面等與其他系統關聯介面（20分）
是否增加了效能風險較高的調整（20分）
是否存在客戶要求必須測試的元件or業務流程（20分）
是否在平台中處於核心位置（15分）
是否存在部署方式調整or優化（15分）
是否涉及多個功能bug的修復，且流程發生較大變化（10分）
使用者視角：
1）頻繁使用，且存在大量使用者使用的場景
2）交易佔比較高，日常佔比 ≥80% 的場景
3）特殊交易日或峰值交易佔比 ≥80% 的場景
4）效能較差且有過調整的場景
專案團隊視角：
1）調整了架構設計的業務
2）邏輯複雜，比較關鍵的業務
3）可能消耗大量資源的業務
4）與外部系統存在介面呼叫，且有大量資料互動的業務
5）呼叫第三方業務元件，邏輯複雜的業務
運營視角：
1）滿足未來業務發展規劃
2）系統需滿足未來業務需求
需求一：使用者數資訊
1）調查系統當前和未來使用的使用者數
系統使用者數=系統目前註冊的使用者數，註冊使用者數並不代表他會每天並且無時無刻的使用。
2）調查系統當前和未來的每日、月活躍使用者數
當前活躍使用者數，即某天大概有多少使用者使用本系統：那麼這部分資料就是當前真正對系統構成壓力的資料
需求二：業務資料量
1）調查當前和未來背景資料量
因為從100條資料中查10條也許很快，但是未來資料量變成100w。。。
2）調查當前和未來業務每天使用的總筆數
每個使用者每天可能下多少筆單，平均需要多少次來執行這個操作？那麼根據使用者數，我們就可以確定每天下單的筆數。如50人，平均每人每天下10次，每次下100筆，那麼總筆數就是50*10*100=50000筆。注意此資料根據tps換算後，我們可以換算出系統的業務總處理量是否能達到這個資料，這也是乙個很重要的指標。
3）調查當前和未來高峰時業務的總筆數
需求三：場景業務的調查
1）系統最關鍵、最核心的業務
從系統出發，以主要的業務邏輯點為第一核心：這些功能對系統或公司來說往往具有舉足輕重的地位，無論怎樣都必須要優先執行滿足這些功能的效能測試
2)高訪問量的功能，經常承受壓力的功能點
3)業務複雜度高
往往說來業務邏輯複雜度的都具備1、2點的要素，可能其功能使用的人數較少但是對系統有很嚴重影響：這些功能由於其業務邏輯具有的複雜度，往往出錯的可能性也比較高，所以這些功能也是必須要進行測試的
效能需求分析
效能測試需求應包括以下內容 a 測試場景及用例，用例訪問url b 目標介面方法的入參 出參 c 外部依賴的服務細節 d 關鍵資料 資料量 高峰業務pv量 e 預期效能指標 響應時間 qps tps等 1.2.1資料量 測試環境的資料量，應該跟線上環境保持一致，至少要在乙個數量級。舉例有，中文站線上...
效能測試 效能需求分析
乙個真實的需求 測試某系統切換成https協議之後效能的下降情況 需求分析 1 對比 http https 2 求出http協議下的效能 3 求出https協議下的效能 4 求出兩者的差異 5 確定效能指標 tps 6 測試報告裡體現 tps的變化 測試策略 1 基準測試 1.1http作為基準 1...
政務專案 效能需求分析
在進行效能測試之前，我們需要先對效能需求進行分析，得出我們測試的依據，同時也是錄製指令碼的方向。先來看一下合同上的效能需求，分時效性需求和併發性需求 a.時效性需求 在系統基礎軟體效能及相應的系統管理保障基礎上，保證90 的使用者一次性成功的登入系統，而且用時不超過2秒，80 的資料提交不超過3秒，...