RyotaVL 測試工程師

Sign in Subscribe

Archive

A collection of 12 issues

Featured

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

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

Latest

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

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

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

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

測試金字塔 (Testing Pyramid)

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

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

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

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

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

你的系統能撐過巨人的進擊嗎？迎戰週年慶流量浪潮

前言最近雙 11 和百貨週年慶又快到了，光是想到那短時間內用戶如巨人般湧入網站，我才不會害怕！我害怕的是荷包變瘦！。但這時候，我們還是要考慮網站系統會瞬間承受巨大的流量衝擊，像是迎接一場巨大的戰鬥。今天，我們就來挑戰如何進行「尖峰期用戶行為模擬」的效能測試，讓你的系統在這樣的尖峰時段依然能夠穩定運行。挑戰目標在某些特定的時間點（如大型促銷活動或節假日），用戶行為會產生異常的峰值流量，例如短時間內大量商品加入購物車或支付請求同時發送。挑戰設計下列測試場景： * 場景 1：模擬用戶在尖峰時段同時進行購物車操作(如一次性加入數千商品)，測試系統在處理大量請求時是否會出現性能問題。 * 場景 2：測試用戶在高峰時同時提交訂單，系統是否能夠正確處理並保持一定的回應速度。 * 場景 3：測試在極端高峰（如秒殺活動）下，系統是否能夠平穩運行，並在流量回落後迅速恢復。衝擊測試（Spike Testing）衝擊測試是模擬系統突然受到高流量衝擊時的表現，目的是檢查系統是否能夠快速響應突發情況，並在流量回落後迅速恢復穩定。系統架構 graph LR; A[

效能分析的基礎： The USE Method 和 The TSA Method

前言在效能測試領域，如何準確找到系統瓶頸，並迅速定位效能問題，是每位測試工程師面臨的重要挑戰。Brendan Gregg 提出的兩個方法論— The USE Method 和 The TSA Method，提供了系統化的方式來進行效能分析和排除故障。本篇文章將介紹這兩種方法，並討論它們在效能測試中的應用，幫助你快速識別並解決系統的效能問題。 The USE Method 是什麼？ The USE Method，全稱是 Utilization（使用率）, Saturation（飽和度）, and Errors（錯誤），是一種用來分析系統效能的檢查方法。它的核心目標是通過三個維度來檢查每個系統資源，從而系統化地找出效能瓶頸。 * Utilization（使用率）：表示某個資源的使用程度，通常以百分比來表達。高使用率表明這個資源可能是系統瓶頸。 * Saturation（飽和度）：表示資源的需求超過其最大處理能力。資源飽和意味著有任務在排隊等待，通常是導致效能下降的原因。 * Errors（錯誤）：指的是資源在使用過程中出現的錯誤或失敗。

挑戰你的直覺：探索 AcademyBugs 裡的隱藏問題

James Bach (註1)曾經講過「如何訓練測試新手」，他說：「訓練一個測試新手時，我會給他一個含有多個 bugs 的產品，讓他去發現這些問題，而不是單純給他一堆測試案例按步驟執行，因為這樣並不有趣。一旦他們找到一個重大的 bug，我會問他們是怎麼找到的。通常他們一開始可能不太清楚自己用了什麼技巧，但隨著了解技術，並運用這些技巧，他們會逐漸進步。」 AcademyBugs 是一個非常適合練習測試技巧的網站。它提供了一個模擬的電商網站，除了教你如何回報 bugs 之外，還會介紹不同類型的 bugs。在其 Find Bugs 頁面上，你可以找到 25 個真實的 bugs。通常，我會給自己 30 分鐘的時間來探索網站的各個功能，挑戰自己能在這段時間內找到多少 bugs。在頁面右上角按下「問號」圖標，你可以跟著網站的教學一步步練習如何發現和回報 bugs。接下來，我想分享一下我在進行探索測試時的分析流程： 1.

自動化測試案例：實現頁面A和頁面B之間的定時切換

在一家充滿科技感的現代化辦公室內，資深測試人員艾蜜莉正在面對一個棘手的測試需求。她的眼神專注，雙手熟練地在鍵盤上敲擊，猶如一位優雅的音樂家在演奏一首複雜的交響曲。這次的測試需求是要在一個網頁應用上自動化測試頁面切換的行為。具體來說，需要確認頁面是否會在同一個頁面上切換。首先，頁面會從首頁（我們稱之為頁面 A）切換到頁面 B，這個過程需要等待 10 秒鐘。接著，頁面 B 會再經過 20 秒鐘後，切換回頁面 A，這個過程會持續循環。艾蜜莉深吸一口氣，打開了她最熟悉的編輯器，開始撰寫自動化測試程式碼。她選擇了 Playwright 這個強大的工具，並使用 pytest 作為測試框架。這兩者的結合，讓他的測試更加高效且可靠。她先是設定了基本的測試環境，確保測試瀏覽器能夠正常啟動並訪問應用首頁。接著，她撰寫了如下的程式碼： import pytest from playwright.sync_api import sync_playwright

自動化測試 - Page Object Pattern 的使用與範例

Page Object 是一個撰寫 UI 自動化測試，經常使用的一種設計模式 (Design Pattern)，透過將網頁元素抽象化成元件的實作方式，讓你可以更有效的管理和組織你的測試程式碼，讓我們看看下面這個例子。元件介紹 * Login Test 和 Search Test 表示針對 Login 和 Search 頁面的測試，在登入相關的測試案例之中，我們需要執行登入的相關動作。 * LoginPage / HomePage / Search Page 都表示各頁面的動作，以登入頁面為例，在登入頁面上，可以按下登入按鈕或是回到首頁按鈕。程式碼實作 class LoginPage: def init(self, page): self.page = page def login(self): self.page.fill("#username&

自動化測試 - Screenplay Pattern 的介紹與應用

Screenplay Pattern 是一種設計模式，用來描述使用者和系統之間的互動。在這個模式中，使用者視為 Actor，動作則是為 (Task)，透過將這些場景 (Scenario) 的動作抽象化成「任務」和「角色」，可以讓你的自動化測試的腳本更具有可讀性和維護性。定義 Actor 類別角色 (Actors) 是測試的核心，用來執行特定的動作來完成測試的目的。 # actors.py from playwright.sync_api import Page class Actor: def __init__(self, name: str, page: Page): self.name = name self.page = page def attempts_to(self,

自動化測試 - Repository Pattern 的使用與介紹

在自動化測試案例中，往往第一步是為這些測試案例準備測試資料。測試資料的來源可能來自於某個檔案、某個資料庫或呼叫某支 API 請求的結果。使用 Repository 設計模式可以將資料的操作抽象化成建立（Create）、讀取（Read）、更新（Update）、刪除（Delete），而不會因為資料來源的實體不同而有不同的操作函式。 User 使用者資料的表示將是一個名為 User 的資料類別，其中包含一些個人資訊，例如電子郵件、使用者名稱。 import dataclasses @dataclasses.dataclass class User: email: str = "" username: str = "" Generic Repository Design Pattern Repository 設計模式的概念是將資料存取邏輯隱藏在業務程式碼之外。隱藏細節使程式碼更易於閱讀、維護。對於自動化測試框架，它使您甚至可以輕鬆地更改資料存取技術。通過抽象層，程式碼閱讀者不需要知道測試資料來自何處。