Pekka Kl??rck，作為Robot Framework的建立者和核心開發者，按照系統級別，介紹了幾種不同的自動化測試方法的區別。
一、記錄回放的方式流行於商業工具之中，無需程式設計技能即可快速上手。然而這種方法相對脆弱，一旦UI變化測試就會受到影響，分散的指令碼不可重用且難以維護，而且系統在測試前必須可用（也就意味著無法使用A-TDD方法）。因此這種方法並不適合大型自動化測試。
二、線性指令碼允許使用各種語言來編寫非結構化指令碼，指令碼直接與被測系統互動。能夠快速上手，靈活性強。但是編寫指令碼需要程式設計技能，系統中一個改動會影響所有指令碼，沒有經過模組化或重用的大量指令碼難以維護。因此這種方法適合簡單任務，不適合大型自動化。
三、模組化指令碼由兩部分組成：驅動指令碼執行測試，測試庫函式完成與被測系統互動。驅動指令碼編寫起來非常簡單，這樣可以更快地建立新測試，容易維護。然而需要花時間和程式設計技能建立測試庫，並將測試資料嵌入指令碼，建立新測試就需要新的測試指令碼。因此，只要擁有程式設計技能，這種方法還是適合大型專案，但不適合非程式設計人員。
四、資料驅動方法，將資料與測試指令碼分離，基於模組化的測試庫，一個驅動指令碼可以執行多個相似測試，這樣非常容易建立新測試。維護工作可以分離，測試人員負責資料，程式設計師負責寫測試庫。然而，不同型別測試仍需要新的驅動指令碼，初始建立資料解析器和重用元件需要花人力。這種方法適合大型專案，只需要較少的程式設計技能。
五、關鍵字驅動，將資料與關鍵字結合來描述如何使用資料執行測試。這種方法具備資料驅動的優勢，同時非程式設計人員也能建立新型別測試。所有測試由同一個框架來執行，無需不同的驅動指令碼。然而初始成本很大，但是可以使用開源方案！因此非常適合大型專案。Pekka對以上五種方法的介紹其實也是對自動化測試發展史的介紹，同時也體現了RobotFramework背後的設計思想。除了測試框架的選擇，要想做好自動化測試，還要關注其他方面。自動化測試需要關注可測性。自動化最難的部分是與被測系統互動，特別是GUI層。確保系統容易被測試，比如給GUI元素增加標識、輸出易於解析的文字、提供自動化介面等。系統一般可以分為GUI層以及GUI之下的業務層。GUI層測試需要呼叫與普通使用者同樣的介面，但是某些GUI技術缺乏好的工具支援，會使測試變得脆弱，而且執行相對較慢。從業務層開始測試相對容易，執行快。但GUI層仍然需要被測試，以保證GUI正確連線到了業務層，甚至有時GUI層也具有業務功能。Pekka建議考慮對業務層進行完全測試，而部分地對GUI層實行端到端測試。 不是所有系統都具有GUI層，卻可能具有API、資料庫、伺服器、命令列等。自動化測試框架可以呼叫不同驅動來進行測試。這些非GUI層相對容易測試，只要把測試用例看作另一個客戶端而已。那麼自動化測試應該在什麼階段進行？如果開發完成後單獨做自動化，這是典型的瀑布式過程，不同團隊之間存在溝通障礙，反饋週期慢，產品在後期難以獲得可測性，從而導致複雜和脆弱的測試方案。相反，典型敏捷式過程中，程式設計師和測試人員協同完成自動化。把自動化看作團隊開發的一部分，可測性不再是問題，團隊做技術決定時就可以考慮可測性和工具選擇，程式設計師可以提前加入提供可測性的鉤子特性。自動化測試需要版本控制和持續整合來支援。將測試和程式碼放在一起，像管理程式碼一樣管理測試指令碼，那麼多可用工具，SVN、GIT、Mercurial，沒道理不用。持續整合是全方位自動化的關鍵，當測試或程式碼有所改動立即執行測試。如果測試執行時間比較長，也可以定期執行。使用Jenkins、Hudson、Cruise Control、BuildBot吧，自己寫定時指令碼或Cron Job可以休矣。選擇商業自動化工具還是開源工具？好東西肯定貴，但是貴的不見得好，再便宜的許可證也會阻止整個團隊的協作。而且商業化工具難以和其他自動化工具（特別是其他廠商的）或版本控制、持續整合進行整合和定製化。另外，產品終止或公司關門是潛在的風險。開源工具可供選擇餘地很大，當然也是良莠不齊。開源工具通常容易與其他工具整合，關鍵是免費，誰都可以隨意使用和定製化，還永遠不會消失。至於免費軟體，越來越少了，很多自由軟體都已經開源。免費軟體同樣不能定製化，且存在中止的風險。做自動化需要哪些技能？一般來說，包括Python、Ruby、Perl、JavaScript、正則表示式、XPath和CSS定位、SQL語句、版本控制等。有了自動化，手工測試還需要嗎？當然需要！！ 不過，要避免手工執行指令碼來測試，還是將其完全自動化吧，測試人員可以更多關注於探索性測試。 記住，機器擅長迴歸測試，人類善於尋找Bug。
Pekka Kl??rck，作為Robot Framework的建立者和核心開發者，按照系統級別，介紹了幾種不同的自動化測試方法的區別。
一、記錄回放的方式流行於商業工具之中，無需程式設計技能即可快速上手。然而這種方法相對脆弱，一旦UI變化測試就會受到影響，分散的指令碼不可重用且難以維護，而且系統在測試前必須可用（也就意味著無法使用A-TDD方法）。因此這種方法並不適合大型自動化測試。
二、線性指令碼允許使用各種語言來編寫非結構化指令碼，指令碼直接與被測系統互動。能夠快速上手，靈活性強。但是編寫指令碼需要程式設計技能，系統中一個改動會影響所有指令碼，沒有經過模組化或重用的大量指令碼難以維護。因此這種方法適合簡單任務，不適合大型自動化。
三、模組化指令碼由兩部分組成：驅動指令碼執行測試，測試庫函式完成與被測系統互動。驅動指令碼編寫起來非常簡單，這樣可以更快地建立新測試，容易維護。然而需要花時間和程式設計技能建立測試庫，並將測試資料嵌入指令碼，建立新測試就需要新的測試指令碼。因此，只要擁有程式設計技能，這種方法還是適合大型專案，但不適合非程式設計人員。
四、資料驅動方法，將資料與測試指令碼分離，基於模組化的測試庫，一個驅動指令碼可以執行多個相似測試，這樣非常容易建立新測試。維護工作可以分離，測試人員負責資料，程式設計師負責寫測試庫。然而，不同型別測試仍需要新的驅動指令碼，初始建立資料解析器和重用元件需要花人力。這種方法適合大型專案，只需要較少的程式設計技能。
五、關鍵字驅動，將資料與關鍵字結合來描述如何使用資料執行測試。這種方法具備資料驅動的優勢，同時非程式設計人員也能建立新型別測試。所有測試由同一個框架來執行，無需不同的驅動指令碼。然而初始成本很大，但是可以使用開源方案！因此非常適合大型專案。Pekka對以上五種方法的介紹其實也是對自動化測試發展史的介紹，同時也體現了RobotFramework背後的設計思想。除了測試框架的選擇，要想做好自動化測試，還要關注其他方面。自動化測試需要關注可測性。自動化最難的部分是與被測系統互動，特別是GUI層。確保系統容易被測試，比如給GUI元素增加標識、輸出易於解析的文字、提供自動化介面等。系統一般可以分為GUI層以及GUI之下的業務層。GUI層測試需要呼叫與普通使用者同樣的介面，但是某些GUI技術缺乏好的工具支援，會使測試變得脆弱，而且執行相對較慢。從業務層開始測試相對容易，執行快。但GUI層仍然需要被測試，以保證GUI正確連線到了業務層，甚至有時GUI層也具有業務功能。Pekka建議考慮對業務層進行完全測試，而部分地對GUI層實行端到端測試。 不是所有系統都具有GUI層，卻可能具有API、資料庫、伺服器、命令列等。自動化測試框架可以呼叫不同驅動來進行測試。這些非GUI層相對容易測試，只要把測試用例看作另一個客戶端而已。那麼自動化測試應該在什麼階段進行？如果開發完成後單獨做自動化，這是典型的瀑布式過程，不同團隊之間存在溝通障礙，反饋週期慢，產品在後期難以獲得可測性，從而導致複雜和脆弱的測試方案。相反，典型敏捷式過程中，程式設計師和測試人員協同完成自動化。把自動化看作團隊開發的一部分，可測性不再是問題，團隊做技術決定時就可以考慮可測性和工具選擇，程式設計師可以提前加入提供可測性的鉤子特性。自動化測試需要版本控制和持續整合來支援。將測試和程式碼放在一起，像管理程式碼一樣管理測試指令碼，那麼多可用工具，SVN、GIT、Mercurial，沒道理不用。持續整合是全方位自動化的關鍵，當測試或程式碼有所改動立即執行測試。如果測試執行時間比較長，也可以定期執行。使用Jenkins、Hudson、Cruise Control、BuildBot吧，自己寫定時指令碼或Cron Job可以休矣。選擇商業自動化工具還是開源工具？好東西肯定貴，但是貴的不見得好，再便宜的許可證也會阻止整個團隊的協作。而且商業化工具難以和其他自動化工具（特別是其他廠商的）或版本控制、持續整合進行整合和定製化。另外，產品終止或公司關門是潛在的風險。開源工具可供選擇餘地很大，當然也是良莠不齊。開源工具通常容易與其他工具整合，關鍵是免費，誰都可以隨意使用和定製化，還永遠不會消失。至於免費軟體，越來越少了，很多自由軟體都已經開源。免費軟體同樣不能定製化，且存在中止的風險。做自動化需要哪些技能？一般來說，包括Python、Ruby、Perl、JavaScript、正則表示式、XPath和CSS定位、SQL語句、版本控制等。有了自動化，手工測試還需要嗎？當然需要！！ 不過，要避免手工執行指令碼來測試，還是將其完全自動化吧，測試人員可以更多關注於探索性測試。 記住，機器擅長迴歸測試，人類善於尋找Bug。