基础训练
场景设定： 综合电商APP - “限时秒杀”功能 功能描述： 某个热门商品在特定时间点（如10:00）开启秒杀。商品库存仅有10件，每个用户限购1件。下单流程为：点击“抢购” -> 提交订单 -> 支付（5分钟内完成）。
训练：竞态条件与公平性测试 问题描述： 在极短时间内，成千上万个请求涌入，必须保证不超卖、不重卖，且逻辑公平。 挑战： 1. 如何通过测试手段验证系统在高并发下，不会出现“库存变为负数”或“10个库存卖给了11个人”的情况？ 2. 如果用户在“提交订单”后、支付前取消了订单，你会关注哪些数据的回滚和同步？
回答：
- 用jemeter模拟？
2.关注库存、用户账户是否被扣款
回答评价与补充
- 评价： 抓住了核心工具（JMeter）和核心数据（库存/扣款）。但在“如何测”和“测什么”的细节上，还需要更严密的逻辑支撑。
- 补充遗漏点：
-
- 秒杀瞬时并发： 使用JMeter时，不能只是简单的循环。需要配合 Synchronizing Timer（集合点） ，确保所有线程在同一秒（甚至毫秒）触发“提交订单”请求，这才是真正的压力测试。
-
- 幂等性测试： 用户狂点“抢购”按钮，或者网络波动导致前端重发请求，后端是否能保证同一个用户只生成一个订单？
-
- 库存锁定的生命周期： * 预扣库存： 提交订单瞬间库存减1。
-
-
- 释放库存： 5分钟不支付，库存必须立刻加回。
-
-
-
- 支付回调： 支付成功后，库存状态是否由“锁定”变为“已售”。
-
-
- 数据库与缓存（Redis）一致性： 这种场景通常先扣缓存，再异步写数据库。如果缓存扣了但数据库没扣（或反之），就会造成数据灾难。
测试意识训练
今日练习：第一题
场景描述： 某APP上线了一个“新老用户拉新”活动。
- 规则： 老用户成功邀请一名新用户（实名且首单满10元），老用户可得20元现金奖励，新用户得50元大礼包。
- 背景： 该活动通过H5页面在微信、微博等社交平台传播。
挑战： 如果你是这个项目的测试负责人，在“防刷/防薅羊毛”这个意识维度下，你会针对哪些隐蔽的风险点进行测试设计？（请不要只说“校验手机号”，试着从设备、网络、账号关联等角度思考）。
回答
emm...这个还真不会。
检查设备IP？
你提到的 IP检查 是入门级的第一步，但对于现在的羊毛党来说，他们可以用代理IP池轻松绕过。
🛡️ 针对“拉新防刷”的意识补充
为了帮你建立这种“对抗性”的测试思维，我补充几个资深测试会关注的点：
- 设备指纹（Device Fingerprint）： 检查同一台手机是否登录了多个账号进行邀请或被邀请。即使换了IP，手机的硬件标识（如IMEI、UUID）是很难彻底清洗的。
- 账号关联性分析：
-
- 支付账号： 不同账号领奖，最后提现是否都到了同一个支付宝/微信钱包？
-
- 实名信息： 身份证号是否重复？
- 行为特征识别： 正常用户会浏览页面、看详情；脚本机器人往往是“秒进、秒点、秒退”。
- 恶意退款拦截： 比如新用户为了让老用户拿20元奖励，下单10元后立刻退款。系统是否能自动追回或冻结已发放的奖励？
今日练习：第二题
场景描述： 某APP接入了三方支付（如支付宝、微信）。
- 功能： 用户购买会员，点击支付后调起微信APP。
- 动作： 用户在微信支付界面输入密码前，突然切换到后台去回复信息，过了两分钟再切回支付界面完成支付。
挑战： 1. 在这个“切换”的过程中，你觉得最容易出问题的状态转换是什么？ 2. 如果用户在微信里付完款了，但切回APP时APP闪退了，你该如何验证这笔钱没丢，且会员权益正常发放了？
回答
1.我只知道这种情况一般会卡死或者输入密码的界面消失
2.从数据库里看
评价与思维补全
- 针对第1点（界面与状态）： * 现象： 你提到的“界面消失”在Android开发中很常见（Activity被系统回收）。
-
- 深度意识： 核心问题在于**“订单有效期” 。如果用户在后台切太久，支付平台的Token可能失效了，此时用户再付钱，可能会出现“钱扣了，但支付平台通知APP时，APP认为订单已超时关闭”的情况。这就是典型的单边账**风险。
- 针对第2点（验证手段）：
-
- 手段： “看数据库”是终极大法，没错。
-
- 深度意识： 但在线上环境，你没法实时看数据库。你需要验证的是**“补单机制” 。当APP闪退时，后端应该有一个主动轮询（Polling）**机制。即使APP没切回来，服务器也应该定时去问支付平台：“刚才那个订单到底付钱没？” 只要付了，权益就该自动到账。
今日练习：第三题
场景描述： 某银行APP上线“转账预约”功能。
- 功能： 用户可以设定在未来的某一天（比如下周一上午9:00）自动给某个账户转账5000元。
- 设定： 用户在今天（周五）设置好了预约。
挑战： 如果你是测试，你会如何设计“时间跨度”上的异常场景？请至少列举出 2个 发生在周五到下周一这段“等待期”内，可能导致周一转账失败或产生逻辑混乱的业务变动情况。
回答
1.时间跨度上的差异：跨天、跨周、跨月、跨年（也就是时间格式有大的变动时）
2.用户余额不足
3.用户账号注销、银行卡冻结...
4.用户提前给某账户转账了，是否会导致转账预约误判
5.服务器停服
6.因为跨年导致程序逻辑混乱，判定预约转账时间+1年
评价与思维升华
- 评价： * 你考虑到了时间维度（跨年、跨月）和账户状态（余额不足、注销），这是基础中的基础，非常稳。
-
- 第4点（提前转账）和第6点（日期偏移）非常有灵气，属于业务关联性和逻辑漏洞的范畴，这正是高级测试需要的“坏心眼”。
- 补充遗漏点：
-
- 预约修改与撤销： 周五预约了，周六能不能改金额？周日能不能取消？如果周一 8:59 取消，系统会不会因为处理延迟依然转账了？（并发与撤销的临界点）
-
- 重复执行： 这是一个经典Bug。由于服务器在周一 9:00 重启或网络重试，导致这一笔预约转账被执行了两次。
-
- 风控规则变更： 周五设置时限额是5万，周日银行突然下调限额到3000，周一转5000时，系统是按“下单时”还是“执行时”的风控规则走？
练习总结
今天我们从基础功能、高并发秒杀、防薅羊毛、支付中断一直练到跨时空业务逻辑。
给你的进阶建议： 你现在的思维已经能覆盖到“点”和“线”了。接下来的目标是建立**“面”**。
- 点： 界面和基本逻辑。
- 线： 整个业务链路（比如从预约到执行到账）。
- 面： 业务之间的互相影响（比如转账和限额、转账和退款、转账和系统升级）。
