【軟件測試】測試才是項目的主導，憑什么聽開發(fā)的？

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

那么各位測試大大準備好“挾天產(chǎn)品以令開發(fā)”了嗎？

一、反應真實需求

這里存在先寫測試和后寫測試的區(qū)別。

先說后寫測試。根據(jù)很多經(jīng)驗，在直接寫產(chǎn)品實現(xiàn)代碼時，需要考慮需求，同時需要兼顧實現(xiàn)的細節(jié)，用什么算法和語法。在對需求和考慮和實現(xiàn)細節(jié)間來回，很容易讓人產(chǎn)生對其中一方的疏忽，遺漏掉一些需求方面，甚至在實現(xiàn)上存在缺陷。

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

結果就是，一旦代碼簽入，開始集成之后，暴露出問題，后補的測試起不到對于實現(xiàn)代碼的保障需求的作用，開發(fā)者不能不借助調試工具，單步跟蹤實現(xiàn)代碼的每一行去尋找問題發(fā)生的原因。

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

這里的重點在于，先寫測試可以讓開發(fā)者把重點放在理解需求和實現(xiàn)需求上，而不是一開始就陷入實現(xiàn)的細節(jié)中同時兼顧需求，掉入兩者都兼顧不好的境地。先寫的測試代碼，作為副產(chǎn)品，可以作為驗證需求的得力保障。

二、設計在其中

先寫測試對于設計的好處在于，先寫測試先定義新的類，以及定義類與類之間的關系，就是在定義類與類之間如何交互，每個類如何暴露自己的接口，類和類之間的引用關系。這時，測試代碼會逼迫開發(fā)者認真考慮如何分解類與類之間的耦合關系，這樣產(chǎn)生的實現(xiàn)代碼更容易利用了IoC和DIP的模式，實現(xiàn)面向接口編程。

這樣實現(xiàn)代碼的好處還在于，代碼的可測試性很高，在加入更多的測試代碼和新類的時候，同樣借力于已有類的面向接口和依賴反轉所帶來的可測試性，達到新實現(xiàn)代碼的面向接口和可測試性，這樣進入良性循環(huán)。而這對于整體的代碼和設計，獲益良多。換句話說，測試即設計。

回頭看后寫測試的情況，因為從一開始開發(fā)者把重心放在實現(xiàn)的細節(jié)和功能需求的往復上，對于代碼設計、類的關系和定義很容易疏于考慮，產(chǎn)生的結果可能是耦合緊，可測試性差。

三、增強信息

在我看來，軟件開發(fā)周期、軟件交付最大的問題在于交付后的運行和維護階段，正是這個階段才是軟件在持續(xù)交付價值的時期。在軟件的可維護性，在這個階段凸顯價值。在軟件交付后，包括軟件開發(fā)周期期間，不可避免的就是開發(fā)者在根據(jù)新的需求，逐漸添加新的功能代碼，或者修復一些已知的缺陷。

很多經(jīng)驗表明，在開發(fā)者按照需求添加一些新的代碼進入系統(tǒng)，或者試圖修復已有缺陷時，很容易導致既有功能出錯，也就是新引入的代碼打破了既有代碼的邏輯，導致回歸問題的出現(xiàn)。因為軟件系統(tǒng)的可測試性差，無法做到快速頻繁自動的回歸測試，帶來的可維護性自然也很差。

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

在持續(xù)集成中，這些測試代碼可以幫助驗證每次簽入的代碼都不會破壞掉已有的功能。這也是《重構》里面反復提到的在每個重構小步驟后都要運行所有的測試代碼的原因所在。

四、粒度與進度

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

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

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

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

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