上周剛剛做完項目的性能測試。今天整理和總結一下，隨便分享給大家。
首頁呢，測試前，我們是有明確的性能指標的，而且測試環境和數據都已准備好，業務分析、場景分析大家根據自己的項目系統進行分析設計，我們選用的都是實際用戶操作頻繁、重要級別高的。還有一個好說明下，今天分享的是Jmeter做APP端的單接口性能測試。下面開始分享吧。
先貼一張我的腳本：
第一步，環境是運維搭建好，那我們只需要准備腳本和腳本數據。從上面的圖中可以看出，我們需要准備：
1、需要開發幫忙去掉系統中的手機驗證碼、token的校驗，因為我們是單接口，因此是繞過登錄的，token校驗呢去掉，用戶ID的校驗還是要保留的。
2、腳本數據：我用的是CSV，每個接口的請求數據，比如關鍵字查詢，我們的業務是用戶登錄成功后，在首頁可以進行關鍵字查詢。那么我在我的CSV文件中准備了200個賬號的用戶ID和對應的關鍵字，根據你的性能指標去准備需要用多少個賬號，當然，你也可以就用一個賬號，不過還是沒有前者實際。
3、編寫接口腳本，除了去掉token校驗和驗證碼校驗，我們還需要自己在腳本中處理參數和參數的加密以及時間戳等，我用的是JSR223 中的JS，引用了一個外部js文件做加密處理。當然如果開發願意，也可以協商去掉密碼。腳本編寫好了，要在測試環境進行測試，看是否能跑通。
4、添加一個定時器，用來確保按照需求進行正確的並發。
5、添加Jmeter插件，監控壓力機與服務器的硬件性能情況。比如CPU、內存、網絡、磁盤讀寫。
以上步驟全部搞定，那么性能測試工作就差不多准備完了。
第二步，開始執行。這個步驟很關鍵也很深。很多人對Jmeter做性能測試，認為只是簡單的設置線程數就OK了。其實不然。
1、保證我們的腳本執行正確、發送正確的參數，得到正確的響應。那我是添加了結果響應斷言，來確保結果的正確性，還有一些注意的，比如：
2、確保正確並發。單純的設置線程數量和Ramp-up是達不到真正的並發的，可以通過結果觀察樹，查看每個請求的開始時間是否一樣。這里呢，我是通過定時器來做的，如下：
線程數設置10，ramp-up設置5，循環1次。定時器中的組合設置10，超時設置10秒。意思就是：
5秒內啟動10個線程，等全部啟動完，也就是說10個線程准備好了，再一起發送，這樣的操作執行1次。
線程數，不多做解釋了，大家都明白。
Ramp-up：這個呢，字面意思也是很好理解的，就是在設置的時間內啟動設置的線程數，啟動完一個發送一個。那么會出現些什么情況呢？
a、設置的時間過短，不能在設置的時間內啟動全部線程 （這也會為什么定時器的超時哪里要設置比Ramp-up的值大或等於的原因）
b、壓力機不同，在相同的時間內，能啟動的線程數量不同。這個就要看配置了。
一般我是先設置3秒或者5秒來測試自己的壓力機合適設置多少。
定時器超時時間：如果Ramp-up設置的時間內，沒有全部啟動線程，就會處於等待狀態，等待的時間就是這個超時時間。
所以，在做並發測試的時候，一定要注意，每個請求的開始時間是否一致
3、分布式，大家都知道，單台壓力機可能不夠，那么需要用到多台壓力機，這就是Jmeter分布式的運用。具體用法百度很多，需要注意以下幾點：
a、每個壓力機上都需要放腳本，而且路徑一致
b、使用了CSV文件的，也需要保存每個壓力機上的CSV文件一致，腳本修改都要同步更新，保持一致
c、每個壓力機上的本地時間要保存一致，最好是同步Intelnet上的時間。不然並發也達不到真正的並發。
4、注意壓力機自身的壓力瓶頸。測試的過程中，要時刻觀察壓力機的情況。有時候線程數較多，一起並發，會瞬間對壓力機產生很多壓力。
5、觀察服務器的性能變化。
6、建議在執行的過程中，要逐步加壓，找到RT與TPS的交叉點（即TPS由上升到下降的那個點）
7、最后還要建議，測試的時候，最好選用壓力機的配置不要太差，還有網絡。
好了，測試完成，大家要開始寫報告了，把你的測試過程、測試結果、以及你的分析寫出來吧。
其實這也是我第二次真正意義上的做性能測試，自己也是一邊學習一邊摸索，其實我覺得性能測試是分成兩個部分的，一個部分是測試執行，一個部分是問題分析，今天給大家分享的是測試執行，至於問題分析，可是很深的一門學問，需要慢慢累積，不過大家只要先保證，測試方案得到評審，測試也是正確的執行，這個過程中，其實你就會發現很多問題和學習到很多東西，最后把這些報告，然后協助開發一起分析問題，弄懂問題的原因，我想我們就會越來越能干了。歡迎大家來討論。