40个小程序测试用例跑下来，小程序测最痛的试实不是发现bug，而是战课发现我们自己设计的“用户”根本不会那么用。这是程总我在实战课程里最大的教训。

第三天下午，小程序测我们测一个电商小程序的试实结算流程。用例步骤写得清清楚楚：添加商品，战课点击结算，程总选择优惠券，小程序测提交订单。试实执行到第12条时，战课测试机上的程总小程序突然卡死了。我第一反应是小程序测网络问题，刷新了三次，试实依旧白屏。战课后来一查日志，是优惠券模块的并发锁没处理好——同一时间只能有一个用户领券，但测试环境里我开了两个模拟器同时操作，直接把它打崩了。

这个bug要是放在真实场景里，就是两个用户同时抢一张限量券，其中一个会永久卡在“领取中”。但我们的用例设计里，压根没考虑“两个用户同时操作”这种并发场景。课程老师当时只说了一句：“你们写用例的时候，脑子里想的是‘用户很乖’，但现实是用户很暴躁，他们会乱点、会连点、会退出去再进来。”

后来我们调整了策略。不再死磕功能路径，而是专门设计“破坏性操作”：比如在支付弹窗弹出瞬间疯狂点击取消，或者在网络切换成飞行模式时提交订单。第27个用例就是这么发现问题的——小程序在弱网环境下，支付成功回调丢失，订单状态停留在“待支付”，但钱已经扣了。这个场景在用例文档里根本不存在，是我们现场用charles模拟3G网络才逼出来的。

还有一次更离谱。我们测一个签到功能，连续签7天送积分。第5天的时候，我发现把手机系统时间往后调一天，签到按钮居然还能点，而且积分照发。这属于典型的“客户端信任问题”——前端只判断了日期是否变化，没校验服务端时间。开发说“谁会改系统时间啊”，但现实里薅羊毛的人就会。这种用例，教科书上不会教你写，只有当你真的把手机扔在桌上，盯着那个签到按钮发呆时才会想到去戳一下。

课程结束前，我们复盘了所有40个用例。真正有价值的发现，几乎都来自那些“不按套路”的测试——多设备并发、弱网、时间篡改、快速重复操作。反而那些老老实实按需求文档写的正向用例，一个bug都没找到。这让我有点怀疑，我们平时测的到底是软件，还是我们自己想象中的软件？

40个用例不算多，但足够撕开一个口子：测试的本质不是验证功能“能用”，而是证明它“不容易坏”。下次再写用例，我打算先问一句：如果用户是个手贱的傻子，他会怎么弄坏这个页面？