最近，在做API的壓力測試，趟了不少坑，然後呢，簡要記錄一下。
壓測前需要準備的一些事
拿到API文檔不要立馬上手，先基準測試，就是執行一次接口測試，至少要壓這個接口，要先熟悉一下他的參數，參數的含義，讀寫哪張表，修改了哪些字段，接口和接口是否有關聯（如上課和下課的接口，必須先上課，再下課），還有接口使用的數據能否複用（如獲取個人信息的接口及參數，可以獲取上萬次，但是刪除文件的接口，接口實現的功能刪除A文件，即使壓10000次，他都只刪了一個文件）等等。
與開發和產品過一遍接口，最好挨個分析一次。開發提供的接口文檔不一定所有的都能進行壓，所以先分析，並且可以把上一步發現的問題拋出來，大家一起研究研究，這個接口壓不壓，怎麼壓，還有儘可能地讓寫數據庫的同事或者開發同事簡單地講一下接口和涉及到的數據庫（如接口的功能是把status由1改爲0，如果想複用剛纔的參數接着壓，需要再把這個的status由0改爲1，方便再用）。
壓力源服務器、被壓服務器、以及數據庫的權限提前都準備好。
壓力源服務器的賬戶和密碼肯定要有，要不然怎麼壓，除非在本地執行；
被壓服務器，登錄看一下CPU、內存、執行日誌、安裝一些Agent工具等，都是很有必要的；
數據庫的權限一定要有，這個和熟悉接口有關係，接口報錯的時候也可以排查錯誤，還有很重要的一點就是造數據。再舉個例子，比如要執行一個結束課程的接口，結束後修改了很多的字段，尤其是自動填入日期這種的，在數據庫無法直接操作，人爲無法干預的，也沒有別的接口可以修改（除非讓開發專門爲了壓測再寫一個還原狀態的接口，跑一次壓測），結束課了就是結束了，這節課就作廢了，不能複用，這類型的接口，就要提前用別的創建課程、再開始課程的接口去製造大量未結束的課程，或者在數據庫直接插入大量的未結束課程的數據，然後在測。
壓力執行參數也要準備、壓力數據也要準備
壓力執行參數，就是這個接口用多少個線程、多大的連接數、持續多久、延遲多久等等。
壓力數據要準備，比如壓測1000個用戶的登錄，至少要準備1000個賬號和密碼吧（當然有緩存的那種接口要這樣做，沒有緩存的那種，可以視情況，把一個學生登錄1000次也可以）。
一些小技能
把壓力源和被壓服務器的時間設置爲一致的，我指的是測試環境的，不是去改線上環境的。
壓測的日誌、或者產生的文件不要刪除，可以做什麼呢，分析結果肯定是很重要的、要看QPS這些的。還要更重要的是，可以看CPU或者帶寬佔用的一些信息。在壓的同時在被壓服務器的Linux機器上執行top命令是可以看，但是要是看曲線呢，難道邊壓測，邊記錄數據，這多費事。（舉個例子，我用JMeter壓阿里雲的Linux機器，可以將產生的jtl文件規範命名，不要隨便寫，否則後面會麻煩，最好命名包含的越詳細越好，接口名、併發量、持續時間、第幾次執行，不建議加中文，誰知道會出現什麼問題，當壓測完後，想知道某一個接口的cpu佔用及帶寬，在這個日誌裏看一下開始時間和結束的大概時間，然後登錄阿里雲的後臺，尋找對應的時間點不就一目瞭然了）。
區分好關聯接口的關係，排好順序，不要逆序走，吃虧的時候就當長一次教訓了。
投機取巧的方法，有些操作數據庫力度不大的，沒有多大影響的，可以把數據庫中已有的數據導出來，篩選篩選，過濾過濾，沒準還能用，就看運氣好不好。
常見需要斟酌的接口類型
單場景的：就執行這一個接口，不與其他接口或者數據有關聯；
複合場景的，舉個例子，A站在門口，門是關着的，要想進入室內，首先要執行打開門的這個操作，然後才能進入室內，這種是有關聯關係的接口；
不操作數據庫的，只是服務端程序返回的一個狀態，不查詢或者操作數據庫；
操作數據庫，這個真的是涵蓋了增刪改查，註冊1000個用戶，這叫增，需要準備好1000個賬號和密碼，要不然沒法壓測。刪除也是這個道理，要刪除1000個用戶，首先數據庫裏要準備好1000個用戶可以讓你刪除。當然也不是沒有捷徑可以走，要註冊1000個用戶，可以註冊完一個，然後刪掉，再註冊，涉及到的數據表少還可以，要是註冊一個學生，寫了很多表，用接口刪數據，那就很費事了；
有關聯關係的接口要注意，比如，要執行發送消息的接口，但是這個接口的前提是判斷是否登錄，所在執行發送消息之前，要先執行登錄的接口；
修改同一個字段的接口要排好順序，打個比方（詞窮了），就比如向“進門”和“出門”改的是同一個字段，沒有進門前status=0，進門了status=1，出門了status=2，只能從0>1>2，不能逆序，從2無法到1，這種情況如果代碼邏輯不嚴謹，先執行了“出門”操作，直接把狀態從0轉到了2，如果要再執行“進門”操作，又要準備一大堆的數據，像這種有關係的接口，代碼邏輯嚴不嚴謹先不考慮，先執行從0到1，執行從1到2；
上傳文件的接口，這個接口寫出來是提醒要注意的，覺得不用壓，運氣好一點就遇上“墨菲定律”了；
發送驗證碼、輸入驗證碼、校驗驗證碼，這種我到目前還沒轍；
幾個數據庫關聯的那種，一定要慎之又慎，之前遇到一個關聯數據庫的，壓測的賬號是別的數據庫提供的，這次壓測還和那個數據庫的產品沒有任何關係，那個造數據和使用數據庫權限還要走流程，這個時候那就走流程吧，保佑壓測不會影響到別的業務，當然也不是沒有辦法，把以前的數據導出來，研究一下，找到一個能用的，然後把和它特點一樣的拿出來用。