簡述
工作以來，主要做企業級Web應用開發，我主要的後端技術棧JAVA，Spring生態，Maven， 從項目構建到業務代碼的完成，單元測試免不了，不過大部分的測試我是直接用PostMan/PostWoman測接口，看測試結果，出問題了直接Debug。有些業務場景涉及到併發操作的，我會直接用JMeter + Badboy去實現併發測試。
作爲一名程序員，不僅要保證自己寫的代碼能通過編譯，正常地運行，而且要滿足需求和設計預期的效果。
下面我從自身工作經歷簡單羅列下自己常用的測試工具。
單元測試框架/工具
JUnit
我目前一直用JUnit4；
這裏給出一個別人的入門教程：JUnit4單元測試入門教程
注：雖然這個這個教程裏面有些內容有點滯後，但是不影響入門JUnit4；
如果你用maven構建項目的話，配置JUnit4依賴就可以在你的代碼中使用JUnit4測試框架了；
小技巧：IDE有生成測試代碼的快捷鍵，用起來很方便，不要自己瞎倒騰從0到1的去寫測試類，沒有必要這樣子。
IDE是啥？
Integrated Development Environment, 例如Eclipse、IntelliJ IDEA這樣的集成開發環境；
TestNG
個人直觀的感受是日常使用和JUnit4差不多，我並沒有把它用出花來（我沒有深度使用過它）。
參考資料：TestNG詳解-深度好文
Mockito
Mockito 是一個強大的用於 Java 開發的模擬測試框架, 通過 Mockito 我們可以創建和配置 Mock 對象, 進而簡化有外部依賴的類的測試.
使用 Mockito 的大致流程如下:
• 創建外部依賴的 Mock 對象, 然後將此 Mock 對象注入到測試類中.
• 執行測試代碼.
• 校驗測試代碼是否執行正確.
爲什麼要使用Mock?
在單元測試中，模擬對象可以模擬複雜的、真實的（非模擬）對象的行爲， 如果真實的對象無法放入單元測試中，使用模擬對象就很有幫助。
哪些場景，可能需要使用模擬對象來代替真實對象
- 真實對象的行爲是不確定的（例如，當前的時間或當前的溫度）；
- 真實對象很難搭建起來；
- 真實對象的行爲很難觸發（例如，網絡錯誤）；
- 真實對象速度很慢（例如，一個完整的數據庫，在測試之前可能需要初始化）；
- 真實的對象是用戶界面，或包括用戶界面在內；
- 真實的對象使用了回調機制；
- 真實對象可能還不存在；
- 真實對象可能包含不能用作測試（而不是爲實際工作）的信息和方法。
例如，一個可能會在特定的時間響鈴的鬧鐘程序可能需要外部世界的當前時間。要測試這一點，測試一直要等到鬧鈴時間才知道鬧鐘程序是否正確地響鈴。如果使用一個模擬對象替代真實的對象，可以變成提供一個鬧鈴時間（不管是否實際時間）,這樣就可以隔離地測試鬧鐘程序。
摘自:維基百科 、Mock和Mockito簡介
注：建議測試框架用好一個就可以了，不過自己平時寫Demo或參與研究型的項目，可以換個框架、工具嚐嚐鮮；
併發測試工具
JMeter
開源，簡單易學，無需安裝；
The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.
JMeter 官網
注：我之前的測試搭檔用loadrunner，不過她老用不好，錄製腳本總失敗，所以我對loadrunner有個刻板的印象：不好用噻，還得花錢買。
我是爲什麼開始用BadBoy、JMeter 的呢？
2017~2018年負責某個平臺的運維開發工作，發現該平臺某個企業級Web應用在Weblogic集羣中頻繁出故障，經過分析應用的運行日誌及業務日誌發現是IO併發引起的，於是開始藉助BadBoy錄製壓測腳本、JMeter 來做壓力測試，在測試環境中復現該應用在生產環境中的故障，生成dump文件來分析、調優，爲了避免走題，後面具體的實施方案就不這裏介紹了；
入門資料：
JMeter入門教程
Jmeter+badboy環境搭建
BadBoy
項目的一般測試流程
爲什麼需要了解項目的一般測試流程呢？
團隊協作，工作協同，項目的測試流程開發人員也需要了解，因爲你面對的對象是項目經理、開發同事、你的Leader、業務人員、測試人員、用戶（或者說甲方爸爸），而這些對象由於各方面的原因，會出現項目流程安排、項目計劃錯誤或者說偏差。
比如項目經理在定開發人天時沒有想到測試人天，你的Leader也未必考慮周全測試人天（而且不是每個Leader、項目經理都懂項目流程），你的測試搭檔或許入行不久或許入職不久或許是外包的測試人員，然後項目經理Email你人天計劃表讓你確定最終開發人天的時候你也不知道測試流程，於是開發人天中沒有測試人天或者測試人天預估少了，buffer裏面也沒有考慮測試人天，後面的故事就精彩了……
注：測試人天一般由測試Leader那邊過目最終定奪，但是大部分情況下會由測試、開發商量確定。
測試流程
不同公司、不同性質（級別）的項目測試流程不一樣，下面簡單的說下項目的一般測試流程。
測試需求分析
測試人員閱讀需求，理解需求，主要就是對業務的學習，分析需求點。
這時候往往：業務、開發都會參與進來幫助測試理清業務需求，方便測試人員寫測試案例；
搭建測試環境
這個一般開發人員來做；
注：UAT前還要搭建好生產環境，一般開發和運維一起做；
編寫測試計劃
這個一般是測試人員瞭解清楚項目的業務需求後製定給出；
編寫測試用例
測試計劃確定了以後，測試人員便開始編寫測試用例；
編寫測試用例一般有模板文檔，每個公司測試用例模板文檔不一樣；
注：
（1）編寫測試用例是一件枯燥且辛苦的事情，一定程度上可以檢驗測試人員是否理解了業務；
（2）通過和測試搭檔聊天瞭解到他們在做測試案例的時候同一個功能要寫正面正例,反例（多種），有時候反例考慮不全會出現一些明顯的、可以避免的bug沒有被測到；
（3）對測試好點，體諒是一方面，另一方面是：也給自己留條後路；
集成測試（SIT）
測試人員做；
SIT (System Integration Testing) 系統集成測試，也叫做集成測試，是軟件測試的一個術語，在其中單獨的軟件模塊被合併和作爲一個組測試。它在單元測試以後和在系統測試之前。集成測試在已經被單元測試檢驗後進行作爲它的輸入模式，組織它們在更大的集合，和遞送，作爲它的輸出，集成系統爲系統測試做準備。集成測試的目的是校驗功能、性能和可靠性要求，配置在主設計項目中。
系統測試（ST）
從技術角度看，系統測試是整個測試階段的最後一步，所有的開發和測試在這一點上集中表現爲生成一個具有一定功能的軟件系統。
該階段主要對系統的準確性及完整性等方面進行測試。
主要進行： 功能確認測試、運行測試、強度測試、恢復測試、安全性測試等。
系統測試的測試人員由測試組成員（或質量保證人員）或測試組成員與用戶共同測試。在整個系統開發完成，即將交付用戶使用前進行。在這一階段，完全採用黑盒法對整個系統進行測試。
用戶驗收測試(UAT)
用戶來測；
UAT (User Acceptance Testing)用戶驗收測試，通常是由最終軟件的用戶（通常這些用戶不瞭解軟件的具體邏輯，而對業務邏輯卻相當熟悉）進行的測試，因此是面向最終用戶的測試，結束之後通常就可以發佈生產環境了。