測試的重要性

（點擊

上方公眾號

，可快速關注）

來源：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技能

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！