如果你採用的是最夯的iterative 開發生命週期，
那專案經理最大的惡夢之一很有可能就是一個iteration結束後，build 卻因為重大的defect而不能用。((這真是慘，如果你的build是星期五出的，很有可能星期六日還要來加班 …所以建議大家把出build 時間挪到星期四或星期一= =+))
iteratively 開發最大的特點在於，需求是一直一直往上加的。但是，你開發了新的功能，或修了 舊的defect，測試卻是需要測試「所有的」功能。因為沒有人敢保證在加新功能的時候，對於舊功能是毫髮無傷的。所以，測試人員的工作只會隨著功能的增加而越來越繁重。如果這個系統十分大，用人工來執行測試到最後真的會測到哭出來。所以，自動測試是iteratively開發的王道。
回到web2.0的應用系統，如果我們想要做網頁程式的自動測試，就需要有一個工具可以來模擬測試人員在測試網頁時的行為，並能夠進行驗證，最最重要的是，它的錄製、修改成本絕對不能太高 - 因為我們要接受一件事實，世界上沒有不變的需求((而且通常是變很大)); 如果每一次的改變，都必需大費週章重新錄製角本，那可能會比人工測試還要慘歐 ~
最近亂逛又看到 selenium 這個工具，覺得十分的不錯。除了它可以鬆錄製測試角本(有selenium IDE, 是FF的plugin)之外，因為它的指令十分簡單，所以修改看來也不是個問題。
讓我印象最深刻的是，它的selector 十分活，你可以指定 element id, XPath(找XPath), 或是用 document.getElementById...這種寫法來取得要click, focus (有許多 command供君選擇)的元件，也可以assert裏面的值。還可以將錄好的角本轉成java unit test整合於 CI(Continuous Integration)上面十分方便。在 firefox 錄好的角本，動動手腳一樣可以在 IE跑，所以也可以跨瀏覽器測試。
不過，有一些功能，像上傳檔案，就沒法子測。(原因尚未參透); 而FF不支援的modal dialog 也無法在FF 錄製，要另外再寫囉。
不過這樣的自動測試面臨的另一個問題是，流程上該怎麼安排? 你需要一個乾淨的資料庫，從頭開始insert資料、驗証資料，還是你只想確保頁面不爛，功能可看 ? 或你有更大的野心 - 把頁面的整合測試納入 CI管控 ? 不同的practice提供的保證不一樣，所付出的成本也不同，只能說看情況選擇最適合自已的囉 ~
沒有留言:
張貼留言