AzureDevOps

「資料驅動測試（data-driven testing）」，你可以用迴圈或是參數化的方式，把多筆資料注入到同一個 test case 裡執行 方法一：使用 test.describe 搭配迴圈 import { test, expect } from '@playwright/test'; const testData = [ { input: 'user1', expected: 'Hello user1!' }, { input: 'user2', expected: 'Hello user2!' }, // 其餘48筆... ]; for (const data of testData) { test(`Should greet ${data.input}`, async ({ page }) => { await page.goto('https://example.com'); await page.fill('#name-input', data.input); await page.click('#submit-button'); const message = await page.textContent('#greeting'); expect(message).toBe(data.expected); }); } 方法二：使用 test.each（Playwright v1.31 以上支援） import { test, expect } from '@playwright/test'; const testData = [ ['user1', 'Hello user1!...

為什麼用 Playwright 測 API？ 雖然我們常用 Postman、curl 或 Jest 來測 API，但若你的專案已經使用 Playwright 做 E2E 測試，那麼善用同一套框架處理 API 測試，不僅可減少工具切換，還能將 UI 流程與 API 驗證整合在一起，提升測試維運的一致性。 Playwright 提供的 request 模組，讓我們可以像在用 fetch 一樣操作 HTTP 請求，非常方便。 開始寫第一個 API 測試 安裝 Playwright 如果你尚未安裝 Playwright，可以透過下列指令快速安裝： npm init playwright@latest 選擇 TypeScript 或 JavaScript 都可以，本篇範例以 TypeScript 為例。 撰寫 API 測試 假設我們有一個簡單的 API：https://jsonplaceholder.typicode.com/posts/1 我們來撰寫一個測試，驗證它回傳的內容正確： import { test, expect, request } from '@playwright/test'; test('GET /posts/1 should return a valid post', async () => { const apiContext = await request....

在現代 Web 開發流程中，自動化測試已經成為持續整合（CI）不可或缺的一環。而 Playwright 作為一個功能強大的 E2E 測試框架，搭配 Azure DevOps Pipeline，可以有效地讓我們在每次 commit 或 PR 時，自動進行跨瀏覽器測試，確保系統品質。 本文將介紹如何從零開始，將 Playwright 測試整合進 Azure DevOps CI 流程。 環境準備 專案初始化 npm init -y npm install -D @playwright/test npx playwright install 新增基本測試檔案（如 tests/example.spec.ts） import { test, expect } from '@playwright/test'; test('首頁標題應正確', async ({ page }) => { await page.goto('https://study4.tw'); await expect(page).toHaveTitle(/study4/); }); 在 package.json 中加入測試腳本 "scripts": { "test": "npx playwright test" } 設定 Azure DevOps Pipeline 在專案根目錄新增 .azure-pipelines.yml trigger: - main pool: vmImage: 'ubuntu-latest' steps: - task: NodeTool@0 inputs: versionSpec: '18....

在撰寫和編輯 Azure Wiki 上的內容時，圖片是一種非常有用的方式，能可以更好地傳達訊息並增強文章的可讀性。但有時候圖片的大小會導致可讀性下降，這時候就需要調整圖片的大小，以符合頁面的版面設計或減少圖片的檔案大小。 第一種方式可以用 HTML Tag <IMG src="<圖片網址>" alt="圖片描述" style="width: 500px;"/> 但如果你的圖片是複製貼上來的，會存在於 Azure Wiki 這個 Repo，這時可以這樣設定去等比例縮放大小  或明確的給寬跟高 

我會建議在使用 Azure Boards 選定 Scrum/Agile 工作流程後，一定要做“繼承”這件事，如此可以彈性的去設定整個專案的模式 Organzation Setting => Process 好處1: 可自訂欄位 可自己設計 Layout 調整不必要顯示的欄位 並且可以增加欄位，譬如增加 Version 用來指定該單子的版號，增加 Selection 來日常管理時挑選單子的輔助欄位 好處2: 自訂工作流程(State) 如果想要讓狀態更明確，可以自己去擴充或增減，譬如可以考慮多一個 State “Pull Request” 好處3: 隱藏不必要的 Work Items 敏捷最重要的精神就是極簡，但如果造內建定義好的 Work Items，也許會讓管理上更綁手綁腳的，通常我會建議可以有兩種玩法 玩法A: 只用 Product Backlogs 或者是 User Story 任何事情都應該對應到商業價值，要解決的問題也都是對應到“人”，用一種方式，依照 User Story 的撰寫方式把它寫好，會讓事情更單純 玩法B: Product Backlogs + User Story + Bug 將 PBI 定義成從團隊內發起的單子，譬如重構類型，User Story 定義成需求面，Bug 單子內容設計用來專注還原操作步驟 用這種玩法可以進一步撈出每次 Sprint 所著重的比例