這篇文章主要講解了“TDD、ATDD、BDD&RBE分別是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“TDD、ATDD、BDD&RBE分別是什么”吧！

成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供桑珠孜網(wǎng)站建設(shè)、桑珠孜做網(wǎng)站、桑珠孜網(wǎng)站設(shè)計、桑珠孜網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、桑珠孜企業(yè)網(wǎng)站模板建站服務(wù)，十年桑珠孜做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

在目前比較流行的敏捷開發(fā)模式（如極限編程、Scrum方法等）中，推崇“測試驅(qū)動開發(fā)（Test Driven Development，TDD）”——測試在先、編碼在后的開發(fā)實踐。TDD有別于以往的“先編碼、后測試”的開發(fā)過程，而是在編程之前，先寫測試腳本或設(shè)計測試用例。TDD在敏捷開發(fā)模式中被稱之為“測試優(yōu)先的編程（test-first programming）”，而在IBM Rational統(tǒng)一過程（Rational Unified Process，RUP）中被稱為“測試優(yōu)先的設(shè)計（test-first design）”。所有這些，都在強調(diào)“測試先行”，使得開發(fā)人員對所做的設(shè)計或所寫的代碼有足夠的信心，同時也有勇氣進行設(shè)計或代碼的快速重構(gòu)，有利于快速迭代、持續(xù)交付。重構(gòu)的前提就是測試就緒（testing is ready），在這樣的前提下，重構(gòu)的風(fēng)險就很低，否則就有比較高的風(fēng)險。

TDD具體實施過程，可以看作兩個層次，如圖1所示：

1. 在代碼層次，在編碼之前寫測試腳本，可以稱為單元測試驅(qū)動開發(fā)（Unit Test Driven Development，UTDD）

2. 在業(yè)務(wù)層次，在需求分析時就確定需求（如用戶故事）的驗收標準，即驗收測試驅(qū)動開發(fā)（Acceptance Test Driven Development，ATDD）。

圖1  TDD的兩個不同層次

先來討論UTDD，如圖2 所示。在打算添加某項新功能時，先不要急著寫程序代碼，而是將程序可能會碰到的特定條件、邊界值、上下文等想清楚，為待編寫（類或方法）的代碼先寫好測試腳本。然后，利用集成開發(fā)環(huán)境或相應(yīng)的測試工具來執(zhí)行這段測試用例，結(jié)果自然是通過不了（失敗）。利用沒有通過測試的錯誤信息反饋，了解到代碼沒有通過測試用例的原因，有針對性的逐步地添加代碼。為了要使該測試用例通過，就要補充、修改代碼，直到代碼符合測試用例的要求，獲得通過。測試用例全部執(zhí)行成功，說明新添加的功能通過了單元測試，可以進入下一個環(huán)節(jié)。這樣的流程也適合代碼修改或重構(gòu)，真正執(zhí)行時，也不會嚴格按照這樣的流程去做，但最基本要求是：先寫好測試腳本（代碼），再寫產(chǎn)品代碼并通過測試。按照UTDD做法，不是先寫產(chǎn)品代碼的類，再寫測試類，而是先寫測試類，再寫產(chǎn)品的類。

圖2   UTDD執(zhí)行的過程

UTDD從根本上改變了開發(fā)人員的編程態(tài)度，開發(fā)人員不能在像過去那樣隨意寫代碼，要求寫的每行代碼都是有效的代碼，寫完所有的代碼就意味著真正完成了編碼任務(wù)。而在此之前，代碼寫完了，實際上只完成了一半工作，遠沒有結(jié)束，因為單元測試還沒執(zhí)行，可能會發(fā)現(xiàn)許多錯誤，一旦缺陷比較多，缺陷就比較難以定位與修正。UTDD在于促進開發(fā)人員思考功能特性的應(yīng)用場景、異常情況或邊界條件，寫出更完善的代碼，避免犯較多的錯誤。其次，也確保測試具有獨立性，不受實現(xiàn)思維的影響，確保測試的客觀、全面。這一點，對開發(fā)人員測試自己的代碼是必要的。如果是倒過來，先寫產(chǎn)品代碼（即功能實現(xiàn)在前）再進行測試，那么測試會受實現(xiàn)思維影響。例如，我們自己寫的文章自己檢查，有時很明顯的問題都發(fā)現(xiàn)不了，就是受實現(xiàn)思維的影響。一般來說（多數(shù)情況下），開發(fā)人員測試自己的代碼有兩個障礙：思維障礙和心理障礙。心理障礙是指開發(fā)人員對自己的代碼不會窮追猛打，發(fā)現(xiàn)了一些缺陷，很可能會適可而止。我們知道，實際上缺陷越多的地方越有風(fēng)險，越要進行足夠的測試。最后，UTDD也確保所有代碼的可測試性，每一行代碼得到了測試，比較徹底地確保代碼的（微觀）質(zhì)量。

許多研發(fā)人員不習(xí)慣UTDD這種模式，推行UTDD會遇到比較大的困難，那TDD的實施可以移到業(yè)務(wù)層，推行ATDD，即在設(shè)計、寫代碼之前，明確系統(tǒng)功能特性的驗收標準，這比較容易推廣實施。例如，在敏捷開發(fā)模式中，每個用戶故事的描述過于簡單，是不具有可測試性的。例如，開發(fā)一個在線旅游網(wǎng)，可以提供交通、酒店、門票等預(yù)定服務(wù)，有一個最基本的用戶故事：

像這樣的用戶故事，如果不加驗收標準，開發(fā)實現(xiàn)起來很容易，在數(shù)據(jù)庫某個表中刪除一條記錄，在其它關(guān)聯(lián)表上修改相應(yīng)的標志位即可。但實際的業(yè)務(wù)不會那么簡單，說取消就取消？不需要有一個時間提前量？取消一定成功嗎？收不收相關(guān)的費用？是否需要線下處理的時間？是否需要通知用戶？通過什么方式通知取消成功或失??？要回答這些問題，就是要給這個用戶故事增加“驗收標準”，如：

• 取消前，需要提醒用戶再次確認

• 需提前24個小時取消

• 需要4個小時處理時間，才能知道取消成功與否

• 這類取消需要收取總金額10%的費用

• 不管取消成功與否，采用郵件和短信雙重通知

• 用戶事后可以查詢?nèi)∠南嚓P(guān)記錄

• 需要保留客戶和旅行網(wǎng)雙向操作記錄日志

這樣，這個用戶故事才具有可測試性，開發(fā)人員也會清楚如何實現(xiàn)這個用戶故事，實現(xiàn)的結(jié)果和產(chǎn)品經(jīng)理所期望的結(jié)果就不會有太大差異。

從ATDD演化出來一種具體落地的開發(fā)模式就是BDD（Behavior Driven Development，行為驅(qū)動開發(fā)）。BDD只是將驗收標準更加明確化，可以看作是ATDD的實例化，即列出用戶故事所可能遇到的應(yīng)用場景，而且將這種應(yīng)用場景的表達方式規(guī)定為GWT格式，即：

BDD再往前推進一步，就是需求實例化（Requirements By Example，RBE），更加明確需求的具體表現(xiàn)。還是以上面用戶故事為例，可以建立類似下列內(nèi)容的需求實例化。

需求越明確，用戶、產(chǎn)品經(jīng)理、開發(fā)與測試等之間的理解就越一致（on the same page），更不產(chǎn)生偏差和誤解，有利于開發(fā)和測試的工作?；赗BE，開發(fā)人員寫產(chǎn)品的代碼，測試人員可以獨立寫測試的代碼，產(chǎn)品經(jīng)理的工作也會變得輕松，不需要太多的解釋、不需要回答開發(fā)和測試的各種問題。

• 從需求角度看，BDD和需求實例化比較徹底地明確需求，統(tǒng)一用戶、產(chǎn)品經(jīng)理、開發(fā)與測試等認識，讓大家處在一個層面上，使研發(fā)工作更高效。

• 從測試角度看，需求即測試，產(chǎn)品的需求就是測試的需求，需求可以被執(zhí)行，即一步到位，將需求變?yōu)樽詣踊瘻y試腳本，開發(fā)出來的功能特性隨時可以被自動驗證。

TDD一改以往的破壞性測試的思維方式，測試在先、編碼在后，更符合“缺陷預(yù)防”的思想。這樣一來，編碼的思維方式發(fā)生了很大的變化，編寫出高質(zhì)量的代碼去通過這些測試，在進行每項設(shè)計、寫每一行代碼時都要想想用戶的真實需求、應(yīng)用場景和一些例外等，確保實現(xiàn)的功能特性符合預(yù)期，并具有健壯性。測試，也從以前的破壞性的方法轉(zhuǎn)移到一種建設(shè)性的方法中來。在這種積極心態(tài)的影響下，開發(fā)人員的工作效率和產(chǎn)品的質(zhì)量都會有顯著的提高，真正實現(xiàn)“質(zhì)量是內(nèi)建的（Quality is built in）”的目標。

感謝各位的閱讀，以上就是“TDD、ATDD、BDD&RBE分別是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對TDD、ATDD、BDD&RBE分別是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！