軟件開發週期通常至少有以下4個步驟：需求分析，軟件開發，測試，部署。而其中的測試是我們今天要說到的重點，今天我們來聊一聊程序員和測試這件事。
現狀
目前大部分軟件公司或者IT部門是沒有配備專門的測試人員的，測試通常依靠程序員自測，公司內部人員測試，自動化工具測試等等。
在沒有測試人員的情況下，其中最重要的環節其實是程序員自測。我們知道好的軟件並不是一蹴而就的，而是一步步迭代而成。而在迭代過程中如何有效保證軟件質量和項目週期，就離不開測試。
認清測試的重要性
在認清測試的重要性之前我們先了解一下軟件項目管理金三角具體是什麼。
我們都知道大部分情況下軟件項目想要同時滿足：“多、快、好、省”是不可能的，一般只能佔兩樣。而在軟件項目中，也有一個類似的平衡關係，就是軟件質量（產品的質量，客戶的滿意度）與範圍（需要實現多少功能）、時間（多久可以完成）、成本（花多少錢）四個要素之間的平衡。《軟件工程之美》-寶玉
我們可以看到質量是放在中間的，因爲軟件工程的目標就是要構建和維護高質量的軟件。而很顯然，想要提高質量必定離不開測試。沒有完善的測試，我們就不能確保交付一個高質量的軟件（高質量的編碼是目前很多程序員還達不到的一個要求）。
看到上圖肯定會有一個問題：時間和成本被壓縮的情況下，我們怎麼能夠保證質量？
成本低可能我只夠招到合適的開發，而專業的測試人員這一塊我們只能放棄。時間緊張，那麼我可能並沒有時間實現一個自動化測試工具或者說對每一份代碼都寫上單元測試。
很多時候，實際情況確實如此。但這並不是我們簡化測試的理由。我個人認爲：單元測試在敏捷開發模型中是必不可少的一部分（瀑布模型中留有足夠的時間給到測試），因爲敏捷開發模型是小步快跑，逐步迭代的。在項目的整個開發過程中，如果沒有配合一定量的單元測試，那麼越到後期測試的壓力越大，耽誤的時間更多。從長遠來講是不划算的。
也有人說，我用敏捷開發模型的目的就是更快推出最小可行性產品，讓市場或者說種子客戶驗證產品，完善產品。如果糾結於完善的單元測試豈不是浪費我寶貴的時間？
上面我們提到了時間、成本、範圍和質量的關係。我們這裏可以通過壓縮範圍來獲得時間，給測試留出空間，優先實現核心功能的單元測試。畢竟你出於對自己的代碼的負責性，總歸是要測試的。不管你是自己點點點還是通過接口工具一類來測試，效果都不如編寫一個完善的單元測試來的更划算。畢竟這功能你可能不止要測試一次，以後業務變更可能還需要測試，這時候你可能會忘記來測試這個功能，而單元測試能幫助你避免這個問題。
自動化測試的分類
自動化測試按照Google的分類可以簡略分爲3種：小型測試、中型測試、大型測試。
小型測試是爲了驗證一個代碼單元的功能，例如針對一個函數或者一個類的測試。上文說的的單元測試就是一個典型的小型測試。
中型測試是驗證兩個或多個模塊應用之間的交互，通常也叫集成測試。
大型測試則是從較高的層次運行，把系統作爲一個整體驗證。會驗證系統的一個或者所有子系統，從前端一直到後端數據存儲。大型測試也叫系統測試或者端對端測試。
而這裏對應程序員自測最基本的要求是能夠完成單元測試。要想提高自己的代碼質量，單元測試可能是最容易實現的一種方式。因爲他不需要你再去學習其他知識就可以提高代碼質量，你只用完善單元測試，發現問題，解決問題，這樣就能培養出好的編碼習慣。
如何培養好的測試習慣
首先一定要培養寫單元測試的習慣。但凡寫完的代碼都需要自己測試的情況下，優先考慮寫個單元測試來查驗代碼的準確性。至於時間成本的問題大家可以自己考慮，畢竟現在單元測試框架都十分的完善了，這並不會花你太多時間。
然後我們再看看在編寫一個完善的單元測試的過程中，我們應該考慮的問題：
- 驗證功能的正確性
- 覆蓋邊界條件
- 異常和錯誤處理
然後更深層次的考慮是我們在編寫代碼的時候就要考慮代碼的可測試性，常見的關鍵點有以下幾個：
- 代碼中包含未決行爲邏輯
- 濫用可變全局變量
- 濫用靜態方法
- 使用複雜的繼承關係
- 高度耦合的代碼
以上幾個關鍵點如果有興趣的同學可以自行去極客時間專欄《設計模式之美》中學習。