01 為什么需要測試

我們按照產品確定的需求，用編程語言把需求邏輯實現了。但是，怎么驗證我們的代碼實現是符合產品的需求呢？這個時候，就需要測試了。

02 測試的分類

就我們常見的測試，有以下幾種類型。
1）前端功能的手工測試，即像正常的用戶一樣，手工使用我們開發出來的每個功能，如果軟件的一切流程都符合需求的預期，就說明測試通過了。

2） 后端的接口測試，與前端測試類似，也是通過輸入參數，請求接口后，獲得響應值。通過觀察響應值與預期值的比較，得出測試結果。

以上兩類手工測試的步驟，其實又可以通過腳本錄制或編寫，實現自動化測試。

3）單元用例測試。這個是從更細的粒度來對代碼邏輯進行測試，它關注的往往是比較單一的小代碼片段，一個函數或方法，就可以編寫對應的單元測試。

4）性能測試。顧名思義，就是針對性能進行的測試，通過大量的并發請求，來測試服務器的處理能力；通過多任務處理，來測試前端渲染的速度，等等，都是性能測試。

5）安全測試。從安全的角度來對軟件進行測試，就是類似黑客攻擊的方式，嘗試找出代碼可能存在的安全漏洞。

03 該怎樣對待測試

在編程界，有“測試驅動”的開發模式，就是在寫代碼前，先寫測試用例，每次覺得代碼邏輯寫完了，就跑一遍測試用例，只有測試通過了才算完成。但是，據我了解，大部分的開發人員，包括我，也沒有能夠按照“測試驅動”的模式開發。

很多時候，我們都是在需求排期壓力下，匆匆寫完業務邏輯就算完成開發了。如果要求嚴格一點的公司，會要求測試用例，但那也是在開發完需求后，再按照已完成的邏輯，造出來一些簡單的用例，其測試點根本無法覆蓋大部分的邊界條件。

在這么多年的開發經驗里，我覺得測試是我們開發人員一個很容易忽略的地方。如果能認真對待測試，其實對我們的代碼質量會有很大的幫助，也減輕了將來重構代碼的負擔。有時候，我們要動一塊很久前的代碼，即使這段代碼是自己寫的，也不太記得當時的邏輯細節了。如果有完善的測試用例，不管你怎么改，只要保證測試用例能通過，就基本不會出錯了。

04 后端怎樣做好測試

作為一名后端開發人員，首先是要保證單元測試的覆蓋率。從細粒度上就保證了覆蓋大部分代碼，那么最終交付的代碼就會比較穩定。當你看一個方法不順眼，要把它重構的時候，只要保證對這個方法的調用方能得到同樣的結果，就可以放心地改了。

接口測試是必須的。我們最終交付出去的，其實是前端需要的一個個接口，因此，對接口進行測試，是對我們工作成果的保障。后端提供的接口，有可能是不同版本的前端都會調用的，我們每次修改代碼，都必須滿足所有支持的在用版本。沒有接口測試，前端同學每次聯調都發現得到不同的結果，是會 kill 人的啊。

性能測試視情況來做。如果項目的目標用戶數是一個較大的數量級，就要考慮系統的性能問題了。而對于一般的內部幾百人使用的系統，一般也不會有太大的性能問題，等客戶反饋操作響應慢時，再關注性能問題也可。

05 測試工具的使用

對于JAVA程序員來說，單元測試一般是JUnit了，而接口測試和性能測試，我覺得都可以使用JMeter這款開源工具。這些都是比較成熟，通用的測試工具，有社區的支持，也有大量用戶的使用分享。工具不在多，在于熟練精通。用好一個工具，自己有能力還可以擴展工具，使自己的能力得到延續，就是很好的選擇。

06 結語

做任何事情，都應該認真對待。要想寫出穩定、高質量的代碼，就要認真做好測試這件事；要想在技術之路上走得更遠，就不能滿足于實現需求。每一個好開發，都應該是一個好測試。