北京軟件開發測試驅動開發(TDD)是一種開發方式，它改變瞭傳統軟件開發的流程，即首先設計程序，再進行編碼與測試工作。TDD採取瞭很小的增量式開發方式：首先編寫一個測試，再編寫實際程序代碼以通過測試，較後對代碼進行改進。這種方式的結果是大量的(通常可達到幾千個)自動化測試，能夠在幾秒鍾之内執行完畢。

　　測(cè)試人員需要注意到一點，這些高效的自動化單元測(cè)試剔除瞭(le)大多數手工測(cè)試的執行。這樣一來，我們就需要重新反思是否有必要在TDD團隊中繼續保留測(cè)試人員的角色。

　　從表面上看，無論是否採(cǎi)用TDD，“測(cè)試人員”都是團隊中必不可少的角色，但實際情況要複雜得多，現在讓我們來看看這些複雜性體現在何處：

　　如果你打算開始嘗(cháng)試TDD，那麽建議你不要試圖在團隊中揉合老派的QA與功能測(cè)試人員。

　　如果你已經成功地實施瞭(le)TDD，那麽在團隊中安排一位專攻測(cè)試的成員仍然是有意義的。

　　在TDD中團隊中能夠取得成功的測(cè)試人員與傳統的功能測(cè)試人員的區别在於(yú)，前者具有更紮實的技術背景。

　　QA的興衰

　　在對“TDD已死?”這一主題所展開的一次對話中，Kent Beck(KB)、Martin Fowler(MF)與David Heinemeier Hansson(DHH)圍繞著(zhe)QA與測試展開瞭(le)激烈的讨論。他們指出瞭(le)專職測試人員曆史的3個發展階段：

　　堆積QA：通常指機能失調的QA部門，其中充斥著(zhe)大量的功能測(cè)試人員。

　　摒棄QA：對於(yú)讓程序員負責測(cè)試的做法過於(yú)自信，在開發過程中摒棄測(cè)試人員。

　　當(dāng)前現(xiàn)狀：在項目中引入适當(dāng)的QA(甚至是功能性的)仍是有必要的。

　　流行於上世紀90年代的堆積QA的做法現在看來似乎已經過時瞭，許多IT組織已經解散瞭他們的QA部門，並(bìng)将測試人員分派到各個敏捷團隊中。不過，在許多敏捷團隊中，這些測試人員仍在繼續著(zhe)早期的手工測試任務。衆多組織仍然受困於延續自20年前的機能失調的測試方法。

　　老派的QA方式之所以出現機能失調的情況，是因爲這種方式依賴於(yú)大量的功能測試人員。這些測試人員是手工測試方面的專家，但對於(yú)技術方面的技能知之甚少。測試人員的專業性決定瞭(le)他們擅長於(yú)對功能的“測試”。但是，老派的QA部門更傾向於(yú)(同時也出於(yú)商業利益的考慮)讓這些測試人員對功能進行“檢查”。

　　“檢查”的主要特點在於(yú)：這種測試完全可以實現自動化(Bach 與Bolton 2013)。這就意味著(zhe)“檢查”功能可以由程序員完成。至於(yú)是應該讓測試人員還是程序員進行功能“檢查”，這種選擇貌似随意，其實不然：無論是發現bug、進行隔離、彙報、跟蹤或是提出修複意見，測試人員都要花費更多的時間(Kaner 2001)。

　　通過手工測試人員對功能進行“檢查”的方式讓老派的QA變得非常低效。一旦團隊培養出“不要測試自己的代碼，把它丢給QA去做”這種觀念，測試工作就變得機能失調瞭(le)(KB與DHH在這次對話中的觀點)。這種方式發展到一定程度，就會造成效率的不斷下降，随著(zhe)投入的測試人員越多，反而會造成bug數量的不斷升高。('Better Testing - Worse Quality'，Hendrickson 2001)

　　摒棄QA是對於手工測試這種機能失調的實踐的一種自然反應。之所以本文的标題沒有取名爲“敏捷團隊中的測試人員”，是因爲摒棄QA的做法在某些情況下並(bìng)不可行，比如你的敏捷團隊雖然實施瞭(le)Scrum框架，卻沒有進行任何自動化單元測試，又或是團隊正在進行某些商業現成品或技術(COTS)的軟件開發。如果團隊中沒有設立功能測試人員，則必須實施TDD實踐，或是其他任何一種能夠生成自動化單元測試的方法。

　　在大多數情形下，選擇瞭TDD就意味著(zhe)你必須改變程序員的技能、習慣，並(bìng)且往往還需要改變他們的态度與自我意識。而實現以上這幾點並(bìng)不容易，同時TDD本身也並(bìng)非可以一促而就的：“要很好地掌握遺留代碼、對單元測試進行适當的隔離、以及集成測試是非常困難的”(Shore 2007)。根據評估，當程序員轉爲採用TDD實踐後，前幾個月的生産力會急劇下降。不僅如此，對實踐TDD的新手往往要進行幾周乃至幾個月時間進行手把手的培訓(Larman，Vodde 2008)。

　　依我的經驗看來，老派的程序員與測試人員之間往往存在著(zhe)一種共生現象。老派的程序員不喜歡進行單元測試，隻要項目中有測試人員，他們就企圖蒙混過關。而老派的測試人員也不願意學習技術知識，隻要爲程序員找到瞭(le)足夠的bug，他們也同樣選擇應付瞭(le)事。老派的程序員與測試人員都希望避免進行任何改變。因此，在我看來，如果程序員已經開始實施TDD實踐，再往團隊中安置一個功能測試人員就是一個壞主意。

　　我在多年的經驗中觀察到瞭(le)這種反模式：如果你打算採用TDD或其他某種由開發者進行測試的實踐，那麽僅僅是因爲在團隊中出現瞭(le)一位功能測試人員，就會讓你的努力付諸東流。因此，如果你確(què)實計劃實施TDD，我的建議是從團隊中取消功能測試人員的角色!

　　但事實上，在實施TDD的過程中，在團隊中保留一定的QA仍然是必要的，這是因爲某些變化或許會出乎你的意料。在上述關於TDD與QA的對話中，David Heinemeier Hansson說道：“或許你已經通過瞭(le)所有測試，但或許它並(bìng)沒有發現真正的問題。一旦到瞭(le)實際應用過程中，用戶會以你始料未及的方式使用你的應用。”

　　Martin Fowler十分贊同David的觀點，但在同一番對話中，Kent Beck的措詞(cí)顯得更爲謹慎。但他也同意，在QA這方面，“事情的發展已經趨向於(yú)另一個極端”。如果你無法預見到所有的可能性，那麽從外部獲取某些反饋的做法“非常有意義”。

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

　　在以上對話的較後，我們已意識到在TDD的實施中，除瞭(le)在編程過程中所創建的測試外，進行一定其他形式的測試工作仍是有意義的。敏捷測試的概念在“敏捷測試”(Crispin，Gregory 2009)等書籍中進行瞭(le)詳盡的描述。但實施敏捷測試是否仍然需要“測試人員”，即專業從事測試的員工，人們對於(yú)這一點似乎還有争論。Google仍然有數百名測試人員，而Facebook幾乎完全沒有設立測試人員的職位。

　　而普通的公司則有著(zhe)不同的考慮，他們必須保證員工已掌握瞭工具與概念方面的知識以開發並(bìng)維護各種應用，並(bìng)確保高效的分工。讓我們實際分析一下在Java環境中引入測試人員意味著(zhe)什麽。

　　支持Java的TDD工具包括JUnit與某種模拟測(cè)試框架，一般的開發者都能夠掌握這些工具。不過，JUnit框架不僅支持在Java環境中應用TDD，它還表現出瞭(le)測(cè)試工作的第二次革新：它不僅支持自動化單元測(cè)試，還支持其他各種測(cè)試的自動化。

　　JUnit目前還支持運行：通過JAX-RS實現的集成測試、自動驗收測試、基於(yú)Selenium Webdriver的UI測試、以及支持各種數據集的參數化測試等等。並(bìng)且這些測試都能夠與持續集成(CI)方案進行整合。

　　除瞭(le)這些測(cè)試工具之外，其他各種工具與框架也大量湧現。可以說，一般的開發者很難掌握在一個普通的現代化項目中所用到的全部工具。

　　概念性的知識是創(chuàng)建高質量應用的基本。要實現高可維護性，開發者需要瞭(le)解代碼整潔之道，而要掌握這方面知識需要多年的經驗積累。如果我們想要精通這一領域的知識，接下來還可以學習設計模式、線程以及性能的原理。

　　準確的、可維護的以及高性能的代碼雖然十分重要，但他們並(bìng)不能保證某個應用是可信賴的。爲瞭(le)彌補這方面的缺失，開發者還需要學習安全方面的知識。而爲瞭(le)創建一個能夠吸引用戶的應用，開發者還要瞭(le)解UX方面的知識。較後，爲瞭(le)設計一種高效的方式以保證以上所說的特性，開發者還需要熟悉測試的知識。

　　在組建IT部門時，工作的分工是又一項要考慮的重點。在團隊的專業構成中，我們可以選擇由各領域的專家，例如由一位安全方面的專家、一位UX設計師和一位測試人員組成一個團隊，但這樣一來就沒有編(biān)碼者的位置瞭(le)，結果就是團隊無法産出任何實際的東西。

　　反過來，我們也可以由多面手構成整個團隊，但這意味著(zhe)整個團隊必須将較好的光陰花費在學習上，除非他們都是天才。這樣的團隊同樣不會有很高的産(chǎn)出。

　　因此，我們的結論是在開發團隊中有必要引入部分專利性。我們不能指望每個開發者不僅能夠掌握全部的工具，並(bìng)且還是整潔代碼、UX以及安全和測(cè)試方面的專家。另一方面，在團隊中引入的專家數量也應有所限制。

　　既然我們必須引入一定的專業性，那麽設置一位測試專家是比較有意義的：對於(yú)開發者來說，如果讓他們來選擇，那麽大多數人不會去探索單元測試之外的内容，甚至有很多人根本不願意承擔任何測試工作。這也是爲什麽許多開發者不喜歡、甚至是厭惡測試的原因。如果要在這種環境中嘗試轉變爲敏捷測試實踐，那麽就需要設立一位對於(yú)測試工作有熱情並(bìng)樂於(yú)實現它的專家。

　　與TDD的實施類似，以上過程同樣需要他人的指導，並(bìng)且向團隊展示其工作結果。如果某位測試專家創建瞭(le)對某個服務的測試集，並(bìng)且能夠從IDE中執行，那麽程序員就很可能會去使用。不僅如此，如果開發者感受到瞭(le)測試的實用性，那麽他們就會開始擴展其功能，並(bìng)以可維護的方式實現。一旦爲測試所觸動之後，程序員就會願意繼續進行測試。但以我的經驗來看，僅靠程序員自己是無法感受到測試的好處的。

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

　　在QA的興衰這一節的總結部分，我曾表示：在實現瞭(le)對手工檢查工作進行自動化的TDD環境中，對於(yú)缺乏技術知識的傳統測試人員的需求已經大大降低瞭(le)。随後在對JUnit與TDD的介紹中，我們又看到開發者創建瞭(le)大量的測試工具，而缺乏技術知識的測試人員将無法使用這些工具。

　　我們現在可以負責任的說，在TDD環境中，我們需要一種新型的測試人員，他們需要具備更紮實的技術背景。至於(yú)他的日常活動包括哪些内容，要考慮到TDD所實施的環境。對於(yú)敏捷測試來說，TDD實現瞭(le)自動化金字塔(Cohn 2009)的底層，以及測試象限(testing quadrants)的第1象限(Marick 2003及Crispin 2009)。

　　爲瞭(le)更清楚地瞭(le)解其效果，讓我們來考慮這個測試場景：某個表單的一個輸入框可以接受一個整數，該數字必須在規定的邊界之内，並(bìng)且要進行後端的校驗。我們在此處可以建立16種功能性的測試用例：{ x | boundary，boundary-1，boundary+1，decimal， locale，Z，0，null，“”，“ “，abc，UTF-8，2^31-1，2^31， -2^31，-2^31-1}，但這些基本的單元測試隻屬於測試象限中的第1象限(通過面向技術的測試指導開發)。

　　而在TDD實踐中，以上測試用例将實現自動化，測試人員不應(參照上文)執行這些測試用例。一般來說，他應當對於(yú)該輸入字段是否存在以及一個正面用例進行校驗(測試象限2，通過面向業務的測試指導開發)。雖然可以通過某種錄制與播放工具完成該任務，但這種方案缺乏可維護性。更有效的技術方案是(通過整潔的代碼)編寫Selenium Webdriver代碼，並(bìng)且讓它能夠在整個團隊共用的IDE中執行。

　　象限2中的其他測試技術包括用戶故事的測試，而這些測試同樣可以實現自動化。“作爲InfoQ的用戶，我希望能夠登錄系統，以下載某些特别的内容”這樣的行爲可以暴露爲REST調用等方式，並(bìng)通過自動化測試執行。對於(yú)在GUI層進行的這種簡單測試，有人可能會選擇使用外部工具(例如SoapUi)。但更高效的做法是讓這個測試能夠在JUnit中作爲集成測試(“LogInIT.java”)而運行。而其他(沒有許可證的)團隊成員可以直接運行與維護該測試，並(bìng)且無需學習該工具的使用。

　　當基本功能都實現瞭(le)自動化檢查後，我們就達到瞭(le)第3象限(通過面向業務的測試來評價産品)：團隊已具備瞭(le)開始進行探索性測試的先決條件。David Heinemeier Hansson在上述對話表示，用戶會以你始料未及的方式使用你的應用。這一點對於(yú)其他系統也成立，此時這種方式叫做突現行爲(emergent behavior)。由於(yú)你不知道應該期望怎樣的行爲，因此此處可引入探索性測試(Hendrickson 2013)。

　　探索性測試(ET)依賴於小型的疊代：執行測試、對應用進行學習並(bìng)爲此設計新的測試。這種測試方式較初是受到Test Heuristics Cheat sheet((Hendrickson 2006))這份非常容易獲取的資料而啓發的，但並(bìng)不是說隻需簡單地執行其中的内容就代表你已經實現瞭(le)探索性測試。探索性測試的真正價值在於它的疊代式特征以及對於知識的運用。

　　舉例來說：在Heuristics Cheat Sheet中提到，在web測試中可以“對url進行各種操作，(例如變更或删除某些參數)”。如果在沒有準備的情況下直接嘗試編寫相關的腳本或直接執行是沒有實用性的。如果要改善這方面的行爲，我們可以首先用幾個疊代的時間去學習該應用使用這些參數的方式，随後想出(設計)一個相關的測試，較後才開始測試(執行)。毫無疑問，如果能夠正確(què)地運用http協議方面的知識，對於(yú)該測試的設計将帶來極大的便利。

　　我在探索性測(cè)試中的常用做法是：在IDE中運行應用程序、對應用程序服務器的日志進行監控、打開數據庫並(bìng)對網絡請求進行監控。這種方式顯然能夠看到一些在GUI中不會顯示出來的錯誤。通過這種方式，我通常能夠發現這些内容：大量的網絡錯誤與請求、日志污染、非預期的持久行爲、大量的/低效的數據庫查詢、安全性隐患以及使用性的錯誤等等。

　　這並(bìng)不是說一旦應用瞭TDD，所有的測試工作就會變得充滿技術性，或是由工具所驅動。依然有一些非常重要的測試與人相關(Ambler 2003-2014)，或是與UX的測試相關。這些測試所包含的技術性較少，但並(bìng)不意味著(zhe)就不需要瞭解深入的知識。

　　以上内容表示，TDD讓測試人員的角色發生瞭(le)變化，而不再需要進行手工功能性測試(例如檢查)。雖然他仍有大量的工作需要完成，但他所負責的功能性測試應該已經實現瞭(le)自動化。而如果他能夠掌握更多的技術、工具或其他方面的知識，那麽他的手工(探索性)測試工作很可能會變得更爲高效，隻是這些知識往往並(bìng)不容易掌握。

　　那麽，TDD團隊中的測試人員究竟應當掌握哪些技術方面的知識呢?以下陳述基本是沒什麽疑問的：敏捷測試人員需要掌握良好的技術知識，瞭(le)解如何與他人合作進行自動化測試，而成爲經驗豐富的探索性測試人員(Crispin, Gregory 2009)對於(yú)TDD團隊來說同樣有意義。

　　但我卻相信，對於(yú)已開始實踐TDD的敏捷團隊與尚未開始實踐TDD的敏捷團隊來說，他們對於(yú)職務的需求也是不同的。對於(yú)尚未開始TDD的團隊來說，敏捷測試人員也許将被迫使用某些不爲開發人員所用的測試工作，或是進行大量的手工測試。而在TDD團隊中，測試人員更有可能在IDE中進行工作，這時，該角色的技術需求就變(biàn)爲：

　　掌握至少一門編(biān)程語言(從而能夠閱讀及編(biān)寫測(cè)試)。

　　瞭(le)解命令行與腳本編(biān)寫的知識(包括服務器與本地機器)。

　　具備(bèi)數據庫方面的經驗(用於(yú)在沒有GUI的情況下檢查持久化的情況)。

　　結語

　　本文引用瞭(le)Kent Beck、Martin Fowler和David Heinemeier Hansson的對話，這也是激勵我撰寫本文的動力。如果你對於(yú)測試有興趣，應該聽一聽他們對於(yú)“将代碼扔給QA”以及“老派的QA做法還不如不要QA”等觀點坦率而直接的表述。

　　爲瞭(le)對此問題進行透徹的分析，我首先描述瞭(le)老派的功能性測試方法，它所造成的結果不經過思考的功能檢查，這種方式帶來的傷害更大於它的價值。這並(bìng)非我的臆想，而是有強烈的迹象表明仍有許多組織以這種方式進行測試，無論他們是否採用瞭(le)“敏捷”實踐。

　　接下來，我指出瞭(le)爲什麽将TDD開發者與“老派的功能測試人員”結合在一起是一種不推薦的方式。在團隊組成那一部分，我對於在TDD團隊中設置測試人員的角色持保留态度，並(bìng)将其修正爲在團隊中應當設立一些對於測試充滿熱情的成員。

　　至於(yú)測(cè)試人員所需的技能，我認爲在TDD過程中已不需要進行老派的功能性檢查。在TDD團隊中仍然有測(cè)試人員的一席之地，但他們的測(cè)試工作需要更專業的技術知識。

　　收獲

　　如果你是一位仍在進行手工檢查的測試人員，那麽應當考慮TDD或其他能夠将手工檢查自動化的解決方案。如果你還不具備上文所提到的技術知識，那麽是時候将你的知識水平提升至這一程度，從測試工作中獲得更大的樂趣!《More Agile Testing》(Crispin Gregory 2015)一書對於應當具備的知識進行瞭(le)詳盡的介紹，我極力推薦這本書給那些希望繼續從事測試工作的讀者們。爲瞭(le)掌握這些知識，我建議大家進行正規的學習，它會讓你更好地瞭(le)解某個主題，並(bìng)且加快學習的速度，同時也使你有機會證明自己已具備瞭(le)這些知識。

　　如果你是一位團隊主管或經理，並(bìng)且對於(yú)測試方面的問題感到受挫，那麽你或許應當考慮一下如何實現更高級的測試方案。你需要的是在團隊中找到能夠實現方案，同時又對測試充滿熱情的人。在“程序員即測試人員?”(Programmers as Testers?)這篇文章(Gregory 2011)中，Janet Gregory表示她傾向於(yú)測試人員應當具備技術背景的觀點，但如果他們将測試人員的角色僅僅當作成爲程序員的一塊墊腳石，那麽就不要以測試人員的身份招聘他們。這一點無可厚非，如果測試人員對於(yú)測試工作沒有熱情，他們就無法很好地實現測試象限或探索性測試。反過來說，如果某個測試人員不具備必需的技能，他就無法實現測試自動化，甚至在探索性測試中也做不到完全高效。換句話說，技能與熱情是實施敏捷測試的必要條件。