性能測試淺談(2)

　　至于具體如何去設定，是需要同業務負責人(一般為PM)和技術負責人(一般為設計人員)共同確認的，業務負責人了解用戶的實際需求和期望，技術負責人了解具體的實現，可以判斷哪些是不可達到的要求。

　　一旦達成了共識，那么測試就要嚴格的按照標準去執行。

　　3.測試設計

　　主要從上面提到的幾個方面進行分析，針對系統的特點設計出合理的測試場景。為了讓測試結果更加準確，這里需要很細致的工作。如建立用戶模型，只有知道真實的用戶是如何對系統產生壓力，才可以設計出有代表性的壓力測試場景。這就涉及到很多信息，如用戶群的分布、各類型用戶用到的功能、用戶的使用習慣、工作時間段、系統各模塊壓力分布等等。只有從多方面不斷的積累這種數據，才會讓壓力場景更有意義。最后將設計場景轉換成具體的用例。

　　測試數據的設計也是一個重點且容易出問題的地方。生成測試數據量達到未來預期數量只是最基礎的一步，更需要考慮的是數據的分布是否合理，需要仔細的確認程序中使用到的各種查詢條件，這些重點列的數值要盡可能的模擬真實的數據分布(數據統計信息、執行計劃相關的內容，此處就不細說了)，否則測試的結果可能是無效的。

　　此外，性能測試執行過程中，需要監控收集的各種指標數據，也需要明確下來。

　　4.測試環境準備

　　部署測試環境，生成測試數據，環境預調優等等。預調優指根據系統的特點和自己的經驗，提前對系統的各個方面做一些優化調整，避免測試執行過程中的無謂返工。比如一個高并發的系統，10000人在線，連接池和線程池的配置還用默認的，顯然是會測出問題的。

　　5.測試執行、監控

　　準備測試腳本，執行之前設計好的各個用例，監控并收集需要的數據。出現問題時，切記要全面的保留事故現場、或者是能進行分析的數據。比如TOMCAT不再響應，不能只把這個現象記錄下來，這對問題的排查定位是沒有意義的，要保留所有相關的日志，導出線程轉儲和堆轉儲。

　　6.問題分析定位、調優

　　發現問題或者性能指標達不到預期，及時的分析定位，處理后重復測試過程。

　　性能問題通常是相互關聯相互影響的，表面上看到的現象很可能不是根本問題，而是另一處出現問題后引起的反應。這就要求監控收集數據時要全面，從多方面多個角度去判斷定位。

　　調優的過程其實也是一種平衡的過程，在系統的多個方面達到一個平衡即可。

　　7.性能報告

　　將測試過程中記錄的各種數據匯總成報告，將各方面需要的結果清楚的展現出來。

　　上面所有內容中，如果排除技術上的問題，性能測試中最難做好的，就是用戶模型(或者叫系統使用模型)的分析。它直接決定了壓力測試場景是否能夠有效的模擬真實世界壓力，而正是這種對真實壓力的模擬，才使性能測試有了更大的意義?？梢哉f，性能測試做到一定程度，差距就體現在了模型建立上。

　　至于性能問題的分析、定位或者調優，很大程度是一種技術問題，需要多方面的專業知識。數據庫、操作系統、網絡、開發都是一個合格的性能測試人員需要擁有的技能，只有這樣，才能從多角度全方位的去考慮分析問題。

　　當然，對于測試人員來說，技術能力只能排在第二號，測試思想才是最根本的。敏銳的嗅覺、嚴謹的邏輯、合理的推測、大膽的實踐是一個合格測試工程師的必備要素。

　　模擬演練

　　寫了一大堆，新手還是不知道如何去做。其實寫本文的目的也不是講具體操作，而是思想，思想。新手學性能測試，建議找一本從LOADRUNNER開講的書比較好。如51TESTING上有連載的《性能測試從零開始》。

　　不過還是盡量說點具體些的內容吧。

　　普通BS架構的系統，一般都采用測試工具(如LR)直接錄制手工操作的方式進行測試。這種方式簡單有效，對測試人員要求不高。但在一些情況下，這種基于錄制的方法可能無法完成，比如頁面上有特殊控件、系統是CS架構、或者通訊的協議無法捕獲等。這時就需要更復雜的測試方法，如手動編寫模擬客戶端的JAVA代碼，而把測試工具當作一個調度控制臺，去調度大量的虛擬用戶線程執行編寫好的代碼。

　　現在假設有一個簡易版的12306網站，JAVA實現，中間件為TOMCAT，數據庫為SYBASE，沒有集群處理(一切從簡，只有查詢和訂票功能)。如何對它進行性能測試呢?

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