l

2011年11月4日 星期五

用 Robot 寫自動化功能測試到底有沒有用

November 04 21:43~20:50


使用免費且開放原始碼的 Robot Framework 來撰寫自動化功能測試也已經有超過一年的時間了,Teddy 曾在『土炮跨平台自動化功能測試環境』與『Automated acceptance tests』提過若干使用的經驗,今天想談一個問題:『用 Robot 寫自動化功能測試到底有沒有用』?

先定義一下何謂『有沒有用』,簡單的說,就是能不能在可接受的成本範圍之內,寫出測試案例並找到 bugs。如果可以,那就認為這個方法是有用的。要如何找?一言以蔽之『做  regression testing』,如何做?不花腦筋的方法:『每天晚上下班之後讓測試系統自動跑所有的 Robot test cases』,隔天早上再來看有那些 test cases 失敗,然後探討失敗的原因,看看是不是因為系統 bugs 導致的,如果是,就加以修正。


以上程序有做過自動化功能測試的鄉民們(無論是否使用 Robot 或是其他工具)應該都很熟悉,也沒什麼特別好說明的。Teddy 想討論的第一件事:『以 Robot 這種透過 UI 來做自動化功能畫測試的方法是否值得』?


有許多開發人員認為透過 UI 來做自動化功能測試是一種不穩定的測試方法,因為 UI 可能會經常改變,導致測試案例失敗,所以常常花了很多時間才發現『原來不是程式有 bugs,而是測試案例有  bugs (因為 UI 修改所導致)』。再加上,許多 UI 操作的 turnaround time(下達指令之後到該指令完成所花的時間)可能差異很大(尤其是在分散式系統中),這樣的功能要透過 UI 來測試系統就常常可能因為 timeout 導致測試案例失敗,但是實際上有可能只是某次的執行時間花的比較久一點(例如後端的資料庫正在忙碌,或是網路速度剛好很慢)。最後,自動化功能測試只能知道『該功能是否成功或失敗』,當功能失敗的時候,不容易直接看出原因,所以後續可能需要花比較久的時間來找出錯誤原因。還有一個開發人員可能不願意透過 UI 來做自動化功能測試的原因,那就是『這種測試案例不是很好寫』。


***

與『自動化單元測試(automated unit testing)』相比,自動化功能測試的確比較不好寫,因為後者要測的範圍比較大(透過 UI做 end-to-end testing)。在剛開始導入 Robot 的前 2-3 個月,Teddy 也一直在想同樣的問題:『讓團隊成員花時間寫 Robot 測試案例是否值得(到底有沒有找到 bugs 啊)』?因為剛開始的時候大家對 Robot 還不是很熟悉,所以寫一個 Robot test case 花的時間比較長,而且這些 Robot test cases 常常會因為『測試環境』的問題導致執行失敗。例如剛剛 Teddy 說過的 timeout 的問題(timeout 時間設太短),再加上測試環境的準備以及一些跨平台測試的因素,所以剛起步的時候幾乎看不出所寫的 Robot test cases 可以找出什麼 bugs,只能求這些 Robot test cases 可以穩定的執行。


為了讓撰寫以及維護 Robot test cases 可以持續正常,每個 sprint 團隊都有一個 technical story 是用來至少確保 Robot test cases 可以正常執行,如果還有時間則每個 sprint 還會持續增加幾個(個位數)新的 Robot test cases


看到這邊可能有鄉民會問,為什麼不把寫 Robot test cases 當作每一個 story 的驗收條件?這樣不是每個 story 完成之後就有現成的自動化功能測試了嗎?理想上這樣是很好,也許有人採用 Acceptance Test Driven Development (ATDD) 就是這樣做的,但是目前團隊並沒有採用 ATDD,每個 story 基本上會有單元測試以及手動的人工驗收測試,等 sprint demo 之後,確定沒有大的介面修改,才會在後續的 sprint 中找時間來『補寫』 Robot test cases。


***


導入 Robot 到現在也超過 1 年了,團隊成員寫 Robot test cases 越來越快,除了對工具本身熟悉度變高以外,還有 team member 熱心的寫了很多好用的 keywords (擴充 Robot)來加速撰寫測試案例的時間。Robot test cases 越來越穩定,當 test cases 執行失敗時找出原因的時間也越來越短,投資總算慢慢看到具體的回報(因為當 Robot test cases 失敗的時候,真的有找到系統的 bugs)。


有些 bugs 在單元測試的層次是不容易找出來的,因為問題可能出在 UI  端與後端元件的溝通上面。或是當整個系統整合起來時,想透過 UI 來測試效能的問題。又或是要確定最後打包的安裝程式是否能夠正常的安裝並執行,確認網頁上面每一個 link 按下去都是正常的。以上種種情況都還是需要做 end-to-end testing。


當看到 JUnit 上面都是『綠燈』的時候,程式設計師的心情會變得比較好一點。當看到 Robot test cases 都通過的時候,每個人的心情都會變好。每個 sprint 投資一點時間在自動化功能測試上絕對是頗值得的一件事。


***

友藏內獨白:『傻的願意相信』是很重要滴,團隊是在寫 Robot 之後,才學會 Robot 。

沒有留言:

張貼留言