用瀏覽器自動化優化你的網頁QA人生

我個人目前偏好的工具是M牌的Playwright。因為早期calypso的e2e tests是用Puppeteer，不知為何它的行為常常跟我預期的相差甚遠，只能說八字不合；至於Selenium就更不對盤了，我連要弄個最基本的開個網頁點個按鈕都弄半天。Playwright倒是幾分鐘內就弄出來了，API設計上對我來說較易理解，而且原生支援多種瀏覽器，就這麼用到現在了。

不只是操作自動化

說到瀏覽器自動化，大部分人第一件想到的事情其實是屬於「操作」的自動化，例如：開啟網頁A，按下按鈕X，如果出現Y對話框就按下Z按鈕等等。但我個人經驗上，對於平日開發工作的輔助上，真正最常用的其實是瀏覽器的狀態設定腳本化，例如：cookies、local storage、query strings、解析度、桌面裝置vs行動裝置等等，能夠把這些都寫成一個能重複使用的腳本，在修改完程式後輕鬆地用一行命令生出需要的瀏覽器實體，不用重複手動設定，又不用動到自己平常用的瀏覽器。過去總是靠匿名視窗去手動調、這個瀏覽器開發用那個瀏覽器日常用，簡直不堪回首。

個人實用例：dot-handy

我針對自己開發WordPress.com的需求寫了一個小工具dot-handy，因為高度針對WordPress.com，在其他地方大概用不太上。雖然沒道理不能改成更泛用些，但目前沒有這個需求就是了。會寫這個工具是因為我的開發風格是以shell為中心，因此想要把工作上常用的瀏覽器設定、操作等都拆分開，讓我能在命令列上組合出我當下需要的自動化，而不需要撰寫新的腳本。在README裡有列10種使用範例，這邊僅列出幾種當代表：

例1. 設定cookies和local storage

設定特定cookies和local storage大概是我最常碰到的需求。下例中我將測試要用的cookie store_sandbox與開啟calypso analytics測試模式的local storage鍵值calypso:analytics:*寫入mine.json，這樣我每次要用這組設定只要加上-C mine 即可：

例2. 搭配GNU parallel比較網頁輸出

另一個常發生的情境是要比較不同情境下的網頁輸出，例如不同cookies，不同瀏覽器等等，這可以搭配GNU Parallel一次運行多個瀏覽器實體來完成。例如下面影片中我跑了一個chromium以及一個Firefox分別比較WordPress.com首頁在設定為菲律賓披索以及台幣的輸出：

例3. 自動化操作當然還是要啦 …

確實狀態設定是我最常用的，但有些太常重複的操作沒有道理不自動化。例如我們團隊常常在碰註冊流程，因此註冊新帳號、選方案、結帳等動作腳本還是有的，例如下面影片用的 yarn start -A new-user pick-free-domain pick-personal-plan checkout 就是創建新帳號 -> 選免費網域 -> 選個人版方案 -> 結帳：

結帳的部分用的是Stripe Test API的測試卡號，production中是不能用的喔，請不要再踹了 XD

如果發現目標網頁超難寫自動化腳本呢？例如經常要寫「在第三個div下的第二個按鈕」或「在標題下包含字串XYZ的段落」這類又難維護又脆弱的查找。這其實是個重要的訊息，代表該網頁缺乏系統化的使用語意標記，CSS命名也缺乏統一的規則、忽視可讀性等等，這反映出兩個重大問題：其一，網頁應用開發規範不成熟，其二，這個網頁的可取用性(accessibility)肯定很差。

從單元測試(unit test)、整合測試(integration test)，至末端到末端測試(end-to-end test)，容易自動化測試與否如同軟體品質的照妖鏡。我確實看過沒考慮過可測試性但實作優良的軟體，但可測試性極高卻寫得很差的倒是沒看過，這也是為什麼會有一說：「測試驅動開發(test-driven development)」，其實執行到最後是「測試驅動設計(test-driven design)」。

例3. A/B test

我們公司有自幹一套內部的A/B test工具叫做ExPlat(Experimentation Platform的簡稱)，在開發階段為了要強制將測試階段設定為控制組或實驗組，要在某些時機呼叫PATCH /experiments/{version}/assignments這個端點，我把它寫成set-explat這個自動化操作，就可以簡單地：

yarn start -A set-explat --explat-experiments <experiment name> <variation-name>

將測試階段設為我需要的組別，搭配上述GNU Parallel的技巧還可以直接兩邊一起比較。例如我們在實驗不同的方案頁面設計時，我是用以下命令讓我可以直接比較控制組與實驗組是否有按照設計實作：

關於瀏覽器自動化測試服務

因為不同的專案需求，過去其實有稍微碰過一些瀏覽器自動化測試服務，例如我們團隊用過的CloudQA。這類服務百百種，但通常不外乎賣三件事：

1. 他們自己的計算資源，讓用戶可以一口氣運行大量測試而不需要擔心資源問題
2. 漂亮的報表
3. 自家獨樹一格的編輯器，「一行程式碼都不用寫」、「直覺到令人感動」云云

要用這類整合型服務與否，通常我也建議從這裡去考量，看看自己的應用是不是真的有這三方面的需求，再來談該產品有沒有解決你的需求。

對我們團隊來說3通常都是缺點不是優點，因為透過他們的編輯器拖拉出來的東西常常無法作版本控管，還要開發人員去學一套新工具，a8c有自己的datawarehouse所以也用不上2，計算資源不是問題所以也用不上1，因此我碰過的專案後來都沒在用這些。我這邊描述的情境因為是自用，就更不需要了。

從我快一年前寫好這套小工具到現在，除了每天節省下來的時間外，更重要的是從重複的事情上釋放出來的心力。可以讓網頁QA人生變得更輕鬆的自動化方法還有很多，但如果你跟我一樣喜歡更全面的程式化彈性，強烈推薦你也試著用Playwright寫一套為自己量身訂製的工具吧！

投注那相對少的時間，不僅可以讓自己更輕鬆，省出來的時間去陪陪重要的人，碼農人生會更圓滿的。