效能測試目的：
效能測試目標：
1、 系統新上線、測試明確的數字標準對比情況下，驗證系統是否可以上線。測試系統的極限，如：系統某些資源已經耗盡，cpu、控制代碼、記憶體、資料庫出現大量的slow query、或者系統有些處理已經變數）或者證明系統能否根據硬體水平擴充套件的。
2、 沒有可以比較的測試結果，但是產品已經上線一段時間（一般3個月以上），有一些運營資料，則分析運營資料來作為比對基準，只要測試系統達到3個月內系統併發峰值的4倍就可以認為是可以接受的。（如果是介面為測試物件，則需要混合主要的介面來進行效能測試）
3、 有以往測試結果進行對比，只要證明類似的測試條件下，此次的結果比以往的測試結果更好即可（每秒處理個數更多、單次請求的處理速度更快等）
4、 開發人員提供經驗值作為對比的基準，則被測物件只需要證明滿足開發人員提出的經驗值。
一般出現瓶頸點：
硬體上的效能瓶頸：
一般指的是cpu、記憶體、磁碟i/o 方面的問題，分為伺服器硬體瓶頸、網路瓶頸（對區域網可以不考慮）、伺服器作業系統瓶頸（引數配置）、中介軟體瓶頸（引數配置、資料庫、web伺服器等）、應用瓶頸（sql 語句、資料庫設計、業務邏輯、演算法等）。
應用軟體上的效能瓶頸：
一般指的是應用伺服器、web 伺服器等應用軟體，還包括資料庫系統。
例如：中介軟體weblogic 平台上配置的jdbc連線池的引數設定不合理，造成的瓶頸。
應用程式上的效能瓶頸：
一般指的是開發人員新開發出來的應用程式。
例如，程式架構規劃不合理，程式本身設計有問題（序列處理、請求的處理執行緒不夠），造成系統在大量使用者方位時效能低下而造成的瓶頸。
作業系統上的效能瓶頸：
一般指的linux等作業系統，我們用的是centos
例如，在進行效能測試，出現物理記憶體不足時，虛擬記憶體設定也不合理，虛擬記憶體的交換效率就會大大降低，從而導致行為的響應時間大大增加，這時認為作業系統上出現效能瓶頸。
網路裝置上的效能瓶頸：
一般指的是防火牆、動態負載均衡器、交換機等裝置。
例如，在動態負載均衡器上設定了動態分發負載的機制，當發現某個應用伺服器上的硬體資源已經到達極限時，動態負載均衡器將後續的交易請求傳送到其他負載較輕的應用伺服器上。在測試時發現，動態負載均衡器沒有起到相應的作用，這時可以認為網路瓶頸。
描述效能測試物件的環境要求：
1、 硬體環境需求（描述資料庫伺服器，應用伺服器，介面後台伺服器配置說明）（依據實際情況，有則寫，沒有則待定）；
2、 軟體環境需求（依據實際情況，有則寫，沒有則待定）；
a、作業系統要求（描述各個硬體伺服器安裝的作業系統）；
b、應用軟體要求（描述各應用軟體的名稱、安裝位置、版本資訊）；
c、客戶端要求（描述對客戶端ie、第三方軟體的版本資訊）；
4、其他環境需求（如有其他環境需求則描述清楚，否則寫無）
1.使用者量基礎資料
測試時需要在使用者表增加多少使用者量，作為使用者基礎資料
2.業務資料
課程基礎資料：在業務表匯入多少資料量作為業務基礎資料，舉例：college_lesson等關聯表資料
心理fm資料：在業務表匯入多少資料量作為業務基礎資料，舉例：fm_broadcast等關聯表資料
web服務--描述是否使用nginx應用還是其他web應用，是否有做靜態分類技術把常用的css、js等樣式、檔案部署在nginx伺服器上，目的是減輕tomcat應用服務效能壓力。
nginx是否做了請求訪問軟負載均衡等等。
列出對應的**，按照真實實際的情況設計填寫；舉例**：
伺服器型別
配製要求
伺服器名
ip用途
備註cpu
記憶體3、測試目標
如果是併發測試，這需要大致估算使用者量；舉例：
基線
使用者量(人)
（估算）併發使用者數
系統設計使用者量
1000
20040
系統上線使用者量
……未來三年使用者量
……4、測試場景
列出系統需要測試的業務場景，作為效能測試指令碼錄製依據；業務場景舉例：
主要業務操作
併發量
是否常用
業務重要性
系統登入是中
參加課程是高
是中是低
5、響應時間要求（使用者最直接感受標準）
業務操作盡可能詳細描寫，系統響應時間需要專案負責人與客戶溝通確認；以下標準可以參考
沒有明確響應時間指標，則按3-5-8原則進行填寫
最為正確的統計做法是用百分比分布統計。
6、網路頻寬及硬體（我們用的阿里雲可以省略）
網路需要注意：描述效能測試環境各應用伺服器之間的區域網網路頻寬多少？網際網路出口的網路頻寬多少？測試客戶端所在的網段頻寬多少？
7、通過準則
1) 通過準則由產品、開發、測試一起制定。
2) 針對不同測試目的確定測試通過準則。
舉例：伺服器可靠性，在保持高併發情況下長時間提供服務（xx併發xx時間不宕機），效能曲線是否下降。
3) 明確本次測試關注點；舉例：
類別
判斷準則
不通過
通過
備註
服務端效能
舉例：鏈結訪問超時率
大於5%
小於5%
1）計算公式：
超時次數/總訪問次數）*100
2）超時率範圍需要確定。
舉例：高併發情況下，事務失敗率(必填)
大於5%
小於5%
1）計算公式：
事務失敗次數/總事務次數）*100
2）失敗率範圍需要確定。
。。。。。。。。
效能測試標準
1.cpu利用率小於40 2.記憶體占用小於80 3.processor queue length小於2 4.response time小於1s 5.吞吐量throughtput大於90 6.業務執行的平均響應時間 期望值 15s 1.吞吐量 單位時間內網路傳輸資料量 2.衝突率 在乙太網上監測到的...
C 標準效能測試
經常我寫乙個類，作為乙個工具類，小夥伴會問我這個類的效能，這時我就需要乙個標準的工具進行測試。現在在 github 提交 如果有小夥伴想要知道某個函式的效能，就會用 benchmarkdotnet 進行測試。例如我有乙個函式 stooter 我定義這個函式的效能是非常高，我需要告訴大家在什麼的裝置執...
Jmeter效能測試 標準效能測試場景設計
如何設計測試場景是效能測試中比較關鍵的內容。在效能測試領域有幾個教科書一樣的場景設計方法，放之四海而皆準 目的單業務基準測試是在伺服器沒有壓力的情況下，獲取單筆業務的處理時間，為後續調優提供資料依託 策略jmeter中設定為單個執行緒迭代n次 如100 取平均響應時間。一般情況下我們不需要監控硬體資...