前言
嗨大家好，我們是 Caleb 以及 Yi-Han，來自 LINE SHOPPING 的 QA & TECH FRESH。很高興這次可以在 Test Corner 中與熊大一起跟各位共襄盛舉，這次跟大家分享了一些在 LINE SHOPPING 中的一些測試計畫以及如何建構自動化流程等等的做法，那以下就分享內容給各位！當天的 slide 也一併分享給大家～
當天簡報: https://speakerdeck.com/line_developers_tw/show-you-my-wisdom
活動影片
介紹
今天的內容，將針對以下 6 個部分逐一詳細介紹：
LINE 購物簡介
LINE 購物作為一個導購及回饋點數的行動電商聯盟平台，總共彙集了超過 600 家商店，超過 2700 萬件商品，活躍消費者已達 370 萬人。我們不只是讓使用者可以搜尋、比價、賺點數，還能主動推薦各種優惠。從 2019 年開始，LINE 購物陸續透過總部提供的 Smart Channel 平台，已經提供了九種內容推薦，像是「個人化專屬推薦」的有：商品推薦、商店加碼推薦；也有「廣泛的推薦」，如：熱門關鍵字搜尋推薦、熱門文章推薦等等，下面就來為各位介紹怎麼串接的吧！
Smart Channel 簡介
Smart Channel 是由 LINE 總部提供的平台，透過它可以將內容推薦給使用者。除了能夠將服務端（例如 LINE 購物）的各種推薦內容發送給 LINE 的使用者以外，也能夠投放廣告。
Smart Channel - 精準推薦
Smart Channel 目前有兩種的推薦模式，第一種是「精準推薦」。意思是指精準地根據使用者的瀏覽紀錄，來推測使用者感興趣的內容。如搜尋關鍵字紀錄、瀏覽商店紀錄、收藏商品紀錄等內容，都能夠協助系統推測使用者感興趣的推薦內容。舉例來說就像是「商店推薦」能夠在使用者有收藏或瀏覽過該店家，並且在該店家的點數回饋提高（加碼）的時候推薦出去。換句話說，精準推薦的關鍵在於，使用者必須先使用過 LINE 購物，才有機會推薦給他。
精準推薦的大致流程如下圖，一共有兩層推薦機制。第一層是服務端的演算法，例如 LINE 購物想要發送「商品推薦」給熊大跟兔兔；「商店推薦」則是只推薦給兔兔。
第二層則是 Smart Channel 的演算法，在收到了每個服務端的推薦內容後，進行彙整，並且排序，同時也可能將不適宜的內容排除，最後根據使用者較可能點擊的時間去發送給使用者。
Smart Channel - 自動推薦
第二種推薦模式叫做「自動推薦」，服務端只需要提供較為廣泛，通用的推薦內容，不需要考慮使用者的瀏覽紀錄，讓 Smart Channel 負責推送給廣大的 LINE 使用者即可。舉例來說就是「搜尋趨勢」的推薦，LINE 購物將近期熱門的搜尋關鍵字彙整之後，送進 Smart Channel 的平台中，由平台的演算法來找尋合適的使用者推薦，而且非 LINE 購物的使用者也可以收到推薦，這是觸及到全新使用者的好機會。
簡短總結一下「精準推薦」與「自動推薦」的運用，LINE 購物使用精準推薦服務了老客戶，從中學習到新客戶也可能感興趣的內容，並且透過自動推薦來服務新客戶及老客戶，新客戶的加入同時也成為老客戶，這是一個正向的循環，讓 LINE 購物的使用者以及推薦量逐步增加。
上線前的準備
上線之前，我們也做了幾個準備，讓兩個團隊可以依照各自的時程部署新的程式碼，也能夠在正式啟動推薦前先觀察產生資料的狀況。
Feature Toggle
首先第一件事情就是所謂的「開關」，用開關來控制：
- 是否要產生資料
- 是否要發送推薦
由於 LINE 購物與總部的 Smart Channel 團隊是不同的部署週期，所以需要有開關來控制排程是否要被執行，才不會觸發不必要的警報。
以前面提到的「自動推薦」為範例，我們在測試環境上，只要 LINE 購物開發完成，即開始產生推薦資料與發送推薦資料。由於這是經過確認，在測試環境中，若 Smart Channel Kafka 尚未部署新版以前，也不會觸發任何警報，才可以這樣進行。進入正式環境時，若 Smart Channel 收到了「不預期」的推薦內容，就會觸發警報。所以 LINE 購物部署新版以後，先測試產生推薦資料，直到雙方約定好的時間，才可以開始發送推薦資料給 Smart Channel 平台，進行後續的驗證。
在這裡我們利用了服務的開關，來決定某些排程是否要被執行，也能夠在上線前先觀察推薦資料是否有被正確產生。
順帶一提，我們內部使用的是叫做 Central Dogma 的技術，歡迎大家上去 github 上面參考。
排程紀錄
前面提到了測試產生推薦資料，就要介紹 LINE 購物內部使用的「排程紀錄」的功能。這個功能紀錄了排程類別、名稱、開始結束時間、執行時間、平均執行時間、執行結果與 memo 等資訊，對 Dev 或是 QA 來說都相當有幫助。像是執行時間，可以觀察每一次排程執行時間是否有因為資料量、新邏輯而產生變化。以下圖為例，5/2 及 5/1 的執行時間就有不同，但是資料筆數一樣，是因為我們套用了新的推薦邏輯，資料來源增加造成執行時間變長。
由於排程紀錄是一個 Dev 與 QA 在 brainstorming 的 session 下產出的功能，所以執行時間、memo 的欄位都可以紀錄下兩個角色各自需要的資訊。像是 QA 會希望知道資料筆數，成功、失敗的數量，而 Dev 則可能需要排程異常結束時，抓到的 exception log，是一個相當實用的功能。
Debug API
最後一個是 Debug API，採用了 RESTful API 的設計，它能夠將指定日期的推薦資料列出來，提供給 QA 手動測試或是 Automation test 使用。
下面是示意圖，左邊是實際在 LINE APP 測試看到的畫面，在 LINE 購物端產生的推薦資料就如右邊的 JSON object 所示，有 originalId、title、iconUrl 與 linkUrl 等欄位，能夠驗證由 LINE 購物產生推薦的資料，透過 Smart Channel 平台，投放在 LINE APP 上面能夠被正確的顯示。
在這邊也分享一下 Debug API 後面的資料是儲存在 MongoDB 上。幾個優點除了快速、富有彈性以外，JSON format 對人眼閱讀，automation test 也方便使用。另外就是這方面的資料是「紀錄用途」，他不需要跟別的 table 有什麼關聯。另外就是我們採用了 TTL Index 的功能，他能夠在資料寫入的時候，就決定了這一筆資料何時會被 MongoDB 系統刪除。這樣做的好處是，這些資料就像記錄檔一樣，需要定時清除，可是放在 MySQL 上的話，你需要特別寫一個排程，定時執行去 delete 或是 archive 過時的資料。透過 MongoDB 可以輕易地達成這件事，讓除錯的需求與資料儲存空間的使用取得平衡。
自動化測試
前面有提到排程執行的過程會被記錄下來，那麼針對這些排程，我們如何建立起驗證機制，去驗證這些排程是否有符合我們預期的進行呢？首先，每一隻排程執行完成後，就會將執行過程的紀錄寫入資料庫中，並透過 API 取得這些資訊。整個驗證過程大致上可分為 3 個步驟：
- 取得排程執行紀錄
- 根據記錄，驗證執行狀況是否符合預期
- 如果沒有符合，則透過 slack channel 發送警告通知
接著，我們再來針對每一步深入探索一下吧～
取得排程紀錄
利用排程名稱與類別，透過 API 可以取得最近一次的執行結果。如之前提及的，API Response 中紀錄了排程類別、名稱、開始結束時間、執行時間、平均執行時間、執行結果與 memo 等資訊，另外，也包含了應觸發時間的 cron expression，提供給 Automation Engineering 更清楚的驗證基準。
驗證執行狀況
什麼樣的執行狀況可以被認定為符合預期呢？可以分成「開始時間點」與「執行時間長」兩個面向。例如：排程 A 預計每天早上九點要執行，所以我們可能會在九點半的時候跑一次驗證，確認排程已經跑了、而且有在 20 分鐘內執行完，換句話說，如果最近一次執行時間在早上九點以前、或整個執行過程超過 20 分鐘的話，則可能就有問題需要檢查。
管理排程
需要被監控的排程其實不只有一隻，那麼有效管理排程就是另一個課題。我們利用 Config file 來記錄所有需要被檢查的項目，當需要新增或移除項目時，只要修改 Config file 就可以了，非常簡潔便利。再以 Jenkins Pipeline 來管理、執行驗證，並加入 Ignored_list 參數，以暫時排除之前有在 Config file 上面記錄過要被檢查、但目前因為某些原因暫不檢查的排程。
紀錄與發送 Slack 通知
Jenkins Pipeline 會在每天固定時間被觸發，執行完成後則會留下一份 Archive file，方便 Dev 們追蹤執行紀錄。最後，在整個驗證過程結束後，如果有任何不符預期的狀況發生，就會發送通知到 Slack Channel，讓相關的人第一時間接收到警訊。
持續優化
當然，除了上述提及的驗證方式之外，還有許多的監測方式能夠實作。例如，我們可以在針對「執行時間長」的部分，觀察一段時間的執行時間、並產出視覺化線圖與報表，如果發現近期的平均執行時間比起之前明顯高出許多，就可以此為出發點，觀察一下系統其他元件是不是有例外狀況導致這樣的情形發生、或單純是資料量比前期增加而導致的必然結果。
而針對「內容」，則可以檢查顯示的文字與預期 pattern 是否相符。根據當下行銷活動的安排，Smart Channel 顯示的文案會有所改變，舉例來說：如果當下有行銷活動、而且與「野餐 帳篷」有關，則 Smart Channel 上面的文字就可能會是「你可能想找的野餐 帳篷優惠比價出爐，搜尋再領 x 點紅包」，比起「你可能想找的野餐 帳篷優惠比價出爐」多了「搜尋再領 x 點紅包」，吸引使用者點按並前往 LINE 購物。當然除了顯示文字以外，也可以驗證導出的 Url pattern 是否正確，保證連結的可靠度。
線上回答問題
在線下活動時，有一位參與者提問了「如何驗證演算法的推薦正確」，由於現場回答時漏了一部分，在這裡也特別完整地回覆一下。
首先是「可重現的瀏覽資料」的部分，舉例來說，「商店加碼推薦」是基於使用者的商店瀏覽、收藏資料來做計算，這就可以透過手動的方式來產生測試資料，進而驗證推薦資料中是否有包含預期的推薦內容。同理，也可以反向從產生的推薦資料中，反查測試帳號是否有「預期範圍內」的瀏覽、收藏資料，來驗證推薦的演算法。
第二個部分是「個人化推薦」的演算法，這裏我們不針對複雜的演算法做測試，而是透過 mock server ，提供 QA 規劃好的 mock data 給演算法來使用。以「文章推薦」為例，會準備好「測試帳號」與「該帳號感興趣的文章分類」，讓演算法用來運算並推薦正確分類的文章。後續 QA 就可以透過推薦的結果（文章）來驗證邏輯（文章分類）是否正確。
總結來說就是透過可控制的變數，搭配設計過的測試資料，就能夠初步驗證推薦的演算法符合預期。
當然每一種推薦都需要定期追蹤成效並改進，每一次的優化我們都必須考慮新的推薦邏輯，是否具有足夠的可測試性(Testability)。
結論
在這次 Test Corner 中很高興可以分享在 LINE 購物工作中的一些經驗，不知道你覺得是 Smart Channel 比較聰明，還是 LINE 購物的 QA 比較聰明呢？希望透過這些經驗分享可以讓各位更了解一些在 LINE 裡面專案處理上的手法以及細節，讓這些內容可以實質幫助到各位工作上的內容，一同在 QA 的領域中進步。非常慶幸有機會可以在社群分享，那我們就下次社群見啦！
最後，如果對於加入 LINE 大家庭有興趣的各位，歡迎參考以下：
活動小結
立即加入「LINE 開發者官方社群」官方帳號，就能收到第一手 Meetup 活動，或與開發者計畫有關的最新消息的推播通知。▼
「LINE 開發者官方社群」官方帳號 ID：@line_tw_dev
關於「LINE 開發社群計畫」
LINE 2019年開始在台灣啟動「LINE 開發社群計畫」，將長期投入人力與資源在台灣舉辦對內對外、線上線下的開發者社群聚會、徵才日、開發者大會等，已經舉辦 30 場以上的活動。歡迎讀者們能夠持續回來察看最新的狀況。詳情請看: