軟體效能測試的目標
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 主要衡量的伺服器端的能力，看伺服器處理返回請求資料報的吞吐率。
效能測試要點
壓測後如何才能更好的優化系統，變相的使用amdahl定律可以給我們提供一定的指導。amdahl定律是固定負載 計算總量不變時 時的量化標準。可用公式 來表示。上式中，計算機執行某個任務的總時間可被改進部分的執行時間所佔百分比，記為f。可被改進部分採用改進措施後比沒有改進前效能提高倍數，記為m。假設在...
軟體效能測試
以前做過一些 山寨版 的效能測試，我都說了，是山寨麼，當然不正規，不過，現在有多少企業的測試流程是正規的能，何況效能測試的流程呢。這是現狀，也是機遇。這次因為專案需要，要做乙個比較正規的，而且有一定難度的效能測試了。b s,c s,介面效能，都涉及到，對自己也是個挑戰和提高。這乙個星期主要做需求理解...
常用的軟體效能測試方法 策略 和測試要點有哪些
1.明確測試目標，測試目標盡可能能夠有量化的標準 1 上線前驗證性的效能測試，針對銀行系統一般的效能指標為tps 響應時間是否滿足業務需求 2 容量測試，測試系統在特定系統環境下的處理能力，關注的效能指標是tps 響應時間 併發使用者數等 3 穩定性測試，銀行系統對系統7 24小時的穩定性要求還是很...