MaartenFolkers是一位測試方面的專家顧問，他對于（管理）傳統(tǒng)的軟件測試方法與現(xiàn)代化的測試技術的應用有著豐富的經(jīng)驗。現(xiàn)代化的測試技術包括TDD風格的編程方式、構建與部署自動化、在構建管道中集成協(xié)議層以及GUI層的測試、以及探索性測試（的宣傳）。Maarten具有法律專業(yè)的碩士學位，并且正在攻讀計算機科學方面的本科學位。他目前居住在位于荷蘭南部的DenBosch，熱衷于歷史、烹飪與跑步。

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

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

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

如果你打算開始嘗試TDD，那么建議你不要試圖在團隊中揉合老派的QA與功能測試人員。

如果你已經(jīng)成功地實施了TDD，那么在團隊中安排一位專攻測試的成員仍然是有意義的。

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

QA的興衰

在對“TDD已死？”這一主題所展開的一次對話中，KentBeck（KB）、MartinFowler（MF）與DavidHeinemeierHansson（DHH）圍繞著QA與測試展開了激烈的討論。他們指出了專職測試人員歷史的3個發(fā)展階段：

1.

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

2.

摒棄QA：對于讓程序員負責測試的做法過于自信，在開發(fā)過程中摒棄測試人員。

3.

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

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

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

“檢查”的主要特點在于：這種測試完全可以實現(xiàn)自動化（Bach與Bolton2013）。這就意味著“檢查”功能可以由程序員完成。至于是應該讓測試人員還是程序員進行功能“檢查”，這種選擇貌似隨意，其實不然：無論是發(fā)現(xiàn)bug、進行隔離、匯報、跟蹤或是提出修復意見，測試人員都要花費更多的時間(Kaner2001)。

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

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

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

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

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

但事實上，在實施TDD的過程中，在團隊中保留一定的QA仍然是必要的，這是因為某些變化或許會出乎你的意料。在上述關于TDD與QA的對話中，DavidHeinemeierHansson說道：“或許你已經(jīng)通過了所有測試，但或許它并沒有發(fā)現(xiàn)真正的問題。一旦到了實際應用過程中，用戶會以你始料未及的方式使用你的應用?！?/p>

MartinFowler十分贊同David的觀點，但在同一番對話中，KentBeck的措詞顯得更為謹慎。但他也同意，在QA這方面，“事情的發(fā)展已經(jīng)趨向于另一個極端”。如果你無法預見到所有的可能性，那么從外部獲取某些反饋的做法“非常有意義”。

TDD團隊中的測試與團隊組成

在以上對話的最后，我們已意識到在TDD的實施中，除了在編程過程中所創(chuàng)建的測試外，進行一定其他形式的測試工作仍是有意義的。敏捷測試的概念在“敏捷測試”（Crispin，Gregory2009）等書籍中進行了詳盡的描述。但實施敏捷測試是否仍然需要“測試人員”，即專業(yè)從事測試的員工，人們對于這一點似乎還有爭論。Google仍然有數(shù)百名測試人員，而Facebook幾乎完全沒有設立測試人員的職位。

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

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

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

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

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

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

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

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

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

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

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

TDD：具有扎實技術背景的測試人員

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

我們現(xiàn)在可以負責任的說，在TDD環(huán)境中，我們需要一種新型的測試人員，他們需要具備更扎實的技術背景。至于他的日常活動包括哪些內(nèi)容，要考慮到TDD所實施的環(huán)境。對于敏捷測試來說，TDD實現(xiàn)了自動化金字塔（Cohn2009）的底層，以及測試象限（testingquadrants）的第1象限（Marick2003及Crispin2009）。

為了更清楚地了解其效果，讓我們來考慮這個測試場景：某個表單的一個輸入框可以接受一個整數(shù)，該數(shù)字必須在規(guī)定的邊界之內(nèi)，并且要進行后端的校驗。我們在此處可以建立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象限（通過面向技術的測試指導開發(fā)）。

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

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

當基本功能都實現(xiàn)了自動化檢查后，我們就達到了第3象限（通過面向業(yè)務的測試來評價產(chǎn)品）：團隊已具備了開始進行探索性測試的先決條件。DavidHeinemeierHansson在上述對話表示，用戶會以你始料未及的方式使用你的應用。這一點對于其他系統(tǒng)也成立，此時這種方式叫做突現(xiàn)行為（emergentbehavior）。由于你不知道應該期望怎樣的行為，因此此處可引入探索性測試（Hendrickson2013）。

探索性測試（ET）依賴于小型的迭代：執(zhí)行測試、對應用進行學習并為此設計新的測試。這種測試方式最初是受到TestHeuristicsCheatsheet（(Hendrickson2006)）這份非常容易獲取的資料而啟發(fā)的，但并不是說只需簡單地執(zhí)行其中的內(nèi)容就代表你已經(jīng)實現(xiàn)了探索性測試。探索性測試的真正價值在于它的迭代式特征以及對于知識的運用。

舉例來說：在HeuristicsCheatSheet中提到，在web測試中可以“對url進行各種操作，（例如變更或刪除某些參數(shù)）”。如果在沒有準備的情況下直接嘗試編寫相關的腳本或直接執(zhí)行是沒有實用性的。如果要改善這方面的行為，我們可以首先用幾個迭代的時間去學習該應用使用這些參數(shù)的方式，隨后想出（設計）一個相關的測試，最后才開始測試（執(zhí)行）。毫無疑問，如果能夠正確地運用http協(xié)議方面的知識，對于該測試的設計將帶來極大的便利。

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

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

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

那么，TDD團隊中的測試人員究竟應當掌握哪些技術方面的知識呢？以下陳述基本是沒什么疑問的：敏捷測試人員需要掌握良好的技術知識，了解如何與他人合作進行自動化測試，而成為經(jīng)驗豐富的探索性測試人員（Crispin,Gregory2009）對于TDD團隊來說同樣有意義。

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

掌握至少一門編程語言（從而能夠閱讀及編寫測試）。

了解命令行與腳本編寫的知識（包括服務器與本地機器）。

具備數(shù)據(jù)庫方面的經(jīng)驗（用于在沒有GUI的情況下檢查持久化的情況）。

結語

本文引用了KentBeck、MartinFowler和DavidHeinemeierHansson的對話，這也是激勵我撰寫本文的動力。如果你對于測試有興趣，應該聽一聽他們對于“將代碼扔給QA”以及“老派的QA做法還不如不要QA”等觀點坦率而直接的表述。

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

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

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

收獲

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

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

請聯(lián)系網(wǎng)站客服，了解詳細的優(yōu)惠課程信息~

優(yōu)質(zhì)、權威、便捷、省心