自動化測試 x Puppeteer - 玩偶QA參一咖 Day07


今日任務: 完成任務

我們先執行程式(puppet.js)看看目前的成果吧,

假設我們沒有要繼續 Assign 其他標籤了,可以點選右上方的 Continue 按鈕。


動作A: 點擊 Continue 按鈕

  1. Inspect後發現它的 class 是 "sc-fjdhpX.fSImrr"
  2. 在本日的A區塊加入
    await page.click(".sc-fjdhpX.fSImrr")
    


頁面會跳出一個確認視窗,我們選擇確認(Confirm)。


動作B: 點擊 Confirm 按鈕

這個動作將會把我們 Assign 給頁面的名字標籤和上傳PDF檔合併成一個新的文件,然後自動觸發 Navigation 事件,將頁面引導到新文件上。

  1. Inspect 後發現它的 id 是 Edit-Field-Send-SignYourself
  2. 因為同時會觸發 Navigation 事件,所以程式碼需要 Promise.all 包覆
    await Promise.all([
          page.click("#Edit-Field-Send-SignYourself"),
          page.waitForNavigation({timeout: 60000})
    ]);
    

只是這一次,我們第一次使用了 timeout 這個 argument,在之前使用page.waitForNavigation時,後面的小括號都是空的,是預設的,而timeout在預設上為30秒(會寫成{timeout: 30000},表示30000毫秒)。在這裡之所以把timeout設成60秒是因為在點下這個按鈕之後,它會花一些時間合併文件,再加上跳轉頁面所需要的時間,有時候在網路沒有那麼穩定的情況下,會執行超過30秒,所以為了讓下一個頁面的執行動作也可以順利地被執行,我們在這裡就將timeout設長一點,因為我們知道它會成功,它只是需要一些時間XD。

  1. 執行程式後發現它找不到"#Edit-Field-Send-SignYourself"這個selector,所以在await Promise.all();上方加入
         await page.waitForSelector("#Edit-Field-Send-SignYourself")
    

如此一來,大家應該都有順利地看到相似的結果

其實做到這裡,自己簽署的任務就算是完成了,大家也可以在自己的信箱收到來自 DottedSign 的信件,其信件內容就會涵蓋我們剛建立新文件的索引連結。


動作C: 點擊管理任務 icon

不過,假設我們還想要回到主頁面,我們應該要怎麼做呢?
我們需要點擊頁面右上方的管理任務 icon,事情有這麼的單純嗎?我們來試試看。

  1. Inspect 後發現它的 class 是 "sc-bdVaJa.iNlDiS"
  2. 由於知道會同時觸發 Navigation 事件,所以會有 await Promise.all(); 來包裹事件,不過,問題來了,我們要怎麼知道什麼時候可以按它?
    答案其實很直觀,我們就等它出現之後再點擊它就好了,所以就可以這樣寫
     await page.waitForSelector(".sc-bdVaJa.iNlDiS")
     await Promise.all([
         page.click(".sc-bdVaJa.iNlDiS")
         page.waitForNavigation()
     ]);
    
    這樣最後就會回到下方的主頁面了

回到這個頁面之後,可以到頁面上方的第三個選項,已完成(completed)頁籤中找到剛剛新建的檔案了,這個部分就留給有興趣想做的人自己試試看了,實作過程中都歡迎找我討論!總之,建立完文件之後,可以在信箱當中看到內有文件連結的mail;如果有想要特別確認的畫面(ex: Day 6 Assign欄位是否都有順利),也可以在程式碼中穿插 Day 2 提過的 Screenshot 來幫助確認。另外也可以取消最後的那一行程式碼的註解註解,同時刪掉waitFor(100),讓瀏覽器可以再執行完任務後關閉。

最後的程式碼:


結語:
經過這七天的操作後,相信大家都可以利用 Puppeteer 來完成自己有興趣的網頁自動化測試了。回顧這七天我們做的事情不外乎就是「找到 selector、執行動作、以及讓人心最累的Debug」,不斷重複這個寫程式的迴圈,我們建立了一個穩定運作的自動化程式,那也許大家在心中會有個疑惑,我們的下一步該做什麼呢?

在這裡提出幾個想法:

  1. 可以繼續撰寫其他的測試路徑(ex: 邀請他人簽署)。
    如果想要做這件事情,那跑完這七天的各位已經可以開始動作了!在這條路上,我們會開始遇到程式碼變得單一、繁雜、重複性高等議題,需要重新建構撰寫程式碼的邏輯,也許可以利用模組化的方式重構程式碼,想辦法對程式碼做分工的動作。網路上搜尋設計模式,也許就會找到適合自己專案的模式。

  2. 可以幫這條測試加上通報機制,在每次完成任務後自動在類似Messenger、Slack等等的群組回報成果。
    如果想要做這件事情,那也許會需要回到程式碼當中,將比較重要或是容易出錯的關鍵流程(或是所有流程)套上try…catch的結構,在必要的時侯(ex:出錯、哪裡出錯、成功)自動推播訊息到群組上,至於怎麼推播訊息,網路上的關鍵字是「利用Webhook發送訊息」,大家可以參考看看。

  3. 我們也可以將測試程式放在AWS Lambda上,規模化自動測試。
    這是我現在努力完成的目標,這同時也是我第一次使用AWS的服務,所以現在還在熟悉裡面提供的各種服務(尤其是Lambda),在查了資料之後,流程大概會是:

    1. 引入套件
    2. 建立測試瀏覽器
    3. 放上測試程式碼

我個人覺得在設定上是頗有難度,該從哪裡開始是有些迷茫,不過打程式剛遇到一個新的事務本來就是這樣,我想這也是coding最為有趣的地方。在網路上有不少相關的教學文章或是影片都很有幫助,想要規模化、想把code放上AWS Lambda上的你可以好好參考,在這條路上我們一起加油!

以上!這就是系列文的終點了,有什麼想法歡迎提出,謝謝大家的參與,測試路上我們一起加油!

#Puppeteer







你可能感興趣的文章

關於 chrome 效能檢測工具的一點心得

關於 chrome 效能檢測工具的一點心得

D42_檢討 W4 作業/W5 複習加寫心得

D42_檢討 W4 作業/W5 複習加寫心得

Google python code style

Google python code style






留言討論