傳統(tǒng)的軟件開發(fā)都是需求分析-設(shè)計(jì)-編碼-測試的過程，這樣的過程也能夠確保交付正確的軟件產(chǎn)品給用戶，但是效率卻很低下（功能特別簡單的軟件除外）。

這是因?yàn)?，如果軟件的功能比較復(fù)雜，規(guī)模較大的情況下，先完成編碼（即便同時(shí)進(jìn)行了功能調(diào)試），必然會(huì)隱藏了很多Bug在其中，這將使得后續(xù)的測試會(huì)花費(fèi)更多的時(shí)間來找出前期編碼過程中埋入的缺陷，而缺陷的定位和修復(fù)，以及回歸測試等又要花費(fèi)大量的時(shí)間。

所以，傳統(tǒng)的開發(fā)過程很難具有較高的開發(fā)效率。

敏捷開發(fā)由此提出來測試驅(qū)動(dòng)開發(fā)（TDD）以提高軟件開發(fā)效率。

測試驅(qū)動(dòng)開發(fā)，就是測試先行，在編碼之前先寫測試，為代碼設(shè)定一個(gè)質(zhì)量之門，也指明了方向；而根據(jù)測試進(jìn)行代碼的編寫將更快捷，通過測試后的代碼就是質(zhì)量得到保證的代碼，后面的開發(fā)無需再擔(dān)心前面代碼會(huì)出現(xiàn)缺陷，因?yàn)樗鼈円呀?jīng)被驗(yàn)證是正確的。

這就使得這種開發(fā)過程不會(huì)出現(xiàn)傳統(tǒng)開發(fā)過程中前期隱藏大量Bug到后期才被發(fā)現(xiàn)和修復(fù)導(dǎo)致的大量工作量的消耗，那自然就會(huì)使得這種開發(fā)過程有較短的開發(fā)周期，較高的開發(fā)效率。

理論上，測試先行是可以提高效率。

越早發(fā)現(xiàn)Bug，消除它的代價(jià)就越低。測試驅(qū)動(dòng)開發(fā)完美地實(shí)踐了這一測試公理。

除此以外，測試驅(qū)動(dòng)開發(fā)還實(shí)踐著另一個(gè)公理：小步快走效率高。

小步快走的意思是將需求拆分成較小的需求塊，這樣的測試容易編寫，代碼容易實(shí)現(xiàn)，代碼的驗(yàn)證也很快。這種方式會(huì)避免較大需求塊測試編寫時(shí)間長，代碼實(shí)現(xiàn)和驗(yàn)證的時(shí)間都被拉長，導(dǎo)致工期劇增（因?yàn)殡S著功能復(fù)雜、規(guī)模增大，耗費(fèi)的周期會(huì)呈指數(shù)增長而非線性增長）。

測試驅(qū)動(dòng)開發(fā)是針對代碼塊的，它可以使得開發(fā)人員快速實(shí)現(xiàn)代碼功能。但是，雖然代碼的實(shí)現(xiàn)快速而正確，但它卻未必滿足需求。要使軟件能夠快速交付，除了應(yīng)用測試驅(qū)動(dòng)開發(fā)（TDD）外，還要應(yīng)用驗(yàn)收測試驅(qū)動(dòng)開發(fā)（ATDD）。

驗(yàn)收測試驅(qū)動(dòng)開發(fā)是針對需求來編寫測試的，每個(gè)功能實(shí)現(xiàn)之后再通過根據(jù)需求編寫出來的測試，這樣就可以在實(shí)現(xiàn)功能的同時(shí)就獲得滿足需求的功能，當(dāng)最后的功能實(shí)現(xiàn)之后，就可以進(jìn)行軟件交付了。

測試驅(qū)動(dòng)開發(fā)確保軟件內(nèi)部質(zhì)量，相當(dāng)于單元測試和集成測試先行；驗(yàn)收測試驅(qū)動(dòng)開發(fā)確保軟件外部質(zhì)量，相當(dāng)于配置項(xiàng)測試和系統(tǒng)測試先行。

如果需要進(jìn)一步提高效率，還需要實(shí)施持續(xù)集成和自動(dòng)化測試。

既然測試先行可以提高效率的原理是“越早發(fā)現(xiàn)Bug，消除它的代價(jià)就越低”以及“小步快走效率高”，那么即便組織不具備實(shí)施完整的敏捷TDD和ATDD實(shí)踐的條件，不妨考慮低配版的測試先行——實(shí)現(xiàn)一個(gè)單元即對這個(gè)單元進(jìn)行單元測試，驗(yàn)證該單元的正確性；實(shí)現(xiàn)兩個(gè)單元?jiǎng)t進(jìn)行集成和集成測試，驗(yàn)證集成后單元的正確性；一個(gè)功能實(shí)現(xiàn)了，就進(jìn)行配置項(xiàng)測試，驗(yàn)證功能的正確性，相信也會(huì)獲得優(yōu)于傳統(tǒng)的軟件開發(fā)效率。

如果測試先行提高開發(fā)效率，你想改變你的開發(fā)過程嗎？

這正是：

測試先行找問題，修復(fù)缺陷成本低

傳統(tǒng)過程不拘泥，先行測試應(yīng)期許