結果分析（監聽器）：

1.聚合報告

Aggregate Report 是 JMeter 常用的一個 Listener，中文被翻譯為“聚合報告”。今天再次有同行問到這個報告中的各項資料表示什麼意思，順便在這裡公佈一下，以備大家查閱。

如果大家都是做Web應用的效能測試，例如只有一個登入的請求，那麼在Aggregate Report中，會顯示一行資料，共有10個欄位，含義分別如下。

Label：每個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這裡顯示的就是 Name 屬性的值

#Samples：表示你這次測試中一共發出了多少個請求，如果模擬10個使用者，每個使用者迭代10次，那麼這裡顯示100

Average：平均響應時間——預設情況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也可以以Transaction 為單位顯示平均響應時間

Median：中位數，也就是 50％ 使用者的響應時間

90% Line：90％ 使用者的響應時間

Note：關於 50％ 和 90％ 併發使用者數的含義，請參考下文

http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html

Min：最小響應時間

Max：最大響應時間

Error%：本次測試中出現錯誤的請求的數量/請求的總數

Throughput：吞吐量——預設情況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也可以表示類似 LoadRunner 的 Transaction per Second 數

KB/Sec：每秒從伺服器端接收到的資料量，相當於LoadRunner中的Throughput/Sec

2. 圖形報表

圖表底部引數的含義如下：
樣本數目是總共傳送到伺服器的請求數。
最新樣本是代表時間的數字,是伺服器響應最後一個請求的時間。
吞吐量是伺服器每分鐘處理的請求數。 
平均值是總執行時間除以傳送到伺服器的請求數。 
中間值是代表時間的數字，有一半的伺服器響應時間低於該值而另一半高於該值。 
偏離表示伺服器響應時間變化、離散程度測量值的大小，或者，換句話說，就是資料的分佈。

3. 監視器結果

“監視器結果”（Monitor Result）是為Tomcat 5設計的，用來實時反映伺服器的效能情況，如果你的AppServer不是Tomcat 5，使用“監視器結果”得不到結果，但是任何servlet container都可以移植status servelet並使用此monitor，如果需要對

新增的“監視器結果”利用的是Tomcat本身的特性，就是直接訪問Tomcat伺服器的/manager/status，獲得相應的伺服器狀態資料並進行呈現。因此，在JMeter中新增“監視器結果”來監視伺服器狀態的步驟如下：

1.                 增加一個HTTP Request的Sampler；

2.                 選中該新增的HTTP Request，修改其屬性：

修改“名稱”為伺服器狀態（非必須）

修改“路徑”為manager/status，必要時給出伺服器的IP地址和Port的值

增加一個引數，該引數的名稱為大寫的XML，值為小寫的true

選中下方的“用作監視器”

如下圖所示：

3.                 增加一個“http授權管理器”因為訪問Tomcat的應用伺服器的/manager/status需要給出使用者名稱和口令。如下圖所示

4.                 新增一個“監視器結果”的節點

執行後，會在監視器結果中的效能頁面顯示圖。其中healthy/Warning/非活動”是根據伺服器上的可用執行緒數/最大可用執行緒數得出，而Load用來衡量應用伺服器的壓力狀況。

comment：我知道經常用的還有“察看結果樹”以及“用表格察看結果”，這篇監視器結果我覺得網上不太多吧，大部分都說聚合報告

其他：

1. 聚合報告的error代表沒有響應率

2. 每個測試不能一下子上1000，應該10 100 200 500 1000這樣的走，看下錯誤的上升率

3. 每個case要跑3次，取平均值，以排除外界干擾

4. 例如通過量、響應時間、CPU負載、記憶體使用等來決定系統的效能

5. 壓力測試（Stress Testing）是通過確定一個系統的瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務級別的測試。

6. 併發效能測試的目的主要體現在三個方面：以真實的業務為依據，選擇有代表性的、關鍵的業務操作設計測試案例，以評價系統的當前效能；

7. 同時記錄下每一事務處理的時間、中介軟體伺服器峰值資料、資料庫狀態等

8. 主要的測試指標包括交易處理效能指標和UNIX資源監控。其中，交易處理效能指標包括交易結果、每分鐘交易數、交易響應時間（Min：最小伺服器響應時間；Mean：平均伺服器響應時間；Max：最大伺服器響應時間；StdDev：事務處理伺服器響應的偏差，值越大，偏差越大；Median：中值響應時間；90%：90%事務處理的伺服器響應時間）、虛擬併發使用者數。

9. 監測的測試指標包括交易處理效能以及UNIX（Linux）、Oracle、Apache資源等。

10. 是否需要疲勞性測試？

11. 基準測試可以在一個相對短的時間內收集可重複的結果。進行基準測試的最好方法是，每次測試改變一個且只改變一個引數。例如，如果想知道增加JVM記憶體是否會影響應用程式的效能，就逐次遞增JVM記憶體（例如，從1024 MB增至1224 MB，然後是1524 MB，最後是2024 MB），在每個階段收集結果和環境資料，記錄資訊，然後轉到下一階段。這樣在分析測試結果時就有跡可循。下一小節我將介紹什麼是基準測試，以及執行基準測試的最佳引數。

12. 　基準測試的關鍵是要獲得一致的、可再現的結果。注意，吞吐量以穩定的速度增長，然後在某一個點上穩定下來。因為伺服器上所有的執行緒都已投入使用，傳入的請求不再被立即處理，而是放入佇列中，當執行緒空閒時再處理。　當系統達到飽和點，伺服器吞吐量保持穩定後，就達到了給定條件下的系統上限。　注意，在執行佇列（圖2）開始增長的同時，響應時間也開始以遞增的速度增長。這是因為請求不能被及時處理。

13. 對於一次給定的測試，應該取響應時間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次載入所有的使用者，然後在預定的時間段內持續執行。

14. 與此相對應的是“ramp-up”測試。

　　ramp-up測試中的使用者是交錯上升的（每幾秒增加一些新使用者）。ramp-up測試不能產生精確和可重現的平均值，這是因為由於使用者的增加是每次一部分，系統的負載在不斷地變化。因此，flat執行是獲得基準測試資料的理想模式。

15. 這不是在貶低ramp-up測試的價值。實際上，ramp-up測試對找出以後要執行的flat測試的範圍非常有用。ramp-up測試的優點是，可以看出隨著系統負載的改變，測量值是如何改變的。然後可以據此選擇以後要執行的flat測試的範圍。

16. 　當測試中所有的使用者都同時執行幾乎相同的操作時，就會發生這種現象。這將會產生非常不可靠和不精確的結果，所以必須採取一些措施防止這種情況的出現。有兩種方法可以從這種型別的結果中獲得精確的測量值。如果測試可以執行相當長的時間（有時是幾個小時，取決於使用者的操作持續的時間），最後由於隨機事件的本性使然，伺服器的吞吐量會被“拉平”。或者，可以只選取波形中兩個平息點之間的測量值。該方法的缺點是可以捕獲資料的時間非常短。

17. 例如，首先使用ramp-up測試確定系統可以支援的使用者範圍。確定了範圍之後，以該範圍內不同的併發使用者負載進行一系列的flat測試，更精確地確定系統的容量。

18. 可行的方法是在這臺伺服器上使用不同級別的負載來進行測試，並根據測試資料獲得系統在這種環境下的最佳負載和最大負載，並根據測試資料對負載和資源消耗的情況進行估算，找到它們之間的關係。

19. 而對於可伸縮性測試，通常來說是要根據併發量、系統的效能表現以及軟硬體資源的消耗情況來進行分析，並使用數學建模的方式獲得一個容量模型。

20. 可伸縮性測試（Scalability Testing） 對於一個系統來說，在一個給定的環境下，它的最佳併發使用者數和最大併發使用者數是客觀存在的，但是系統所面臨的壓力卻有可能隨上線時間的延長而增大。例如，一個線上購物站點，註冊使用者數量不斷增多，訪問站點查詢商品資訊和購買商品的人也不斷的增多，我們應該用一種什麼樣的方案，在不影響系統繼續為使用者提供服務的前提下來實現系統的擴容？

21. Jmeter的併發數是沒有上限的（http://bbs.51testing.com/thread-264979-1-3.html）

comment：上面其實主要是一些測試效能的指標，還有思路（不是光把jmeter跑起來就可以的，要知道怎麼設定跑的次數以及check的點這些）

好啦，基本上記錄的差不多了，當然文章還有好多好多，不過沒辦法都記錄在部落格中，這邊就作為一個大致的流程記錄下來吧，如果以後再有什麼好發現，我可以開一個二，呵呵

btw, http://shijianwu1986-163-com.iteye.com/blog/507888 （這篇說的很細緻，挺好的，記錄這邊）