TDD:具有扎實技術背景的測試人員
在QA的興衰這一節的總結部分,我曾表示:在實現了對手工檢查工作進行自動化的TDD環境中,對于缺乏技術知識的傳統測試人員的需求已經大大降低了。隨后在對JUnit與TDD的介紹中,我們又看到開發者創建了大量的測試工具,而缺乏技術知識的測試人員將無法使用這些工具。
我們現在可以負責任的說,在TDD環境中,我們需要一種新型的測試人員,他們需要具備更扎實的技術背景。至于他的日?;顒影男﹥热?,要考慮到 TDD所實施的環境。對于敏捷測試來說,TDD實現了自動化金字塔(Cohn 2009)的底層,以及測試象限(testing quadrants)的第1象限(Marick 2003及Crispin 2009)。
為了更清楚地了解其效果,讓我們來考慮這個測試場景:某個表單的一個輸入框可以接受一個整數,該數字必須在規定的邊界之內,并且要進行后端的校驗。我們在此處可以建立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實踐中,以上測試用例將實現自動化,測試人員不應(參照上文)執行這些測試用例。一般來說,他應當對于該輸入字段是否存在以及一個正面用例進行校驗(測試象限2,通過面向業務的測試指導開發)。雖然可以通過某種錄制與播放工具完成該任務,但這種方案缺乏可維護性。更有效的技術方案是(通過整潔的代碼)編寫Selenium Webdriver代碼,并且讓它能夠在整個團隊共用的IDE中執行。
象限2中的其他測試技術包括用戶故事的測試,而這些測試同樣可以實現自動化。“ 作為InfoQ的用戶,我希望能夠登錄系統,以下載某些特別的內容 ”這樣的行為可以暴露為REST調用等方式,并通過自動化測試執行。對于在GUI層進行的這種簡單測試,有人可能會選擇使用外部工具(例如 SoapUi)。但更高效的做法是讓這個測試能夠在JUnit中作為集成測試(“LogInIT.java”)而運行。而其他(沒有許可證的)團隊成員可以直接運行與維護該測試,并且無需學習該工具的使用。
當基本功能都實現了自動化檢查后,我們就達到了第3象限(通過面向業務的測試來評價產品):團隊已具備了開始進行探索性測試的先決條件。 David Heinemeier Hansson在上述對話表示,用戶會以你始料未及的方式使用你的應用。這一點對于其他系統也成立,此時這種方式叫做突現行為(emergent behavior)。由于你不知道應該期望怎樣的行為,因此此處可引入探索性測試(Hendrickson 2013)。
探索性測試(ET)依賴于小型的迭代:執行測試、對應用進行學習并為此設計新的測試。這種測試方式最初是受到Test Heuristics Cheat sheet((Hendrickson 2006))這份非常容易獲取的資料而啟發的,但并不是說只需簡單地執行其中的內容就代表你已經實現了探索性測試。探索性測試的真正價值在于它的迭代式特征以及對于知識的運用。
舉例來說:在Heuristics Cheat Sheet中提到,在web測試中可以“對url進行各種操作,(例如變更或刪除某些參數)”。如果在沒有準備的情況下直接嘗試編寫相關的腳本或直接執行是沒有實用性的。如果要改善這方面的行為,我們可以首先用幾個迭代的時間去學習該應用使用這些參數的方式,隨后想出(設計)一個相關的測試,最后才開始測試(執行)。毫無疑問,如果能夠正確地運用http協議方面的知識,對于該測試的設計將帶來極大的便利。
我在探索性測試中的常用做法是:在IDE中運行應用程序、對應用程序服務器的日志進行監控、打開數據庫并對網絡請求進行監控。這種方式顯然能夠看到一些在GUI中不會顯示出來的錯誤。通過這種方式,我通常能夠發現這些內容:大量的網絡錯誤與請求、日志污染、非預期的持久行為、大量的/低效的數據庫查詢、安全性隱患以及使用性的錯誤等等。
這并不是說一旦應用了TDD,所有的測試工作就會變得充滿技術性,或是由工具所驅動。依然有一些非常重要的測試與人相關(Ambler 2003-2014),或是與UX的測試相關。這些測試所包含的技術性較少,但并不意味著就不需要了解深入的知識。
以上內容表示,TDD讓測試人員的角色發生了變化,而不再需要進行手工功能性測試(例如檢查)。雖然他仍有大量的工作需要完成,但他所負責的功能性測試應該已經實現了自動化。而如果他能夠掌握更多的技術、工具或其他方面的知識,那么他的手工(探索性)測試工作很可能會變得更為高效,只是這些知識往往并不容易掌握。
原文轉自:http://www.infoq.com/cn/articles/testers-TDD-teams