GTAC 2010: The Future of Front-End Testing

GTAC 2010: The Future of Front-End Testing

摘要如下:


*誰該為測試負責? (請反白看答案)

所有人, 不僅僅只是QA人員, 工程師自己也需要為測試負責


*童子軍原則 - 見到營地(此處指程式碼)不整潔者, 主動整理乾淨.

*Test only have value when trusted
如果一個測試結果不能確認有沒有問題, 那比沒有測試還糟.

*使用hook來消失測試中的不確定性.
例如 Capche, 每次登入時都出現不一樣的 Capche, 就無法測試, 較好的作法是寫一個測試時, 使之能預測Capche值的機制.

* Waiting for state change
測試時, 要等到網頁是正確的狀態才能測試.

使用ajax時, 因為網頁不會 reload, 所以要等待到正確狀態.

等待有2種, 好的跟壞的.
壞的等待是固定等一段時間. (這會讓整個測試變得很慢)
好的等待是你可以測試該狀態是否是你要的, 不是的話才繼續等待.

偵測狀態改變可以由測試工程師做, 但比較好的作法是由開發人員在系統內提供機制(hook)
(例如, 狀態改變時, 連結或字的顏色改變
或是改變個Javascript 的變數值.).


*網頁元件儘量使用 id, 定位容易, 速度快, 且容易維護.
不要使用 xpath 定位, 速度慢, 不同瀏覽器的 xpath 定位結果不同, 難維護(很難看懂).
(id > name > css selector >>> xpath)
(在Q&A的時候有提到, 請不要國際化 id 啊~~~(笑))

*Page Object Pattern, 可以將網頁封裝成服務(例如登入頁, 提供登入服務, 測試人員不需要理會頁面的呈現.).

此外, 使用Page Object, 也可以使網頁流程更明確(例如, 點了Gmail的編寫按鈕, 就會返回一個編寫郵件的Page Object).

Page Object也可以用來解決 i18n 的問題.

*使用MVP模式可以將邏輯與呈現完全切開, 有助於測試.
關於MVP與MVC的差異請看此

*不要 hard code URL(可用IoC framework來處理, 影片中提到 google 採用 juice)
不要在測試時使用id, 上正式環境時卻將 id 拿掉, 那會使你無法驗證程式是否正確.
如果是因為網頁會變大這個理由, 請使用別的機制將網頁縮小(笑)

*平行測試時, 共享資源需要鎖定機制, 不然可能會發生測試有時通過, 有時失敗的情況.

*他們(主講者為Google工程師)已投入大量人力於 Selenium 2/3, 如果您有自動化測試的需求, 請不要重造輪子.