Ryota.VL

Ryota.VL

建立自己的知識體系

建立自己的知識體系

本篇文章分享如何建立一套屬於自己的知識體系與工作流程。良好的知識體系能幫助我們: * 擴展知識邊界:探索未知或尚未熟悉的領域。 * 穩固知識深度:深化已掌握的領域知識。 在《跨能致勝》(Range)一書中指出,現代世界中不再只是「專家」才能解決問題,反而是那些具備跨領域興趣與能力的通才(generalists),能在面對複雜與不可預期的挑戰時,活用不同領域的思維方式,提出更具創意的解法。 知識管理的四個階段 輸入 (Input) 知識的輸入來源非常多元,包括: * 社群媒體:如 Twitter(X)、Instagram、LinkedIn、Podcast、YouTube、電子報等,可透過追蹤 KOL 或特定主題來吸收新知。 * 書籍與資料:針對有明確主題的學習,閱讀書籍仍是最穩定與深入的方式,過程中也可發現更多延伸資源。 個人工具: * 我主要透過 O’Reilly Learning、使用電子閱讀器 (Amazon Kindle、Kobo、文石) 進行閱讀與筆記。
Ryota.VL
測試左移:使用 K6 和 Github Action 進行小範圍的 Load Testing

測試左移:使用 K6 和 Github Action 進行小範圍的 Load Testing

隨著產品快速迭代,團隊開始重視「測試左移(Shift Left Testing)」,也就是把測試往開發流程的前端推進。而性能測試(Performance Testing)過去往往是在部署或上線前才進行,是否可以相其他測試項目,提早發現系統瓶頸的機會。 本篇文章想要分享如何在開發階段就導入簡單的負載測試,透過使用 K6 和 Github Action 的整合,讓每次 push 程式碼就可以執行小範圍的負載測試,讓開發人員能夠提早發現潛在問題。 本篇文章裡會說明: * 在 Github 專案裡整合 K6 到 CI 的工作流程 * 在開發人員 push 時觸發負載測試 * 撰寫簡單的 K6 測試腳本 * 透過 Github comment 手動觸發負載測試 * 在 Grafana Cloud 上面看到測試結果 安裝 K6 環境 Load
Ryota.VL
在新創公司建立測試流程 - 從零開始的 QA 之路

在新創公司建立測試流程 - 從零開始的 QA 之路

前言 最近在 reddit 看到一篇文章(原文連結),讓我感觸很深。身為新創公司唯一的 QA/SDET,我發現不少人也面臨相同的挑戰。即使有多年經驗,還是會覺得挑戰不小,更何況是剛入行的 QA?這感覺就像是一個新手球隊經理,獨自肩負打造冠軍隊伍的責任,既困難但也充滿機會。 了解公司的開發流程 在一間已經有產品上線的新創公司要建立測試流程,第一步是先搞清楚目前的開發流程,看看是否已經有測試機制運作中。也要特別注意開發週期中是否有經常被忽略的環節,這些地方往往是問題最多、最容易在上線後爆發的地方。 如果前期的測試還無法涵蓋大部分的使用者情境,那麼上線後的監控就變得特別重要。確保有足夠的監控機制,能夠即時發現問題、快速修復,這樣才能降低對用戶體驗的影響,並持續優化產品品質。 通常,我會使用測試金字塔模型或敏捷測試象限圖來檢視測試的缺口,確認有哪些地方做得不夠完善,但卻很關鍵部分。這些工具可以幫助我們更有系統地分配測試資源,確保每個環節都有適當的測試覆蓋。 在測試執行方面,一般來說: * 單元測試通常由開發人員來寫,如果團隊還沒有這個習慣,可以先鼓勵大家養成撰寫單元測試或整合
Ryota.VL
實戰分享:如何用 Robot Framework 建立自動化測試流程

實戰分享:如何用 Robot Framework 建立自動化測試流程

回到 2019 年,那時的我們對 Robot Framework 的了解還不夠深入,導致許多測試案例無法平行執行;再加上測試資料管理的不足,進一步加大了測試的複雜度。然而,經過這些年的實踐,我們逐漸找到了應對之道。在撰寫新的自動化測試框架時,我們特別考慮了這些問題,並融入了解決方案。與五年前相比,現在的測試流程更加效率且穩定。 前言 在 2019 年初,隨著產品迭代的速度變得越來越快,對於快速釋出新功能變得越來越不容易。當時團隊負責的產品已經是第八版 (2019),已經累積將近 8000 多個測試案例。 如果要釋出一項新功能,必須花費將近數個禮拜的時間做迴歸測試 (Regression Testing),除了原本的新功能,還必須重複地執行可能會被影響的舊功能的測試案例,以確保舊功能沒有任何的影響。 於是透過自動化測試保護重要的功能和新功能。最後花費將近一年的時間,將大部分的 RAT 的測試案例自動化,即使整體自動化的比例還是偏低,但還是減輕了不少測試上的壓力。 組織架構 康威定律指出,產品的架構會反映出組織的溝通結構。在我們的團隊中,產品團隊分為開發團隊和測試團隊,因此
Ryota.VL
測試金字塔 (Testing  Pyramid)

測試金字塔 (Testing Pyramid)

前言 測試金字塔是一個用來劃分不同層次測試的策略。透過將測試分成三個主要層次:單元測試 (Unit Test)、應用層測試 (API Test)、以及端對端測試 (E2E Test),我們能更有效地驗證系統的各個部分,確保每一層的功能都能運作正常,並且提升整體的測試效率。 單元測試 (Unit Test) 通常我們會進行單元測試,驗證某個模組或功能的正確性。例如,測試 GraphQL API 的呼叫是否能正確取得使用者資料。這是測試最基礎的部分,能快速驗證小範圍的功能是否運作正常。 應用層測試 (API Test) 當我們確保了單元測試的功能正確後,下一步是進行應用層測試,這主要是用來驗證系統的 API 是否能正確運作。像是查詢某使用者時,檢查回傳的資料是否完整且正確。這能幫助我們確認系統內部的服務是否能正常運作,並且回傳正確的資料給使用者。 # 單元測試 (Unit Test) import requests def test_get_issues(): query = '
Ryota.VL
我的 API 不可能這麼慢吧!看看 K6 怎麼拯救它

我的 API 不可能這麼慢吧!看看 K6 怎麼拯救它

前言 透過刻意練習,我們能夠從實務中獲取經驗與不足,並且定期回顧自己用到什麼技術或工具。今天我們就回顧前幾天我們使用的測試工具 K6,本篇文章透過執行效能測試的步驟。 什麼是 K6 K6 是一款開放原始碼的負載測試工具,專為測試網站、API 及應用程序的效能而設計,類似的工具還有 Locust 、JMeter。K6 由 Grafana Labs 支持,能夠幫助開發人員和測試人員模擬高併發的使用者行為,測試系統在高負載下的表現,從而找出效能瓶頸並進行優化。 撰寫效能測試腳本的步驟 1. 設計問題場景 想像我們有一個 /api/users 的 API,但由於資料庫查詢效率低,導致回應時間過長。這樣的問題會在高併發下更加顯著影響系統性能。 2. K6 測試腳本模擬高併發負載 使用 K6 來模擬多個併發請求,測試 API 的回應時間和效能。 3. 執行測試並分析報告 根據 K6 的報告,
Ryota.VL
使用影分身之術,挑戰多任務負載測試

使用影分身之術,挑戰多任務負載測試

前言 回到昨天的題目,我們只模擬尖峰時段,大量的購物車加入商的測試場景,但實際運行環境上,可能會不同的使用者做著不同的事情:購買商品、搜尋商品、加入到購物車、移除商品到購物車、結帳和付款等等。就像《火影忍者》裡的「影分身之術」吧!當主角鳴人同時分出數十個影分身,每個分身都在做不同的事:戰鬥、學習、探查,這就像我們的系統在面對多任務負載時的挑戰! 挑戰目標 模擬一個視訊串流平台的高負載場景,並測試系統在同時進行多任務操作(如影片上傳、即時觀看、評論、搜尋)的情況下,是否能保持系統穩定。 挑戰設計測試場景: * 場景 1:模擬用戶大量上傳影片,並且同時進行即時觀看,測試系統的寫入和讀取性能。 * 場景 2:在用戶大量提交評論的時候,同時進行影片的搜尋,測試系統在高頻率讀寫操作中,是否能夠維持回應的速度。 * 場景 3:模擬影片上傳的瞬間尖峰,同時用戶進行多條影片的即時觀看和評論,測試系統是否能夠承受高並發操作並平穩恢復。 測試背景資訊 系統架構