# 📋 FriendPass 測試計劃書

> **Test Plan for FriendPass - Activity Registration Management System**

---

## 📄 文檔資訊

| 項目 | 內容 |
|------|------|
| **專案名稱** | FriendPass 活動報名管理系統 |
| **文檔類型** | 測試計劃書 (Test Plan) |
| **文檔版本** | v1.0 |
| **撰寫日期** | 2025-11-10 |
| **最後更新** | 2025-11-10 |
| **測試負責人** | QA Team |
| **專案狀態** | 開發測試階段 |
| **預計上線日期** | 2025-12-05 |

---

## 📑 目錄

1. [專案概述](#1-專案概述)
2. [測試目標](#2-測試目標)
3. [測試範圍](#3-測試範圍)
4. [測試策略](#4-測試策略)
5. [測試資源](#5-測試資源)
6. [測試環境](#6-測試環境)
7. [測試進度與排程](#7-測試進度與排程)
8. [測試交付物](#8-測試交付物)
9. [風險管理](#9-風險管理)
10. [測試完成標準](#10-測試完成標準)
11. [溝通機制](#11-溝通機制)
12. [附錄](#12-附錄)

---

## 1. 專案概述

### 1.1 產品簡介

**FriendPass** 是一個專為活動主辦方設計的全方位活動報名管理系統（SaaS），提供從活動創建、宣傳推廣、報名管理、現場報到到數據分析的完整解決方案。

### 1.2 產品特色

- **快速建立活動** - 6步驟完成活動設定（地點、票券、禮品、日期、宣傳頁、表單）
- **多渠道追蹤** - 支援 FB/LINE/Instagram/EDM 來源追蹤
- **即時報到管理** - QR Code 掃描 + 手動報到雙模式
- **數據可視化** - 即時銷售數據與來源渠道分析
- **團隊協作** - 支援共編者權限管理

### 1.3 核心業務流程

#### 主辦方工作流程

註冊登入 → 創建活動 → 設定票券 → 設定表單 → 生成分享連結 
→ 宣傳推廣 → 收集報名 → 現場報到 → 數據分析

#### 參加者報名流程

點擊分享連結 → 查看活動資訊 → 選擇票券 → 填寫報名表單 
→ 選擇付款方式 → 完成付款 → 收到門票 → 現場報到

### 1.4 目標用戶

| 角色 | 描述 | 關鍵需求 |
|------|------|---------|
| **活動主辦方** | 舉辦活動的組織或個人 | 快速建立活動、收集報名、數據分析 |
| **現場工作人員** | 負責現場報到與禮品發放 | 快速掃描報到、手動報到、禮品兌換 |
| **共編者** | 受邀協助管理活動的成員 | 查看數據、協助報到、編輯活動 |
| **活動參加者** | 報名參加活動的一般用戶 | 簡化報名流程、便利報到、即時通知 |

---

## 2. 測試目標

### 2.1 總體目標

確保 FriendPass 系統在功能、效能、安全性、相容性和使用者體驗等方面符合產品需求規格（PRD），並能穩定、安全地支持活動主辦方和參加者的核心業務流程。

### 2.2 具體測試目標

#### 2.2.1 功能性目標

✅ **核心業務流程完整性**
- 註冊登入流程 100% 可用
- 活動建立與設定流程 100% 可用
- 報名與付款流程 100% 可用
- 現場報到流程 100% 可用

✅ **數據正確性與完整性**
- 財務數據計算準確率 100%（銷售總額、票種金額）
- 報名數據準確率 100%（報名人次、報到人數）
- 來源渠道追蹤準確率 ≥ 95%

✅ **多用戶角色與權限管理**
- 共編者權限控制正確性 100%
- 敏感操作權限驗證 100%

#### 2.2.2 非功能性目標

🚀 **效能目標**
- 頁面載入時間 < 3 秒（首屏）
- QR Code 掃描辨識速度 < 1 秒
- 搜尋功能響應時間 < 500ms
- 支援 1000+ 並發用戶（報名高峰）

🔒 **安全性目標**
- 通過 OWASP Top 10 安全驗證
- 密碼加密儲存（bcrypt / Argon2）
- 防止 SQL Injection、XSS、CSRF 攻擊
- 敏感資料傳輸使用 HTTPS

🌍 **相容性目標**
- 支援主流瀏覽器（Chrome、Safari、Edge、Firefox）最新版本
- 支援行動裝置（iOS 14+、Android 10+）
- 手機端響應式設計適配（320px - 2560px）

😊 **使用者體驗目標**
- 關鍵操作流程直覺易用（需求用戶測試）
- 錯誤提示清晰明確
- Loading 狀態即時反饋
- 空狀態提示友善

---

## 3. 測試範圍

### 3.1 測試包含範圍

#### 3.1.1 前台系統（參加者端）- 135 個測試案例

| 模組 | 測試案例數 | 測試重點 |
|------|-----------|---------|
| **1.1 活動宣傳頁面** | 17 | 活動資訊展示、載入狀態、報名入口 |
| **1.2 票券選擇** | 30 | 數量選擇、金額計算、庫存控制 |
| **1.3 報名表單填寫** | 27 | 表單驗證、自訂欄位、資料完整性 |
| **1.4 結帳與付款** | 18 | 付款方式、金流整合、交易安全 |
| **1.5 付款完成與門票** | 26 | QR Code生成、門票管理、查詢功能 |
| **1.6 異常與邊界情況** | 17 | 防超賣、網路異常、Session處理 |

**關鍵測試重點**：
- ✅ 財務正確性（金額計算、防重複扣款）
- ✅ 庫存管理（防超賣、即時庫存檢查）
- ✅ 金流整合（付款成功/失敗/取消/超時）
- ✅ 門票管理（QR Code 生成與掃描驗證）

#### 3.1.2 後台系統（主辦方端）- 735 個測試案例

| 模組 | 測試案例數 | 測試重點 |
|------|-----------|---------|
| **1. 登入模組** | 90 | 註冊、登入、密碼重設、安全性 |
| **2.1 我的活動模組** | 68 | 活動列表、狀態管理、CRUD 操作 |
| **2.2 概覽模組 - 活動設定** | 108 | 6步驟設定流程、數據驗證 |
| **2.2 概覽模組 - 分享活動** | 62 | 分享連結、渠道追蹤、QR Code |
| **2.3 報到模組** | 75 | 手動/掃描報到、禮品兌換 |
| **2.4 銷售狀況模組** | 45 | 銷售總額、報名統計、票種分析 |
| **2.5 分析洞察模組** | 47 | 票務分析、來源渠道、環狀圖 |
| **3. 帳號模組** | 203 | 帳號管理、共編者、方案升級 |
| **4. 掃描模組** | 55 | QR Code 掃描、速度、錯誤處理 |
| **5. 整合測試** | 27 | 跨模組流程、相容性、UX |

**關鍵測試重點**：
- ✅ 活動完整建立流程（6/6 步驟完成）
- ✅ 報到現場營運流暢性（掃描速度 < 1秒）
- ✅ 財務數據準確性（銷售總額、票種金額）
- ✅ 來源渠道追蹤正確性（FB/LINE/IG/EDM）
- ✅ 共編者權限控制

#### 3.1.3 整合與非功能性測試

**跨模組整合測試**
- 端到端業務流程（主辦方創建活動 → 參加者報名 → 現場報到）
- 數據一致性驗證（前後台數據同步）
- 權限跨模組驗證

**效能測試**
- 頁面載入時間測試
- 搜尋功能響應時間
- QR Code 掃描速度
- 並發用戶壓力測試

**安全性測試**
- 身份驗證與授權測試
- SQL Injection / XSS / CSRF 防護
- 敏感資料加密驗證
- Session 管理與 Token 安全

**相容性測試**
- 瀏覽器相容性（Chrome、Safari、Edge、Firefox）
- 行動裝置相容性（iOS、Android）
- 響應式設計測試（320px - 2560px）

**使用者體驗測試**
- 介面載入速度
- 錯誤提示清晰度
- 按鈕回饋機制
- 空狀態友善提示

### 3.2 測試不包含範圍

❌ **第三方服務內部邏輯**
- 金流平台內部交易邏輯（僅測試整合介面）
- Email 服務商內部運作（僅測試發送觸發）
- LINE OA / FB API 內部邏輯（僅測試整合正確性）

❌ **基礎設施層**
- 雲端服務商（AWS/GCP/Azure）底層可用性
- CDN 服務內部運作
- 資料庫軟體本身的穩定性

❌ **超出當前版本規格**
- 未在 PRD v1.0 中定義的功能
- 實驗性功能或 Beta 功能
- 未來版本規劃功能

❌ **特殊使用場景**
- 極端罕見的邊界情況（發生機率 < 0.1%）
- 不支援的舊版瀏覽器（IE11 以下）
- 非官方支援的裝置或作業系統

---

## 4. 測試策略

### 4.1 測試類型與方法

#### 4.1.1 功能測試 (Functional Testing)

**測試方法**：黑箱測試 (Black Box Testing)

**執行階段**：
1. **Smoke Testing**（冒煙測試）- 每日 Build 後執行
- 測試範圍：P0 核心功能（約 100 個關鍵案例）
- 通過標準：100% Pass
- 失敗處理：阻擋進入完整測試

2. **功能測試**（主要測試階段）
- 測試範圍：全部 870 個測試案例
- 執行順序：P0 → P1 → P2
- 通過標準：P0 100% Pass、P1 ≥ 95% Pass、P2 ≥ 90% Pass

3. **回歸測試 (Regression Testing)**
- 觸發時機：每次程式碼變更後
- 測試範圍：受影響模組的完整測試案例
- 自動化覆蓋率目標：≥ 70%

#### 4.1.2 整合測試 (Integration Testing)

**測試重點**：
- 跨模組數據流驗證（活動建立 → 分享 → 報名 → 報到）
- API 整合測試（前後台 API 呼叫）
- 第三方服務整合（金流、Email、LINE OA）

**測試案例數**：27 個（包含在後台整合測試模組）

#### 4.1.3 系統測試 (System Testing)

**端到端測試 (E2E Testing)**
- 完整業務流程模擬（從註冊到活動結束）
- 多角色協作測試（主辦方 + 共編者 + 參加者）

#### 4.1.4 效能測試 (Performance Testing)

**負載測試 (Load Testing)**
- 模擬正常負載（100 並發用戶）
- 驗證響應時間符合 SLA

**壓力測試 (Stress Testing)**
- 逐步增加負載至系統極限（1000+ 並發用戶）
- 觀察系統崩潰點與恢復能力

**特定場景測試**
- QR Code 掃描速度測試（目標 < 1 秒）
- 搜尋功能響應時間（目標 < 500ms）
- 大量報名同時湧入（模擬搶票情境）

**工具**：JMeter / Locust / k6

#### 4.1.5 安全性測試 (Security Testing)

**測試項目**：
- ✅ 身份驗證與授權機制
- ✅ SQL Injection 防護
- ✅ XSS (Cross-Site Scripting) 防護
- ✅ CSRF (Cross-Site Request Forgery) 防護
- ✅ 密碼加密與儲存安全
- ✅ Session 管理與 Token 安全
- ✅ HTTPS 傳輸加密
- ✅ 敏感資料遮罩

**工具**：OWASP ZAP / Burp Suite

#### 4.1.6 相容性測試 (Compatibility Testing)

**瀏覽器測試**
- Chrome（最新版）- 優先
- Safari（最新版）- 優先（iOS 主流）
- Edge（最新版）
- Firefox（最新版）

**行動裝置測試**
- iOS 14+ （iPhone 11 / 12 / 13 / 14）
- Android 10+ （Samsung / Pixel / Xiaomi）
- 響應式設計（320px - 2560px）

**工具**：BrowserStack / Sauce Labs

#### 4.1.7 使用者體驗測試 (UX Testing)

**測試項目**：
- 介面載入速度（< 3 秒）
- 錯誤訊息清晰度
- 按鈕回饋機制（Loading、Disable 狀態）
- 空狀態提示友善性
- 導航流暢度

**方法**：啟發式評估 + 使用者測試

### 4.2 測試執行策略

#### 4.2.1 三階段測試執行

**階段一：Smoke Testing（P0 優先）**
- **目標**：確保系統可上線營運
- **測試範圍**：519 個 P0 測試案例
- **執行時間**：2-3 天
- **通過標準**：100% Pass

**測試模組順序**：
1. 登入模組 P0 → 確保用戶可進入系統
2. 活動建立與設定 P0 → 確保主辦方可建立活動
3. 前台報名流程 P0 → 確保參加者可報名與付款
4. 分享連結 P0 → 確保報名渠道可用
5. 報到功能 P0 → 確保現場可順利報到
6. 財務數據 P0 → 確保金額與人數正確

**階段二：核心功能驗證（P0 + P1）**
- **目標**：完整驗證核心業務流程
- **測試範圍**：519 個 P0 + 249 個 P1 = 768 個案例
- **執行時間**：5-7 天
- **通過標準**：P0 100% Pass、P1 ≥ 95% Pass

**階段三：輔助功能與整合（P1 + P2）**
- **目標**：完整測試覆蓋與 UX 優化
- **測試範圍**：全部 870 個測試案例
- **執行時間**：7-10 天
- **通過標準**：P0 100%、P1 ≥ 95%、P2 ≥ 90%

#### 4.2.2 測試自動化策略

**自動化目標**：
- **UI 自動化覆蓋率**：≥ 40%（關鍵路徑優先）
- **API 自動化覆蓋率**：≥ 70%（後台 API）
- **回歸測試自動化**：≥ 70%

**自動化工具**：
- **UI 自動化**：Playwright / Cypress
- **API 自動化**：Postman / REST Assured
- **單元測試**：Jest / Vitest（前端）、pytest / JUnit（後端）
- **CI/CD 整合**：GitHub Actions / GitLab CI

**自動化優先順序**：
1. P0 核心業務流程（登入、活動建立、報名、報到）
2. 回歸測試高頻變動模組（活動設定、報名表單）
3. API 層級測試（所有後台 API）

**手動測試保留**：
- 探索性測試（Exploratory Testing）
- UX/UI 視覺驗證
- 特殊設備與瀏覽器測試
- 複雜業務邏輯邊界情況

### 4.3 缺陷管理策略

#### 4.3.1 缺陷優先級定義

| 優先級 | 定義 | 處理時間 | 範例 |
|--------|------|---------|------|
| **Critical (P0)** | 阻斷核心功能，系統無法使用 | 立即修復（4小時內） | 無法登入、無法建立活動、付款失敗、數據丟失 |
| **High (P1)** | 重要功能異常，有替代方案 | 24小時內修復 | 編輯功能異常、搜尋失效、報表錯誤 |
| **Medium (P2)** | 次要功能問題，影響體驗 | 1週內修復 | UI 顯示錯誤、提示不清、非主流瀏覽器問題 |
| **Low (P3)** | 輕微問題，優化項目 | 依資源排程 | 文字錯別字、樣式微調 |

#### 4.3.2 缺陷處理流程

發現缺陷 → 記錄缺陷（Jira/Redmine） → 指派開發 → 開發修復 
→ QA 驗證 → 通過（關閉）/ 失敗（重新開啟）→ 回歸測試

**缺陷資訊包含**：
- 缺陷標題（簡潔明確）
- 重現步驟（Step by Step）
- 預期結果 vs 實際結果
- 截圖/錄影
- 環境資訊（瀏覽器、裝置、OS）
- 嚴重程度與優先級
- 相關測試案例編號

---

## 5. 測試資源

### 5.1 人力資源

#### 5.1.1 測試團隊組成

| 角色 | 人數 | 職責 |
|------|------|------|
| **QA** | 1-2 | 測試計劃制定、測試案例撰寫、功能測試執行、缺陷追蹤、風險管理 |
| **PM** | 1-2 | 需求澄清、功能驗收、進度追蹤、UAT 協調 |
| **FE** | 2-3 | 前端開發、UI/UX 相關缺陷修復、前端自動化測試 |
| **BE** | 2-3 | 後端開發、API/業務邏輯缺陷修復、API 測試 |

**總人力需求**：6-10 人

#### 5.1.2 外部支援

- **UI/UX** - UI 視覺驗收、使用者體驗評估
- **實際使用者（Beta Tester）** - UAT（用戶驗收測試）

### 5.2 測試工具

#### 5.2.1 測試管理工具

- **測試案例管理**：Excel
- **缺陷追蹤**：Asana
- **測試報告**：TBD

#### 5.2.2 自動化測試工具

- **UI 自動化**：Playwright / Cypress
- **API 自動化**：Postman / Apidog
- **單元測試**：Jest / Vitest / pytest
- **CI/CD**：GitHub Actions / GitLab CI / Jenkins

#### 5.2.3 效能測試工具

- **壓力測試**：k6
- **監控工具**：Grafana

#### 5.2.4 安全性測試工具(TBD)

- **漏洞掃描**：OWASP ZAP / Burp Suite
- **靜態分析**：SonarQube
- **依賴檢查**：npm audit / Snyk

#### 5.2.5 相容性測試工具

- **跨瀏覽器測試**：BrowserStack / Sauce Labs
- **行動裝置測試**：BrowserStack / Firebase Test Lab
- **響應式測試**：Chrome DevTools / Responsively App

#### 5.2.6 其他輔助工具

- **截圖/錄影**：Jam
- **資料產生**：Faker.js / Mockaroo
- **資料庫工具**：Navicat

### 5.3 測試數據

#### 5.3.1 測試數據需求

**使用者帳號數據**
- 一般使用者帳號：50 個
- 主辦方帳號：20 個
- 共編者帳號：10 個
- 異常帳號（測試用）：10 個

**活動數據**
- 草稿狀態活動：10 個
- 已上架活動：20 個
- 進行中活動：15 個
- 已結束活動：10 個

**報名數據**
- 模擬報名記錄：1000+ 筆
- 不同渠道來源：FB(30%) / LINE(35%) / IG(20%) / EDM(15%)
- 不同票種：免費票、付費票、VIP票

**金流測試數據**
- 測試信用卡號（金流商提供）
- 各種付款成功/失敗場景

#### 5.3.2 測試數據管理

- **數據隔離**：測試環境獨立資料庫
- **數據重置**：每日自動重置測試數據
- **數據備份**：關鍵測試數據腳本化建立
- **敏感數據**：使用假名、假信箱、假電話

---

## 6. 測試環境

### 6.1 環境架構

| 環境類型 | 用途 | 更新頻率 | 存取權限 |
|---------|------|---------|---------|
| **Dev（開發環境）** | 開發測試、整合測試 | 隨時更新 | 開發團隊 + QA Team |
| **UAT（用戶驗收測試環境）** | 功能測試、回歸測試、UAT、壓力測試 | 每日更新 | QA + PM + FE + BE + Beta User |
| **Production（正式環境）** | 正式服務 | 版本發布時 | 所有用戶 |

### 6.2 環境規格

#### 6.2.1 UAT 測試環境（主要測試環境）

**後端**
- **作業系統**：Linux (Ubuntu 22.04)
- **Runtime**：Node.js 18+ / Python 3.10+
- **資料庫**：PostgreSQL 14+ / MySQL 8+
- **快取**：Redis 7+
- **負載均衡**：Nginx

**前端**
- **靜態網站託管**：Vercel / Netlify / AWS S3 + CloudFront

**第三方服務**
- **金流**：測試環境串接（Sandbox Mode）
- **Email**：測試信箱 SMTP（MailHog / Mailtrap）
- **LINE OA**：測試頻道

#### 6.2.2 測試裝置清單

**桌面裝置**
- Windows 10/11 + Chrome/Edge/Firefox
- macOS 13+ + Safari/Chrome

**行動裝置**
- iPhone 11/12/13/14 (iOS 14+)
- Samsung Galaxy S21/S22 (Android 11+)
- Pixel 5/6 (Android 11+)

### 6.3 環境管理

**環境維護責任**：FE + BE + QA

**環境監控**：
- 即時監控（Uptime、Response Time）
- 每日健康檢查（Smoke Test）
- 問題回報機制（Slack Channel）

**資料重置**：
- UAT 環境：每日凌晨自動重置

---

## 7. 測試進度與排程

### 7.1 測試里程碑

**專案關鍵日期**：
- **開始日期**：2025/11/10（星期一）
- **UAT 上線目標**：2025/12/5（星期四）- 管理層驗收
- **可用工作天數**：18 個工作天

| 階段 | 開始日期 | 結束日期 | 工作天數 | 測試案例數 | 主要交付物 | 負責人員 |
|------|---------|---------|---------|----------|-----------|---------|
| **Week 1: 測試準備與 Review** | 11/11 (一) | 11/15 (五) | 5 天 | Review 870個案例 | 測試案例評審完成、UAT 環境就緒 | QA + PM + FE + BE |
| **Week 2: P0 核心功能測試（一）** | 11/18 (一) | 11/22 (五) | 5 天 | ~260個 P0 | 前台全測試、登入+活動建立 | QA + PM |
| **Week 3: P0 核心功能測試（二）** | 11/25 (一) | 11/29 (五) | 5 天 | ~259個 P0 | 報到+掃描+帳號+整合測試 | QA + PM |
| **Week 4: P1 測試 + UAT 準備** | 12/2 (一) | 12/5 (四) | 3 天 | 高優先 P1 | 回歸測試、UAT 上線 | QA + PM |

**總測試週期**：約 **4 週（18 個工作天）** - 精簡版快速測試週期

### 7.2 詳細測試排程

#### Week 1: 測試準備與 Review（11/11 ~ 11/15）

**本週目標**：完成所有測試案例 Review，建立 UAT 環境

**每日排程**：

| 日期 | 主要工作 | Review 模組 | 測試案例數 | 負責人 |
|------|---------|-----------|----------|--------|
| **11/11 (一)** | Kick-off Meeting + 前台 Review | 前台全部 | 135個 | QA + PM |
| **11/12 (二)** | 後台 Review（一） | 登入+我的活動+概覽 | 310個 | QA + PM |
| **11/13 (三)** | 後台 Review（二） | 報到+銷售+分析洞察 | 167個 | QA + PM |
| **11/14 (四)** | 後台 Review（三） | 帳號+掃描+整合測試 | 258個 | QA + PM |
| **11/15 (五)** | UAT 環境準備 + 測試數據建立 | 環境驗證 | - | FE + BE + QA |

**主要工作**：
- ✅ 測試案例 Review 完成（870個全部檢視）
- ✅ 建立 UAT 測試環境（FE + BE）
- ✅ 準備測試數據（帳號、活動、報名資料）（QA + BE）
- ✅ 配置測試工具（Asana、BrowserStack）（QA）
- ✅ 測試團隊 Kick-off Meeting（QA + PM + FE + BE）

**負責人員**：QA + PM + FE + BE

**交付物**：
- ✅ 測試案例 Review 報告
- ✅ UAT 測試環境就緒確認
- ✅ 測試數據準備完成
- ✅ 測試排程確認

#### Week 2: P0 核心功能測試（一）（11/18 ~ 11/22）

**本週目標**：完成前台全測試 + 後台登入與活動建立核心流程

**測試範圍**：約 260 個 P0 測試案例

| 日期 | 測試模組 | 測試案例數 | 測試重點 | 負責人 |
|------|---------|----------|---------|--------|
| **11/18 (一)** | 前台 - 宣傳頁 + 票券選擇 | 41個 P0 | 活動資訊展示、票券計算、庫存控制 | QA + PM |
| **11/19 (二)** | 前台 - 表單 + 結帳付款 | 37個 P0 | 表單驗證、金流整合、付款流程 | QA + PM |
| **11/20 (三)** | 前台 - 門票 + 異常處理 | 29個 P0 | QR Code 生成、防超賣、邊界測試 | QA + PM |
| **11/21 (四)** | 登入模組 | 58個 P0 | 註冊、登入、密碼重設 | QA + PM |
| **11/22 (五)** | 我的活動 + 概覽模組 | 95個 P0 | 活動 CRUD、6步驟設定流程 | QA + PM |

**並行工作**：
- 執行測試案例（QA + PM）
- 記錄缺陷至 Asana（QA）
- 每日 Stand-up 同步進度（QA + PM + FE + BE）
- 開發團隊修復 P0 缺陷（FE + BE）
- 回歸測試已修復缺陷（QA）

**負責人員**：QA + PM + FE + BE

**交付物**：
- ✅ 前台完整測試報告（135個案例）
- ✅ 登入模組測試報告（90個案例）
- ✅ 活動建立測試報告（163個案例）
- ✅ P0 缺陷清單與修復追蹤
- ✅ Week 2 測試進度報告

#### Week 3: P0 核心功能測試（二）（11/25 ~ 11/29）

**本週目標**：完成報到、掃描、帳號、整合等核心功能測試

**測試範圍**：約 259 個 P0 測試案例

| 日期 | 測試模組 | 測試案例數 | 測試重點 | 負責人 |
|------|---------|----------|---------|--------|
| **11/25 (一)** | 分享活動模組 | 48個 P0 | 分享連結、渠道追蹤、QR Code | QA + PM |
| **11/26 (二)** | 報到模組 | 48個 P0 | 手動報到、掃描報到、禮品兌換 | QA + PM |
| **11/27 (三)** | 掃描模組 | 33個 P0 | QR Code 掃描、速度測試、錯誤處理 | QA + PM |
| **11/28 (四)** | 帳號模組 | 121個 P0 | 帳號管理、共編者權限、方案管理 | QA + PM |
| **11/29 (五)** | 銷售 + 整合測試 | 30個 P0 | 銷售數據正確性、端到端流程 | QA + PM |

**並行工作**：
- 執行測試案例（QA + PM）
- 開發團隊修復 P0 缺陷（FE + BE）
- QA 回歸測試已修復缺陷（QA）
- P0 缺陷收斂（目標：P0 全部修復）

**負責人員**：QA + PM + FE + BE

**交付物**：
- ✅ 分享活動測試報告（62個案例）
- ✅ 報到模組測試報告（75個案例）
- ✅ 掃描模組測試報告（55個案例）
- ✅ 帳號模組測試報告（203個案例）
- ✅ 銷售與整合測試報告（72個案例）
- ✅ P0 完整測試報告（519個案例）
- ✅ Week 3 測試進度報告

#### Week 4: P1 高優先測試 + UAT 上線（12/2 ~ 12/5）

**本週目標**：完成 P1 高優先功能測試、回歸測試、UAT 環境上線

**測試範圍**：高優先 P1 測試案例（約 100-150 個）+ 全面回歸測試

| 日期 | 主要工作 | 測試內容 | 負責人 |
|------|---------|---------|--------|
| **12/2 (一)** | P1 高優先測試 | 分享連結、報到進階功能、銷售數據 | QA + PM |
| **12/3 (二)** | P1 高優先測試 | 共編者權限、掃描進階功能 | QA + PM |
| **12/4 (三)** | 全面回歸測試 | P0 全部回歸、P1 重點回歸 | QA + PM + FE + BE |
| **12/5 (四)** | **UAT 上線** | 管理層驗收、UAT 環境開放 | PM + QA + FE + BE |

**本週重點**：
- ✅ P0 缺陷 100% 修復並驗證
- ✅ P1 高優先缺陷 ≥ 90% 修復
- ✅ 全面回歸測試（自動化 + 手動）
- ✅ UAT 環境穩定性確認
- ✅ 準備管理層驗收文檔

**負責人員**：QA + PM + FE + BE

**交付物**：
- ✅ P1 高優先測試報告
- ✅ 全面回歸測試報告
- ✅ UAT 上線報告
- ✅ 已知問題清單（未修復 P1/P2）
- ✅ 管理層驗收簡報
- ✅ UAT 環境使用指南

### 7.3 後續測試階段（12/5 之後）

#### 階段五：UAT 管理層驗收（12/5 ~ 12/12）

**本階段目標**：管理層驗收核心業務流程

| 工作項目 | 時間 | 負責人 | 說明 |
|---------|------|--------|------|
| 管理層 UAT 測試 | 12/5 - 12/9 | PM + 管理層 | 管理層驗收關鍵流程 |
| 收集 UAT 反饋 | 12/9 - 12/10 | PM + QA | 整理 UAT 發現問題 |
| UAT 缺陷修復 | 12/10 - 12/12 | FE + BE | 修復 UAT 發現的問題 |
| UAT 驗收報告 | 12/12 | QA + PM | UAT 驗收結果報告 |

#### 階段六：P1/P2 完整測試（12/13 ~ 12/20）

**測試範圍**：剩餘 P1 (約100-150個) + P2 (102個)

| 工作項目 | 時間 | 負責人 | 說明 |
|---------|------|--------|------|
| P1 完整測試 | 12/13 - 12/17 | QA + PM | 完成所有 P1 測試案例 |
| P2 次要功能測試 | 12/18 - 12/19 | QA | 完成 P2 測試案例 |
| 相容性測試 | 12/19 - 12/20 | QA | 跨瀏覽器、行動裝置測試 |

#### 階段七：效能與安全測試（12/23 ~ 12/27）

**效能測試**：
- 負載測試（100 並發用戶）
- 壓力測試（1000+ 並發用戶）
- QR Code 掃描速度測試
- 搜尋功能響應時間測試

**安全性測試**：
- OWASP Top 10 驗證
- 漏洞掃描（ZAP/Burp Suite）
- 權限驗證測試

**負責人員**：QA + BE

#### 階段八：正式上線準備（12/30 ~ 1/3）

**上線準備工作**：
- 全面回歸測試
- 生產環境驗證
- 上線檢查清單確認
- Go/No-Go 決策會議

**負責人員**：QA + PM + FE + BE + 管理層

---

## 8. 測試交付物

### 8.1 測試文檔交付物

| 文檔名稱 | 交付時間 | 負責人 | 備註 |
|---------|---------|--------|------|
| **測試計劃書** | 測試開始前 | QA Lead | 本文檔 |
| **測試案例文檔** | 測試開始前 | QA Team | 已完成（870個案例） |
| **測試數據準備文檔** | 測試開始前 | QA Engineer | 測試帳號、活動數據 |
| **每日測試進度報告** | 每日 | QA Engineer | Email / Slack |
| **每週測試摘要報告** | 每週五 | QA Lead | 進度、缺陷統計、風險 |
| **Smoke Test 報告** | 階段一完成 | QA Engineer | 關鍵功能驗證 |
| **功能測試報告** | 階段二/三完成 | QA Lead | 完整測試結果 |
| **效能測試報告** | 第 7 週 | Performance Tester | 負載、壓力測試結果 |
| **安全性測試報告** | 第 7 週 | Security Tester | 漏洞掃描、滲透測試結果 |
| **相容性測試報告** | 第 6 週 | QA Engineer | 瀏覽器、裝置相容性 |
| **UAT 報告** | 第 8 週 | QA Lead + PM | 用戶驗收結果 |
| **最終測試報告** | 測試結束 | QA Lead | 綜合測試結果、上線建議 |
| **已知問題清單** | 上線前 | QA Lead | 未修復缺陷列表與風險評估 |

### 8.2 測試執行成果

**測試執行記錄**：
- 測試案例執行狀態（Pass / Fail / Blocked / N/A）
- 測試案例執行截圖/錄影
- 測試數據與環境資訊

**缺陷追蹤記錄**：
- 缺陷清單（Jira / Excel）
- 缺陷統計圖表（優先級分布、模組分布、趨勢圖）
- 缺陷修復進度追蹤

**測試覆蓋率報告**：
- 功能覆蓋率（已測試功能 / 全部功能）
- 需求覆蓋率（已測試需求 / 全部需求）
- 代碼覆蓋率（自動化測試）

### 8.3 測試報告內容範本

#### 8.3.1 每週測試摘要報告

【FriendPass 測試週報】第 X 週 (YYYY/MM/DD - YYYY/MM/DD)

一、測試進度
- 本週測試案例執行：XXX 個（累計：XXX / 870）
- 測試案例通過率：XX%
- 進度狀態：✅ 如期 / ⚠️ 延遲 X 天

二、缺陷統計
- 本週新增缺陷：XX 個（P0: X | P1: X | P2: X | P3: X）
- 本週修復缺陷：XX 個
- 未解決缺陷：XX 個（P0: X | P1: X | P2: X | P3: X）
- 缺陷修復率：XX%

三、測試重點與發現
- 測試重點模組：XXX
- 主要發現問題：
  1. [P0] XXXX
  2. [P1] XXXX

四、風險與阻礙
- 風險項目：XXXX
- 阻礙項目：XXXX
- 需求支援：XXXX

五、下週計劃
- 測試目標：XXX 個案例
- 測試重點：XXX 模組

#### 8.3.2 最終測試報告

【FriendPass 最終測試報告】

一、測試摘要
- 測試期間：YYYY/MM/DD - YYYY/MM/DD
- 測試版本：vX.X.X
- 測試案例總數：870 個
- 測試案例執行數：XXX 個（執行率：XX%）
- 測試案例通過數：XXX 個（通過率：XX%）

二、優先級測試結果
- P0 (Critical)：通過率 XX%（XXX / 519）
- P1 (High)：通過率 XX%（XXX / 249）
- P2 (Medium)：通過率 XX%（XXX / 102）

三、缺陷統計
- 總缺陷數：XXX 個
- 已修復：XXX 個（修復率：XX%）
- 未修復：XX 個
  - P0: X 個（⚠️ 阻擋上線）
  - P1: X 個
  - P2: X 個

四、測試覆蓋範圍
✅ 功能測試（870 個案例）
✅ 整合測試（27 個案例）
✅ 效能測試（負載、壓力測試）
✅ 安全性測試（OWASP Top 10）
✅ 相容性測試（4 瀏覽器 + 多裝置）
✅ UAT（X 位使用者參與）

五、主要發現問題
【已修復】
1. [P0] XXXX
2. [P1] XXXX

【未修復 - 風險評估】
1. [P1] XXXX - 風險：低（有替代方案）
2. [P2] XXXX - 風險：極低（次要功能）

六、效能測試結果
✅ 頁面載入時間：平均 X.X 秒（目標 < 3 秒）
✅ QR Code 掃描速度：平均 X.X 秒（目標 < 1 秒）
✅ 搜尋響應時間：平均 XXX ms（目標 < 500ms）
✅ 並發用戶支援：通過 1000 並發測試

七、安全性測試結果
✅ OWASP Top 10：全數通過
✅ SQL Injection：無漏洞
✅ XSS 防護：通過
✅ CSRF 防護：通過
✅ 密碼加密：符合標準

八、上線建議
【建議上線】✅ / 【不建議上線】❌

理由：
- XXX
- XXX

【上線前必須修復】
- [P0] XXXX

【上線後優化項目】
- [P1] XXXX
- [P2] XXXX

九、附件
- 測試案例執行明細
- 缺陷清單
- 效能測試數據
- 安全測試報告

---

## 9. 風險管理

### 9.1 測試風險識別

| 風險類別 | 風險描述 | 可能性 | 影響程度 | 風險等級 |
|---------|---------|--------|---------|---------|
| **進度風險** | 測試時間不足，無法完整執行 870 個案例 | 中 | 高 | 🔴 高 |
| **資源風險** | QA 人力不足，關鍵人員請假 | 中 | 中 | 🟠 中 |
| **環境風險** | 測試環境不穩定，頻繁當機 | 低 | 高 | 🟠 中 |
| **需求風險** | 需求變更頻繁，測試案例需大量修改 | 中 | 中 | 🟠 中 |
| **整合風險** | 第三方服務（金流、Email）測試環境異常 | 中 | 中 | 🟠 中 |
| **自動化風險** | 自動化測試開發延遲，影響回歸測試 | 中 | 低 | 🟡 低 |
| **數據風險** | 測試數據不足或品質不佳 | 低 | 中 | 🟡 低 |
| **技術風險** | 新技術棧（如特定框架）測試經驗不足 | 低 | 中 | 🟡 低 |

### 9.2 風險應對策略

#### 🔴 高風險應對

**風險：測試時間不足**

**應對策略**：
- ✅ **優先級測試**：嚴格按 P0 → P1 → P2 執行，確保核心功能優先測試
- ✅ **測試自動化**：關鍵路徑優先開發自動化，提升回歸測試效率
- ✅ **並行測試**：多位 QA 並行測試不同模組
- ✅ **風險評估**：若時間不足，與 PM 協商調整上線範圍（P2 功能可延後）

**應對責任人**：QA + PM

#### 🟠 中風險應對

**風險：QA 人力不足**

**應對策略**：
- ✅ **交叉培訓**：QA 成員互相備份，避免單點依賴
- ✅ **外部支援**：必要時引入外包測試人力
- ✅ **開發協助**：開發團隊協助執行部分測試（API 測試、單元測試）
- ✅ **請假預警**：提前規劃人員休假，避免關鍵時期人力短缺

**風險：測試環境不穩定**

**應對策略**：
- ✅ **環境監控**：建立即時監控（Uptime、Response Time）
- ✅ **快速重建**：環境建置腳本化（Docker / Terraform），快速重建
- ✅ **備援環境**：準備備援測試環境（Dev 環境作為 backup）
- ✅ **問題追蹤**：建立環境問題回報機制（Slack Channel）

**風險：需求變更頻繁**

**應對策略**：
- ✅ **需求凍結**：測試階段進入後，需求變更需經過變更管理流程
- ✅ **影響評估**：需求變更時，立即評估對測試案例的影響範圍
- ✅ **回歸測試**：變更後執行受影響模組的完整回歸測試
- ✅ **變更記錄**：完整記錄需求變更歷史

**風險：第三方服務測試環境異常**

**應對策略**：
- ✅ **Mock Service**：建立 Mock 服務模擬第三方 API（金流、Email）
- ✅ **定期驗證**：每日驗證第三方測試環境可用性
- ✅ **錯誤處理測試**：重點測試第三方服務異常時的系統錯誤處理
- ✅ **供應商聯繫**：建立第三方服務商緊急聯絡窗口

#### 🟡 低風險應對

**風險：自動化測試開發延遲**

**應對策略**：
- ✅ **手動測試補充**：自動化未完成前，手動測試覆蓋
- ✅ **優先級開發**：優先開發關鍵路徑自動化（登入、報名、報到）
- ✅ **框架選擇**：選擇成熟且易上手的自動化框架（Playwright）

**風險：測試數據不足**

**應對策略**：
- ✅ **數據腳本**：開發測試數據自動生成腳本（Faker.js）
- ✅ **數據庫備份**：建立標準測試數據庫備份，快速還原
- ✅ **數據多樣性**：準備各種邊界情況測試數據（空值、極值、特殊字元）

### 9.3 風險監控與報告

**風險監控頻率**：
- **每日 Stand-up**：同步當日風險狀況
- **每週測試會議**：檢視風險清單，更新風險等級
- **重大風險**：立即上報至 Project Manager / QA Lead

**風險上報機制**：
- **風險等級變更**：立即通知相關人員
- **新增高風險**：24 小時內提出應對計劃
- **風險實現**：啟動應急預案，評估影響範圍

---

## 10. 測試完成標準

### 10.1 測試完成條件

#### 10.1.1 強制完成條件（Go/No-Go 關鍵指標）

| 指標 | 完成標準 | 檢查方式 |
|------|---------|---------|
| **P0 測試案例執行率** | 100% | 測試案例執行記錄 |
| **P0 測試案例通過率** | 100% | 無任何 P0 缺陷未修復 |
| **P1 測試案例執行率** | ≥ 95% | 測試案例執行記錄 |
| **P1 測試案例通過率** | ≥ 95% | 未修復 P1 缺陷 ≤ 5% |
| **P0 缺陷修復率** | 100% | 無任何 P0 缺陷未修復 |
| **P1 缺陷修復率** | ≥ 95% | Jira 缺陷追蹤報告 |
| **效能測試通過** | 100% | 頁面載入 < 3秒、掃描 < 1秒 |
| **安全性測試通過** | 100% | OWASP Top 10 全數通過 |
| **UAT 通過** | ≥ 90% | 使用者驗收問卷 |

#### 10.1.2 建議完成條件

| 指標 | 建議標準 | 檢查方式 |
|------|---------|---------|
| **P2 測試案例執行率** | ≥ 90% | 測試案例執行記錄 |
| **P2 測試案例通過率** | ≥ 85% | 未修復 P2 缺陷 ≤ 15% |
| **迴歸測試通過率** | ≥ 95% | 自動化測試報告 |
| **跨瀏覽器相容性** | 4 個主流瀏覽器全通過 | 相容性測試報告 |
| **行動裝置相容性** | iOS + Android 測試通過 | 真機測試報告 |
| **測試文檔完整度** | 100% | 所有測試交付物已提交 |

### 10.2 測試退出標準

#### 10.2.1 可以上線（Go）

滿足以下所有條件：

✅ **功能測試**
- P0 測試案例 100% Pass（519/519）
- P1 測試案例 ≥ 95% Pass
- 無任何 P0 未修復缺陷
- P1 未修復缺陷 ≤ 12 個（5%），且風險可控

✅ **效能測試**
- 頁面載入時間 < 3 秒
- QR Code 掃描速度 < 1 秒
- 支援 1000+ 並發用戶

✅ **安全性測試**
- OWASP Top 10 全數通過
- 無高風險安全漏洞

✅ **相容性測試**
- Chrome、Safari、Edge、Firefox 最新版本通過
- iOS 14+ 和 Android 10+ 測試通過

✅ **UAT**
- 用戶驗收滿意度 ≥ 90%
- 關鍵業務流程用戶驗證通過

#### 10.2.2 不可上線（No-Go）

出現以下任一情況：

❌ **阻斷性缺陷**
- 任何 P0 缺陷未修復（如無法登入、無法建立活動、付款失敗）
- P1 缺陷數量超過 15 個（6%）或存在高風險 P1 缺陷

❌ **效能問題**
- 頁面載入時間 > 5 秒
- 無法支援基本並發需求（100 用戶）

❌ **安全性問題**
- 存在高風險安全漏洞（SQL Injection、XSS、權限繞過）

❌ **數據正確性問題**
- 財務數據計算錯誤
- 數據丟失或損壞

❌ **測試覆蓋不足**
- P0 測試案例執行率 < 100%
- 效能測試或安全測試未完成

#### 10.2.3 延後上線（Postpone）

建議延後上線並進一步測試：

⚠️ **缺陷數量過多**
- P1 缺陷數量 > 15 個
- P2 缺陷數量 > 30 個

⚠️ **測試覆蓋不足**
- P1 測試案例執行率 < 95%
- 重要模組測試未完成（如報到模組、金流）

⚠️ **風險不明確**
- 存在未評估的高風險項目
- UAT 滿意度 < 80%

### 10.3 剩餘缺陷處理

**已知問題清單（Known Issues）**

上線前需產出「已知問題清單」，明確列出：

| 缺陷編號 | 優先級 | 模組 | 問題描述 | 影響範圍 | 替代方案 | 計劃修復時間 |
|---------|--------|------|---------|---------|---------|------------|
| BUG-XXX | P1 | XXX | XXX | XX% 用戶 | 手動處理 / 無替代 | v1.1（2週後） |

**上線後監控**
- 針對已知問題設定監控 Alert
- 優先處理使用者回報相關問題
- 2 週內修復所有 P1 已知問題

---

## 11. 溝通機制

### 11.1 測試溝通會議

#### 11.1.1 每日 Stand-up（Daily Stand-up）

- **時間**：每日上午 10:00
- **時長**：15 分鐘
- **參與者**：QA + PM + FE + BE
- **議程**：
- 昨日測試進度
- 今日測試計劃
- 遇到的阻礙與風險
- 缺陷修復狀況

#### 11.1.2 每週測試會議（Weekly Test Review）

- **時間**：每週五下午 3:00
- **時長**：1 小時
- **參與者**：QA + PM + FE + BE
- **議程**：
- 本週測試執行摘要
- 缺陷統計與分析
- 風險項目檢視
- 下週測試計劃
- 需求澄清與變更討論

#### 11.1.3 測試階段評審會議（Phase Review）

- **時機**：每個測試階段結束（Smoke / P0+P1 / 全部完成）
- **時長**：1-2 小時
- **參與者**：QA + PM + FE + BE + 管理層
- **議程**：
- 測試階段成果報告
- 缺陷統計與風險評估
- Go / No-Go 決策
- 下一階段計劃

#### 11.1.4 上線決策會議（Go/No-Go Meeting）

- **時機**：UAT 完成後、上線前 3 天
- **時長**：2 小時
- **參與者**：QA + PM + FE + BE + 管理層
- **議程**：
- 最終測試報告呈現
- 測試完成標準檢核
- 剩餘缺陷風險評估
- 上線決策（Go / No-Go / Postpone）
- 上線準備確認

### 11.2 測試報告發送

| 報告類型 | 發送頻率 | 發送對象 | 發送方式 |
|---------|---------|---------|---------|
| **每日測試進度** | 每日下午 6:00 | QA + PM + FE + BE | Slack / Email |
| **每週測試摘要** | 每週五下午 5:00 | 全團隊 | Email |
| **階段測試報告** | 階段完成時 | QA + PM + FE + BE + 管理層 | Email + 會議簡報 |
| **最終測試報告** | 測試結束 | QA + PM + FE + BE + 管理層 | Email + 會議簡報 |
| **緊急缺陷報告** | 發現 P0 缺陷立即 | QA + PM + FE + BE | Slack @all + Asana |

### 11.3 缺陷溝通流程

**缺陷回報**：
1. QA 發現缺陷 → 記錄至 Asana（包含重現步驟、截圖）
2. 自動通知至 Slack Channel #bugs
3. P0 缺陷額外 @PM + FE + BE

**缺陷修復**：
1. FE/BE 接收缺陷 → 評估優先級與修復時間
2. FE/BE 修復完成 → 更新 Asana 狀態為「待驗證」
3. 自動通知原 QA → 進行回歸測試

**缺陷關閉**：
1. QA 驗證通過 → 關閉 Asana Task
2. QA 驗證失敗 → 重新開啟，附上失敗原因

### 11.4 問題上報機制

**一般問題**：
- Slack Channel #qa-support
- 回應時間：4 小時內

**緊急問題**（P0 缺陷、測試環境當機、阻擋測試）：
- Slack @channel 通知所有人
- 電話通知 PM / QA
- 回應時間：1 小時內
- 解決時間：4 小時內

### 11.5 測試知識分享

**測試案例 Review**：
- 每兩週一次
- QA Team 內部互相 Review 測試案例
- 提升測試品質與覆蓋率

**Bug 分析會議**：
- 每月一次
- 分析高頻缺陷根因
- 提出流程改善建議

**測試技術分享**：
- 每月一次
- 分享新工具、新技術、最佳實踐

---

## 12. 附錄

### 12.1 縮寫與術語

| 縮寫 | 全名 | 說明 |
|------|------|------|
| **QA** | Quality Assurance | 品質保證 |
| **PRD** | Product Requirements Document | 產品需求文檔 |
| **UAT** | User Acceptance Testing | 用戶驗收測試 |
| **E2E** | End-to-End | 端到端測試 |
| **API** | Application Programming Interface | 應用程式介面 |
| **UI** | User Interface | 使用者介面 |
| **UX** | User Experience | 使用者體驗 |
| **CI/CD** | Continuous Integration/Continuous Deployment | 持續整合/持續部署 |
| **OWASP** | Open Web Application Security Project | 開放網路應用程式安全專案 |
| **XSS** | Cross-Site Scripting | 跨站腳本攻擊 |
| **CSRF** | Cross-Site Request Forgery | 跨站請求偽造 |
| **SQL Injection** | SQL 注入 | 資料庫攻擊方式 |
| **SLA** | Service Level Agreement | 服務等級協議 |
| **QR Code** | Quick Response Code | 快速響應碼 |

### 12.2 參考文檔

| 文檔名稱 | 路徑 | 說明 |
|---------|------|------|
| **產品需求文檔（PRD）** | `./FriendPass 產品需求文檔 (PRD).md` | 完整產品規格說明 |
| **測試案例總索引** | `./FriendPass 測試案例總索引.md` | 870 個測試案例導航 |
| **前台測試案例** | `./FriendPass 前台測試案例.md` | 135 個前台測試案例 |
| **後台測試案例** | `./FriendPass 後台測項.md` | 735 個後台測試案例 |
| **登入模組 PRD** | `./PRD/1. 登入模組 PRD.md` | 登入模組詳細規格 |
| **活動設定 PRD** | `./PRD/2. 概覽模組 - 活動設定 PRD.md` | 活動設定 6 步驟規格 |
| **分享活動 PRD** | `./PRD/3. 概覽模組 - 分享活動 PRD.md` | 分享連結與渠道追蹤規格 |
| **我的活動 PRD** | `./PRD/4. 我的活動模組 PRD.md` | 活動管理功能規格 |
| **報到掃描 PRD** | `./PRD/5. 報到與掃描模組 PRD.md` | 報到與掃描功能規格 |
| **數據分析 PRD** | `./PRD/6. 數據分析模組 PRD.md` | 銷售與分析功能規格 |
| **帳號模組 PRD** | `./PRD/7. 帳號模組 PRD.md` | 帳號管理功能規格 |
| **前台報名 PRD** | `./PRD/8. 前台報名流程 PRD.md` | 前台報名完整流程規格 |

### 12.3 測試工具清單

#### 測試管理工具
- **Asana** - 缺陷追蹤與專案管理
- **Excel** - 測試案例管理

#### 自動化測試工具
- **Playwright** - UI 自動化測試
- **Cypress** - UI 自動化測試（備選）
- **Postman** - API 測試

#### 效能測試工具
- **JMeter** - 負載與壓力測試
- **k6** - 現代化效能測試工具

#### 安全性測試工具
- **OWASP ZAP** - 漏洞掃描
- **Burp Suite** - 滲透測試
- **SonarQube** - 程式碼靜態分析
- **npm audit** / **Snyk** - 依賴檢查

#### 相容性測試工具
- **BrowserStack** - 跨瀏覽器與裝置測試
- **Sauce Labs** - 雲端測試平台
- **Chrome DevTools** - 響應式設計測試

#### 輔助工具
- **Jam** - 截圖與錄影
- **Faker.js** - 測試數據生成
- **Navicat** - 資料庫管理

### 12.4 測試數據範例

#### 測試帳號

【主辦方帳號】
Email: [e-mail]
密碼: Test1234!
角色：主辦方

【共編者帳號】
Email: [e-mail]
密碼: Test1234!
角色：共編者

【一般使用者】
Email: [e-mail] ~ [e-mail]
密碼: Test1234!
角色：活動參加者

#### 測試活動數據

【活動範例】
活動名稱：2025 科技論壇
活動日期：2025-12-01
活動場次：上午場（09:00-12:00）、下午場（14:00-17:00）
票種：早鳥票（NT$ 500）、一般票（NT$ 800）、VIP票（NT$ 1500）
報名人數上限：500 人

#### 金流測試數據

【測試信用卡號】（金流商提供）
卡號：4242 4242 4242 4242
到期日：12/25
CVV：123
結果：成功

卡號：4000 0000 0000 0002
結果：失敗（卡片被拒）

### 12.5 文檔變更歷史

| 版本 | 日期 | 變更內容 | 變更人 |
|------|------|---------|--------|
| v1.0 | 2025-11-10 | 初版完成，包含完整測試計劃 | QA Team |

---

## 📌 測試計劃核准

| 角色 | 姓名 | 簽核日期 | 簽名 |
|------|------|---------|------|
| **QA** | | | |
| **TL** | | | |
| **PM** | | | |
| **PO** | | | |

---

**文檔狀態**：✅ 已完成
**文檔版本**：v1.0
**最後更新**：2025-11-10
**下次審查日期**：測試階段開始前 1 週

---

> 💡 **提示**: 本測試計劃書為活文檔 (Living Document)，測試過程中如有任何變更，將即時更新並通知相關人員。