知識星球（點選上方公眾號，可快速關註）
來源：koala bear，
wsfdl.com/devops/2018/03/30/importance_of_testing.html
首先從一段真實經歷講起，這是一段悲慘的經歷。數年前的老東家盯上了一塊大蛋糕，欲基於開源專案研發一套平臺級別的解決方案。那時理想崇高，但經驗很缺乏，步子邁的大，扯的蛋也很疼。任務緊急怎麼辦？大家一起來做需求，所以早中期無力構建一套 CI／CD，每當提交程式碼時，手工(簡單的)驗證下即可合入。對於一個千萬行程式碼級別平臺來說，裡面種種依賴，數百路人馬的程式碼合入一起，結果實在太美。首先幾百個 API，如果沒有自動化測試，手工驗證的效率極其低下，改寫率也非常低，質量難以保證；其次，各路人馬交叉合入，不經意間互相影響了對方的邏輯，竟然多次出現如介面都對不上的低階錯誤，甚至連一個可行的開發測試環境都搭建困難，大量的時間耗費在定位問題和扯皮上。縱然長期高強度通宵，穩定的版本依舊遲遲難產，交付日期一拖再拖再再再拖。
雖然能理解任務緊急，更明白平臺級別的軟體研發本身就充滿挑戰。但是忽視自動化測試(CI)的行為為以後低效痛苦的研發埋下了伏筆，撿了芝麻丟了西瓜。
為什麼需要測試
那麼為什麼需要自動化測試，更具體的說，為什麼合入程式碼前，一定要跑通測試用例，甚至增加測試用例？原因主要有兩點：
-
確保本次 commit 不會影響其它部分的邏輯。
-
確保本次 commit 的功能程式碼無 bug。
其中第一點是最重要因素。試想，在一個較大的專案裡，你還記得一個月前寫的程式碼嗎？你還記得小夥伴們提交了什麼程式碼？你知道這一處程式碼對上下游的影響嗎？這時，自動化測試的好處就顯而易見了，它能在較短的時間內確定本次 commit 對整體邏輯的影響，如果自動化測試用例全部跑過，意味著它影響其它部分業務邏輯的機率就很低。如果說我們在建一座大廈，自動化測試則保證了每一塊磚，每一粒沙都是透過質檢要求的。
《快速軟體開發》指出：“修改一個 bug 的代價是在 bug 產生時修改它的代價的 10 倍。” 本人甚至覺得，對於一個較為複雜的系統，代價遠遠不止 10 倍。磨刀不誤砍柴工，在研發流程中，自動化測試就是一把鋒利的寶劍，它在一定程度上高效的保證了合入的程式碼的可靠性，它是快速迭代的基礎之一，最終提升了研發效率，保證產品質量。
防火勝於救火，我們要透過多種手段儘量避免 bug。營造一個循序漸進，有成就感的開髮狀態；避免搞出一坨 shit，人人充當救火隊員。
測試的分類
從層次的緯度，可以將測試分為三類
-
單元測試
-
整合測試
-
效能測試
單元測試(Unit Test)是面向函式級別的測試用例，由開發人員編寫，測試某個或者多個函式的功能。單元測試環境應該容易搭建和執行，執行時一般不依賴其它的服務：如資料庫，快取，第三方服務等，所以在產生其它依賴的地方往往需要 mock 框架，如此有利於提升開發效率。單元測試註重改寫率，通常情況下，70-80% 左右的改寫率往往滿足絕大部分場景。
整合測試(Integration Test)是面向 API 級別的測試用例，由開發／測試人員編寫，測試一個或者多個 API 的功能是否正常，多個元件之間是否互相配合，正常工作。整合測試環境的搭建相對比較複雜，它可能依賴資料庫，快取，第三方服務等，一般為大家共用。
效能測試(Performance Test)主要用於測試效能，分析效能瓶頸等，屬於高階別的測試類似。受多種條件影響，不同應用的效能測試方式各有差異，在此不多展開。
通常情況下，每次 commit 都應該先跑通單元測試和整合測試後才能提交 merge request。每次釋出上線時，一定要確保釋出的版本能透過單元測試和整合測試，某些應用甚至要求跑通效能測試。
什麼時候更需要測試
專案的核心程度
不言而喻，越是核心的專案，越是需要測試用例保證其程式碼質量。
程式碼量
整個專案的程式碼量越大，越需要測試用例來保障其質量。程式碼量越大，意味著越難以熟諳所有的邏輯，每次 commit 帶來的不確定影響越大。個人認為，當功能程式碼在數千行內，自行決定是否需要測試；當功能程式碼超過 5000 行時，請補上單元測試，對於有 API 的應用，請補充整合測試。
開發人員數量
開發人員數量越多，越需要測試用例。當開發人員越多時，特別當水平層次不齊時，會極大的增加溝通成本，降低研發效率，增加引入缺陷的機率。所以研發人員越多，越需要一個自動化門檻，濾那些低質量的 commit。
程式語言
都說動態一時爽，重構火葬場。一般來說，動態型別的語言在執行期間做資料型別的檢查，如 Python，Ruby；而靜態型別的語言一樣需要嚴格的定義資料型別，併在編譯期間做檢查資料型別，如 C 等。所以 Python 等動態型別語言比靜態語言更需要測試。
專案研發週期
對於開源專案，一般開源專案都有豐富的測試用例，在做任何開發和迭代之前，建議先搭建 CI／CD，然後逐步迭代把車開起來。
對於自研專案，在專案開發初期，首先需要設計好架構，並對一些重要第三方模組選型。所以在專案初期的不確定性會比較大，如果過早的設計測試框架和用例，反而容易成為絆腳石，降低研發效率。當專案的架構較為穩定，核心的模組均已選型，基本功能可用時。就需要為該專案新增測試框架，補充測試用例，並達到一定的改寫率，為以後的迭代開發提供扎實的基礎。
看完本文有收穫？請轉發分享給更多人
關註「ImportNew」，提升Java技能
