Latest

前言 透過刻意練習，我們能夠從實務中獲取經驗與不足，並且定期回顧自己用到什麼技術或工具。今天我們就回顧前幾天我們使用的測試工具 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[

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

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

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

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 是一種設計模式，用來描述使用者和系統之間的互動。在這個模式中，使用者視為 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,

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