10個對於不寫程式就完成自動化測試的錯誤迷失
這篇文章主要說明一般對於自動化測試, 特別是不寫程式的方法的錯誤迷思
有些是因為不夠專業所導致, 有些是因為對自動化測試本身有所誤解,
因此, 藉由這篇文章來補充說明, 這些迷思與觀念.
迷思1: 不寫程式完成自動化, 是用錄製的方式?
錯. 錄製的方式缺點在於可重複使用的機率很多,
而且對於錄製完成的腳本如果沒有一定程度的理解與編輯,
未來該自動化腳本也會很難維護.
因此我們建議用 Key Word Driven 的方式, 而不是錄製的方式
迷思2: 不寫程式完成自動化, 只能達到10%自動化率?
錯! 自動化操作的步驟 + 驗證結果, 才是自動化測試的核心價值
因此, 將重複性的動作自動化, 依據筆者經驗其實高達 80%的操作或是功能都可以自動化!
迷思3: 我們產品UI不斷更新, 不適合自動化?
筆者常見的一個無法自動化的理由是, 我們研發的產品UI 不斷的更新,
因此自動化耗時且無法重複被使用
耗時的問題在於工具選用, 只要應用得當是可以完全不耗時完成自動化
UI 修改無法重複被使用, 通常是因為UI Web Element Locator 與開發團隊沒有達成一致,
只要 Web Element Locator定義好, 通常UI 怎麼修改, 架構怎樣修改都不會影響的!
這也是筆者普遍遇到的迷思與困惑
迷思4: Selenium IDE自動化測試無法與CI結合?
錯. Selenium IDE 的測試腳本是可以從指令模式下啟動, 透過指令呼叫跟CI結合
如此一來, 每天的 CI build, 就可以啟動Selenium測試
迷思5: Selenium IDE自動化測試無法擴充?
Selenium IDE 可以將腳本輸出 .NET, Java, Python 等腳本, 反而更容易擴充
迷思6: Selenium IDE自動化測試只能測試FireFox?
Selenium IDE 的執行是可以啟動 chrome, 或是其他瀏覽器. 不限定在FireFox
迷思7: Selenium IDE 指令很多?
其實核心的指令不超過十個, 就可對Web 進行各種操作與驗證.
迷思8: 不寫程式的自動化就不夠專業?
- Selenium IDE 可以將定義的腳本直接輸出為Python or Java, 反而增加開發的速度
- 自動化測試的目的是有效率的減少重複性的驗證與操作, 不是比賽寫程式專業度
迷思9: 自動化測試一定要導入很多Framework?
自動化測試前似乎都有導入很多Framework與工具才叫做自動化測試?
錯! 自動化測試的核心問題是減少重複性操作, 自動驗證結果,
達到這個目的其實Selenium IDE 就足夠
迷思10: Selenium IDE 有太多限制不如一開始就用Java/Python?
精通Selenium IDE是可以讓自動化測試開發工作加速,
重點在於是否精通Selenium IDE 清楚的知道哪些情境下會有限制, 哪些情境下沒有限制