z-notes

1.UAT基础认知：

• 定义：UAT（User Acceptance Testing）是系统上线前的“最后防线”，由业务代表/真实用户执行，验证系统是否符合业务需求。
• 核心原则：用业务语言写场景，不用技术脚本；在类生产环境中使用真实/脱敏数据进行测试。

2.UAT全流程技能：

• 规划与准备：明确验收标准（Acceptance Criteria）、搭建独立UAT环境、导入脱敏历史数据。
• 用例设计：覆盖核心业务流（Happy Path）与异常流（Edge Cases，如无效数据、断网）。
• 执行与缺陷管理：记录详细复现步骤、截图/录屏/日志；开发修复后进行回归测试。
• 常见坑点规避：避免“UAT挤压”（上线前最后两天才测）、避免使用纯假数据（如Test User买0.01元商品）、避免由开发/QA代替代替业务用户测试。

3.沟通与协作软技能：

作为业务与IT的“桥梁”，需具备将业务痛点转化为测试场景的能力，并用开发能听懂的语言提交缺陷。

4.案例学习：

4.1.场景1：新单FNA合规校验

4.1.1规则：

1.按保监局GL30：卖寿险/医疗险前，必须让客户填《财务需要分析（FNA）问卷》+签字，上传到系统才能进核保/出单（硬卡死，没有商量）
2.按保监局GL27：如果客户买新单是为了替换旧保单（比如退旧重疾买新的），系统必须弹警示，要代理人填「替换原因」+客户签「知悉风险」，才能继续
3.系统里的对应元素：FNA是附件上传框、签名是电子签区域、替换保单是1个勾选框

4.1.2模拟操作

【页面：投保信息页】
□ 客户姓名：陈XX  年龄：35
□ 选择产品：危疾加护保（美元）
□ 勾选框：是否替换现有保单？（旧单号：_________）
□ 上传附件：FNA问卷（必填）、客户签名（必填）
□ 按钮：「下一步 进入核保」

现在做3次操作，记录结果：

1. 操作A：不传FNA、不传签名→点下一步→系统弹“请上传FNA及签名”，卡住 ✅（符合规则）
2. 操作B：勾选“替换旧单”，不填旧单号、不写替换原因→点下一步→弹警示“需填替换原因+客户签风险确认”，卡住 ✅（符合规则）
3. 操作C：传了FNA、没传签名→点下一步→系统直接跳去核保页，显示“待核保” ❌（这是你要提的Bug）

4.1.3.UAT用例

4.1.4.缺陷报告

【标题】新单模块：未传FNA签名仍允许进核保，违反IA GL30
【等级】高（合规风险，会被保监局罚）
【复现步骤】
UAT环境登test_agent账号
新建危疾单，年龄35，只传FNA问卷，不上传签名
点「下一步进入核保」
【预期】弹窗要求传签名，流程终止
【实际】跳转至核保页，状态=待核保
【业务影响】前线可绕过签名出单，上线后客户投诉/监管处罚风险极高
【技术备注】/api/newPolicy/submit接口未校验signature_file非空，请加校验

4.2.场景2：自动核保（Auto-Underwriting）边界值验证

测试目标：验证系统能根据受保人年龄、健康告知及保额，准确触发自动核保结论或转人工复核，符合香港保险核保规则。

4.2.1.规则

1.香港自愿医保（VHIS）规定：受保人≤65岁走简易核保（系统自动过），≥66岁必须转人工核保
2.健康告知勾“高血压/糖尿病”→系统自动加“医疗责任除外”条款
3.总保额≥500万港币→自动转人工复核（再保前置要求）

4.2.2.模拟操作

【核保页】
□ 受保人年龄：___（填66）
□ 健康告知：□无异常 □高血压 □糖尿病
□ 总保额：600万港币
□ 按钮：「提交核保」

4.2.3.UAT用例

4.2.3.缺陷报告

没有