执律度势，定鼎至臻
第一阶段：基础训练
场景设定： 电子票务系统的“优惠券码兑换”功能 功能描述： 用户在输入框输入 8 位字母数字混合的兑换码，点击“兑换”后，账户内增加相应的优惠券。
训练：基础功能测试
问题描述： 验证兑换码核销的基础逻辑。
挑战： 请给出 3 条 能够验证该功能“核心业务流程已实现”的测试用例。
回答：
- 2分钟内可以撤回消息
- 成功撤回后，显示“XX撤回了一条消息”
- 发消息1分59秒后，撤回消息
- 刚刚超过2分钟，撤回消息
- 在2分钟内弹出弹窗选择，等超过2分钟再选择“撤回”
- 撤回消息失败，有没有提示
评价与补充：
评价：
亮点： 你的第 3、4、5 点非常出彩。特别是第 5 点（卡在临界点打开弹窗再操作），这是典型的状态机测试，能有效发现前端倒计时和后端权限校验不一致的问题。
- 不足： 基础测试中漏掉了最基本的对象兼容性（比如文字能撤回，图片、表情包、语音、文件能撤回吗？）。
补充遗漏点：
- 多端同步： 手机端撤回后，电脑端（或网页端）是否同步消失并显示撤回提示？
- 状态可见性： 如果对方正在看聊天框，撤回时对方屏幕是否实时更新（无需退出重进）？
训练：边界与约束测试问题描述： 针对“2分钟”这个时间限制和“消息内容”本身进行边界挖掘。 挑战： 除了你刚才提到的时间边界，请给出 2 个关于“撤回对象”或“撤回状态”的边界测试场景。
回答：
emm...不太清楚
内容的“边界”： 撤回一条**正在发送中（转圈圈）**的消息。
- 逻辑： 此时消息还没完全到达服务器，撤回操作是否会导致程序崩溃或显示异常？
身份/状态的“约束”： 在群聊中，群管理员撤回普通成员的消息。
- 逻辑： 约束不仅是针对自己的动作，还涉及权限。管理员撤回后，提示语是“管理员撤回了成员消息”还是“你撤回了一条消息”？
群管理员撤回时，对方刚好撤回了消息
今日练习：第一题
场景描述： 你负责测试一个电商 App 的“购物车”页面。现在产品经理提出了一个新需求：在购物车页面增加一个**“猜你喜欢”**的商品瀑布流，放在所有已添加商品的下方。
挑战： 作为测试，你认为引入这个新模块后，除了测试“猜你喜欢”本身好不好用，最需要担心（测试）它对原有购物车功能造成的哪个潜在影响？ （请给出一个你认为最严重的风险点）。
回答：
猜你喜欢的商品，会不会被计入购物车价值计算当中
评价与补充
- 评价：
-
- 亮点： 你的切入点非常专业。在开发层面，如果底层代码复用了同一个“商品列表”的逻辑，确实极容易发生数据混淆。这直接关系到用户的钱袋子，是最高优先级的 Bug。
- 深度： 这种意识叫作**“回归测试意识”**——关注新功能是否破坏了老功能的正确性。
- 补充遗漏点（全局意识）：
-
- 性能压力（滑不到底）： “猜你喜欢”通常是无限滚动的加载。如果加载过多，会不会导致购物车页面卡顿，甚至让用户无法点击底部的“去结算”按钮？
- 视觉干扰： 当购物车为空时，这个模块会不会反客为主，让用户误以为自己已经把这些商品“加入”购物车了？
- UI/UX 遮挡： 在小屏幕手机上，这个新模块是否会遮挡原有的优惠券领用或客服入口？
今日练习：第二题
场景描述： 公司要做一个**“年度账单”**功能（类似网易云或支付宝年度报告）。这个功能需要调取用户过去一整年的消费数据、足迹数据。由于数据量巨大，该功能仅计划在元旦期间上线 7 天。
挑战： 这种**“短期高并发、大数据量调取”的功能，你认为测试时最需要关注的非功能性指标**是什么？（或者说，你最怕上线那天发生什么服务器层面的事故？）
回答：
要关注服务器的处理能力，防止上线当天因为活动太火爆，导致服务器崩溃
评价与补充
- 评价：
-
- 亮点： 你的直觉很对。对于这种有时效性的“爆款”功能，**服务器宕机（崩溃）**就是最大的事故。如果用户点不开，这个功能做得再漂亮也是零分。
- 意识： 你具备了**压力测试（Load Testing）和并发（Concurrency）**的意识。
- 补充遗漏点：
-
- 数据延迟与超时： 由于要调取一整年的大数据，如果查询 SQL 没优化，数据库可能会瞬间被“憋死”，导致用户界面一直显示“加载中...”，最后报错。
- 降级（Fallback）预案： 万一服务器真的扛不住了，有没有“熔断”机制？比如提示用户“由于火爆，请稍后再试”，而不是直接白屏或让整个 App 瘫痪。
- 缓存失效（Cache Stampede）： 元旦零点大家一起点开，如果缓存在那一刻失效，所有请求直接冲击数据库，这就是可怕的“缓存雪崩”。
今日练习：第三题（最后一题）
场景描述： 你现在要测试一个金融 App 的**“强制实名认证”**功能。 需求规定：如果用户没实名，点击“转账”、“理财”、“红包”等任何涉及金钱的按钮，都必须强制弹窗跳到实名页面。
挑战： 这种**“全局拦截”的功能，测试起来最容易漏掉哪种场景？（提示：从“路径跳过”**的角度想想，有没有什么办法能绕过这个弹窗直接把钱转出去？）
回答
不太会
答案解析：绕过拦截的 3 种常见招式
- 多端/多入口漏洞： 你测试了点击“转账按钮”会弹窗，但如果用户通过**“最近转账记录”直接发起呢？或者通过“语音助手（嘿 Siri，转账给XX）”**发起呢？这些非主流入口最容易漏掉拦截逻辑。
- 后台进程恢复： 用户先进入转账页面（此时已实名或状态异常），然后把 App 挂在后台，去系统设置里撤销实名权限，再回到 App。此时页面已经打开，如果不点击按钮而是直接操作，拦截器还会生效吗？
- 深层链接（Deep Link）： 外部如果有个网页链接，点击后直接跳转到 App 内部的转账二级页面，是否会因为跳过了首页和中间路径，导致拦截弹窗没触发？
全局总结与建议
在今天的训练中，我发现你的测试直觉表现如下：
- 强项： 你对业务逻辑的闭环和关键边界值（特别是时间边界）非常敏感。
- 进阶方向： 以后可以多往**“关联性” （新功能对旧功能的影响）和“权限绕过”**（如果不按规矩走会怎样）去思考。
【今日任务达成！】
你已经完成了：
- 1 道基础训练（消息撤回）
- 3 道意识训练（购物车、年度账单、实名拦截）
