北京軟件開(kāi)發(fā)測(cè)試驅(qū)動(dòng)開(kāi)發(fā)(TDD)是一種開(kāi)發(fā)方式，它改變了傳統(tǒng)軟件開(kāi)發(fā)的流程，即首先設(shè)計(jì)程序，再進(jìn)行編碼與測(cè)試工作。TDD采取了很小的增量式開(kāi)發(fā)方式：首先編寫(xiě)一個(gè)測(cè)試，再編寫(xiě)實(shí)際程序代碼以通過(guò)測(cè)試，較后對(duì)代碼進(jìn)行改進(jìn)。這種方式的結(jié)果是大量的(通?？蛇_(dá)到幾千個(gè))自動(dòng)化測(cè)試，能夠在幾秒鐘之內(nèi)執(zhí)行完畢。

　　測(cè)試人員需要注意到一點(diǎn)，這些高效的自動(dòng)化單元測(cè)試剔除了大多數(shù)手工測(cè)試的執(zhí)行。這樣一來(lái)，我們就需要重新反思是否有必要在TDD團(tuán)隊(duì)中繼續(xù)保留測(cè)試人員的角色。

　　從表面上看，無(wú)論是否采用TDD，“測(cè)試人員”都是團(tuán)隊(duì)中必不可少的角色，但實(shí)際情況要復(fù)雜得多，現(xiàn)在讓我們來(lái)看看這些復(fù)雜性體現(xiàn)在何處：

　　如果你打算開(kāi)始嘗試TDD，那么建議你不要試圖在團(tuán)隊(duì)中揉合老派的QA與功能測(cè)試人員。

　　如果你已經(jīng)成功地實(shí)施了TDD，那么在團(tuán)隊(duì)中安排一位專(zhuān)攻測(cè)試的成員仍然是有意義的。

　　在TDD中團(tuán)隊(duì)中能夠取得成功的測(cè)試人員與傳統(tǒng)的功能測(cè)試人員的區(qū)別在于，前者具有更扎實(shí)的技術(shù)背景。

　　QA的興衰

　　在對(duì)“TDD已死?”這一主題所展開(kāi)的一次對(duì)話(huà)中，Kent Beck(KB)、Martin Fowler(MF)與David Heinemeier Hansson(DHH)圍繞著QA與測(cè)試展開(kāi)了激烈的討論。他們指出了專(zhuān)職測(cè)試人員歷史的3個(gè)發(fā)展階段：

　　堆積QA：通常指機(jī)能失調(diào)的QA部門(mén)，其中充斥著大量的功能測(cè)試人員。

　　摒棄QA：對(duì)于讓程序員負(fù)責(zé)測(cè)試的做法過(guò)于自信，在開(kāi)發(fā)過(guò)程中摒棄測(cè)試人員。

　　當(dāng)前現(xiàn)狀：在項(xiàng)目中引入適當(dāng)?shù)腝A(甚至是功能性的)仍是有必要的。

　　流行于上世紀(jì)90年代的堆積QA的做法現(xiàn)在看來(lái)似乎已經(jīng)過(guò)時(shí)了，許多IT組織已經(jīng)解散了他們的QA部門(mén)，并將測(cè)試人員分派到各個(gè)敏捷團(tuán)隊(duì)中。不過(guò)，在許多敏捷團(tuán)隊(duì)中，這些測(cè)試人員仍在繼續(xù)著早期的手工測(cè)試任務(wù)。眾多組織仍然受困于延續(xù)自20年前的機(jī)能失調(diào)的測(cè)試方法。

　　老派的QA方式之所以出現(xiàn)機(jī)能失調(diào)的情況，是因?yàn)檫@種方式依賴(lài)于大量的功能測(cè)試人員。這些測(cè)試人員是手工測(cè)試方面的專(zhuān)家，但對(duì)于技術(shù)方面的技能知之甚少。測(cè)試人員的專(zhuān)業(yè)性決定了他們擅長(zhǎng)于對(duì)功能的“測(cè)試”。但是，老派的QA部門(mén)更傾向于(同時(shí)也出于商業(yè)利益的考慮)讓這些測(cè)試人員對(duì)功能進(jìn)行“檢查”。

　　“檢查”的主要特點(diǎn)在于：這種測(cè)試完全可以實(shí)現(xiàn)自動(dòng)化(Bach 與Bolton 2013)。這就意味著“檢查”功能可以由程序員完成。至于是應(yīng)該讓測(cè)試人員還是程序員進(jìn)行功能“檢查”，這種選擇貌似隨意，其實(shí)不然：無(wú)論是發(fā)現(xiàn)bug、進(jìn)行隔離、匯報(bào)、跟蹤或是提出修復(fù)意見(jiàn)，測(cè)試人員都要花費(fèi)更多的時(shí)間(Kaner 2001)。

　　通過(guò)手工測(cè)試人員對(duì)功能進(jìn)行“檢查”的方式讓老派的QA變得非常低效。一旦團(tuán)隊(duì)培養(yǎng)出“不要測(cè)試自己的代碼，把它丟給QA去做”這種觀(guān)念，測(cè)試工作就變得機(jī)能失調(diào)了(KB與DHH在這次對(duì)話(huà)中的觀(guān)點(diǎn))。這種方式發(fā)展到一定程度，就會(huì)造成效率的不斷下降，隨著投入的測(cè)試人員越多，反而會(huì)造成bug數(shù)量的不斷升高。('Better Testing - Worse Quality'，Hendrickson 2001)

　　摒棄QA是對(duì)于手工測(cè)試這種機(jī)能失調(diào)的實(shí)踐的一種自然反應(yīng)。之所以本文的標(biāo)題沒(méi)有取名為“敏捷團(tuán)隊(duì)中的測(cè)試人員”，是因?yàn)檗饤塓A的做法在某些情況下并不可行，比如你的敏捷團(tuán)隊(duì)雖然實(shí)施了Scrum框架，卻沒(méi)有進(jìn)行任何自動(dòng)化單元測(cè)試，又或是團(tuán)隊(duì)正在進(jìn)行某些商業(yè)現(xiàn)成品或技術(shù)(COTS)的軟件開(kāi)發(fā)。如果團(tuán)隊(duì)中沒(méi)有設(shè)立功能測(cè)試人員，則必須實(shí)施TDD實(shí)踐，或是其他任何一種能夠生成自動(dòng)化單元測(cè)試的方法。

　　在大多數(shù)情形下，選擇了TDD就意味著你必須改變程序員的技能、習(xí)慣，并且往往還需要改變他們的態(tài)度與自我意識(shí)。而實(shí)現(xiàn)以上這幾點(diǎn)并不容易，同時(shí)TDD本身也并非可以一促而就的：“要很好地掌握遺留代碼、對(duì)單元測(cè)試進(jìn)行適當(dāng)?shù)母綦x、以及集成測(cè)試是非常困難的”(Shore 2007)。根據(jù)評(píng)估，當(dāng)程序員轉(zhuǎn)為采用TDD實(shí)踐后，前幾個(gè)月的生產(chǎn)力會(huì)急劇下降。不僅如此，對(duì)實(shí)踐TDD的新手往往要進(jìn)行幾周乃至幾個(gè)月時(shí)間進(jìn)行手把手的培訓(xùn)(Larman，Vodde 2008)。

　　依我的經(jīng)驗(yàn)看來(lái)，老派的程序員與測(cè)試人員之間往往存在著一種共生現(xiàn)象。老派的程序員不喜歡進(jìn)行單元測(cè)試，只要項(xiàng)目中有測(cè)試人員，他們就企圖蒙混過(guò)關(guān)。而老派的測(cè)試人員也不愿意學(xué)習(xí)技術(shù)知識(shí)，只要為程序員找到了足夠的bug，他們也同樣選擇應(yīng)付了事。老派的程序員與測(cè)試人員都希望避免進(jìn)行任何改變。因此，在我看來(lái)，如果程序員已經(jīng)開(kāi)始實(shí)施TDD實(shí)踐，再往團(tuán)隊(duì)中安置一個(gè)功能測(cè)試人員就是一個(gè)壞主意。

　　我在多年的經(jīng)驗(yàn)中觀(guān)察到了這種反模式：如果你打算采用TDD或其他某種由開(kāi)發(fā)者進(jìn)行測(cè)試的實(shí)踐，那么僅僅是因?yàn)樵趫F(tuán)隊(duì)中出現(xiàn)了一位功能測(cè)試人員，就會(huì)讓你的努力付諸東流。因此，如果你確實(shí)計(jì)劃實(shí)施TDD，我的建議是從團(tuán)隊(duì)中取消功能測(cè)試人員的角色!

　　但事實(shí)上，在實(shí)施TDD的過(guò)程中，在團(tuán)隊(duì)中保留一定的QA仍然是必要的，這是因?yàn)槟承┳兓蛟S會(huì)出乎你的意料。在上述關(guān)于TDD與QA的對(duì)話(huà)中，David Heinemeier Hansson說(shuō)道：“或許你已經(jīng)通過(guò)了所有測(cè)試，但或許它并沒(méi)有發(fā)現(xiàn)真正的問(wèn)題。一旦到了實(shí)際應(yīng)用過(guò)程中，用戶(hù)會(huì)以你始料未及的方式使用你的應(yīng)用。”

　　Martin Fowler十分贊同David的觀(guān)點(diǎn)，但在同一番對(duì)話(huà)中，Kent Beck的措詞顯得更為謹(jǐn)慎。但他也同意，在QA這方面，“事情的發(fā)展已經(jīng)趨向于另一個(gè)極端”。如果你無(wú)法預(yù)見(jiàn)到所有的可能性，那么從外部獲取某些反饋的做法“非常有意義”。

　　TDD團(tuán)隊(duì)中的測(cè)試與團(tuán)隊(duì)組成

　　在以上對(duì)話(huà)的較后，我們已意識(shí)到在TDD的實(shí)施中，除了在編程過(guò)程中所創(chuàng)建的測(cè)試外，進(jìn)行一定其他形式的測(cè)試工作仍是有意義的。敏捷測(cè)試的概念在“敏捷測(cè)試”(Crispin，Gregory 2009)等書(shū)籍中進(jìn)行了詳盡的描述。但實(shí)施敏捷測(cè)試是否仍然需要“測(cè)試人員”，即專(zhuān)業(yè)從事測(cè)試的員工，人們對(duì)于這一點(diǎn)似乎還有爭(zhēng)論。Google仍然有數(shù)百名測(cè)試人員，而Facebook幾乎完全沒(méi)有設(shè)立測(cè)試人員的職位。

　　而普通的公司則有著不同的考慮，他們必須保證員工已掌握了工具與概念方面的知識(shí)以開(kāi)發(fā)并維護(hù)各種應(yīng)用，并確保高效的分工。讓我們實(shí)際分析一下在Java環(huán)境中引入測(cè)試人員意味著什么。

　　支持Java的TDD工具包括JUnit與某種模擬測(cè)試框架，一般的開(kāi)發(fā)者都能夠掌握這些工具。不過(guò)，JUnit框架不僅支持在Java環(huán)境中應(yīng)用TDD，它還表現(xiàn)出了測(cè)試工作的第二次革新：它不僅支持自動(dòng)化單元測(cè)試，還支持其他各種測(cè)試的自動(dòng)化。

　　JUnit目前還支持運(yùn)行：通過(guò)JAX-RS實(shí)現(xiàn)的集成測(cè)試、自動(dòng)驗(yàn)收測(cè)試、基于Selenium Webdriver的UI測(cè)試、以及支持各種數(shù)據(jù)集的參數(shù)化測(cè)試等等。并且這些測(cè)試都能夠與持續(xù)集成(CI)方案進(jìn)行整合。

　　除了這些測(cè)試工具之外，其他各種工具與框架也大量涌現(xiàn)?？梢哉f(shuō)，一般的開(kāi)發(fā)者很難掌握在一個(gè)普通的現(xiàn)代化項(xiàng)目中所用到的全部工具。

　　概念性的知識(shí)是創(chuàng)建高質(zhì)量應(yīng)用的基本。要實(shí)現(xiàn)高可維護(hù)性，開(kāi)發(fā)者需要了解代碼整潔之道，而要掌握這方面知識(shí)需要多年的經(jīng)驗(yàn)積累。如果我們想要精通這一領(lǐng)域的知識(shí)，接下來(lái)還可以學(xué)習(xí)設(shè)計(jì)模式、線(xiàn)程以及性能的原理。

　　準(zhǔn)確的、可維護(hù)的以及高性能的代碼雖然十分重要，但他們并不能保證某個(gè)應(yīng)用是可信賴(lài)的。為了彌補(bǔ)這方面的缺失，開(kāi)發(fā)者還需要學(xué)習(xí)安全方面的知識(shí)。而為了創(chuàng)建一個(gè)能夠吸引用戶(hù)的應(yīng)用，開(kāi)發(fā)者還要了解UX方面的知識(shí)。較后，為了設(shè)計(jì)一種高效的方式以保證以上所說(shuō)的特性，開(kāi)發(fā)者還需要熟悉測(cè)試的知識(shí)。

　　在組建IT部門(mén)時(shí)，工作的分工是又一項(xiàng)要考慮的重點(diǎn)。在團(tuán)隊(duì)的專(zhuān)業(yè)構(gòu)成中，我們可以選擇由各領(lǐng)域的專(zhuān)家，例如由一位安全方面的專(zhuān)家、一位UX設(shè)計(jì)師和一位測(cè)試人員組成一個(gè)團(tuán)隊(duì)，但這樣一來(lái)就沒(méi)有編碼者的位置了，結(jié)果就是團(tuán)隊(duì)無(wú)法產(chǎn)出任何實(shí)際的東西。

　　反過(guò)來(lái)，我們也可以由多面手構(gòu)成整個(gè)團(tuán)隊(duì)，但這意味著整個(gè)團(tuán)隊(duì)必須將較好的光陰花費(fèi)在學(xué)習(xí)上，除非他們都是天才。這樣的團(tuán)隊(duì)同樣不會(huì)有很高的產(chǎn)出。

　　因此，我們的結(jié)論是在開(kāi)發(fā)團(tuán)隊(duì)中有必要引入部分專(zhuān)利性。我們不能指望每個(gè)開(kāi)發(fā)者不僅能夠掌握全部的工具，并且還是整潔代碼、UX以及安全和測(cè)試方面的專(zhuān)家。另一方面，在團(tuán)隊(duì)中引入的專(zhuān)家數(shù)量也應(yīng)有所限制。

　　既然我們必須引入一定的專(zhuān)業(yè)性，那么設(shè)置一位測(cè)試專(zhuān)家是比較有意義的：對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，如果讓他們來(lái)選擇，那么大多數(shù)人不會(huì)去探索單元測(cè)試之外的內(nèi)容，甚至有很多人根本不愿意承擔(dān)任何測(cè)試工作。這也是為什么許多開(kāi)發(fā)者不喜歡、甚至是厭惡測(cè)試的原因。如果要在這種環(huán)境中嘗試轉(zhuǎn)變?yōu)槊艚轀y(cè)試實(shí)踐，那么就需要設(shè)立一位對(duì)于測(cè)試工作有熱情并樂(lè)于實(shí)現(xiàn)它的專(zhuān)家。

　　與TDD的實(shí)施類(lèi)似，以上過(guò)程同樣需要他人的指導(dǎo)，并且向團(tuán)隊(duì)展示其工作結(jié)果。如果某位測(cè)試專(zhuān)家創(chuàng)建了對(duì)某個(gè)服務(wù)的測(cè)試集，并且能夠從IDE中執(zhí)行，那么程序員就很可能會(huì)去使用。不僅如此，如果開(kāi)發(fā)者感受到了測(cè)試的實(shí)用性，那么他們就會(huì)開(kāi)始擴(kuò)展其功能，并以可維護(hù)的方式實(shí)現(xiàn)。一旦為測(cè)試所觸動(dòng)之后，程序員就會(huì)愿意繼續(xù)進(jìn)行測(cè)試。但以我的經(jīng)驗(yàn)來(lái)看，僅靠程序員自己是無(wú)法感受到測(cè)試的好處的。

　　TDD：具有扎實(shí)技術(shù)背景的測(cè)試人員

　　在QA的興衰這一節(jié)的總結(jié)部分，我曾表示：在實(shí)現(xiàn)了對(duì)手工檢查工作進(jìn)行自動(dòng)化的TDD環(huán)境中，對(duì)于缺乏技術(shù)知識(shí)的傳統(tǒng)測(cè)試人員的需求已經(jīng)大大降低了。隨后在對(duì)JUnit與TDD的介紹中，我們又看到開(kāi)發(fā)者創(chuàng)建了大量的測(cè)試工具，而缺乏技術(shù)知識(shí)的測(cè)試人員將無(wú)法使用這些工具。

　　我們現(xiàn)在可以負(fù)責(zé)任的說(shuō)，在TDD環(huán)境中，我們需要一種新型的測(cè)試人員，他們需要具備更扎實(shí)的技術(shù)背景。至于他的日常活動(dòng)包括哪些內(nèi)容，要考慮到TDD所實(shí)施的環(huán)境。對(duì)于敏捷測(cè)試來(lái)說(shuō)，TDD實(shí)現(xiàn)了自動(dòng)化金字塔(Cohn 2009)的底層，以及測(cè)試象限(testing quadrants)的第1象限(Marick 2003及Crispin 2009)。

　　為了更清楚地了解其效果，讓我們來(lái)考慮這個(gè)測(cè)試場(chǎng)景：某個(gè)表單的一個(gè)輸入框可以接受一個(gè)整數(shù)，該數(shù)字必須在規(guī)定的邊界之內(nèi)，并且要進(jìn)行后端的校驗(yàn)。我們?cè)诖颂幙梢越?6種功能性的測(cè)試用例：{ x | boundary，boundary-1，boundary+1，decimal， locale，Z，0，null，“”，“ “，abc，UTF-8，2^31-1，2^31， -2^31，-2^31-1}，但這些基本的單元測(cè)試只屬于測(cè)試象限中的第1象限(通過(guò)面向技術(shù)的測(cè)試指導(dǎo)開(kāi)發(fā))。

　　而在TDD實(shí)踐中，以上測(cè)試用例將實(shí)現(xiàn)自動(dòng)化，測(cè)試人員不應(yīng)(參照上文)執(zhí)行這些測(cè)試用例。一般來(lái)說(shuō)，他應(yīng)當(dāng)對(duì)于該輸入字段是否存在以及一個(gè)正面用例進(jìn)行校驗(yàn)(測(cè)試象限2，通過(guò)面向業(yè)務(wù)的測(cè)試指導(dǎo)開(kāi)發(fā))。雖然可以通過(guò)某種錄制與播放工具完成該任務(wù)，但這種方案缺乏可維護(hù)性。更有效的技術(shù)方案是(通過(guò)整潔的代碼)編寫(xiě)Selenium Webdriver代碼，并且讓它能夠在整個(gè)團(tuán)隊(duì)共用的IDE中執(zhí)行。

　　象限2中的其他測(cè)試技術(shù)包括用戶(hù)故事的測(cè)試，而這些測(cè)試同樣可以實(shí)現(xiàn)自動(dòng)化。“作為InfoQ的用戶(hù)，我希望能夠登錄系統(tǒng)，以下載某些特別的內(nèi)容”這樣的行為可以暴露為REST調(diào)用等方式，并通過(guò)自動(dòng)化測(cè)試執(zhí)行。對(duì)于在GUI層進(jìn)行的這種簡(jiǎn)單測(cè)試，有人可能會(huì)選擇使用外部工具(例如SoapUi)。但更高效的做法是讓這個(gè)測(cè)試能夠在JUnit中作為集成測(cè)試(“LogInIT.java”)而運(yùn)行。而其他(沒(méi)有許可證的)團(tuán)隊(duì)成員可以直接運(yùn)行與維護(hù)該測(cè)試，并且無(wú)需學(xué)習(xí)該工具的使用。

　　當(dāng)基本功能都實(shí)現(xiàn)了自動(dòng)化檢查后，我們就達(dá)到了第3象限(通過(guò)面向業(yè)務(wù)的測(cè)試來(lái)評(píng)價(jià)產(chǎn)品)：團(tuán)隊(duì)已具備了開(kāi)始進(jìn)行探索性測(cè)試的先決條件。David Heinemeier Hansson在上述對(duì)話(huà)表示，用戶(hù)會(huì)以你始料未及的方式使用你的應(yīng)用。這一點(diǎn)對(duì)于其他系統(tǒng)也成立，此時(shí)這種方式叫做突現(xiàn)行為(emergent behavior)。由于你不知道應(yīng)該期望怎樣的行為，因此此處可引入探索性測(cè)試(Hendrickson 2013)。

　　探索性測(cè)試(ET)依賴(lài)于小型的迭代：執(zhí)行測(cè)試、對(duì)應(yīng)用進(jìn)行學(xué)習(xí)并為此設(shè)計(jì)新的測(cè)試。這種測(cè)試方式較初是受到Test Heuristics Cheat sheet((Hendrickson 2006))這份非常容易獲取的資料而啟發(fā)的，但并不是說(shuō)只需簡(jiǎn)單地執(zhí)行其中的內(nèi)容就代表你已經(jīng)實(shí)現(xiàn)了探索性測(cè)試。探索性測(cè)試的真正價(jià)值在于它的迭代式特征以及對(duì)于知識(shí)的運(yùn)用。

　　舉例來(lái)說(shuō)：在Heuristics Cheat Sheet中提到，在web測(cè)試中可以“對(duì)url進(jìn)行各種操作，(例如變更或刪除某些參數(shù))”。如果在沒(méi)有準(zhǔn)備的情況下直接嘗試編寫(xiě)相關(guān)的腳本或直接執(zhí)行是沒(méi)有實(shí)用性的。如果要改善這方面的行為，我們可以首先用幾個(gè)迭代的時(shí)間去學(xué)習(xí)該應(yīng)用使用這些參數(shù)的方式，隨后想出(設(shè)計(jì))一個(gè)相關(guān)的測(cè)試，較后才開(kāi)始測(cè)試(執(zhí)行)。毫無(wú)疑問(wèn)，如果能夠正確地運(yùn)用http協(xié)議方面的知識(shí)，對(duì)于該測(cè)試的設(shè)計(jì)將帶來(lái)極大的便利。

　　我在探索性測(cè)試中的常用做法是：在IDE中運(yùn)行應(yīng)用程序、對(duì)應(yīng)用程序服務(wù)器的日志進(jìn)行監(jiān)控、打開(kāi)數(shù)據(jù)庫(kù)并對(duì)網(wǎng)絡(luò)請(qǐng)求進(jìn)行監(jiān)控。這種方式顯然能夠看到一些在GUI中不會(huì)顯示出來(lái)的錯(cuò)誤。通過(guò)這種方式，我通常能夠發(fā)現(xiàn)這些內(nèi)容：大量的網(wǎng)絡(luò)錯(cuò)誤與請(qǐng)求、日志污染、非預(yù)期的持久行為、大量的/低效的數(shù)據(jù)庫(kù)查詢(xún)、安全性隱患以及使用性的錯(cuò)誤等等。

　　這并不是說(shuō)一旦應(yīng)用了TDD，所有的測(cè)試工作就會(huì)變得充滿(mǎn)技術(shù)性，或是由工具所驅(qū)動(dòng)。依然有一些非常重要的測(cè)試與人相關(guān)(Ambler 2003-2014)，或是與UX的測(cè)試相關(guān)。這些測(cè)試所包含的技術(shù)性較少，但并不意味著就不需要了解深入的知識(shí)。

　　以上內(nèi)容表示，TDD讓測(cè)試人員的角色發(fā)生了變化，而不再需要進(jìn)行手工功能性測(cè)試(例如檢查)。雖然他仍有大量的工作需要完成，但他所負(fù)責(zé)的功能性測(cè)試應(yīng)該已經(jīng)實(shí)現(xiàn)了自動(dòng)化。而如果他能夠掌握更多的技術(shù)、工具或其他方面的知識(shí)，那么他的手工(探索性)測(cè)試工作很可能會(huì)變得更為高效，只是這些知識(shí)往往并不容易掌握。

　　那么，TDD團(tuán)隊(duì)中的測(cè)試人員究竟應(yīng)當(dāng)掌握哪些技術(shù)方面的知識(shí)呢?以下陳述基本是沒(méi)什么疑問(wèn)的：敏捷測(cè)試人員需要掌握良好的技術(shù)知識(shí)，了解如何與他人合作進(jìn)行自動(dòng)化測(cè)試，而成為經(jīng)驗(yàn)豐富的探索性測(cè)試人員(Crispin, Gregory 2009)對(duì)于TDD團(tuán)隊(duì)來(lái)說(shuō)同樣有意義。

　　但我卻相信，對(duì)于已開(kāi)始實(shí)踐TDD的敏捷團(tuán)隊(duì)與尚未開(kāi)始實(shí)踐TDD的敏捷團(tuán)隊(duì)來(lái)說(shuō)，他們對(duì)于職務(wù)的需求也是不同的。對(duì)于尚未開(kāi)始TDD的團(tuán)隊(duì)來(lái)說(shuō)，敏捷測(cè)試人員也許將被迫使用某些不為開(kāi)發(fā)人員所用的測(cè)試工作，或是進(jìn)行大量的手工測(cè)試。而在TDD團(tuán)隊(duì)中，測(cè)試人員更有可能在IDE中進(jìn)行工作，這時(shí)，該角色的技術(shù)需求就變?yōu)椋?/span>

　　掌握至少一門(mén)編程語(yǔ)言(從而能夠閱讀及編寫(xiě)測(cè)試)。

　　了解命令行與腳本編寫(xiě)的知識(shí)(包括服務(wù)器與本地機(jī)器)。

　　具備數(shù)據(jù)庫(kù)方面的經(jīng)驗(yàn)(用于在沒(méi)有GUI的情況下檢查持久化的情況)。

　　結(jié)語(yǔ)

　　本文引用了Kent Beck、Martin Fowler和David Heinemeier Hansson的對(duì)話(huà)，這也是激勵(lì)我撰寫(xiě)本文的動(dòng)力。如果你對(duì)于測(cè)試有興趣，應(yīng)該聽(tīng)一聽(tīng)他們對(duì)于“將代碼扔給QA”以及“老派的QA做法還不如不要QA”等觀(guān)點(diǎn)坦率而直接的表述。

　　為了對(duì)此問(wèn)題進(jìn)行透徹的分析，我首先描述了老派的功能性測(cè)試方法，它所造成的結(jié)果不經(jīng)過(guò)思考的功能檢查，這種方式帶來(lái)的傷害更大于它的價(jià)值。這并非我的臆想，而是有強(qiáng)烈的跡象表明仍有許多組織以這種方式進(jìn)行測(cè)試，無(wú)論他們是否采用了“敏捷”實(shí)踐。

　　接下來(lái)，我指出了為什么將TDD開(kāi)發(fā)者與“老派的功能測(cè)試人員”結(jié)合在一起是一種不推薦的方式。在團(tuán)隊(duì)組成那一部分，我對(duì)于在TDD團(tuán)隊(duì)中設(shè)置測(cè)試人員的角色持保留態(tài)度，并將其修正為在團(tuán)隊(duì)中應(yīng)當(dāng)設(shè)立一些對(duì)于測(cè)試充滿(mǎn)熱情的成員。

　　至于測(cè)試人員所需的技能，我認(rèn)為在TDD過(guò)程中已不需要進(jìn)行老派的功能性檢查。在TDD團(tuán)隊(duì)中仍然有測(cè)試人員的一席之地，但他們的測(cè)試工作需要更專(zhuān)業(yè)的技術(shù)知識(shí)。

　　收獲

　　如果你是一位仍在進(jìn)行手工檢查的測(cè)試人員，那么應(yīng)當(dāng)考慮TDD或其他能夠?qū)⑹止z查自動(dòng)化的解決方案。如果你還不具備上文所提到的技術(shù)知識(shí)，那么是時(shí)候?qū)⒛愕闹R(shí)水平提升至這一程度，從測(cè)試工作中獲得更大的樂(lè)趣!《More Agile Testing》(Crispin Gregory 2015)一書(shū)對(duì)于應(yīng)當(dāng)具備的知識(shí)進(jìn)行了詳盡的介紹，我極力推薦這本書(shū)給那些希望繼續(xù)從事測(cè)試工作的讀者們。為了掌握這些知識(shí)，我建議大家進(jìn)行正規(guī)的學(xué)習(xí)，它會(huì)讓你更好地了解某個(gè)主題，并且加快學(xué)習(xí)的速度，同時(shí)也使你有機(jī)會(huì)證明自己已具備了這些知識(shí)。

　　如果你是一位團(tuán)隊(duì)主管或經(jīng)理，并且對(duì)于測(cè)試方面的問(wèn)題感到受挫，那么你或許應(yīng)當(dāng)考慮一下如何實(shí)現(xiàn)更高級(jí)的測(cè)試方案。你需要的是在團(tuán)隊(duì)中找到能夠?qū)崿F(xiàn)方案，同時(shí)又對(duì)測(cè)試充滿(mǎn)熱情的人。在“程序員即測(cè)試人員?”(Programmers as Testers?)這篇文章(Gregory 2011)中，Janet Gregory表示她傾向于測(cè)試人員應(yīng)當(dāng)具備技術(shù)背景的觀(guān)點(diǎn)，但如果他們將測(cè)試人員的角色僅僅當(dāng)作成為程序員的一塊墊腳石，那么就不要以測(cè)試人員的身份招聘他們。這一點(diǎn)無(wú)可厚非，如果測(cè)試人員對(duì)于測(cè)試工作沒(méi)有熱情，他們就無(wú)法很好地實(shí)現(xiàn)測(cè)試象限或探索性測(cè)試。反過(guò)來(lái)說(shuō)，如果某個(gè)測(cè)試人員不具備必需的技能，他就無(wú)法實(shí)現(xiàn)測(cè)試自動(dòng)化，甚至在探索性測(cè)試中也做不到完全高效。換句話(huà)說(shuō)，技能與熱情是實(shí)施敏捷測(cè)試的必要條件。