LINE Corporation 於2023年10月1日成爲 LY Corporation。LY Corporation 的新部落格在這裏。LY Corporation Tech Blog

Blog


LINE 開發者社群計畫: Test Corner 第 31 場講者議程分享

講者與工作人員們一起感謝大家的參加

前言

大家好,LINE 致力於舉辦對內的技術交流、教育訓練,以及對外的社群聚會、校園演講、開發者徵才日與開發者大會等各式各樣的活動。我們希望創造更多技術分享與跨國交流的機會,同時持續招募優秀人才加入 LINE 台灣開發工程團隊! 

9/28 與充滿創新精神的 Test Corner 合作一同舉辦線上第 31 場的 meetup,和與會者一起探索測試的奧義,本次聚會的各種巧思令人耳目一新,充滿社群活力的氛圍讓在家防疫的我們跟著熱血起來,一起來感受本次聚會的魅力吧!

KKTIX 活動網頁: 活動網址

Latest Test Trends for LINE Shopping - Sherry Chen 

目前 LINE 購物的 test trends 採用以下三種方式:

  • Mock Server/Mock Data:
    因 LINE 購物與許多第三方服務做串接,為了確保想要測試的情境皆有測試資料,以及可能串接的服務端並沒有提供測試環境資料,所以我們會使用 mock server & mock data。

    mockserver 使用 https://www.mock-server.com/

    與第三方服務串接的 api 會請 dev 幫忙,在測試環境的部分連到我們的 proxy server, 我們可以將 proxy server 的 mock 啟動或關閉,
    也因為不是全部的第三方 api 都有做 mock data, 所以也會判斷 config 有沒有 mock data, 若有 mock data 則會 response mock 資料,沒有則繼續打回 actual server, 以取得 actual response
  • Performance Test:
    採用的 performance tools 有 Jmeter, Wrk2, K6 and Webpagetest

    performance test 我們定義的 acceptance criteria 為:
    • status code all 200
    • failure rate < 0.1%
    • response time < 200ms
  • Health Check/Load Test:
    • Health Check:
      提供 file manager 讓所有人都可以以編輯的方式更改需要排程跑 health check 的檔案,
      也透過 dashboard 確認 health check 狀況,若有 fail 則會發 LINE notify 到相關群組。
    • Load Test:
      確保線上 api 穩定性以及 response time 正常,若超過預期的 response time 或 api error,
      也會發 LINE notify 到相關群組。

Q&A:

  1. 除了與其他服務串接時會做 performance test, 還會在什麼時候做嗎 ?
    A: 我們通常會在以下三種狀況時做 performance test
    > New API or Page
    > 3rd party issue
    > Developer, Planner or QA have performance concerns
  2. 請問像雙 11 大日子會怎麼準備相關測試呢?
    A: 雙 11 最主要是流量會大增,要注意流量的部分,而每年雙 11 會有不同的玩法,就會有不同地方需要注意, 
    我們會先與 planner 諮詢今年的玩法,來討論可能的風險在哪邊,接著再著手做 performance test, 確保以雙 11 大流量下,系統及頁面是穩定的

Continuous Load Testing in LINE Shopping - Johnny Chiang 

Load Testing 指的是

  1. 以 同時使用人數 或是 requests per second 來評估系統效能
  2. 確保當系統有任何更動時 (新功能加入,架構更改時) 系統可以持續符合 效能標準

Continuous Load Testing 則是一種風險管理,應用程式本身的風險通常會轉移成更嚴重的商業風險,效能相關的風險會更為顯著。以 LINE 購物為例,假設因效能問題導致使用者無法進入 商品 或是 廠商 轉導頁面,可能就會損失很多潛在獲利機會。
Load Testing 相信大家都有做,但是當一支新的 API 上線後,沒有 continuous testing,很容易會忽略 feature change 對效能造成的影響。
Continuous load testing 在 production deployment 的前後都會執行,特別 在 production deployment 前的部分 , 因為很多東西,到 production 環境之後就太慢了

LINE 購物對 Continuous Load Testing 有以下需求,需要滿足效能評估、可用性可靠性驗證、即時失敗通知、可依環境模組擴充、容易設置、彈性的通過標準
針對以上需求,我們以 Jmeter, Jenkins, Docker, InfluxDB, Grafana 組成我們的 load tests

透過 Continuous Load Testing,我們也察覺了不少問題,如 code changes 造成的 效能問題、當 data 增加時,API 因此變慢... 等

Q&A

  1. 請問 LINE 購物在 production 做 performance test 有沒有什麼限制要注意?
    A: 有一些 API 在 production 環境是不能 (適合) 執行的,並且我們不會用太大的量在 production 環境執行,除此之外,我們在測試環境還有 production 環境通過的標準都一樣
  2. 請問一下執行 Jmeter runner 有 monitor? cluster worker 跑在 docker 上請問怎麼做系統資源監控
    A: LINE 購物本身放在我們的私有雲 VKS cluster 上,針對 cluster worker 的資源 (cpu,memory usage, 或是 pods 運行狀況) 皆有進行監控,這部分與 load test 是分開的
    此外,application 也有一些 whitebox metrics 可以進行參考,若在 load test 發現了什麼異樣,可以馬上進行回查

LINE Travel x POI Poll Activity - Judy Tsai 

LINE Travel 是個提供旅遊相關商品,文章,景點,旅遊規劃功能的服務平台。 平台以旅遊商品導購為主;受疫情影響,LINE Travel 也開始投入加強平台的資訊豐富度和實用性。這次和公司內部團隊合作的 POI Poll Activity 一方面可增加和使用者的互動外也同步將使用者比賽上傳的景點圖片回傳到 Travel 的景點相簿內,增加景點的可看性

測試內容分為兩個重點:

1. 使用者在比賽的作品上傳頁面點下 "選擇景點" 按鈕後會被導到 Travel 選擇景點的頁面,使用者在選擇完景點後,景點應該被正確帶回作品上傳頁面

2. 使用者上傳的作品經人工審核沒問題後,圖片作品應該被自動同步到 Travel 相對應的景點相簿內;同理,若使用中在比賽頁面將投稿的作品刪除後,Travel 的景點相簿也應該同步將此圖片刪除

測試工具: 

1. Beta/ RC 比賽連結: E2E 測試

2. Cypress io: 自動化測試

3. Grafana: 使用者上傳 / 刪除作品的 log (確認 Travel 的 Repository 有聽到 Kafka 的事件)

4. LMP: 作品審核後台系統

5. Mongo DB: 存放使用者同步回 Travel 的作品和記錄

6. OBS: 圖片確切儲存位置,也可使用 OBS_ID + 連結組出使用者照片

Q&A:

1. 有使用 Mock Data 嗎? 

   A: 沒有,測試的時候都是根據線上的資料去做使用。

2. 導購的測試重點? 

   A: 導購最重要的是確保使用者的 trackingCode 和旅遊平台認的 key/value 有在轉導頁被正確帶上 url, 並且在使用者選擇商品和購買的過程中不會掉,避免使用者沒收到 Travel 的訂單通知和後續的回饋點數發點問題。

3. 使用的自動化測試工具是? 

   A: Cypress io

4. 自動化測試有沒有遇到什麼困難? 

   A: 有,使用者進到作品上傳的頁面會需要做 LINE account login, 和原本 config 裡面就有的 Travel login 不一樣;解決的方式是 因為這個 POI Poll Activity 是個短期的活動,所以先用手動的方式登入拿到 X-LINE-ACCESS-TOKEN, 再放進 config 裡面來完成登入驗證。

5. 自動化測試如何做到地圖移動的比較? 

   A: 手動測試手法是在地圖上做拖拉去移動地圖,確認地圖上有沒有出現 "搜尋此區域" 的按鈕,但自動化測試較難實作拖拉的動作,因此改為 google 地圖同樣有提供的功能 - 點兩下 (測試設定在右上角的固定位置), 也可以移動地圖並確認有沒有出現 "搜尋此區域" 的按鈕。

6. 自動化測試都是 E2E 嗎?有沒有針對元件做測試? 

   A: Travel 的自動化測試以做 E2E 測試為主,元件的測試都會讓 RD 在開發過程中的 unit test 去做。

結論

活動小結

因為疫情關係無法在 LINE 辦公室與 Test Corner 的各位見面。但小編非常開心大家在線上很踴躍得與我們互動,看到社群無限的熱情並對於 LINE 的產品測試有高度的興趣,希望上述的分享能夠讓各位開發者朋友帶走更多關於我們的經驗分享。

立即加入「LINE 開發者官方社群」官方帳號,就能收到第一手 Meetup 活動,或與開發者計畫有關的最新消息的推播通知。▼

「LINE 開發者官方社群」官方帳號 ID:@line_tw_dev