EWA 上線前的 60 個 UAT 測試場景

EWA 上線前的 60 個 UAT 測試場景：從考勤到薪資對賬

EWA 的 UAT 不僅僅是檢查“點擊提取並看到錢到賬”。系統可能在標準流程中運行良好，但在工資被修改、兩個請求同時到達、銀行超時、員工離職或薪資結算時出錯。以下 60 個測試場景幫助企業通過數據和可對比的結果來測試整個流程。

> 簡而言之： 只有當測試證明正確的人—正確的工資—正確的數字—正確的賬戶—無重複支付—可對賬—進入正確的薪資期時，才應該上線。所有與金錢、權限或個人數據相關的錯誤必須有明確的阻止標準。

> 警告： 這是一個參考測試場景庫，不能替代系統的測試計劃。未經允許，不要嘗試破壞性交易或真實數據。測試金額、賬戶和環境必須經各方批准。

1. UAT 與演示有何不同？

(查看更多：企業需要準備什麼來實施日薪預支和EWA 集成架構。)

演示顯示產品在準備好的情況下可以運行。UAT 回答產品在實際和例外條件下是否滿足已簽署的業務需求。

每個測試案例需要有：

• 編碼和目標；
• 前提條件；
• 輸入數據；
• 執行步驟；
• 預期結果；
• 實際結果；
• 證據；
• 執行者/審核者；
• 錯誤等級；
• 測試狀態和重新測試日期。

2. 準備 UAT 數據

創建受控的模擬用戶組：

• 新員工、在職、離職和調動；
• 同名但不同身份證號碼的人；
• 為一個或多個客戶工作的人；
• 正常班次、夜班、缺勤、加班；
• 正確名稱、錯誤名稱、不存在的賬戶；
• 接近限額的人；
• 成功、失敗、等待和退款的交易；
• 開放期、接近截止日期和已鎖定的期。

不要在未經批准的範圍外使用真實員工的身份證或賬戶。

3. 錯誤等級和阻止條件

等級	例子	決策
P1 嚴重	重複支付、錯誤的人、洩露密鑰/大量數據	阻止上線
P2 高	可用金額錯誤、薪資錯誤、超權限	修復並重新測試前阻止
P3 中等	錯誤通知、難用的例外流程	評估風險和修復計劃
P4 低	不影響業務的展示錯誤	經批准可放入待辦事項

最終標準必須記錄在測試計劃中，不可在上線日憑感覺決定。

4. 組 A — 檔案和使用條件 (UAT 01–06)

UAT 01 — 活躍用戶，檔案齊全

預期： 登錄並看到正確的客戶/功能已啟用。

UAT 02 — 已離職用戶

預期： 根據截止日期鎖定權限；不能創建新請求。

UAT 03 — 同名用戶

預期： 系統通過身份識別鍵區分，不混淆工資/交易。

UAT 04 — 缺少身份證或 OCR 不匹配

預期： 不允許交易；顯示處理指南，不洩露他人數據。

UAT 05 — 客戶調動用戶

預期： 調動前後的效力正確；不會錯看客戶數據。

UAT 06 — 一人多地工作

預期： 工資和可用金額正確分開；總數不重複計算。

5. 組 B — 考勤和同步 (07–14)

UAT 07 — 實時考勤應用

預期： 記錄按 SLA 出現，初始狀態正確。

UAT 08 — 合法的 Google Sheet 同步

預期： 正確匹配人員/日期/班次；報告成功行數。

UAT 09 — Sheet 行錯誤的人員編碼

預期： 列入錯誤列表，不推測分配給其他人。

UAT 10 — 重複導入同一文件/記錄

預期： 不會重複計算工資。

UAT 11 — 跨午夜的夜班

預期： 根據客戶規則正確分配班次/日期。

UAT 12 — 不同的時間/日期格式

預期： 支持的格式正確讀取；不支持的格式清楚報錯。

UAT 13 — 兩個來源的數據不同

預期： 正確應用真實來源/優先規則並發出警告。

UAT 14 — 同步任務中斷後補運行

預期： 不丟失/重複記錄；檢查點和警告正確。

6. 組 C — 審核和修改工資 (15–20)

UAT 15 — 合法監督審核

預期： 轉換狀態，保存審核人/時間。

UAT 16 — 合法客戶審核

預期： 僅影響客戶範圍內的人員。

UAT 17 — 無審核權限的人

預期： 在服務器端被拒絕並記錄。

UAT 18 — 兩方幾乎同時審核

預期： 一致的結果，不創建重複事件。

UAT 19 — 修改已審核的工資

預期： 返回待審核，保存前後狀態並根據規則更新可用金額。

UAT 20 — 當天/未來的工資

預期： 如果未滿足已結算日期的規則，則不計算。

7. 組 D — 公式和可用金額 (21–28)

UAT 21 — 基本公式

預期： 已審核工資 × 單價減去已提取和保留金額計算正確。

UAT 22 — 無已審核工資

預期： 可用金額為 0，並有易於理解的原因。

UAT 23 — 向下取整至 1,000 元

預期： 在邊界值正確，不向上取整。

UAT 24 — 期內已提取部分

預期： 剩餘金額正確減少，不重複扣除。

UAT 25 — 根據天數保留

預期： 根據配置保留最近 N 天的金額。

UAT 26 — 根據比例/門檻保留

預期： 正確應用條件；界面能解釋保留部分。

UAT 27 — 期內單價變動

預期： 每筆工資使用正確的政策或已審核規則版本。

UAT 28 — 多客戶，多單價

預期： 各地分開計算，不混淆單價。

8. 組 E — 限額和使用控制 (29–34)

UAT 29 — 低於最低限額

預期： 系統在發出命令前拒絕。

UAT 30 — 正好達到最低限額

預期： 如果滿足其他條件則接受。

UAT 31 — 每筆命令的上限

預期： 接受；超過一個單位被拒絕/正確調整。

UAT 32 — 通過多個命令超過每日上限

預期： 當日命令總數不超過政策。

UAT 33 — 兩個請求同時使用相同的可用金額

預期： 鎖定防止超支或重複支付。

UAT 34 — 限額變更生效

預期： 正確的批准人、正確的生效日期並有審計記錄。

9. 組 F — 賬戶、設備和身份識別 (35–40)

UAT 35 — VPBank 賬戶名稱正確

預期： 驗證成功並適當顯示遮罩。

UAT 36 — 賬戶名稱錯誤

預期： 不允許使用，提供處理指南。

UAT 37 — 賬戶不存在/無法查詢

預期： 保持未驗證狀態，不允許支付。

UAT 38 — 嘗試更改已鎖定的賬戶

預期： 用戶不能自行更改流程外；所有例外需批准/記錄。

UAT 39 — 在第二台設備上登錄

預期： 正確應用一人一機政策和設備更換流程。

UAT 40 — 登錄會話過期/被劫持

預期： 要求重新驗證；舊令牌不能創建交易。

10. 組 G — 交易和銀行 (41–48)

UAT 41 — 成功交易

預期： 一個命令碼，正確的金額/賬戶、狀態和收據。

UAT 42 — 銀行明確拒絕

預期： 正確的失敗狀態；可用金額按規則處理。

UAT 43 — 發送命令後超時

預期： 轉為等待，不會自動重新支付新命令。

UAT 44 — 超時後延遲回應

預期： 更新同一交易，不創建第二筆資金記錄。

UAT 45 — 多次點擊重新發送

預期： 保證唯一的財務結果。

UAT 46 — 回應簽名/來源錯誤

預期： 被拒絕，發出安全警告；不轉為已支付。

UAT 47 — 支付服務連接丟失

預期： 失敗關閉，按設計排隊/恢復，通知不誤導。

UAT 48 — 緊急停止開關

預期： 阻止新命令；等待中的交易被保護；重新啟動需要權限和記錄。

11. 組 H — 對賬和薪資 (49–55)

(詳情：見EWA 與薪資和會計的交易對賬。)

UAT 49 — 完全匹配的對賬單

預期： 所有交易正確匹配並標記對賬。

UAT 50 — 系統上有，對賬單上缺少

預期： 生成例外，不自動結論或無證據修正。

UAT 51 — 對賬單上有，系統上缺少

預期： 從銀行方向檢測到系統並轉交調查。

UAT 52 — 金額錯誤/重複命令碼

預期： 不強制匹配；必要時發出警告並鎖定。

UAT 53 — 將交易納入薪資

預期： 僅成功交易，正確的人/客戶/期。

UAT 54 — 接近截止日期的交易

預期： 正確應用期規則並能解釋橋接報告。

UAT 55 — 工資日已覆蓋

預期： 不會累積到下一期；工資單和交易總額匹配。

12. 組 I — 權限、數據和運營 (56–60)

UAT 56 — 客戶交叉查看數據

預期： 無法訪問其他客戶的人員/工資，即使修改 URL/API。

UAT 57 — 敏感的超級管理員權限

預期： 配置/例外操作需驗證、記錄和按規定批准。

UAT 58 — 報告導出和數據遮罩

預期： 正確的範圍；身份證/賬戶被遮罩；導出文件受控。

UAT 59 — 投訴“扣款但未收到”

預期： 客服正確查找命令碼，查看足夠證據，不要求通過不安全渠道發送數據。

UAT 60 — 故障後恢復

預期： 服務按目標恢復；不丟失/重複交易；對賬確認最終狀態。

13. 預設日薪預支配置的邊界測試

如果客戶試點使用代碼中的預設值，應至少檢查：

參數	低於邊界	正好邊界	高於邊界
每次最低	49,000	50,000	51,000
每筆命令上限	2,999,000	3,000,000	3,001,000
每日上限	4,999,000	5,000,000	5,001,000
四捨五入	99,999	100,000	100,001

上述數字是技術預設，並非對所有客戶的應用承諾。測試計劃必須在試點環境中使用真實配置。

14. UAT 證據矩陣

組別	最低證據
檔案	源數據、結果屏幕、同步日誌
工資	前後記錄、審核人、審計跟踪
公式	獨立計算表和系統結果
賬戶	已遮罩數據的驗證結果
交易	命令碼、狀態時間線、有效日誌
銀行	回應和測試對賬單
薪資	輸入文件、橋接報告、樣本工資單
權限	權限矩陣和被阻止的訪問嘗試
故障	時間線、警告、運行手冊和恢復結果

單獨的屏幕截圖不足以證明端到端流程。

15. 上線條件建議

(上線後：見EWA 上線後的運營。)

• 100% 的 P1/P2 測試場景已運行並通過；
• 不再有可能錯誤支付、重複支付或超權限的錯誤；
• 試點樣本的工資、交易、對賬單和薪資匹配；
• 所有 P3 錯誤已評估風險，有負責人和修復期限；
• 生產配置已獨立檢查；
• 試點用戶/客戶名單準確；
• 金額限額和停止開關已批准；
• 銀行、HR、薪資、安全和客服的聯絡人已準備就緒；
• 監控/警報運行正常；
• 回滾和通信計劃已演練。

不要機械地設置“60/60”條件，如果某些測試不適用，必須記錄排除原因和批准人。

16. 錯誤管理流程

1. 使用數據和可重現的證據記錄錯誤。
2. 根據實際影響分級。
3. 確定處理負責人，不在各方之間推卸。
4. 在受控環境中修復。
5. 重新運行錯誤測試和相關回歸測試。
6. 業務負責人確認結果。
7. 如果原因不僅是代碼，更新文檔、運行手冊或控制措施。

不要僅因“無法重現”而關閉錯誤，未檢查日誌、數據和時間條件前。

17. 常見問題

誰應該簽署 UAT 報告？

應包括業務負責人、產品/供應商負責人以及受影響領域的代表，如 HR/薪資、財務、IT 或安全，根據 RACI。

UAT 時需要轉賬真錢嗎？

優先使用沙盒或已批准的試點賬戶/金額。如果需要測試生產環境，必須限制範圍，有監督，立即對賬並有停止方案。

單元測試多是否可以替代 UAT？

不可以。單元測試檢查組件；UAT 證明流程滿足用戶需求和政策，並使用接近真實的數據。

小錯誤會阻止上線嗎？

視影響而定。展示錯誤可能不會阻止；錯誤導致金額誤解、數據洩露、權限錯誤或影響對賬的必須嚴格評估。

上線後需要重新運行 UAT 嗎？

當公式、限額、工資來源、銀行、薪資、權限、基礎設施或有顯著影響的版本發布時，需要進行回歸測試。

---

作者： Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

企業日薪預支解決方案諮詢： 熱線 0937.022.655 · 電郵 info@nhankiet.vn · 企業日薪預支