軟體效能測試的目標：
1、測試系統的最佳使用者數（隨著使用者數量的增多系統的響應時間並沒有受到影響，直到某個數量的使用者數響應時間開始明顯增長）
2、測試系統的最大使用者數（隨著使用者數量的增多，系統的響應時間開始延遲，直到某個數量的使用者數時，系統開始響應失敗或崩潰）
3、a、找到目前系統的效能瓶頸（依次測試系統的資料庫、服務層各個介面、直到web端，分析找到最大使用者數值最小的那幾個部分，即是系統的瓶頸）
b、找到軟體以外的效能瓶頸則可以在廣域網中進行測試，結合軟體的測試資料分析網路和硬體！
4、系統的穩定性測試（較高數量的使用者持續訪問系統較長的時間長度，期間系統一直能有效響應，並沒有明顯的響應時長起伏或宕機）
注：本人在實際測試過程中發現，目前所測試的系統的響應時長是隨著使用者數量的增多正比例增加的，並沒有乙個增長點的存在；響應失敗的出現也並非不常見，在資料量很小的情況下，就有可能出現偶爾失敗的情況，當資料量很大時，響應失敗的情況並沒有顯著增加。這也許跟本公司的框架處理機制有關係，具體問題具體分析，不可拘泥於教條。
效能測試的環境因素：
1）硬體環境
伺服器硬體配置，客戶端的硬體配置，如：cpu記憶體等
2）軟體環境
系統的架構，前端、中介軟體、伺服器（這裡指執行系統軟體伺服器，如tomcat）、資料庫，以及他們的部署位置。用於加壓的客戶端採用什麼效能測試工具進行加壓。
3）網路環境
網路環境很重要。在上面的幾個目的中，除了找出系統效能瓶頸可以在廣域網進行，因為這個目的可以不用設定太多的虛擬使用者，只要找出系統哪個地方影響了整個系統的效能就行。 其他目的的測試都需要在，區域網進行，不然你壓力工具所傳送的請求都會卡死在網路的傳輸過程中。
確定系統的壓力點：
我們需要對系統的哪個頁面或業務進行加壓。系統的首頁？系統的登入？還是系統的交易過程？各個業務的使用者比例是多少？只有獲得有效的效能需求，才容易尋找和定位壓力點
併發的兩種情況：
1、所有的使用者在同一時刻做同一件事或操作，這種操作一般指做同一型別的業務。比如，所有使用者同一時刻做併發登入，同一時刻做表單提交。
2、多個使用者對系統發出了請求或者進行了操作，但這些請求或操作可以是相同的，也可以是不同的。比如，在同一時刻有使用者在登入，有使用者在提交表單。
測試思路：
測試最佳使用者數和最大使用者數的思路：（有點黑盒效能測試的感覺）
1、首先分析壓力點，通過直接錄製指令碼的方式錄製出想要的指令碼,比如要測試靜態頁面則錄製靜態頁面的指令碼，要測試登陸則錄製登陸的介面，要全系統分析則錄製全系統所有功能的指令碼。
2、處理讓指令碼可以按照自己的思路（設計何種併發、新增哪些測試元件、壓力點的設定）順利執行。要注意遮蔽圖形驗證碼，以及1.6jdk不支援https控制項等常見問題，具體問題具體分析解決。
3、執行指令碼分析資料。
效能瓶頸測試思路：（有點白盒效能測試的感覺）
1、首先要熟悉軟體的架構，比如：web--服務層--db。
2、根據軟體的架構採用從前往後或從後往前的測試思路逐層測試，在測試服務層的每個介面時需要知道內部介面的入參、出參手動編輯指令碼。這一步也叫介面效能測試。
3、分析測試資料，主要對web前端的效能、每個介面的效能、資料庫效能等進行分析，對中介軟體如：redis、nginx、tomcat，以及資料庫要能夠簡單調優。最終將測試結果反饋給對應開發負責人。
穩定性測試：
這裡與最佳使用者數以及最大使用者數的測試方法類似，使用者數設定為最佳使用者數與最大使用者數之間的多組資料，將執行緒設定為迴圈，指定迴圈時間為12小時以上。
測試資料的分析：
1、work load = virtual users 工作負荷 = 虛擬使用者數
對伺服器產生多大壓力，可以由多少使用者同時對伺服器傳送請求來衡量。也就是伺服器的效能可以看它同時處理多少使用者傳送來的請求來衡量。
虛擬使用者數可以用程序或執行緒的方式進行模擬。
2、response time 響應時間
從客戶端將資料報發出，到接收到伺服器端發來的請求。這個過程的總體時間叫response time
這個時間用來衡量的處理請求的速度（丟擲網速限制的前提下）
3、response/successful response 響應/成功的響應
4、throughput ~ti & to 吞吐率
「吞吐率」，就是單位時間的吞吐量，比如吞吐量/秒。
站在伺服器端，t-in表示「吞」；t-out表求「吐」
ti：t-in 主要衡量客戶端的能力，看客戶端往伺服器傳送的請求資料報的吞吐率。
to： t-out 主要衡量的伺服器端的能力，看伺服器處理返回請求資料報的吞吐率。
效能測試 效能測試步驟
針對此次庫內作業效能測試，梳理一下期間的工作流程 梳理已有的介面指令碼，確認需要做效能測試的幾個介面，即使用率高，對效能有要求的幾個主要介面。結合頁面的操作，和確認的介面，梳理具體的業務邏輯 同時，請開發人員部署了測試環境。測試環境的伺服器指標，盡量和生產環境一致。部署的時候，負載均衡等情況也盡量和...
效能測試之前端效能測試
本次總結總共分為以下部分 1.如何衡量乙個系統是否要做壓測 2.壓測的準備過程 3.壓測工具選擇 4.壓測資料以及報告結果相關 1.如何衡量乙個系統是否要做壓測 首先需要衡量乙個系統是否需要壓測，從以下角度考慮 從兩個角度進行分析 a.業務角度 明確系統是對內使用還是對外使用，使用人數是多少，如果使...
IT之路 效能測試系列 初識效能測試
上一章節我們大概了解了下loadrunner，這一章，我們來認識一下效能測試。說到效能測試，很多同學會有自己不同的感想。web前端的測試同學說 頁面怎麼半天打不開啊，沒辦法測啊，必須改善。一線運維的同學說 靠，系統上線這才多久啊，怎麼就嘎嘣的宕機了？這可以不行啊，客戶跳起來了，必須趕緊處理。終端使用...