先定義一下何謂『有沒有用』，簡單的說，就是能不能在可接受的成本範圍之內，寫出測試案例並找到 bugs。如果可以，那就認為這個方法是有用的。要如何找？一言以蔽之『做 regression testing』，如何做？不花腦筋的方法：『每天晚上下班之後讓測試系統自動跑所有的 Robot test cases』，隔天早上再來看有那些 test cases 失敗，然後探討失敗的原因，看看是不是因為系統 bugs 導致的，如果是，就加以修正。
以上程序有做過自動化功能測試的鄉民們（無論是否使用 Robot 或是其他工具）應該都很熟悉，也沒什麼特別好說明的。Teddy 想討論的第一件事：『以 Robot 這種透過 UI 來做自動化功能畫測試的方法是否值得』？
有許多開發人員認為透過 UI 來做自動化功能測試是一種不穩定的測試方法，因為 UI 可能會經常改變，導致測試案例失敗，所以常常花了很多時間才發現『原來不是程式有 bugs，而是測試案例有 bugs （因為 UI 修改所導致）』。再加上，許多 UI 操作的 turnaround time（下達指令之後到該指令完成所花的時間）可能差異很大（尤其是在分散式系統中），這樣的功能要透過 UI 來測試系統就常常可能因為 timeout 導致測試案例失敗，但是實際上有可能只是某次的執行時間花的比較久一點（例如後端的資料庫正在忙碌，或是網路速度剛好很慢）。最後，自動化功能測試只能知道『該功能是否成功或失敗』，當功能失敗的時候，不容易直接看出原因，所以後續可能需要花比較久的時間來找出錯誤原因。還有一個開發人員可能不願意透過 UI 來做自動化功能測試的原因，那就是『這種測試案例不是很好寫』。
***
為了讓撰寫以及維護 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。
***
有些 bugs 在單元測試的層次是不容易找出來的，因為問題可能出在 UI 端與後端元件的溝通上面。或是當整個系統整合起來時，想透過 UI 來測試效能的問題。又或是要確定最後打包的安裝程式是否能夠正常的安裝並執行，確認網頁上面每一個 link 按下去都是正常的。以上種種情況都還是需要做 end-to-end testing。
當看到 JUnit 上面都是『綠燈』的時候，程式設計師的心情會變得比較好一點。當看到 Robot test cases 都通過的時候，每個人的心情都會變好。每個 sprint 投資一點時間在自動化功能測試上絕對是頗值得的一件事。
***
友藏內獨白：『傻的願意相信』是很重要滴，團隊是在寫 Robot 之後，才學會 Robot 。
沒有留言:
張貼留言