最近，關於下一代功能測試工具發展方向的討論熱鬧地開了鍋。不過，還是眾多組織仍然在努力讓傳統的「錄製-回放」測試工具跟上敏捷的腳步
。被稱為「測試狂人
」的elisabeth hendrickson
告訴他們為什麼不要再白費功夫
了。 hendrickson將她的看法出色地總結為下面這種索引卡片的形式：
為什麼傳統的、「錄製-回放」式的、重量級的、商業化測試自動化解決方案做不到敏捷hendrickson首先講述 「錄製-回放」式工具的「最後再測試」方式是如何難以取得成功的，而無關乎專案是否敏捷。她解釋了為什麼這對敏捷專案來說尤其是個傷害。在敏捷專案中，「最後再測試」的工作流程至少有下列問題：三個原因：
對於敏捷團隊來說，類似工具所鼓勵的「最後再測試」的工作流程是完全錯誤的。
類似工具建立的無法維護的指令碼會成為敏捷所需的變更的障礙。
這樣的特定工具會需要專門的自動化測試專家，因此會形成單打獨鬥的局面。
hendrickson解釋了測試指令碼如何成為這些「錄製-回放」測試工具的基礎，而且會無可避免地造成類似義大利面的混亂局面，將ui**中有關業務上的期待和具體實現細節混雜在一起，從而導致敏捷專案很容易變為一場維護的噩夢。她簡明地說：……進一步說，「最後再測試」工具無法支援「
驗收測試驅動開發（acceptance test driven development）
」。敏捷團隊需要的測試工具要支援「首先測試」的方式，並可以馬上開始進行自動化測試。
敏捷團隊需要可以將要測試的業務實質內容與實現細節相分離的工具。接下來，在很大程度上出於考慮高昂成本和**所有權的需要，典型的「錄製回放」工具會將大多數組織引向建立專有的「自動化測試專家」小組之路，並且他們會被授權負責監控自動化測試。hendrickson強調了這樣的方式是如何對有效敏捷所需的協作方式形成阻礙的。這樣的分離
是良好設計的標誌，並可以增加可維護性。
敏捷團隊通過破除單幹的局面來提公升工作效率，這憑一些所謂的自動化測試「超級英雄」無法完成。也就是說自動化測試成為需要協作完成的工作。業務利益相關 者、分析師和黑盒測試人員，他們都可以通過可自動化的形式（比如fit**）來做出對測試的貢獻；而程式設計師則負責編寫**將測試與實現相關聯。最後，hendrickson討論了敏捷團隊確實需要什麼樣的自動化測試工具，並以此作為結束：
敏捷團隊需要的自動化測試工具或框架要像這樣：很值得花費一些時間來讀elisebeth hendrickson這篇完整的部落格帖子fit、
fitnesse
以及相關工具可以達成上述要求。
，這樣更加了解她深入的想法和經驗。此外還可以閱讀brian marrick的部落格
來獲取更多關於敏捷測試
的專家級建議。
檢視英文原文：why traditional test-automation tools stifle agility.
譯者鄭柯 發布於www.infoq.com/cn/news/2008/05/testobsessed-agile-auto-testing
為何傳統自動化測試工具會扼殺敏捷
為何傳統自動化測試工具會扼殺敏捷？最近，關於下一代功能測試工具發展方向的討論熱鬧地開了鍋。不過，還是眾多組織仍然在努力讓傳統的 錄製 回放 測試工具跟上敏捷的腳步。被稱為 測試狂人 的elisabeth hendrickson告訴他們為什麼不要再白費功夫了。hendrickson將她的看法出色地總結...
自動化測試工具
二 如何實施自動化測試 自動化測試指軟體測試的自動化，在預設狀態下執行應用程式或者系統預設條件包括正常和異常，最後評估執行結果。將人為驅動的測試行為轉化為機器執行的過程。自動化測試框架一般可以分為兩個層次，上層是管理整個自動化測試的開發，執行以及維護，在比較龐大的專案中，它體現重要的作用，它可以管理...
自動化測試工具monkey
monkey是android中的乙個命令列工具，可以執行在模擬器裡或實際裝置中。它向系統傳送偽隨機的使用者事件流 如按鍵輸入 觸控螢幕輸入 手勢輸入等 實現對正在開發的應用程式進行壓力測試。monkey測試是一種為了測試軟體的穩定性 健壯性的快速有效的方法。a 測試的物件僅為應用程式包，有一定的侷限...