测试小白每日训练-04

基础训练

场景设定： 银行 APP “转账到卡”功能 功能描述： 用户输入收款人姓名、银行卡号、转账金额，选择付款账户，点击“确认转账”并输入 6 位交易密码完成操作。

训练：基础功能测试

问题描述： 验证转账流程的最基本闭环，确保用户在正常路径下能成功把钱转出去。 挑战： 请列出该功能基础路径下的核心测试点（Happy Path）。

回答：

1. 功能打开正常、UI及弹窗显示正常
2. 姓名、银行卡号、转账金额、密码的输入的数据类型、输入的字符长度都做了限制
3. 密码校验功能正常
4. “确认转账”的一系列操作作为事务进行
5. 确认转账后，无论APP出现了什么异常，用户都可以通过某些地方看到交易状态反馈

评价与补充：

评价： 基础覆盖到位，特别是提到了“事务”和“状态反馈”，这说明你具备后端逻辑和用户闭环意识。

补充点：

• 余额校验（预检查）： 在输入金额后，系统是否即时校验余额是否充足？如果余额不足，“确认转账”按钮是否置灰或报错？
• 手续费计算： 金融业务中，转账往往涉及手续费。基础路径必须验证手续费计算是否正确，且总额（转账额+手续费）是否从账户扣除。
• 收款人联想/历史记录： 现在的 APP 通常会有自动联想开户行或从常用联系人选人的功能，这属于基础路径的变体。
• 短信/消息通知： 转账成功后，除了 APP 内的反馈，是否收到了银行短信或系统推送（Push）？

回答 账户状态：

1. 转账账户可以正常使用（不处于封禁、冻结...的状态）
2. 收款账户处于封禁、冻结...的状态是否有提示（我没有给封禁、冻结状态的账户转钱的经验，不太了解这些） 转账金额：
3. 金额不能为负数
4. 最小金额不为0
5. 最大金额不能超过某个数（或每日限制的转账额度、每月限制的转账额度）
6. 转账金额不能超过已有余额（如果做了这个功能限制的话）
7. 转账金额可以刚好等于当前允许转账的数值

评价与补充：

1. 评价：

• • 金额维度： 覆盖了负数、零、最大额度（日/月限额）、余额不足等关键边界。
  • 状态维度： 考虑到了双向账户的可用性，这非常棒。通常收款账户如果被冻结，后端在校验阶段会返回特定错误码（如“目标账户状态异常”），前端需展示对应弹窗。

2. 补充点：

• • 金额的“精度”边界： 金融金额通常精确到小数点后两位（分）。测试点：输入三位小数（如10.001）是否自动截断或报错？
  • 限额的“临界值”： 如果日限额是 5 万，测试：已转 49999 元后再转 1 元（刚好达到）、再转 1.01 元（微超）。
  • 单笔最小限额： 有些银行规定单笔转账不得低于 0.01 元或 1 元。
  • 账户状态的特殊细分： 除了封禁，还有“挂失”、“销户”、“过期（针对某些理财户）”、“只进不出”等状态。
  • 组合约束： 比如虽然余额充足，但超过了银行卡本身的“单日支付限额”。

回答

1. 手机突然坏了，直接死机（或没电关机）
2. 手机系统强制升级
3. 网络中断
4. 服务器崩了

评价与补充：

1. 评价：

• • 捕捉到了断电/死机和网络中断这两个最经典的问题。
  • 提到了服务器崩溃，这涉及到了接口超时和幂等性的深层逻辑。

2. 补充点（从移动端特有属性出发）：

• • 弱网/网络切换： 点击瞬间，网络从 5G 切换到弱信号 Wi-Fi，或者进入电梯。这种情况下，请求可能发出去了但没收到回包（导致重复点击或状态未知）。
  • 中断干扰（前台）： 点击瞬间弹出一个全屏电话、视频通话，或收到系统闹钟。APP 是否会因为失去焦点而导致进程挂起，从而使交易中断？
  • 快速连击： 快速点击两次“确认转账”按钮。如果没有做防重处理，是否会触发两次转账请求？
  • 本地存储满： 极少见但存在。如果转账成功的日志无法写入本地数据库或缓存，APP 是否会闪退？

下面我们进入测试意识训练（更加偏重于发散思维、用户心理和业务逻辑的潜在风险）。

今日练习：第一题

场景描述： 某理财 APP 推出了一项“自动续期”功能。用户购买的定期理财产品到期后，本金和利息会自动购买下一期同类型产品。用户可以在产品持有期间，随时通过开关来开启或关闭“自动续期”。

挑战： 如果这个“自动续期”功能的开关状态在前端显示和后端逻辑上出现了不一致（例如：用户关了开关，但后端依然自动续期了），这可能会由哪些原因导致？请尝试从测试的角度发散，列出 3 个可能的诱因。

回答

1. 用户在关开关时，出现了网络波动。而当前系统没有处理好网络波动，造成前后端不一致的情况。
2. 单纯的逻辑没处理好。
3. 用户在关闭开关状态时，点击频率过快，次数过多，导致一些请求发送失败或处理失败

评价与补充：

1. 评价：

• • 网络波动： 抓住了最核心的外部因素，即请求发出了但响应没回来，前端状态回滚失败。
  • 逻辑处理： 这是一个比较概括的说法，具体到金融业务，通常是状态机转换的问题。
  • 快速连击： 意识到了幂等性和竞态条件（Race Condition）的问题，这在开关类功能中很常见。

2. 补充点（更深层的测试意识）：

• • 多端同步（关键）： 用户可能在手机端关闭了开关，但此时平板电脑或 PC 端还处于打开状态。如果旧端的定时心跳或操作覆盖了新状态，就会产生冲突。
  • 缓存与数据库延迟（主从同步）： 后端为了性能，开关状态可能存在 Redis 缓存中。如果用户关闭了开关，数据库更新了但缓存刷新失败，而“自动续期”脚本执行时读的是缓存，就会导致错误续期。
  • 生效阈值（时间点敏感）： 理财产品到期前的“最后期限”。例如产品明天到期，规定今天 15:00 后禁止更改状态。如果用户在 14:59:59 秒点击，前端显示成功，但后端处理时已过 15:00，系统该如何裁定？
  • 版本兼容： 旧版本 APP 逻辑不支持新出的理财产品类型，导致用户在旧版操作成功，但在新业务逻辑里失效。

今日练习：第二题

场景描述： 某金融 APP 的“实名认证”流程：用户需要上传身份证正反面照片，然后进行人脸识别。

挑战： 在进行人脸识别这一步时，除了验证“是不是本人”，从**安全性（防止作弊）**的角度出发，你认为还需要测试哪些场景？（请至少列出 4 个方向）

回答 这个挺有意思，之前我实习的公司就测过人脸安全问题

1. 使用图片、视频做测试
2. 使用人头道具做测试
3. 使用橡胶人脸面具做测试
4. 双胞胎测试

评价与补充：

1. 评价：

• • 维度精准： 从 2D（图片/视频）到 3D（面具/道具），再到相似度挑战（双胞胎），覆盖了从低级到高级的物理欺诈。
  • 实战性强： 这正是金融安全等级中“抗攻击性测试”的必经之路。

2. 补充点（从“技术攻防”和“环境干扰”角度发散）：

• • 注入式攻击（软件层）： 这是目前最高级的作弊手段。测试是否可以通过 Hook 手段，跳过摄像头调用，直接将录制好的视频流“注入”给 APP 接口。
  • 光线与环境极端测试： 强光直射（过曝）、暗光（看不清）、红绿彩光。金融 APP 需要在这些环境下依然能准确区分真人与照片。
  • 活体动作随机性： 如果人脸识别要求“眨眨眼、张张嘴”，需要测试这些动作的顺序是否固定。如果固定，攻击者可以录制对应视频；如果随机，安全性更高。
  • 眼镜/遮挡/妆容： 戴墨镜、戴口罩、化浓妆（尤其是改变骨相的修容）。测试系统是否能识别出异常，或是否会因遮挡导致误判。
  • 翻拍屏幕测试： 专门针对从电脑/另一台手机屏幕翻拍。测试算法是否能通过摩尔纹（Moiré pattern）或屏幕反光识别出这并非真人现场。

今日练习：第三题

场景描述： 某银行 APP 为了提升活跃度，推出了“每日签到领积分”功能。积分可以用来兑换还款券、话费或小礼品。

挑战： 假设你在测试中发现：用户只要在签到成功后的弹窗弹出瞬间，迅速断开网络并反复点击刷新，有概率会导致后端返回多次签到成功，从而重复获得积分。

请问：

1. 这个缺陷属于什么类型的漏洞？
2. 如果你是测试负责人，除了要求修复这个漏洞，你还会建议开发在数据库设计或后台对账上做哪些优化来彻底杜绝此类“薅羊毛”行为？

回答：

1. emm...什么类型我不知道，是幂等性校验吗？
2. 布吉岛

评价与补充：

1. 评价：

• • 你提到的**“幂等性校验”**完全正确！
  • 漏洞类型： 在安全测试中，这通常被称为**“并发竞争漏洞” （Race Condition）或者更通俗地叫“重放攻击”**。即攻击者利用系统处理请求的时间差，在短时间内发送多个相同请求，试图骗过服务器。

2. 补充建议（针对你“布吉岛”的部分）： 作为测试负责人，不仅要发现 Bug，还要能给出“治本”的方案。针对金融类薅羊毛，我会给出以下建议：

• • 数据库层——唯一索引（Unique Index）： 在积分记录表里，给 用户ID + 业务类型(签到) + 日期(2023-10-27) 增加一个联合唯一索引。
  • • 效果： 就算前端发了一万个请求，数据库在插入第二条时会因为冲突直接报错，从物理上保证一个人一天只能领一次。
  • 后台逻辑——分布式锁： 在处理签到请求前，先在 Redis 里存一个“处理中”的旗标（Lock），处理完再释放。如果第二个请求进来发现旗标还在，直接拒绝。
  • 后台对账——异常预警脚本： 每天跑一个自动对账脚本，筛选出 当天积分获取次数 > 1 的异常用户。
  • • 效果： 即便系统逻辑被攻破，我们也能在 24 小时内发现并回滚这些非法积分，止损。
  • 前端控制——Loading 状态阻断： 点击签到后立即进入全局 Loading 或置灰按钮，直到收到服务器明确的“成功”或“失败”反馈。

总结

你今天的表现非常不错！

• 基础测试： 逻辑严密，对金融业务的字段校验很熟悉。
• 意识训练： 能够快速识别活体检测的物理攻击手段，对“并发”和“网络异常”造成的逻辑混乱有很好的敏感度。

以下是你今天掌握的核心知识点总结：

1. 金融级功能测试的“闭环思维”

• 不仅看前端，更看后端事务： 你意识到转账不只是 UI 的跳转，更是一个数据库事务（Transaction） ，必须保证状态反馈的最终一致性。
• 双向状态校验： 在测试账户类功能时，你学会了不仅要看“发起方”状态（是否冻结），还要看“接收方”状态，这种双向链路思维是金融测试的基石。

2. 极端环境下的“鲁棒性”测试

• 物理与系统的干扰： 你掌握了在交易瞬间模拟死机、断电、系统强制升级等极端情况，验证数据的完整性。
• 网络异常处理： 理解了在“请求已发出但未收到响应”的真空期，如何通过测试发现重复扣款或状态显示错误。

3. 金融安全与“活体检测”防范

• 物理层攻防： 通过实习经验和讨论，巩固了使用照片、视频、3D面具、双胞胎等手段对人脸识别进行攻击的测试路径。
• 进阶安全意识： 我们补充了**注入式攻击（Hook 摄像头流）和环境干扰（光线/遮挡）**的概念，这让你在安全测试上更进一步。

4. 核心技术原理：幂等性与并发控制

• 幂等性（Idempotency）： 你通过“积分签到”的案例，深刻理解了为何系统必须保证“同一个操作无论执行多少次，结果都一样”。
• 漏洞防御思维： * 数据库侧： 利用“唯一索引”做最后一道防线。
• • 缓存侧： 利用“分布式锁”防止并发操作。
  • 业务侧： 利用“对账系统”进行事后补偿和监控。

5. 测试覆盖的“边界感”

• 多维边界： 除了数值的边界（最大/最小额度），你还触达了时间边界（到期前后的临界点）和权限边界（不同账户状态的访问控制）。

建议： 你现在的逻辑已经很清晰了，但在技术深度（如：数据库如何配合测试、接口层面的并发测试）上还有很大的发掘空间。