12講測試也是程序員的事嗎_W

1、12講測試也是程序員的事嗎在“任務(wù)分解”這個模塊，我準備從個讓我真正深刻理解了任務(wù)分解的主題開始，這個主題就是“測試”。這是個讓程序員愛有恨的主題，愛測試，因為它能讓項的質(zhì)量有保證；恨測試，因為測試不好寫。實際上，很多之 所以寫不好測試，主要是因為他不懂任務(wù)分解。在上個模塊，我們提到了些最佳實踐，但都是從“以終為始”這個度進講解的。這次，我準備換個 ，五講的篇幅，完整地講下“開發(fā)者測試”，讓你和我起，重新認識這個你可能忽視的主題。準備好了嗎？我們先從讓很多疑惑的話題開始：程序員該寫測試嗎？誰要做測試？你是個程序員，你當然知道為什么要測試，因為是我們開發(fā)的軟件，我們得盡可能地保證它是對的，畢竟最

2、基本的職業(yè)素養(yǎng) 是要有的。但測試作應(yīng)該誰來做，這是個很有趣的話題。很多憑直覺想到的答案是，測試不就該是測試員的事嗎，這還問？測試員應(yīng)該做測試，這是沒錯的，但是測試只是測試員的事嗎？事實上，作為程序員，你多半已經(jīng)做了很多測試作。如，在提交代碼之前，你肯定會把代碼跑遍，保證提交的基本功能 是正確的，這就是最基本的測試。但通常，你并不把它當成測試，所以，你的直覺，測試是測試員的事。但我依然要強調(diào)，測試應(yīng)該是程序員作的部分，為什么這么說呢？我們不妨想想，測試員能測的是什么？沒錯，他們只能站在系統(tǒng)外部做功能特性的測試。個軟件是由它內(nèi)部諸多模塊組 成的，測試員只從外部保障正確性，所能達到的效果是有限的。打

3、個，你 機器，每個零部件都不保證正確性，卻要讓最后的結(jié)果正確，這實在是個可笑的要求，但這卻真實地發(fā)在軟件開發(fā)的過程中。更新請加微信1182316662 眾籌更多課程19在軟件開發(fā)中有個重要的概念：軟件變更成本，它會隨著時間和開發(fā)階段逐步增加。也就是說我們要盡可能早地發(fā)現(xiàn)問題， 修正問題，這樣所消耗掉的成本才是最低的。上個模塊講“以終為始”，就是在強調(diào)盡早發(fā)現(xiàn)問題。能從需求上解決的問題，就不要到開發(fā)階段。同樣，在開發(fā)階段能解決 的問題，就不要留到測試階段。你可以想下，是你在代碼中發(fā)現(xiàn)錯誤改代碼容易，還是測試了報了 bug，你再定位找問題便。更理想的情況是，質(zhì)量保證是貫穿在軟件開發(fā)全過程中，從需求

4、開始的每個環(huán)節(jié)，都將“測試”納考量，每個交付 的作成果時，都多問句，你怎么保證交付物的質(zhì)量。需求員要確定驗收標準，開發(fā)員則要交出的開發(fā)者測試。這是個來于精益原則的重要思想：內(nèi)建質(zhì)量（Build Quality In）。所以，對于每個程序員來說，只有在開發(fā)階段把代碼和測試都寫好，才有資格說，交付的是質(zhì)量的代碼。動化測試不同于傳統(tǒng)測試員只通過的式進驗證，程序員這個群體做測試有個天然的優(yōu)勢：會寫代碼，這個優(yōu)勢可以讓我們把 測試動化。早期測試代碼，最簡單的式是另外寫個程序，我初職場的時候，也曾經(jīng)這么做過，畢竟這是種符合直覺的做法。 不過，既然程序員有寫測試的需求，如此反復出現(xiàn)的東，就會有更好的動化案。

5、于是開始測試框架出現(xiàn)了。最早的測試框架起源是 Smalltalk。這是早期的向?qū)ο蟪绦蛟O(shè)計語，它有很多擁躉，很多今天流的編程概念就來于 Smalltalk，測試框架便是其中之。真正讓測試框架泛流起來，要歸功于 Kent Beck 和 Erich Gamma。Kent Beck 是極限編程的創(chuàng)始，在軟件程領(lǐng)域名鼎鼎， Erich Gamma 則是著名的設(shè)計模式書的作者，很多熟悉的 Visual Studio Code 也有他的重貢獻。有 次 ， 起 從 往 亞 特 蘭 參 加 OOPLSA（Object-Oriented Programming, Systems, Languages & App

6、lications）會，在航班上兩個結(jié)對編程寫出了JUnit。從這個名字你便不難看出，它的標是打造個單元測試框架。順便說下，如果你知道 Kent Beck 是個狂熱的 Smalltal絲，寫過 SUnit 測試框架，就不難理解這兩個為什么能在次航班上就完成這樣的作。JUnit 之后，測試框架的概念逐漸開始流起來。如今的“程序世界”，測試框架已經(jīng)成為業(yè)標配，每個程序設(shè)計語都有的測試框架，甚不種，些語甚把它放到了標準庫，業(yè)也 XUnit 統(tǒng)稱這些測試框架。這種測試框架最的價值，是把動化測試作為種最佳實踐引到開發(fā)過程中，使得測試動作可以通過標準化的段固定下 來。測試模型：蛋卷與字塔在前的討論，我們把

7、測試分為測試和動化測試。即便我們只關(guān)注動化測試，也可以按照不同的層次進劃分：將 測試分成關(guān)注最程序模塊的單元測試、將多個模塊組合在起的集成測試，將整個系統(tǒng)組合在起的系統(tǒng)測試。有喜歡把驗收測試也放到這個分類。為了簡化討論，我們暫時忽略驗收測試。隨之來的個問題是，我們應(yīng)該寫多少不同層次的測試呢？理論上固然是越多越好了，但實際上，做任何事都是有成本的， 所以，們必須有所取舍。根據(jù)不同測試的配，也就有了不同的測試模型。有種直覺的做法是，既然越層的測試覆蓋越，那就多寫層測試，如系統(tǒng)測試。當然，有些情景層的測試不容易覆蓋到的，所以，還要有些底層的測試，如單元測試。在這種情況下，底層的測試只是 作為層測試的

8、補充，主就是層測試。這樣就會形成下這樣種測試模型：冰淇淋蛋卷。聽說過冰淇淋蛋卷測試模型的并不多，它是種費時費的模型，要準備層測試實在是太麻煩了。之所以要在這提及它，是因為雖然這個概念很多沒聽說過，但是有不少團隊的測試實際采的就是這樣種模型，這也是 很多團隊覺得測試很麻煩卻不明就的緣由。接下來，要說說另種測試模型，也是業(yè)的最佳實踐：測試字塔。更新請加微信1182316662 眾籌更多課程20Mike Cohn 在的著作Succeeding with Agile提出了測試字塔，但多數(shù)都是通過 Martin Fowler 的章知道的這個概念。從圖中我們不難看出，它乎是冰淇淋蛋卷的反轉(zhuǎn)，測試字塔的重點

9、就是越底層的測試應(yīng)該寫得越多。想要理解測試字塔成為業(yè)最佳實踐的緣由，我們需要理解不同層次測試的差異。越是底層的測試，牽扯到相關(guān)內(nèi)容越少，層測試則涉及更。如單元測試，它的關(guān)注點只有個單元，沒有其它任何東。所以，只要個單元寫好了，測試就是可以通過的；集成 測試則要把好個單元組裝到起才能測試，測試通過的前提條件是，所有這些單元都寫好了，這個周期就明顯單元測試要；系統(tǒng)測試則要把整個系統(tǒng)的各個模塊都連在起，各種數(shù)據(jù)都準備好，才可能通過。這個模塊的主題是“任務(wù)分解”，我必須強調(diào)點：事反饋周期短，事反饋周期。事容易做好，事難度則得 多。所以，以這個標準來看，底層的測試才更容易寫好。另外，因為涉及到的模塊過多

10、，任何個模塊做了調(diào)整，都有可能破壞層測試，所以，層測試通常是相對較脆弱的。 此外，在實際的作中，有些層測試會牽扯到外部系統(tǒng)，這樣來，復雜度在不斷地提升。們會本能地都會傾向于少做復雜的東，所以，們肯定不會傾向于多寫層測試，其結(jié)果必然是，層測試的測試量不會 太多，測試覆蓋率論如何都上不來。且，旦測試失敗，因為牽扯的內(nèi)容太多，定位起來也是常麻煩的。反過來，將底層測試定義為測試主體，因為牽扯的內(nèi)容少，更容易寫，才有可能讓團隊得到更多的測試，且旦出現(xiàn)問 題，也會更容易發(fā)現(xiàn)。所以，雖然冰淇淋蛋卷更符合直覺，但測試字塔才是業(yè)的最佳實踐。當測試字塔遇到持續(xù)集成測試字塔是個重要實踐的基礎(chǔ)，它就是持續(xù)集成。當測試

11、數(shù)量達到定規(guī)模，測試運的時間就會很，我們可能法在 本地環(huán)境次性運所有測試。般我們會選擇在本地運所有單元測試和集成測試，把系統(tǒng)測試放在持續(xù)集成服務(wù)器上執(zhí)。更新請加微信1182316662 眾籌更多課程21這個時候，底層測試的數(shù)量就成了關(guān)鍵，按照測試字塔模型，底層測試數(shù)量會很多，測試可以覆蓋主要的場景；按照冰淇 淋蛋卷模型，底層測試的數(shù)量則有限。作為提交代碼的防護，測試數(shù)量多寡決定著得到反饋的早晚。所以，字塔模型與持續(xù)集成天然就有著很好的配合。需要特別注意的是，不是單元測試框架寫的測試就是單元測試。很多單元測試框架寫的是集成測試或是系統(tǒng)測試。單元 測試框架只是個動化測試的具已，并不是來定義測試類型

12、的。在實際作中，區(qū)分不同測試有很多種做法，如，將不同的測試放到不同的錄下，或是給不同類型的測試個統(tǒng)的命名 規(guī)范。區(qū)分不同類型測試主要的，主要是在不同的場景下，運不同類型的測試。就像前提到的做法是，在本地運單元測試和 集成測試，在持續(xù)集成服務(wù)器上運系統(tǒng)測試。總結(jié)時刻總結(jié)下今天的內(nèi)容。測試是軟件開發(fā)重要的組成部分，測試應(yīng)該是軟件開發(fā)團隊中所有的事，不僅僅是測試員的事。 因為軟件變更成本會隨著時間和開發(fā)階段逐步增加，能在早期解決的問題，就不要將它延后下個階段。在測試問題上，程序員有著天的優(yōu)勢，會寫代碼，于是，程序員擁有了個突出的強項，動化測試。寫測試應(yīng)該是程序員作完成的重要組成部分。隨著們對于測試理

13、解的加深，各種各樣的測試都出現(xiàn)了，也開始有了測試的分類：單元測試、集成測試、系統(tǒng)測試等等。越 在底層測試，成本越低，執(zhí)越快；越在層測試，成本越，執(zhí)越慢。的時間和精是有限的，所以，們開始思考不同的測試如何組合。在這個的最佳實踐稱之為測試字塔，它強調(diào)的重 點是，越底層的測試應(yīng)該寫得越多。只有按照測試字塔的式寫測試，持續(xù)集成才能更好地發(fā)揮作。如果今天的內(nèi)容你只能記住件事，那請記住：多寫單元測試。最后，我想請你分享下，你的團隊在寫測試上遇到哪些困難呢？歡迎在留區(qū)寫下你的想法。 感謝閱讀，如果你覺得這篇章對你有幫助的話，也歡迎把它分享給你的朋友。更新請加微信1182316662 眾籌更多課程23 精選留

14、 弗與卡夫卡我有個執(zhí)念，不愿主動寫測試代碼的程序員，不太可能是優(yōu)秀的程序員2019-01-25 00:41作者回復我認同你的說法2019-01-25 08:05Johnsen像前端項主要以UI為主，版本迭代速度很快的情況下怎么進單元測試的編寫2019-01-25 14:34作者回復先，迭代速度快慢與是否寫測試沒關(guān)系，取決于作是否完成是前提到的 DoD。其次，前端之所以能夠在今天成為個獨的項，在于它有量的邏輯需要寫，如今 JavaScript 相關(guān)的測試框架已經(jīng)發(fā)展得很完整了，就按照正常的式去寫測試就好了。2019-01-28 07:47毅團隊開發(fā)員的編程功不夠，即使想寫單元測試也是奢望。那種前

15、代碼不分，著先進的設(shè)計模式但寫著落后式實現(xiàn)的代碼的，旦開始了單元測試，估計部分時間不是在實現(xiàn)上是在頻繁修改單元測試代碼上了。2019-01-25 19:49作者回復說得有道理，不過，在接下來的篇，我們先把關(guān)于測試的理念梳理順了，知道問題出在哪，以后才好進改進。2019-01-25 21:55張洪團隊認知，開發(fā)周期，軟件和命財產(chǎn)關(guān)系不，是單元測試的攔路2019-01-25 08:46作者回復還有點是，知識，很多不愿意寫測試的原因是不會寫測試。2019-01-28 07:57Xunqf前好像部分公司都不怎么要求寫單元測試，即使有些公司要求測最多也只是業(yè)務(wù)上的測試，就像前端和移動端很多時候都是UI還

16、原度和適配上的問題，也只有視覺上的東暴露的更直接些，其他的問題般都很難說清楚，般公司業(yè)績考核也更看重直觀的東，所以部分都不會去做些底層的單元測試！2019-01-28 22:10作者回復你說的是現(xiàn)狀，我這在討論的是，應(yīng)該是什么樣。我反復提到，許多團隊深陷泥潭不知，就是現(xiàn)有的做事式讓他們陷了進去。2019-01-29 07:29巫妖測試沒有銀彈，主要看家對測試這件事情的認知是否致，現(xiàn)在都在推崇測試左移，盡可能玩發(fā)現(xiàn)問題，這就對程序員提出更的要求。2019-01-27 19:19作者回復優(yōu)秀程序員總是少數(shù)的，會寫測試就已經(jīng)上了級臺階，能在寫代碼之前思考測試，就會再上級臺階。2019-01-28 07:43墩快跑看績效了，只要價錢夠，就能保證了2019-01-26 12:15作者回復經(jīng)濟學告訴我們，沒有夠的價錢。2019-01-28 21:48草原上的奔跑作