1、頁面加載時間
　　從頁面開始加載到頁面onload事件觸發的時間。一般來說onload觸發代表着直接通過HTML引用的CSS，JS，圖片資源已經完全加載完畢。
　　
2、全部頁面加載時間
　　全部頁面載入時間指從最初啟動瀏覽開始，直到所有元素都被加載完成后，在2秒后仍然沒有網絡活動的時間。
　　0-2秒：用戶體驗最好，打分100
　　2-8秒：用戶可以容忍，從第2秒開始，每超過1秒減5分
　　8-15秒：用戶不能忍受，從第2秒開始，每超過1秒減5分
　　
3、首字節時間
　　從開始加載到收到服務器返回數據的第一字節的時間
　　達標時間=DNS解析時間+創建連接時間+SSL認證時間+100ms.比達標時間每慢10ms減1分.
　　0-1秒：用戶體驗最好
　　1-2秒：用戶可以容忍
　　2-3秒：用戶不能容忍
　　
4、使用長連接
　　連接視圖展現了頁面加載過程中創建的（keepalive）連接，以及通過每個連接所加載的資源。
　　
5、DNS時間
　　進行域名解析所需要的時間
　　0-50毫秒100分
　　50-500毫秒一般，可能會影響用戶體驗，從50毫秒開始，每增加10毫秒則減去2分
　　500毫秒以上，嚴重影響?用戶的網頁體驗，從50毫秒開始，每增加10毫秒則減去2分
　　
6、TCP時間
　　客戶端建立連接的時間
　　0-100毫秒100分
　　100-500毫秒，一般，可能會影響用戶體驗，從100毫秒開始，沒增加10毫秒，減去1分
　　500毫秒以上，嚴重影響?用戶的網頁體驗，從100毫秒開始，每增加10毫秒，減去1分
　　
7、HTTP網頁打分
　　頁面渲染、下載速度、頁面流暢度
　　
8、綜合評分
　　以上評分的加權
　　計算值=全部頁面載入時間評分*0.2+首字節時間評分*0.2+使用了長連接*0.1+DNS時間評分*0.2+TCP時間評分*0.2+HTTP網頁評分*0.1
　　
9、其他一些測量指標
　　請求時間
　　定義：所謂的請求時間是指用戶從三次握手到最后一次請求發出的這一段時
　　間，這個時間可以用於定位網絡問題。
　　網絡丟包率
　　定義：當前的網絡的丟包情況統計。
　　網絡時延
　　定義：當前網絡的時延。包括RTTc和RTTs。
　　RTTc
　　用戶到探針的傳輸時延
　　RTTs
　　探針到服務器的傳輸時延
　　可以關聯的其他指標
　　受影響的用戶數
　　所謂受影響，即當該業務的某個指標比較差時，有多少個用戶受到影響。通過
　　這個指標，可以進而得到具體受到影響的用戶是哪些。
　　受影響的站點數
　　即當網絡出現問題，或者是服務器出現問題時，有多少個站點受到影響。通過

　　這個指標，可以進而得到具體受到影響的站點是哪些。

 

　　還有什么指標呢？
　　簡單的說一個Web請求的處理包括以下步驟：
　　（1）客戶發送請求
　　（2）webserver接受到請求，進行處理；
　　（3）webserver向DB獲取數據；
　　（4）webserver生成用戶的object(頁面)，返回給用戶。給客戶發送請求開始到最后一個字節的時間稱為響應時間(第三步不包括在每次請求處理中）。
1.事務Transaction
2.請求響應時間
3.事務響應時間
　　事務可能由一系列請求組成,事務的響應時間主要是針對用戶而言,屬於宏觀上的概念，是為了向用戶說明業務響應時間而提出的.
　　例如:跨行取款事務的響應時間就是由一系列的請求組成的.
　　事務響應時間是直接衡量系統性能的參數.
4.並發用戶數
　　並發一般分為2
　　種情況。一種是嚴格意義上的並發，
　　即所有的用戶在同一時刻做同一件事情或者操作，這種操作一般指做同一類型的業務。比如在信用卡審批業務中，一定數目的擁護在同一時刻對已經完成的審批 業務進行提交；還有一種特例，即所有用戶進行完全一樣的操作，例如在信用卡審批業務中，所有的用戶可以一起申請業務，或者修改同一條記錄。
　　另外一種並發是廣義范圍的並發。這種並發與前一種並發的區別是，盡管多個用戶對系統發出了請求或者進行了操作，但是這些請求或者操作可以是相同的，也可以是不同的。對整個系統而言，仍然是有很多用戶同時對系統進行操作，因此也屬於並發的范疇。
　　可以看出，后一種並發是包含前一種並發的。而且后一種並發更接近用戶的實際使用情況，因此對於大多數的系統，只有數量很少的用戶進行“嚴格意義上的並 發”。對於WEB性能測試而言，這2種並發情況一般都需要進行測試，通常做法是先進行嚴格意義上的並發測試。嚴格意義上的用戶並發一般發生在使用
　　比較頻繁的模塊中，盡管發生的概率不是很大，但是一旦發生性能問題，后果很可能是致命的。嚴格意義上的並發測試往往和功能測試
　　關聯起來，因為並發功能遇到異常通常都是程序問題，這種測試也是健壯性和穩定性測試的一部分。
　　用戶並發數量：關於用戶並發的數量，有2種常見的錯誤觀點。
　　一種錯誤觀點是把並發用戶數量理解為使用系統的全部用戶的數量，理由是這些用戶可能同時使用系統；還有一種比較接近正確的觀點是把在線用戶數量理解為 並發用戶數量。實際上在線用戶也不一定會和其他用戶發生並發，例如正在瀏覽網頁的用戶，對服務器沒有任何影響，但是，在線用戶數量是計算並發用戶數量的主 要依據之一。
5.吞吐量
　　指的是在一次性能測試過程中網絡上傳輸的數據量的總和
　　.吞吐量/傳輸時間,就是吞吐率.
6.tps
7.點擊數PV
　　每秒鍾用戶向WEB服務器提交的HTTP請求數.這個指標是WEB應用特有的一個指標:WEB應用是"請求-響應"模式,用戶發出一次申請,服務器就要處理一次,所以點擊是WEB
　　應用能夠處理的交易的最小單位.如果把每次點擊定義為一個交易,點擊率和TPS就是一個概念.容易看出,點擊率越大,對服務器的壓力越大.點擊率只是 一個性能參考指標,重要的是分析點擊時產生的影響。需要注意的是,這里的點擊並非指鼠標的一次單擊操作,因為在一次單擊操作中,客戶端可能向服務器發出多 個HTTP請求.
8.資源利用率
　　性能項命令指標
　　CPU限制vmstat當%user+%sys超過80%時
　　磁盤I/O限制Vmstat當%iowait超過40%(AIX4.3.3或更高版本)時
　　應用磁盤限制Iostat當%tm_act超過70%時
　　虛存空間少Lsps，-a當分頁空間的活動率超過70%時
　　換頁限制Iostat,stat虛存邏輯卷%tm_act超過I/O(iostat)的30%，激活的虛存率超過CPU數量(vmstat)的10倍時

　　系統失效Vmstat,sar頁交換增大、CPU等待並運行隊列。

響應時間：

　　1.利用2-5-8原則去判定
吞吐量：
　　1.125*x kb/s*0.5，若小於前面的數值為優，其中x為x Mb/s，例如1 Mb/s
每秒點擊數：

　　1.指客戶端每秒鍾向服務器端提交的請求數量，如果客戶端發出的請求數量越多，與之相對的平均吞吐量也應該越大
並發用戶數：

　　1)、經典公式1：

  　　 一般來說，利用以下經驗公式進行估算系統的平均並發用戶數和峰值數據

  　　　　1）平均並發用戶數為 C = nL/T

 　　　　 2）並發用戶數峰值 C‘ = C + 3*根號C

    　　　　C是平均並發用戶數，n是login session的數量，L是login session的平均長度，T是值考察的時間長度

   　　　　 C’是並發用戶數峰值

舉例1，假設系統A，該系統有3000個用戶，平均每天大概有400個用戶要訪問該系統（可以從系統日志從獲得），對於一個典型用戶來說，一天之內用戶從登陸到退出的平均時間為4小時，而在一天之內，用戶只有在8小時之內會使用該系統。

  那么，

  　　　　平均並發用戶數為：C = 400*4/8 = 200

  　　  　 並發用戶數峰值為：C‘ = 200 + 3*根號200 = 243

舉例2， 某公司為其170000名員工設計了一個薪酬系統，員工可進入該系統查詢自己的薪酬信息，但並不是每個人都會用這個系統，假設只有50%的人會定期用該系統，這些人里面有70%是在每個月的最后一周使用一次該系統，且平均使用系統時間為5分鍾。則一個月最后一周的平均並發用戶數為（朝九晚五）：

 　　　　 n = 170000*0.5*0.7/5 = 11900

 　　　　 C= 11900*5/60/8 = 124

  　　　　吞吐量計算為：F = Vu * R / T 單位為個/s

   　　　　　 F為事務吞吐量，Vu為虛擬用戶數個數，R為每個虛擬用戶發出的請求數，T為處理這些請求所花費的時間

　　2)、通用公式2：

  　　對絕大多數場景，我們用（用戶總量/統計時間）*影響因子（一般為3）來進行估算並發量。

  　　比如，以乘坐地鐵為例子，每天乘坐人數為5萬人次，每天早高峰是7到9點，晚高峰是6到7點，根據8/2原則，80%的乘客會在高峰期間乘坐地鐵，則每秒 到達地鐵檢票口的人數為50000*80%/（3*60*60）=3.7，約4人/S，考慮到安檢，入口關閉等因素，實際堆積在檢票口的人數肯定比這個要 大，假定每個人需要3秒才能進站，那實際並發應為4人/s*3s=12，當然影響因子可以根據實際情況增大！

　　3)、根據PV計算公式：

 　　 比如一個網站，每天的PV大概1000w，根據2/8原則，我們可以認為這1000w pv的80%是在一天的9個小時內完成的（人的精力有限），那么TPS　　為：

  　　1000w*80%/(9*3600)=246.92個/s,取經驗因子3，則並發量應為：

 　　 246.92*3=740

　　4)、根據TPS估計：

  　　 公式為 C = (Think time + 1)*TPS

　　5)、根據系統用戶數計算：

   　　並發用戶數 = 系統最大在線用戶數的8%到12%

資源使用率：
　　1).平均事務響應時間
　　Average Transation Response Time優秀：<2s
　　良好：2-5s
　　及格：6-10s
　　不及格：>10s
　　2).每秒點擊率
　　Hits per Second
　　當增大系統的壓力(或增加 並發用戶數)時，吞吐率和TPS的變化曲線呈大體一致，則系統基本穩定若壓力增大時，吞吐率的曲線增加到一定程度后出現變化緩慢，甚至平坦，很可能是網絡出現帶寬瓶頸.同理若點擊率/TPS曲線出現變化緩慢或者平坦，說明服務器開始出現.
　　3).請求響應時間
　　Time to Last Byte
　　4).每秒系統處理事務數
　　Transaction per second
　　5).吞吐量
　　Throughout
　　6).CPU利用率
　　Processor/%Processor Time好：70%
　　壞：85%
　　很差：90%+
　　7). 數據庫操作消耗的CPU時間
　 　Processor/%User Time如果該值較大，可以考慮是否能通過友好算法等方法降低這個值。如果該服務器是數據庫服務器，Processor\%User Time值大的原因很可能是數據庫的排序或是函數操作消耗了過多的CPU時間，此時可以考慮對數據庫系統進行優化。
　　8).核心態CPU平均利用率
　　Processor/%Privileged Time如果該參數值和"Physical Disk"參數值一直很高，表明I/O有問題。可考慮更換更快的硬盤系統
　　9).處理列隊中的線程數
　 　Processor/Processor Queue Length如果該值保持不變(>=2)個並且%Processor Time超過90%，那么可能存在處理器瓶頸。如果發現超過2，而處理器的利用率卻一直很低，那么或許更應該去解決處理器阻塞問題，這里處理器一般不是瓶 頸。
　　10).文件系統緩存
　　Memory/Cache Bytes 50%的可用物理內存
　　11).剩余的可用內存
　　Memory/Avaiable Mbytes至少要有10%的物理內存值
　　本文出自51Testing軟件測試網，感謝會員fmsbai5在每周一問(08-12-29)中的精彩回答。 http://bbs.51testing.com/forum-157-1.html
　　12).每秒下載頁數
　　Memory/pages/sec好：無頁交換
　　壞：CPU每秒10個頁交換
　　很差：更多的頁交換
　　13).頁面讀取操作速率
　　Memory/page read/sec如果頁面讀取操作速率很低，同時%Disk Time和Avg.Disk Queue Length的值很高，則可能有磁盤瓶徑。但是，如果隊列長度增加的同時頁面讀取速率並未降低，則內存不足。
　　14).物理磁盤利用率
　　Physical Disk/%Disk Time好：<30%
　　壞：<40%
　　很差：<50%+
　　15).物理磁盤平均磁盤I/O隊列長度
　　Physical Disk/Avg.Disk Queue Length該值應不超過磁盤數的1.5~2倍。要提高性能，可增加磁盤
　　16).網絡吞吐量
　　Network Interface/Bytes Total/sec判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬，結果應該小於50%
　　17).數據高速緩存區命中率命中率應大於0.90最好
　　18).共享區庫緩存區命中率命中率應大於0.99
　　19).監控SGA中字典緩沖區的命中率命中率應大於0.85
　　20)檢測回滾段的爭用小於1%
　　21).監控SGA中重做日志緩存區的命中率
　　應該小於1%
　　22).監控內存和硬盤的排序比率最好使它小於10%