對于測試人員而言，TDD意味著什么？

還記得早前CSDN發過的這篇《TDD已死，測試永生》嗎？文中大意是說Ruby on Rails的創始人David Heinemeier痛批TDD過于偏重單元測試，過于瑣碎，會使系統由許多中間層、中間對象網組成，帶來復雜臃腫的架構。對于這一觀點頗有爭議，本文作者Duncan Nisbet則認為TDD對于測試人員來說有著很好的指導作用。

譯文如下：

作為一名測試人員，似乎測試驅動開發(TDD)技術與自己沒有太大關系，但是在實際工作中，我卻發現TDD對測試環節也是有很好指導作用的。

作為極限編程(XP)所倡導的方式，TDD中的角色配置如下：

• 程序員
• 開發人員
• 用戶

我對TDD的看法

除了要掌握TDD中提出的“紅-綠-重構”環，我認為能否寫出一個有效的測試缺陷是關鍵的一步，而能否弄清測試缺陷是什么更是關鍵中的關鍵。

較少與寫代碼打交道的測試人員該如何參與TDD環節

很多時候，人們認為程序員關注的是代碼設計，測試員關注的是軟件行為。但是這兩者之間的界限其實是不需要太過明確的，他們雙方可以形成互補。根據軟件測試大師James Bach的定義，測試人員有兩個主要的職責：可控制性和可監控性。比方說：系統能否在我們設好的狀態下正常運作以及我們該如何進行監控？程序能否在設定的關鍵點上按時執行以及該如何進行記錄？

在談及程序員的角色時，我習慣用時序圖來描述系統中有關請求和響應的部分。這樣會讓程序員和測試員都能明白系統在不同狀態下的走向，從而明白什么樣的測試才是需要的。測試人員與程序員應該互相合作，避免重復或無效的測試。

這是一個典型的Web程序時序圖：

設計一個測試缺陷

一般情況下，在TDD環中，程序員的工作始于代碼，同時等候著單元測試那邊的反饋。

我會琢磨該選擇哪種測試方法和什么樣的邊界測試用例，以及列出測試中可能遇到的情況。由于軟件設計工作是漸進明細的，有不少問題會在這個過程中產生。例如：需要就某個特殊情況對單元測試做出修改，或是邊界用例需要代碼做出變更。因此要設計好測試用例，盡早把潛在缺陷暴露出來。

多溝通多測試

程序員會與我就測試范圍和時間進行溝通，然后我們會一起把代碼以及測試計劃粗略過一遍，商討好具體的測試范圍與標準，然后開展測試工作。

我會嘗試測試幾個預先設計好的邊緣用例和突發用例，以檢查其有效性。這樣做的好處是能有機會向客戶展示軟件，看是否符合他們的期望。一般情況下，這個雙向的溝通交流過程需要幾個小時。

重構

程序員繼續完善代碼，測試人員繼續完成測試任務。以搭檔的形式與程序員一起工作，可以更好地理解程序的流程走向，清楚什么測試才是需要的，以及找出程序的灰色地帶和錯誤多發位置，進行改進修正。通過透明坦誠的雙向溝通，會減少很多誤會和無用功。

閉環

到了收尾階段，我覺得這個工作與修補衣服差不多的。縫補的針線越細密，出差錯的幾率越少。

要做軟件功能性方面的審查，參與方不能僅僅是測試人員，還得與該軟件相關聯的人員或部門參與，如：運營部，市場部等。這樣一來，在最后的項目結束會議中，多方可以各抒己見，從而最終評定該產品是否值得推出和推廣。

寫在最后

依據上述步驟，我在TDD環中加入了測試人員工作環節，形成TDD-測試人員環，請看下圖：

結合自己的實際情況，我還有以下幾點提示，可以讓TDD-測試人員環走得更順：

1.  嘗試情景驅動測試

當剛從一個瀑布開發團隊轉入極限編程團隊時，我經歷了一段過渡陣痛期。而情景驅動測試的出現，幫助我最終順利完成 了轉換。

2.  做個細心的觀察者

程序員一般都會為自己的作品感到驕傲。我們不妨多花時間去了解身邊的程序員，看看他們做了什么，怎么做的，又是如何得到今天的成就的。天道酬勤，你會有意想不到的收獲。

3.  干一行，精一行。

我們不能僅僅關注自己的測試工作，所謂知己知彼，百戰不殆；我們需要深入了解自己公司的產品，看看這個軟件幫助客戶解決了什么問題或還沒有解決什么問題，將來會如何發展。只有凡事占得先機，我們在測試這條路上才會走得更好更遠。