上次 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... 持續做下去，就可以達到『顏回』不貳過的境界啦。
***
友藏內心獨白：禮拜六為什麼一大早就起床寫部落格...。
沒有留言:
張貼留言