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

        英文原文：What does TDD mean for me, the Tester?

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

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

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

        我對 TDD 的看法

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

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

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

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

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

        設計一個測試缺陷

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

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

        多溝通多測試

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

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

        重構

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

        閉環

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

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

        寫在最后

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

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

        1.   嘗試情景驅動測試

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

        2.   做個細心的觀察者

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

        3.   干一行，精一行。

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

                    <span id="shareA4" class="fl">   

                        </span> 

</div>