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 — 资金支付服务连接丢失

预期： 失败关闭，队列/恢复按设计，通知不引起误解。

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 · 企业日薪预支