Site Acceptance Testing，通常簡稱 SAT，是在設備、軟體、系統或整合解決方案安裝到客戶現場之後進行的正式驗證流程。它的目的，是確認交付的系統能夠在真實運行環境中正確工作，滿足專案要求，與相關系統完成整合，並已具備移交、運作或最終核準條件。
不同於發貨或部署前進行的工廠測試，SAT 更關注現場實際條件。電源供應、網路連線、環境因素、現場佈線、使用者權限、第三方介面、警報、控制邏輯、安全功能、操作人員流程以及文件資料，都要在系統真正投入使用的條件下進行檢查。
為什麼專案現場的最終驗證很重要
一個系統即使通過了工廠檢驗，安裝後仍可能出現故障，因為真實現場會引入工廠無法完全模擬的變數。纜線長度可能不同，網路規則可能更嚴格，設備間接地條件可能不同，操作人員可能採用不同流程，第三方系統的回應也可能與測試模擬器不一致。
SAT 有助於弥合這一差距。它提供了一種結構化方式，用來驗證交付方案不僅在技術上完整，而且在運營層面真正可用。對專案業主來說，它可以降低接受一個後續需要反覆改善系統的風險。對供應商和整合商來說，它形成了清楚記錄，說明哪些內容已經測試、哪些通過、哪些失敗，以及哪些仍需追蹤。
在複雜專案中，SAT 也有助於責任管理。它可以幫助區分設備缺陷、安裝問題、設定錯誤、介面問題、文件缺失、操作訓練不足，以及超出原始範圍的現場條件。
工廠測試與現場測試的區別
Factory Acceptance Testing，即 FAT，通常在系統發貨或交付之前進行。它用於檢查產品或系統是否在受控測試環境中滿足約定要求。供應商可以在部署前模擬輸入、輸出、網路鏈路、操作動作和故障條件。
SAT 發生在更後面的階段，也就是系統已經安裝到專案地點之後。它檢查同一套系統能否與真實電源、實際現場設備、真實通信鏈路、建築基礎設施、客戶網路、安全系統、控制室流程和最終使用者操作一起正確運作。
兩類測試都很有價值。FAT 降低了交付不完整或有缺陷系統的機率；SAT 則確認安裝後的系統能夠成為客戶真實環境的一部分。專案如果跳過任一階段，都可能面臨更高的調試風險。
驗收流程通常如何進行
準備與測試規劃
流程從測試計畫開始。計畫需要定義測試內容、參與人員、所需文件、測試工具、驗收標準，以及結果記錄方式。
好的計畫應與合約、技術規格書、設計文件、核準圖紙、介面要求、安全要求和專案範圍相關聯。如果缺少清楚標準，SAT 很容易從受控驗收流程變成一次非正式展示。
現場就緒性檢查
正式測試開始前，團隊會檢查現場是否已經具備條件。這可能包括供電可用性、接地、網路接入、機櫃安裝、纜線端接、環境條件、設備標籤、軟體安裝、授權啟用和基礎系統啟動。
如果現場尚未就緒，正式驗收測試可能產生誤導性失敗。例如，一套通訊平台可能看起來像設備故障，但真正問題可能只是防火牆規則被阻擋或佈線沒有完成。
功能測試
功能測試用於確認每一項要求的功能是否按專案規格運作。這可能包括正常操作、使用者登入、設備控制、警報觸發、通話路由、資料顯示、報表產生、訊號輸入、輸出控制、錄音、通知和操作人員動作。
功能測試應使用實用、清楚的語言編寫。每個測試項都應說明操作動作、預期結果、通過或失敗條件以及所需證據。這樣結果更容易驗證，也更便於日後稽核。
整合測試
許多系統都依賴其他系統。建築平台可能需要連接消防警報、門禁、CCTV、公共廣播、電梯、暖通空調、網路交換器、資料庫或第三方軟體。SAT 必須在真實條件下驗證這些介面。
隱藏問題通常出現在整合測試階段。主系統單獨運作可能正常，第三方系統單獨運作也可能正常，但它們之間的介面可能因為協定不匹配、時序延遲、位址錯誤、權限問題或資料格式差異而失敗。
效能與可靠性檢查
根據專案情況，SAT 還可能包含效能測試。這可能涉及回應時間、通話品質、吞吐量、數據更新率、警報延遲、故障切換行為、負載處理能力、錄音品質、網路延遲或重新啟動後的系統恢復。
對於支援安全、生產、通信、能源、交通、醫療、安防或公共服務的系統，可靠性檢查尤為重要。系統不應只在展示時運作一次，而應在預期運作條件下持續穩定工作。
SAT 不是走形式的最後一步，而是證明交付系統能夠在客戶真實環境中，面對真實使用者、真實介面和真實約束運作的實務證據。
檢查清單通常包含哪些項目
安裝品質
團隊會核實設備是否按照核準圖紙、現場標準、安全規則和製造商要求安裝。機櫃固定、纜線走線、標籤、接地、通風、連接器保護和實體存取條件都可能被檢查。
安裝品質很重要，因為一個系統可能通過軟體測試，但仍然因為纜線鬆動、標籤混亂、接地不良、氣流受阻或安裝不安全而存在未來可靠性風險。
設定與參數審核
設定檢查用於確認系統設定是否與專案設計一致。這些內容可能包括 IP 位址、使用者角色、分機號碼、警報臨界值、路由規則、設備名稱、時區、錄音策略、儲存路徑、存取權限和備份計畫。
設定應當形成文件。如果日後系統需要更換、恢復或擴充，未記錄的設定會讓維護變得困難。
使用者操作
SAT 應驗證系統對實際使用人員是否可用。操作人員可能需要登入、查看狀態、確認警報、撥打電話、控制設備、匯出記錄、產生報表、切換模式或執行應急流程。
這一階段常常暴露可用性落差。某項功能可能在技術上存在，但如果難以找到、標示不清或與客戶工作流程不一致，就可能需要補充訓練或調整介面。
警報與故障處理
故障和警報行為需要認真測試。系統應能檢測正確事件、顯示正確資訊、觸發預期通知、儲存事件記錄，並在故障清除後恢復正常。
警報測試在安全、安防、工業、醫療和交通環境中尤其重要。誤報、漏報、優先順序錯誤或事件描述不清，都會影響回應品質。
備份與恢復
許多系統需要設定備份、資料庫備份、日誌保留、備援電源、故障切換伺服器、備品設備或恢復流程。SAT 可以驗證備份和恢復過程是否按承諾運作。
這一部分常被忽視，因為系統在移交時看起來運作正常。然而，當出現故障、斷電、硬體更換或軟體損壞時，恢復能力會變得非常關鍵。
對專案業主和供應商的價值
降低移交風險
SAT 降低了接受不完整或不穩定系統的機率。專案業主可以在最終簽字前確認所需功能已經展示並記錄。
對供應商來說，SAT 為移交建立了明確依據。團隊不必只依賴口頭確認，而可以提供測試記錄、遺留問題清單、改善措施和驗收簽字。
及早發現現場特定問題
有些問題只有系統安裝到真實地點後才會出現。這些問題可能包括網路限制、纜線故障、供電容量不足、第三方系統不相容、現場接線錯誤、環境干擾或操作流程不匹配。
在 SAT 階段發現這些問題，比系統進入日常運作後再發現要好得多。
改善團隊之間的溝通
驗收測試會把專案業主、供應商、整合商、安裝人員、操作人員、IT 團隊、安全團隊和維護人員聚在一起。這個共同流程有助於釐清期望和責任。
當某項測試失敗時，團隊可以識別問題屬於設定、安裝、設計、現場基礎設施、第三方介面還是使用者訓練。這能減少互相指責，並提升問題解決效率。
支持文件化與合規
測試記錄、報告、檢查清單、設定檔、圖紙和驗收表單會成為專案文件的一部分。這些記錄可以支持稽核、保修索賠、後續維護、監管檢查和系統擴充。
在受監管環境中，形成文件的驗收過程與測試本身同樣重要。它證明系統在移交時已經按照明確要求進行檢查。
建立維護基準
驗收完成後，SAT 結果可以作為基準。如果系統日後表現不同，維護團隊可以將目前效能與原始測試記錄進行對比。
這對於故障排查、版本升級、硬體更換、軟體修補程式和未來擴充都很有用。
不同專案中的應用
工業自動化
工業專案使用 SAT 驗證 PLC 系統、SCADA 平台、感測器、驅動器、控制櫃、安全聯鎖、警報、操作面板和生產線功能。測試確認系統能夠與真實現場設備和製程條件配合運作。
由於工業故障可能影響生產和安全，SAT 應包括正常運作、異常條件、手動控制、急停行為、警報處理和資料記錄。
電信與網路系統
電信專案可以使用 SAT 驗證伺服器、閘道、IP PBX 平台、路由器、交換器、錄音系統、調度系統、SIP 中繼、接入設備和監控工具。團隊會檢查連通性、路由、品質、故障切換和管理功能。
基於網路的系統應使用真實 IP 位址、VLAN、防火牆規則、QoS 設定、遠端存取策略和使用者帳號進行測試，而不能只依賴實驗室設定。
建築管理與安防
建築專案會將 SAT 用於門禁、CCTV、消防警報介面、公共廣播、對講、電梯、暖通空調控制、照明控制和整合管理平台。目標是驗證不同子系統能夠協同工作。
整合尤其重要。例如，消防警報可能需要同時觸發門禁释放、攝影機彈窗、公共廣播播報和控制室事件記錄。
醫療與實驗室系統
醫院、診所、實驗室和潔淨室環境可能需要對通信系統、監控設備、門禁、環境系統、醫療支持基礎設施和數據平台進行 SAT。
測試應考慮安全、隱私、準確性、可追溯性、使用者角色和服務連續性。在這些環境中，文件品質通常非常關鍵。
能源與公用事業基礎設施
發電廠、變電站、水處理設施、油氣現場和再生能源專案會使用 SAT 確認監測、控制、通信、安全、計量和警報功能。
這些現場可能還需要額外檢查備援、接地、突波保護、環境條件、網路安全和應急回應流程。
測試期間常見的問題
安裝未完成
有些失敗是由安裝未完成造成的，而不是產品缺陷。缺少纜線、標籤錯誤、端子鬆動、接地未連接、機櫃佈線不完整或授權缺失，都可能導致測試無法通過。
客戶見證測試開始前進行預 SAT 就緒性檢查，有助於減少這些問題。
設定不匹配
設定錯誤很常見。IP 位址、使用者權限、警報臨界值、路由規則、設備 ID、時間設定、資料庫連接或協定參數，都可能與核準設計不一致。
這些錯誤通常可以較快修正，但仍應記錄下來，以便最終設定可追溯。
介面失敗
第三方介面可能因為協定差異、防火牆阻擋、憑證缺失、版本不匹配、數據對應錯誤或 API 設定不完整而失敗。
介面測試應讓連接双方都參與。一個系統能發送數據還不夠，接收系統也必須能夠正確處理。
驗收標準不清
如果測試計畫沒有定義通過和失敗條件，就可能產生爭議。一方可能認為系統可以接受，而另一方可能期待更高效能水平或不同工作流程。
清楚標準應在測試開始前達成一致。這樣可以避免移交過程中的主觀判斷。
使用者訓練不足
有時系統本身可以運作，但使用者並不知道如何操作。驗收過程中，這可能看起來像技術故障。
訓練、快速參考指南和基於角色的操作流程，應在最終移交前準備好。
許多 SAT 失敗並不是由設備損壞引起的，而是來自安裝不完整、範圍不清、文件薄弱、介面規劃不足或真實工作流程未經測試。
順利移交的最佳實務
盡早準備檢查清單。SAT 檢查清單不應在最後一刻才編寫，而應根據合約要求、技術規格、核準圖紙、使用者流程和專案風險點制定。
邀請合適人員參與。測試應包括供應商、安裝方、客戶、最終使用者團隊、IT 部門、安全團隊和維護團隊的代表單。缺少關鍵利益相關方可能延誤驗收，因為重要檢查之後可能需要重新進行。
記錄證據。截圖、照片、日誌、匯出報表、測量記錄、通話記錄、警報記錄和簽字表單，都有助於證明測試已經完成。
使用遺留問題清單。如果仍有小問題，應明確記錄責任人、優先順序、改善措施和目標完成日期。這樣專案可以繼續推進，同時仍能跟蹤未完成事項。
不要忽視反向測試。證明正常運作有效還不夠。在需要時，系統還應測試故障警報、無效輸入、斷電、通信中斷、故障切換和恢復行為。
最終報告應包含哪些內容
最終報告應包含專案名稱、系統範圍、測試日期、參與人員、測試環境、參考文件、檢查清單結果、通過專案、失敗項目、改善措施、照片或日誌、設定記錄和驗收簽字。
如果存在偏差，應形成文件。偏差可以由客戶接受，也可以在移交前修正，或加入遺留問題清單稍後完成。關鍵是不能讓偏差保持隱藏或模糊不清。
報告還應包含版本資訊。軟體版本、韌體版本、資料庫版本、圖紙版本和設定備份日期，都對未來維護有幫助。
FAQ
SAT 可以在所有現場工作完成前進行吗？
可以進行部分測試，但最終驗收通常應等到必要的安裝、佈線、設定、介面和運作條件都準備好之後。否則，測試結果可能無法反映真實系統状態。
谁應該簽署驗收報告？
簽署方取決於專案情況，但通常包括供應商或整合商、客戶代表單、專案經理、最終使用者负責人，有時還包括維護、安全或品質代表單。
如果某個測試項失敗會怎樣？
失敗應記錄原因、責任方、改善措施、優先順序和複測要求。關鍵失敗通常需要在驗收前修正，轻微問題則可在客戶同意後加入遺留問題清單。
純軟體專案也需要 SAT 吗？
需要。部署在客戶現場或雲端環境中的軟體，仍可能需要针對設定、使用者角色、整合、效能、安全、報表和操作流程進行現場驗收測試。
測試開始前應準備哪些文件？
有用的文件包括已核準的技術規格書、系統圖紙、網路規劃、I/O 清單、設定表單、使用者帳號清單、測試檢查表單、操作手册、維護指南，以及可用的前期 FAT 報告。
