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 — 登錄會話過期/被劫持
預期結果： 要求重新驗證；舊 token 不允許交易。
10. 組 G — 交易和銀行 (41–48)
UAT 41 — 成功交易
預期結果： 一個指令碼，正確的金額/賬戶、狀態和收據。
UAT 42 — 銀行明確拒絕
預期結果： 正確的失敗狀態；可用金額按規則處理。
UAT 43 — 發送指令後超時
預期結果： 轉為等待，不自動重新支付新指令碼。
UAT 44 — 超時後延遲回應
預期結果： 更新同一交易，不創建第二筆記錄。
UAT 45 — 多次點擊發送
預期結果： 保證一個財務結果的冪等性。
UAT 46 — 錯誤的簽名/來源回應
預期結果： 被拒絕，發出安全警告；不轉為已支付。
UAT 47 — 支付服務連接丟失
預期結果： fail-closed，按設計排隊/恢復，通知不引起誤解。
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 — 敏感的 superadmin 權限
預期結果： 配置/例外操作需驗證、記錄和按規定批准。
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. 錯誤管理流程
- 使用數據和可重現的證據記錄錯誤。
- 根據實際影響分級。
- 確定處理負責人，不在各方之間推卸。
- 在受控環境中修復。
- 重新運行錯誤測試和相關回歸測試。
- 業務負責人確認結果。
- 更新文檔、運行手冊或控制措施，如果原因不僅僅是代碼。
不要僅因“無法重現”而關閉錯誤，除非已檢查日誌、數據和時間條件。
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 · 企業日薪預支