系統測試是在開發完成後，把整個系統或產品當成一體，驗證它的整體行為與能力是否符合需求規格的測試層級，常同時包含端到端作業的功能測試，以及效能、安全等品質特性的非功能測試；之後再由實際使用者進行使用者驗收測試（UAT），確認系統可以上線。企業端在驗收前要確認三件事：測試依據是需求文件裡的驗收條件，每個缺陷都有紀錄、修正與複測結果，修正後做過回歸測試，確認變更沒有影響原本正常的功能。
系統測試的定義：把整個系統當成一體驗證
國際軟體測試資格委員會（ISTQB）的基礎級課綱說明，系統測試著重在整個系統或產品的整體行為與能力，常包含端到端作業的功能測試與品質特性的非功能測試；它可以由獨立的測試團隊執行，依據的是系統的規格。也就是說，系統測試不是檢查某一支程式寫得對不對，而是從使用者與業務流程的角度，確認前台、後台、資料庫、通知與外部串接組合起來後，是否照需求運作。
企業端可以要求廠商提供測試計畫與測試案例清單：需求文件裡每一條驗收條件，都應該對應到至少一個測試案例，案例寫明前置條件、操作步驟與預期結果，執行後記錄實際結果。先確認範圍沒有漏掉重要流程，再安排自己的驗收時程。
測試層級：從元件、整合、系統到驗收
| 層級 | ISTQB 課綱的重點 |
|---|---|
| 元件測試（單元測試） | 單獨測試個別元件 |
| 元件整合測試 | 元件之間的介面與互動 |
| 系統測試 | 整個系統或產品的整體行為與能力 |
| 系統整合測試 | 受測系統和其他系統、外部服務之間的介面 |
| 驗收測試 | 確認是否符合使用者的業務需求、是否可以部署上線 |
課綱把驗收測試的主要形式列為使用者驗收測試、營運驗收測試、合約與法規驗收測試，以及 Alpha 與 Beta 測試。企業端不必參與每一層，但可以請廠商說明各層的範圍與完成條件，並在進入使用者驗收前，拿到系統測試的結果摘要。
功能測試：測試案例要涵蓋的情境
功能測試評估系統應該執行的功能是否正確。測試案例不只走一次正常流程，還要涵蓋：
- 邊界值：欄位長度上限、數量的上下限、日期跨月與跨年，例如預約系統在月底、優惠券在到期當天。
- 角色與權限：列出每個角色能看、能改、能刪的項目，用不同帳號逐一確認，包括直接輸入網址能否看到不該看的資料。
- 計算正確性：金額、稅額、折扣、庫存扣減與點數，用事先算好的答案比對。
- 狀態流轉：訂單、簽核、預約在各狀態間的轉換，以及取消、退回、逾期後的處理。
- 通知與輸出：電子郵件或推播的內容與收件對象，報表與匯出檔的欄位。
- 裝置與瀏覽器：依需求文件列出的手機、平板與瀏覽器組合實際操作。
系統整合測試：外部服務與 API 串接
企業系統常會串接金流、電子發票、物流、通訊平台或既有的 ERP。ISTQB 課綱把受測系統和其他系統、外部服務之間的介面測試列為系統整合測試。除了確認資料格式與流程一致，也要測異常情況：
- 對方服務回應錯誤或逾時，系統是否顯示清楚的訊息，資料是否停在可以重試的狀態。
- 同一筆通知重複送達時，會不會重複建立訂單或重複扣款。
- 付款成功但訂單仍顯示未付款這類不一致，誰會收到通知、怎麼補正。
- 測試用的金鑰與帳號和正式環境分開，上線時切換正確。
API 回應的狀態碼代表什麼、驗收要看哪些規格，可參考RESTful API 的狀態碼與驗收重點。外部服務若提供測試環境或沙盒帳號，整合測試先在那裡完成，上線時再做少量的確認操作。
效能測試：負載測試與壓力測試的差別
以 Microsoft Azure 架構完善框架的效能測試說明為例，負載測試用來驗證系統在正常及尖峰使用時能否處理預期的使用者量；壓力測試則用來了解系統的極限與臨界點。同一份說明也建議測試環境盡可能接近正式環境，並把初次測試的效能指標記錄成基準，後續測試再和基準比較。
規劃時先在需求文件寫下預期情境，例如活動開賣時同時下單、報名截止前的尖峰，再決定觀察的指標：主要操作的回應時間、負載下的錯誤率，以及處理器、記憶體與資料庫連線的使用狀況。效能測試會對主機送出大量請求，執行前要先確認主機或雲端服務商的規範，並避開營業時段。頁面載入速度與 Core Web Vitals 屬於另一種檢測，做法見網站效能檢測的工具與指標。
安全測試、確認測試與回歸測試
安全是非功能測試要評估的品質特性之一。Open Worldwide Application Security Project（OWASP）的網頁安全測試指南，把測試項目分成資訊蒐集、組態與部署管理、身分管理、驗證、授權、工作階段管理、注入、錯誤處理、弱加密、業務邏輯、用戶端與 API 測試等類別，可以作為和廠商討論範圍的參考。更深入的弱點掃描或滲透測試，可另外委請專業單位執行。
缺陷修正後要做兩種測試：確認測試確認原本的缺陷已經修好；回歸測試確認這次變更沒有造成其他不良影響。ISTQB 課綱也指出，回歸測試會重複執行很多次，案例通常隨每次改版增加，很適合自動化，所以常用的測試案例值得整理成固定清單。
使用者驗收測試（UAT）怎麼安排
ISTQB 課綱說明，驗收測試理想上應由預定的使用者執行。安排時可以依序進行：
- 挑選測試者：每個角色都要有人參與，包括一般人員與負責簽核的主管。
- 準備情境腳本：以實際工作為單位，例如「接到電話訂單，建立訂單並安排出貨」，不要只列功能名稱。
- 使用接近真實的資料：在與正式站分開的網站測試環境進行，涉及個資的資料先去識別化。
- 統一回報格式：記錄操作步驟、預期結果、實際結果、截圖與嚴重程度，方便廠商重現。
- 確認與簽核：缺陷修正後由原回報者複測，驗收條件全部通過後雙方簽核。
介面好不好用、使用者會不會卡住，屬於可用性測試的範圍，可以在設計階段另外進行。
驗收前檢查清單
- 文件：測試計畫、測試案例與執行結果、缺陷清單都已提供，每個缺陷都有狀態。
- 功能：需求文件中的驗收條件逐條對應到測試案例並通過。
- 缺陷：嚴重與高等級缺陷已修正並複測；允許帶著上線的低等級缺陷，已書面確認處理期限。
- 資料：轉入的舊資料已核對，測試資料已從正式環境清除。
- 效能與安全：測試結果已提供，未通過的項目有改善計畫。
- 上線準備：正式環境備份、回退步驟、監控與告警已設定，管理員帳號已移交企業。
清單逐項確認後再簽驗收，日後對範圍或缺陷責任有疑問時，才有可以對照的紀錄。
常見問題
系統測試和使用者驗收測試有什麼不同？
系統測試依系統規格驗證整個系統的行為與能力，可由獨立的測試團隊執行；使用者驗收測試理想上由預定的使用者執行，確認系統符合業務需求、可以上線。
小型專案也需要寫測試案例嗎？
需要，只是可以精簡。至少把每條驗收條件寫成一個測試案例，包含操作步驟與預期結果，驗收時逐條執行並記錄結果，避免上線前才爭論功能有沒有做完。
測試發現的缺陷要怎麼分級？
可以依影響程度分成嚴重、高、中、低：系統無法使用或資料錯誤列為嚴重，主要功能異常但有替代做法列為高，介面或文字問題列為中低。分級標準要在測試前和廠商約定。
可以直接在正式網站上測試嗎？
不建議。在正式環境測試可能產生假訂單、寄出測試通知給真實顧客，或影響正在使用的人。應在與正式站分開的測試環境完成，上線時只做少量確認。
上線後還需要測試嗎？
需要。每次修改功能、更新外掛或套件、調整串接後，都要對受影響的功能做回歸測試，確認變更沒有造成不良影響，並把常用的測試案例整理成固定清單。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
系統開發或改版進入尾聲時，先把需求文件裡的驗收條件整理成測試案例清單，指定各角色的測試者，並和廠商約定缺陷分級與複測方式，驗收才有共同的依據。
京采的網頁設計服務涵蓋網站與系統的規劃、開發、測試、驗收與上線，可以協助整理驗收清單、建立測試環境並安排上線切換。想討論專案的測試與驗收安排，歡迎與我們聯繫。
