上次 Teddy 談到『用 Robot 寫自動化功能測試到底有沒有用』 這個問題,最近剛好把開發的系統做了一些『升級』,更是體會到『Robot...不能沒有你』。
***
各位吃『軟飯』的鄉民們應該會和 Teddy 一樣有相同的感慨,軟體開發久了,最後發現絕大部份的時間都花在『測試』上面。假設相同一隻程式(code)也許只要寫(改)個 10 次好了,光是測試可能就要 10 * N 次。這是什麼意思?假設你的程式要支援 8 個作業系統(Window XP,Windows 2003,Windows 2008,Windows 7,RHEL 6.x,SUSE 11.x,Ubuntu 11.x,CentOS 6.x),32-bit 和 64-bit ,以及 3 種瀏覽器(IE,Firefox,Chrome),Teddy 數學不好,請鄉民們自行算一下有幾種測試環境的組合。
你可能會說:『Developers 只要測試主要的開發平台(1-2 種平台),其他的找測試部門做平台相容性測試就好了啊』。『理想上』是如此,但是,如果你的 team 沒有配合的『測試人員或是測試部門』,那怎麼辦?你可以選擇『讓客戶幫你測 ...XD』,或是認命一點,自己測。
假設鄉民們和 Teddy 一樣都是『有理想,有
***
但是要讓電腦累死之前自己可能會先累死...XD...因為:
- 要寫自動化(功能)測試案例。寫完一個 Robot test case 可能需要 4-6 小時的時間(包含寫這個 test case 和測試這個 test case 的時間)。
- 要準備測試環境。光有自動化功能測試案例,沒有測試環境也是白搭啊。以剛剛 Teddy 提到的那 8 個作業系統的例子,至少就要準備 16 個作業系統(8 個作業系統各 32-bit 和 64-bit 一共 16 個)。
看到這邊鄉民們可能會大喊一聲...等一下....『我們可是窮苦人家的小孩耶,去那邊生 16 台電腦出來安裝這 16 個測試環境?』。關於這一點請參考『土炮跨平台自動化功能測試環境』裡面介紹的方法。什麼....你說:『用 VM 不就好了』...
如果鄉民們參考 Teddy 在『土炮跨平台自動化功能測試環境』裡面所建議採用『DRBL Server 管理測試 images』的方法,準備好這 16 個測試環境就沒事了嗎?當然不是,因為採用 DRBL Server 管理測試 images 的方式主要是用來在下班之後跑 nightly build,每次 restore 一個測試 image 可能需要 數分鐘 到 10 幾分鐘的時間,如果再加上執行 Robot test cases 的時間,一定無法滿足『Ten-Minute Build』的要求。如果要用這種方法在白天開發程式時拿來當作測試的環境,這種測試方法的 turnaround time 就稍嫌長了一點,developers 也不會想要去用(測試)。
那怎麼辦?兩種方法:
- 多增加若干台『實體機器』以執行與硬體相關的測試:這些給 developers 在『白天』用來測試的『實體機器』,可以是原本完整測試環境的『子集合』。以前面提到 8 個作業系統的例子,最少可以只準備一台 Windows 64-bit 電腦與一台 Linux 64-bit 電腦就好了。Developers 在本機上寫好的程式可以丟到這些實體機器上面測試。
- 增加一組或以上的 VM 以執行與硬體無關的測試:對於與硬體無關的功能,可以依據『
公司口袋的深度硬體測試資源的多寡』準備很多組 VM,例如準備上述 16 種完整的測試環境,或是完整測試環境的子集合。然後使用類似 Jenkins 這種『分散式持續整合系統』,當 developers 認為需要的時候,在 Jenkins 上面只要輕輕按下『建構按鈕』便可將所開發的軟體系統『同時丟到這些 VM 上面跑 Robot 測試案例』。那種感覺....很...過...癮...尤其是全部 test cases 都 pass 的時候....不過此種現象出現的機會大概跟 9 星連成一線一樣,百年難得一見....XD。
***
又扯了這麼多,你看的不累,Teddy 都寫到累了...XD。總結一下:
- 要持續寫 Robot test cases:假設剛開始寫一個測試案例需要花 8 小時以上,熟了之後可能只需要 4 小時完成一個 Robot 測試案例。想到這個測試案例可以一直使用,這 4 小時的投資算是滿划算的。
- 準備三種不同的測試環境:(1)用 DRBL Server 管理給 nightly build 用的眾多實體測試環境之 OS images;(2)準備若干台實體機器(通常是完整測試環境的子集合)給 developers 白天開發軟體與測試之用;(3)依據公司口袋深度準備若干(越多越好) VM,在白天上班時間由持續整合系統定期(例如每小時一次)或是由 developers 手動將自動化測試案例『同時』丟一組 VM 上執行。
- 找專人持續關注測試案例執行後的結果。透過 UI 執行的自動化功能測試通常是很『脆弱』滴,很有可能因為『不明原因』執行失敗(有時成功,有時失敗)。因此,要指定
倒楣鬼專門技術人員...XD,持續關注測試案例執行結果。看看測試案例執行錯誤原因是因為程式錯誤,測試環境問題,還是測試案例撰寫問題,然後加以排除。
***
什麼,你問 Robot test cases 有沒有找到什麼問題?有啊,舉的例子,Teddy 曾經遇到過換了新版的 jQuery 之後原本 UI 上面的某個 check box 突然消失了 。這個問題就被『檢查所有網頁連結』的 Robot test case 給找出來了。那麼 Robot test cases 可以涵蓋到所有的軟體功能嗎?別傻了...當然...還沒有(需要時間和人力才能達到這樣的地步),所以,人工測試還是有需要滴。當人工測試找到新的 bug 時,要記得為此 bug 加上一個新的 Robot test case ,以確保日後如果相同的問題再次出現,可以被測試案例給逮住。這也算是符合 agile 精神... incremental growth... 持續做下去,就可以達到『顏回』不貳過的境界啦。
***
友藏內心獨白:禮拜六為什麼一大早就起床寫部落格...。