2）測試一些顯而易見的bug；
3）建立性能方面的信心；
4）可在測試的同學做完測試以後做一個對比，不至于偏離太過離譜。
參照測試部門的意見，我把這次的性能測試總結了如下幾個步驟：
1、測試目标和範圍：根據需要滿足的非功能需求，确定上線功能點哪些需要測試。測試性能、穩定性、最大壓力。
2、測試方案準備：包括施壓方式，環境配置，環境依賴，資源監控，整理方案文檔。
4、資料準備：根據線上預估資料，對資料庫資料進行準備和模拟。
6、進行測試：通過用戶端施壓伺服器，監控器各方面資源利用。
7、進行測試分析總結：寫測試報告。tps，吞吐量，cpu占比等。對異常現象記錄，如記憶體溢出等。
8、根據測試報告對程式進行優化或重構。
做技術還是有做技術的天性，我們開發最關心的也就是5-8的步驟。我們的應用主要以hessian接口的形式向外面暴露，另外的就是任務在背景處理接口推送過來的資料。是以，我們的測試主要集中在接口測試和任務測試。比一般網頁的性能測試更簡單一些。
在壓力測試過程中，包括兩部分的資源檢測，jvm的資源占用。一般利用jdk自帶工具集
1、jps
常用的幾個參數：
-l輸出java應用程式的mainclass的完整包
-m輸出傳遞給main方法的參數
-v輸出傳遞給jvm的參數。在診斷jvm相關問題的時候，這個參數可以檢視jvm相關參數的設定
2、jstat-javavirtualmachinestatisticsmonitoringtool
jstat[options]vmid[interval][count]
options--選項，我們一般使用-gcutil檢視gc情況還有其他選項如：
-class-compiler-gc-gccapacity-gccause-gcnew-gcnewcapacity-gcold-gcoldcapacity-gcpermcapacity-gcutil-printcompilation
vmid--vm的程序号，即目前運作的java程序号
interval--間隔時間，機關為毫秒
count--列印次數，如果預設則列印無數次
-----------------------------------------------jstat-gcutil[pid]輸出解釋
s0--heap上的survivorspace0區已使用空間的百分比
s1--heap上的survivorspace1區已使用空間的百分比
e--heap上的edenspace區已使用空間的百分比
o--heap上的oldspace區已使用空間的百分比
p--permspace區已使用空間的百分比
ygc--從應用程式啟動到采樣時發生younggc的次數
ygct--從應用程式啟動到采樣時younggc所用的時間（機關秒）
fgc--從應用程式啟動到采樣時發生fullgc的次數
fgct--從應用程式啟動到采樣時fullgc所用的時間（機關秒）
gct--從應用程式啟動到采樣時用于垃圾回收的總時間（機關秒）
3、jhat-javaheapanalysistool用于記憶體快照檔案的分析，當然還有很多類似工具
4、jstatd-virtualmachinejstatdaemon
5、jinfo-configurationinfo
6、jvisualvm-javavirtualmachinemonitoring，troubleshooting，andprofilingtool
7、jconsole-javamonitoringandmanagementconsole
8、jmap-memorymapjvm記憶體分析工具，得到最普遍的使用。
jmap-histo<pid>b。log輸出記憶體類占用，對比各時段的記憶體類，可友善知道回收情況和占用情況。
jmap-dump：format=b，file=heap。dump<pid>輸出記憶體快照，可用許多開源工具分析記憶體快照。
jprofile太耗記憶體，如果靜态分析能得出結論的可避免使用
9、jstack-stacktrace列印線程的堆棧跟蹤資訊
10、btrace-sun提供的檢測工具，很好很強大，用于檢測函數耗時等，微浸入。
而伺服器端的資源監控多用linux的shell指令如：top，free，vmstat，iostat，uptime等，詳細用法不累述。
本次測試過程中遇到的幾個誤區和犯的錯誤：
1、jmeter關于線程組的線程數和ramp-up值的設定，如果設定ramp-up為1秒，線程數為10，我錯誤的了解為這就是一秒内的請求量。其實是jmeter一秒内啟動了10個線程，這10個線程分别發送請求，知道伺服器端傳回後，再次發送。
這個錯誤的了解直接導緻我們的一個異步接口（接口把資料儲存在一個無上限queue中，另外起線程來消費）在壓力測試過程中，被壓垮，以為是記憶體洩露問題，其實隻是我們的伺服器沒能力處理這樣一個資料量。
2、在一個日志處理子產品中的生産和消費者模型中，産生的線程過多。後經過配置修改了消費者和生産者的比例。但是在定位問題時，産生很多困難，因為不知道是什麼線程出現這麼多。程式中所有的線程必須命名才友善工具的觀察，需要開發中規範和定義好。
3、對于任務類型的性能測試沒有傳回值，我們怎麼觀察任務處理一條記錄的時間，或機關時間内處理記錄的條數呢？開發 人員習慣在源代碼中去修改，并做trace，更好的方法是采用btrace工具來跟蹤方法的進出。它在監控方法的耗時，檢視某些方法的參數值，監控記憶體使 用情況等一系列場合中使用。
4、開發錯誤的了解org。springframework。scheduling。concurrent。 threadpooltaskexecutor類的corepoolsize和maxpoolsize和queuecapacity三者的關系。原以為 corepoolsize是啟動時變初始化的核心線程數，如果還有任務需要執行，那麼就會建立線程到線程池中，直到達到最大maxpoolsize的大 小。然後放不下的任務才浸入queuecapacity中存儲。而實際情況确是：任務到達corepoolsize之後，就放入 queuecapacity的queue中了。造成我們的配置錯誤，引起串行的任務執行。
的确在開發功能測試中沒有發現的問題，通過性能測試暴露了出來。除了這些bug之外，我們還确認了我們接口的性能，任務的性能和穩定性。
本文出自seven的測試人生公衆号最新内容請見作者的github頁：http://qaseven.github.io/