测试小白打卡-05

执律度势，定鼎至臻

题目来自Gemini

基础训练题

场景设定： 外卖 APP - “确认订单”页面 功能描述： 用户从购物车点击“去结算”进入此页面。系统需综合计算商品原价、打包费、配送费、满减优惠、红包/代金券、会员权益，并支持选择送达时间、备注以及支付方式。

训练一：业务逻辑测试 问题描述： 验证多种优惠叠加后的金额计算准确性。 挑战： 假设商家设置了“满 30 减 10”的活动，用户手中有一张“满 20 减 5”的平台通用红包。在测试优惠叠加逻辑时，除了验证最终实付金额正确外，你如何验证系统对于“优惠计算顺序”的处理是符合预期的？（即：是先减商家优惠，还是先减平台红包？为什么这很重要？）

训练二：用户体验（UE）与交互测试 问题描述： 针对地址选择与配送时效的实时性反馈。 挑战： 当用户在确认订单页面停留时间过长（例如超过 5 分钟），此时商家可能歇业，或者某个商品刚好售罄。作为测试，你会关注系统在用户点击“立即支付”的那一刻，应该做出哪些**“前置校验”和“交互提示”？

训练三：数据一致性与状态流转测试 问题描述： 验证订单从“草稿”到“正式生成”的状态切换。 挑战： 用户点击“立即支付”但跳转到第三方支付渠道（如微信/支付宝）后，不输入密码直接点击返回。此时回到 APP 订单列表页，该订单应该处于什么状态？你会重点检查数据库中该订单的哪些关键字段以防出现“丢单”或“额度冻结错误”？

回答：

训练一：

1. 验证优惠券能否正确叠加。商品金额大于等于30时，30-10后，是否还会出发20-5（因为当前金额大于等于20）
2. 不知道...按理来说，用户没有指定的情况下，应该是先用商家券，再用平台券，但是我不知道怎么说

训练二：

1. 前置校验：校验当前商家是否已经到了歇业时间或商品数量是否为0，如果到了，则应该有提醒
2. 交互提示：“商家已歇业”、“当前商品已售完”
3. 这个我也不太清楚，看来还是要多练

训练三：

1. 若用户未支付密码，订单应该仍然处于未确认状态。
2. 检查支付状态、订单是否成功交易这两个字段

以下是我对你回答的评价及补充：

1. 业务逻辑测试：优惠券叠加

• 你的回答： 提到先用商家券再用平台券，但不确定原因。
• 评价： 直觉是正确的。在电商/外卖行业，通常遵循**“先由内而外”**的抵扣顺序。
• 补充遗漏点：
• • 计算顺序： 通常为：商品原价 -> 商家活动（满减/折扣） -> 店铺优惠券 -> 平台红包/代金券。这涉及到成本分摊，商家优惠由商家承担，平台红包由平台补。
  • 门槛计算基数： 测试重点是**“门槛是基于原价还是折后价”**。
  • • 场景：原价 35 元，商家满 30 减 10。减完后剩 25 元。
    • 挑战：此时 20 元的平台红包还能用吗？如果红包门槛是“实付满 20”，则可用；如果是“原价满 20”，也可用。测试必须明确门槛定义。

2. 用户体验（UE）与交互：前置校验

• 你的回答： 提到了商家歇业和售罄的提醒，方向完全正确。
• 评价： 抓住了核心矛盾点。
• 补充遗漏点：
• • 交互细节： 不仅仅是弹窗提示，最好的体验是**“自动刷新”**。点击支付时发现失效，应自动弹回订单确认页，置灰失效商品，并引导用户修改。
  • 价格变化校验： 5 分钟内，配送费可能因为天气或高峰期从 3 元涨到 7 元。点击支付前必须重新请求后台接口，校验价格一致性，若不一致需提示“价格已变动”。

3. 数据一致性：异常中断处理

• 你的回答： 订单处于未确认状态；检查支付状态和交易字段。
• 评价： 意识到了要查库，但对“金融/订单系统”的中间状态理解略显模糊。
• 补充遗漏点：
• • 状态名： 此时订单不叫“未确认”，通常叫**“待支付”**。
  • 核心字段检查： * Order_Status: 必须是“Pending/待支付”，不能是“Cancelled/已取消”或“Paid/已支付”。
  • • Stock_Lock: 必须处于**“锁库存”**状态。用户没付钱，但这几根串得先给人家留着，直到订单超时（如 15 分钟）才释放。
    • Pay_Serial_No: 检查是否生成了预支付流水号，方便后续对账。

今日练习：测试意识训练 第一题（支付安全意识）： 场景描述： 在 App 支付页面，用户可以开启“免密支付”。 挑战： 如果用户在点击开启免密支付的同时，快速点击“返回”按钮。作为测试，除了看页面有没有崩溃，你认为如何验证系统**“操作原子性”**（即要么全成，要么全败）？

第二题（数据迁移/兼容意识）：

场景描述： APP 进行了一次大版本更新，对“理财资产”的展示界面做了完全重构（从卡片式变成了列表式）。

挑战： 对于从未更新过 APP 的老用户（版本差了 3 个大版本），他们直接升级到最新版后，你认为最容易在数据展示上出现的风险点是什么？

第三题（消息触达/骚扰意识）：

场景描述： 银行 App 的“促销推送”功能。

挑战： 业务方要求针对“账户余额大于 10 万”的用户推送高收益理财广告。从测试意识出发，除了检查“推得准不准”，你认为在推送频率和用户时段上，有哪些必须考虑的“负面测试点”？

回答

第一题： 查看免密支付是否开启。 后续要做这样的测试：

1. 在点击确认开启之前断网，然后确认开启，杀死APP，打开网络并打开APP查看是否开启。
2. 在点击确认开启之后断网，杀死APP，打开网络并打开APP查看是否开启。
3. 在点击确认开启之后断网，等待5分钟后打开网络，查看是否开启。

第二题： 这个很重要，因为我之前没接触过，也没思考过

1. 客户端界面显示错误（可能因为缓存？或者太久没更新，导致UI显示错误？）
2. 如果有字段的数据结构发生变化，会导致部分数据显示异常（不知道和这个有没有关）
3. 不知道了，需要你补充一下

第三题： 负面测试点？

1. 推送频率过高的话，是否会导致服务器资源消耗太大
2. 推送时段不合理的话（例如凌晨睡觉时、第二天要返工时），会不会导致用户取消通知或删除应用

以下是对你三道题的评价与深度补充：

第一题：支付安全（原子性）

• 你的回答： 观察是否开启，并设计了多个时间点的断网与杀进程测试。
• 评价： 策略非常好！你关注到了“网络中断”和“进程终止”这两个关键触发点。
• 补充遗漏点：
• • 后端状态回滚： 原子性的核心是前后端同步。如果前端显示“已开启”，但后端接口因为你点击返回而中断，没收到指令，就会出现“前端免密，后端要密”导致支付报错。
  • 并发冲突： 快速点击“开启”和“返回”，本质是两个指令的竞争。测试需确认系统是否有Loading遮罩（防止二次点击）以及后端是否以最后一次有效指令为准。

第二题：数据迁移/大跨度升级

• 你的回答： 意识到了UI缓存和数据结构变化可能导致异常。
• 评价： 抓到了重点！数据结构（Schema）的变化是老版本跳跃升级的最大隐患。
• 补充遗漏点：
• • 字段缺失/默认值： 比如旧版只有“总资产”，新版拆分为“活期、定期、理财”。老用户升级后，如果旧数据没有正确映射到新字段，页面可能显示为 0 或 Null。
  • 本地缓存清理： 老版本在手机本地可能存有旧格式的 JSON 缓存。新版 APP 启动时，如果尝试读取旧格式缓存而没有做兼容处理（Try-Catch），会导致 APP 启动即闪退。
  • 登录态（Token）失效： 大版本更新往往涉及安全协议升级，需测试老用户升级后是否被强制登出，以及重新登录后数据是否同步。

第三题：消息推送（负面测试）

• 你的回答： 考虑到了服务器压力和用户扰民（取消通知/删应用）。
• 评价： 具备了初步的“产品意识”和“性能意识”。
• 补充遗漏点（测试视角）：
• • 时段冲突： 金融 APP 严禁在非工作时间（如凌晨 2 点）推送非紧急通知。测试应包含：当系统在凌晨触发推送逻辑时，是否会自动延迟到次日 9 点发出？
  • 状态同步： 如果用户在 APP 设置里关闭了“营销推送”，但后台因为他是“10万以上大客户”依然强发，这就是严重的合规违规。
  • 幂等性测试（重复推送）： 针对同一批次用户，如果脚本跑了两遍，用户是否会收到两条一模一样的短信/Push？这会极大地降低品牌高级感。

总结：

1. 优惠计算：看顺序

• 核心： 别只看最后金额。要查是先减“商家优惠”还是先减“平台红包”，这关乎谁出钱。
• 重点： 验证优惠门槛是基于原价还是折后价。

2. 异常中断：看状态

• 核心： 支付到一半退出、断网、闪退，不能只看页面。
• 重点： 检查后台订单是否处于**“待支付”并成功“锁库存”**，防止数据对不上。

3. 版本升级：看兼容

• 核心： 老用户连跳三级更新，最容易崩。
• 重点： 检查旧缓存是否导致新版闪退，以及旧数据能否正确映射到新界面的字段。

4. 交互细节：看校验

• 核心： 别等用户付完钱才报错。
• 重点： 点击支付的瞬间必须重查价格和库存。如果变了，要弹窗提醒，不能默认成交。