测试小白的测试意识训练打卡-01

执律度势，定鼎至臻。

题目来自Gemini

测试意识训练：第一题

【场景描述】： 用户在你的 App 里发起一笔认购，调用了 MetaMask 或内置钱包进行签名支付。就在用户点击钱包弹窗中的**“确认签名”那一刻，由于各种原因（可能是焦虑，也可能是误操作），他突然手动杀掉了你的 App 进程**。

【挑战】： 站在技术与产品逻辑的角度，请列举出 2 个你最担心的“状态不一致”风险点。

回答：

1. 交易已经提交，但是APP的交易请求还没有发送成功。

2. 在刚刚完成扣费的请求后，用户恰巧杀死了进程

AI评估：

风险点 1：Tx Hash 丢失导致的“孤儿交易”

• 现象： 如你所说，交易已经通过钱包提交到链上了。但因为进程被杀，App 没能拿回钱包返回的交易哈希（Tx Hash）。
• 后果： 用户再次打开 App 时，App 认为用户“还没买”，依然显示“立即认购”。如果用户急躁，再次点击，就会造成重复认购。
• 深层痛点： 此时 App 成了“瞎子”，它知道用户想买，但不知道链上已经有一个正在排队的交易。

风险点 2：业务回调（Hook）中断导致的“逻辑断层”

• 现象： 钱包扣费（或授权）刚完成，App 进程死了，导致 App 内部原本计划在支付成功后执行的“后置逻辑”没能跑完。
• 后果： 链上钱扣了，但 App 本地没把这笔交易和用户的账户关联上。用户会发现**“钱没了，货没到”**。
• 深层痛点： 这属于典型的原子性（Atomicity）失效——资产转移成功了，但业务状态更新失败了。

风险点 3：Nonce 值的“隐形占位”导致账户瘫痪

描述： 以太坊等链有一个 Nonce（随机数） 机制，要求交易必须按顺序执行。

• 现象： 用户杀掉 App 时，如果刚才那一笔交易因为 Gas 费给得不够“卡”在了链上，由于 App 已经死掉，它无法引导用户去执行 Speed Up（加速） 或 Cancel（取消） 。
• 后果： 用户的整个钱包地址会被这笔“幽灵交易”卡死。他之后在该地址发起的任何操作都会失败。
• 对 App 的影响： 用户会认为是你的 App 把他的钱包“弄坏了”，这种信任危机比单纯的一次认购失败要严重得多。

风险点 4：前端 UI 的“虚假繁荣”与“二次焦虑”

描述： 如果你的 App 采用了某些前端持久化技术（如缓存了点击状态），但没能成功记录 Tx Hash。

• 现象： 用户重启 App 后，由于本地缓存显示“已操作”，UI 可能会一直转圈（Loading），或者显示一个错误的“处理中”状态，但实际上链上可能已经 Revert（退回）了。
• 后果： 用户既不敢再次尝试，也等不到结果。这种信息不对称产生的焦虑，是 Web3 用户流失的高发区。

测试意识训练：第二题

【场景描述】： 你的 App 正在进行一场火爆的认购。用户成功完成了签名，App 也顺利拿到了 Transaction Hash。此时，前端界面兴奋地跳出了 “恭喜！认购申请已提交” 。

然而，过了 30 秒，用户发现自己的余款没变，认购也没成功，但 Gas 费却实实在在被扣掉了。

【挑战】： 请列举出 2 个导致这种“扣了 Gas 费却没买到”的深层原因。

提示： 这不是因为网络延迟，也不是因为 App 崩溃，而是区块链底层的逻辑碰撞。

请开始你的回答。 （这道题考的是你对“智能合约执行失败”和“链上竞争”的理解，试着从这两个角度切入看看？）

回答：

1. 太过火爆，区块对于这笔交易还没计算完成。

2. 不知道了

AI评估：

第二题深度解析：为什么钱花了，事没办成？

1. 链上竞争失败（First-come, First-served）

• 专业术语： Out of Stock / Hard Cap Reached
• 解释： 虽然你的交易被区块打包了（这就是为什么扣了 Gas 费），但在你这一笔交易排队进入区块的一瞬间，认购额度已经被别人抢先一步买光了。
• 逻辑： 智能合约在执行你的请求时，会先检查：if (soldOut) revert();。因为额度已满，合约执行了“拒绝”操作。
• 结果： 交易失败，不产生资产转移，但矿工已经帮你计算过了，所以 Gas 费不退。

2. 交易触发了“执行异常”（Execution Reverted）

• 专业术语： Slippage or Condition Not Met
• 解释： 在火爆场景下，价格或条件波动极大。比如你认购时，合约要求最少持有 100 个积分，结果在你的交易排队时，你的积分被其他操作划走了，或者认购价格瞬间跳变超出了你设定的范围。
• 结果： 虚拟机（EVM）运行到一半发现条件不满足，强制停止。同样，计算资源已消耗，Gas 费照扣。

测试意识训练：第三题（测试用例进阶版）

【场景描述】： 你正在为一个 Web3 认购功能设计测试用例。用户需要支付 100 USDC 来认购一个资产。这个过程涉及：

1. 检查余额。
2. Approve（授权） ：允许合约扣除你的 100 USDC。
3. Confirm（执行认购） ：调用合约方法。

【挑战】： 为了确保上线后不会出大事故，请列举出 3 个你认为最容易被忽视、但必须测试的“异常/边缘”测试用例。

提示： 别只盯着“钱够不够”，多想想链上的“变数”。

请开始你的回答。 （我会根据你的用例深度，教你如何用“等价类划分”和“边界值”来彻底覆盖 Web3 业务逻辑。）

回答：

1. 用户余额为99.5/100.4 U时，会不会四舍五入，导致用户少/多花一些钱买入

2. 用户余额恰好为100U时，能否正常买入

3. 不知道

AI评估：

1. 精度陷阱：99.5 还是 100.4？（精度与截断）

• 你的思考： 用户余额差一点点，或者多一点点，系统怎么处理？
• 硬核补位： Web3 里的代币（如 USDC）通常有 6 位或 18 位小数。
• • 测试重点： 如果前端显示 100 U，但合约底层要求的是 $100 \times 10^6$（最小单位），而用户余额是 $99.999999$。结论是： 只要少 $10^{-6}$，交易都会立即 Revert（失败） 。
  • 测试设计： 测试前端是否做了“向上取整”的误导。如果前端显示“余额足够”，但用户点击后钱包报错，这就是一个体验 Bug。

2. “恰好” 100 U 的生死线（Gas 费消耗）

• 你的思考： 余额刚好等于认购价，能买吗？
• 硬核补位： 这取决于用户用什么币付 Gas 费。
• • 如果是 Native Token（如 ETH）： 如果用户余额刚好 100 ETH，认购价也是 100 ETH，必失败。因为你没有额外的钱付 Gas 费了。
  • 如果是 Stablecoin（如 USDC）： 余额 100 USDC，认购价 100 USDC，可以买。但前提是，用户的钱包里必须有额外的 ETH 来付手续费。
  • 测试设计： 测试“有币买资产，没币付手续费”的极端情况。

3. 那个“不知道”：授权过期的“幽灵”状态（Approve Sequence）

这是 Web3 测试中最容易漏掉的一环。

• 场景： 用户先点了一次 Approve（授权 100 U），但在执行 Confirm 之前，他去别的 App 把这 100 U 花掉了，或者他取消了之前的授权。
• 测试设计： “异步状态干扰测试” 。
• • 步骤：点击授权 -> 在另一台设备转走余额 -> 回到原 App 点击购买。
  • 预期结果： App 必须能即时捕获错误，而不是卡在“发送中”直到超时。

4. 授权覆盖与“零授权”回滚（Allowance Reset）

• 场景： 用户之前已经授权过 50 U 给你的合约，但这次认购需要 100 U。
• 潜在 Bug： 很多 App 的代码逻辑是“检测到有授权，就直接跳过授权步骤”。结果用户点击认购，合约因为授权额度不足（只有 50 U）直接报错。
• 测试点： * 不足额覆盖： 现有授权 < 目标金额。
• • 超额覆盖： 现有授权 > 目标金额。
  • 清零测试： 用户手动在钱包里取消了授权，App 界面是否能实时感知并重新引导授权。

5. “预估 Gas”失败的心理防线（Gas Estimation Failure）

• 场景： 用户点击认购时，钱包弹出来，但上面显示一行红字： “This transaction is expected to fail.” （此交易预期会失败）。
• 潜在 Bug： 这种报错通常是因为合约代码检测到用户不符合资格（比如认购时间没到），但 App 前端却把“购买”按钮点亮了。
• 测试点： “资格前置校验” 。
• • 在调用钱包弹窗前，App 是否先在后台跑一遍 eth_estimateGas？
  • 如果预估失败，App 应该直接拦截并提示具体原因（如“非白名单”），而不是让用户付了 Gas 费最后看交易失败。

6. 网络切换的“时空错位”（Chain ID Switch）

• 场景： 你的 App 支持以太坊和 Polygon。用户在 App 里选了 Polygon 认购，但他的 MetaMask 钱包正连在以太坊上。
• 测试点： * 点击认购时，App 是否会自动调用钱包弹出“切换网络”请求？
• • 如果用户拒绝切换网络，App 的加载状态是否会卡死？