很多時候很多公司都是產品說了算，在之後就是開發，測試的地位比較低，但是事實真的是這樣嗎，成熟的專案進行中應該是測試人員作為主導的，測試是唯一一個最早進入專案、最後確認專案完工的職位，所以本文就是幫助大家糾正這個錯誤

那麼各位測試大大準備好“挾天產品以令開發”了嗎？

一、反應真實需求

這裡存在先寫測試和後寫測試的區別。

先說後寫測試。根據很多經驗，在直接寫產品實現程式碼時，需要考慮需求，同時需要兼顧實現的細節，用什麼演算法和語法。在對需求和考慮和實現細節間來回，很容易讓人產生對其中一方的疏忽，遺漏掉一些需求方面，甚至在實現上存在缺陷。

有人會說我可以通過後寫測試來保證。第一經驗是，很多人都不會在實現完成後，補充測試，因為還有更多的工作和需求需要實現。第二是開發人員很容易在後補的測試中，只是試圖去測試他已有的實現，而不是需求本身，很容易遺漏掉一些邊界檢查之類，在測試時，已有的實現細節會在腦子裡面先入為主，即使實現存在問題或有漏洞，也很難在後補的測試中測出來。我閱讀過很多面試者的測試程式碼，很明顯都是後補的，因為一些很明顯的問題沒有測出來，甚至已經實現的邏輯也是隻測試了一部分。而這些面試者都承認。

結果就是，一旦程式碼簽入，開始整合之後，暴露出問題，後補的測試起不到對於實現程式碼的保障需求的作用，開發者不能不借助除錯工具，單步跟蹤實現程式碼的每一行去尋找問題發生的原因。

再說先寫測試。按照TDD的流程，先寫失敗的測試，再寫恰好讓測試成功的實現程式碼，最後重構，如此往復。這樣的好處在於，每先寫一個測試，都是在試圖用自己對問題和需求的理解，來定義實現程式碼的架子。從測試的不同角度，範圍、邊界、大小、功能等等，來定義實現程式碼將來會是個什麼樣子。一個測試接著一個測試，利用TDD的過程，把實現程式碼恰好不多不少，正好驅動出解決這個需求和問題的實現程式碼來。

這裡的重點在於，先寫測試可以讓開發者把重點放在理解需求和實現需求上，而不是一開始就陷入實現的細節中同時兼顧需求，掉入兩者都兼顧不好的境地。先寫的測試程式碼，作為副產品，可以作為驗證需求的得力保障。

二、設計在其中

先寫測試對於設計的好處在於，先寫測試先定義新的類，以及定義類與類之間的關係，就是在定義類與類之間如何互動，每個類如何暴露自己的介面，類和類之間的引用關係。這時，測試程式碼會逼迫開發者認真考慮如何分解類與類之間的耦合關係，這樣產生的實現程式碼更容易利用了IoC和DIP的模式，實現面向介面程式設計。

這樣實現程式碼的好處還在於，程式碼的可測試性很高，在加入更多的測試程式碼和新類的時候，同樣借力於已有類的面向介面和依賴反轉所帶來的可測試性，達到新實現程式碼的面向介面和可測試性，這樣進入良性迴圈。而這對於整體的程式碼和設計，獲益良多。換句話說，測試即設計。

回頭看後寫測試的情況，因為從一開始開發者把重心放在實現的細節和功能需求的往復上，對於程式碼設計、類的關係和定義很容易疏於考慮，產生的結果可能是耦合緊，可測試性差。

三、增強資訊

在我看來，軟體開發週期、軟體交付最大的問題在於交付後的執行和維護階段，正是這個階段才是軟體在持續交付價值的時期。在軟體的可維護性，在這個階段凸顯價值。在軟體交付後，包括軟體開發週期期間，不可避免的就是開發者在根據新的需求，逐漸新增新的功能程式碼，或者修復一些已知的缺陷。

很多經驗表明，在開發者按照需求新增一些新的程式碼進入系統，或者試圖修復已有缺陷時，很容易導致既有功能出錯，也就是新引入的程式碼打破了既有程式碼的邏輯，導致迴歸問題的出現。因為軟體系統的可測試性差，無法做到快速頻繁自動的迴歸測試，帶來的可維護性自然也很差。

而作為TDD的副產品之一——可以快速頻繁自動執行的測試程式碼，可以在開發者新引入程式碼之際，給予開發者足夠的信心，每次新增一點新程式碼，一個方法，一個類，都已頻繁執行已有相關的測試程式碼，來確保新引入程式碼不會打破已有的功能。

在持續整合中，這些測試程式碼可以幫助驗證每次簽入的程式碼都不會破壞掉已有的功能。這也是《重構》裡面反覆提到的在每個重構小步驟後都要執行所有的測試程式碼的原因所在。

四、粒度與進度

按照TDD的原則，先寫測試，可以讓開發者在同一時間只關注在功能需求的一小部分，把功能需求且分到一定小的粒度，用測試程式碼去表示這樣的需求，用實現程式碼讓測試通過，實現這樣的需求，然後重構。

這樣的好處在於，開發者自己的注意力和重心不用在整個功能需求內的小需求點之間猶豫，每次注重解決單個小問題，解決完一個進入下一個小問題的解決。在保證小粒度實現的同時，保證進度可以隨時被打斷，但同時被打斷時已經做完的是完整可以執行，至少是實現了部分需求的實現程式碼。

而後寫測試的代價是，首先實現程式碼很有可能包含設計上的問題，甚至含有缺陷，在完美的測試程式碼完成之前（事實上這是不可能的），可以交付的是可能存在嚴重缺陷，甚至是曲解了功能需求的實現程式碼。

今天送給大家的福利是《標準版測試需求文件》文件為上市公司需求文件

需要的小夥伴可以在評論中留言