性能測試步驟(2)

　　JVM的監控，可以用jprofiler工具，linux下面的jmap、jhat等。

　　響應時間、吞吐量等，由grinder提供。

　　上述這些信息，一般在測試結束后，均需要歸檔整理，已備后續詳細分析

　　我們自己開發一套腳本，用于以固定的頻率獲取測試客戶端和服務器的vmstat和top輸出、grinder的log，并從中截取有用信息保存，用于事后分析。

　　每次測試運行完以后，肯定會增加很多數據，需要考慮本次執行對數據量的影響，如果數據量的變化對后續測試會有影響，則需要清理數據。

　　性能測試步驟(五)——測試分析

　　測試分析一般跟測試監控息息相關，在測試執行的過程中，用各種監控工具能看到系統運行的狀態，并及時發現問題。

　　常見的問題有：內存問題、有限資源競爭問題。

　　內存問題

　　從top中看tomcat的內存占用，這個是不準的，需要用專門的內存分析工具來查看。

　　工具：jmap，jhat，jstat，可以得到內存快照，得到堆內存的詳細信息。

　　垃圾收集配置會影響系統性能，如果內存塊生成和銷毀量很大，則能看到系統吞吐量隨垃圾收集呈現周期性的變化。

　　從理論上來說，JAVA會出現內存泄漏的情況，不過我們在被測試的應用中還沒有發現過這種情況。

　　但是，在某些系統架構下，內存會成為瓶頸問題。比如我們曾經測試過聊天系統，每個長連接需要占用5M內存，那么，一臺10G內存的服務器只能保持2000個長連接。

　　共享資源競爭問題

　　有限資源的競爭有很多，比如Service層的一個共享對象，比如數據庫連接，比如數據庫中的某一個使用頻率很高的數據表。

　　一個共享資源在一個時間點上，只能被一個線程獲得，其他線程必須等待，這就容易造成很多線程的timed wait狀態。通過jprofiler工具，能夠得到線程快照，并分析改進方法。

　　性能測試經驗交流——偶然性問題

　　跟一般的功能測試一樣，性能測試也會出現偶然性問題。

　　碰到這種問題，我們需要發揮測試人員的革命精神，追查到底。我們常發現的因素如下：

　　獠懇蛩乇浠??熱紓?臣復尾饈裕?惺焙蠔茫?惺焙蠆緩茫?⒚揮泄媛煽裳?W詈蠓⑾衷?詞且蛭??綺晃榷ㄔ斐傘G肭蠓禱乇浠?S惺焙虻詼?吻肭蟮哪諶萑【鲇詰諞淮蔚姆禱匭畔ⅲㄒ簿褪撬?降摹骯亓?保??庵止亓?話閫ü齭tring的parse實現，而這一般都不是很可靠，返回一旦變化，可能就會出錯。

　　應用服務器如果是集群，一個用戶請求某一臺服務器能得到正確返回，但是如果換做另一個用戶，可能該服務器并沒有該用戶的信息，所以返回錯誤。

　　性能測試經驗交流——客戶端并發

　　測試客戶端要模擬高并發，必然要啟動多線程，所以肯定也會存在線程并發問題。比如：

　　在做參數化的時候，存儲參數的數組就是一個共享對象。如果要使每個線程的每次循環都讀取不一樣的參數，那數組下標的更新需要注意并發問題。

　　比如，如果在腳本中要調用System.out，那么也需要注意這也是一個共享對象，如果調用System.out過多，會導致線程的等待，使客戶端性能降低。

　　性能測試經驗交流——測試人員

　　性能測試由于涉及面廣，對測試人員的要求就很高。我想，性能測試人員應該培養如下幾方面的能力：

　　如前所述，對應用架構的透徹理解。

　　溝通能力，測試進行過程中，一定要培養勤于跟開發溝通的意識，以提高工作效率。

　　解決問題的能力，在編腳本或者測試執行過程中，會碰到很多問題。首先是不要害怕，先考慮問題的可能原因，然后一步步定位、驗證。當然，這個過程，需要調試等經驗的不斷積累。

原文轉自：http://www.uml.org.cn/Test/20114111.asp