TDD團隊中的測試人員(3)

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

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

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

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

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

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

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

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

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

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

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

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

原文轉自：http://www.infoq.com/cn/articles/testers-TDD-teams