好久沒發文了，今天聊一下效能測試。
這是一篇關於效能測試的入門文章，沒有涉及到高大上的全鏈路壓測等等，純粹是給剛上手效能測試的小白乙個簡單的了解。當然對於一些使用者量不大、沒有做過效能測試的產品，這些入門的方法完全可以填補上效能測試這個空白。
我們首先了解下關於效能測試的幾種測試場景：
一般來說，對於乙個新系統的效能測試會通過容量測試來體現當前我們的系統到底能撐多少的併發，也算給領導乙個交代，當然這只是效能測試的開始，先把這一關扛過去。
容量測試可以按照以下步驟執行：
選取需要測試的功能模組，一般測試需要跟開發共同商定哪些功能對效能有要求，特別是那些常用的，比如登入、首頁展示等等。
選取完功能模組後劃分一下每個模組的業務比例，這個對後續的單場景和多場景有幫助。在多場景測試時可以根據業務佔比分配對應比例的併發數，盡可能接近跟真實場景。
針對每個場景梳理相關介面及介面所需要的資料。比如說我要測試登入介面的併發，最好不要用乙個賬號和密碼，而是盡量使用不同的賬號密碼，這樣更接近現實場景。當然如果**裡邊已經處理了同一賬號跟不同賬號的登入邏輯相同，則可以用乙個賬號代替。建立資料的時候寫個指令碼，要不然手工建立會把你累死，登入併發一般都要用幾十萬的賬號，乙個乙個的賬號建立啥時候能完成。。。所以學點指令碼對平時的工作還是很有用處的。
選擇效能測試工具：一般使用jmeter，不要問我為啥，開源、免費的東西就是香 ? 怎麼使用jmeter我就不在這裡說了，已經有很多類似的文章，不過針對大併發使用分布式壓測機的場景我會在另外一篇文章裡分享。
生成測試資料：我們應該先從小的併發數開始不斷的增加，建議從50開始，再使用100、150、180、200等，越到最後併發數間隔越小，使得到的併發數越準確。每個併發我們都要記錄以下資料：
介面、併發使用者數、吞吐量、評價響應時間、90%line、95%line、99%line、錯誤率、cpu%、mem%，這樣就生成了不同併發數下的資料，很直觀，一目了然。根據資料做乙個總結，比如錯誤率或者cpu、mem突然變好的轉折點就是系統的併發容量。
最後再追加乙個總的結論，對整個系統的各個模組進行評價。
以上是乙個簡單的容量測試的步驟，步驟只是乙個參考，我們執行的意義也不在於展示資料，主要還是解決影響效能的問題。在做效能測試過程中，需要多跟開發溝通，尤其是復現問題的時候看一下log，這樣也比較有目標性。
這算是乙個效能測試的開端吧，主要是幫助沒有做過效能測試的小夥伴開擴一下思路，後面會順著這個思路講一下：
記錄介面響應時間的相關工具
jmeter分布式併發
一些真實的效能測試案例
。。。
基於 JMeter 完成 Dubbo 介面的測試
開班通知 測試開發實戰高階 第 17 期即將開班，文末 免費試聽！jmeter 預設是不支援 dubbo 介面測試的，但是我們可以通過拓展的外掛程式或 jar 包實現此功能。由於我的 jmeter 是使用 mac 的 homebrew 安裝的，所以我的路徑為 usr local cellar jme...
jmeter做SOAPui介面的效能測試
url 可以直接複製帶引數請求的url，3320那原來是個?soap xml rpc data 那裡直接複製帶引數請求的部分 3320 send soapaction 這裡先不填任何東西，重新回到soapui中，切換到request 1中的raw部分，如下圖 將藍色框裡的http鏈結貼上到jmete...
C 基於介面的排序
需要注意的是int32,int16 string,decimal等資料型別已經實現了icomparable介面 因此對於複雜的資料型別進行排序的時候才考慮讓資料型別繼承自icomparable介面。icomparable介面只有乙個方法compareto。因此還要實現compareto方法。comp...