1. 项目背景与测试范围确认1.1 “开心大转盘”到底是个什么东西“开心大转盘”是一个典型的线上抽奖营销活动用户通过H5页面或者小程序入口进入每天登录签到或者完成指定任务后可以获得抽奖机会点击转盘按钮后指针旋转最终停在某个奖品区域系统发放对应奖励。这类玩法在电商大促、公众号增粉、线下门店引流、年会暖场这些场景里太常见了几乎每个公司都做过一模一样的。我接到这个项目的时候开发已经写了大概两周前后端联调刚跑通第一版。转盘整体分为三个模块抽奖核心逻辑、奖品库存管理与发放、用户中奖记录。前端用Canvas画转盘后端是Java系微服务抽奖接口和用户中心分开部署奖品数据放在Redis里做缓存订单记录落在MySQL。测试这个项目最重要的是先想清楚抽奖活动的核心底线是什么第一用户绝对不能白抽也就是转盘转了、机会扣了、结果没返回第二奖品绝对不能超发库存显示还有但是发不出来或者直接发超了第三用户绝对不能刷绕过次数限制无限抽。三条底线守住其他都是体验问题。1.2 测试周期与资源安排整个测试排期一共七天前三天功能测试第四天兼容性和安全测试第五天性能压测第六天留作回归和修复验证第七天出报告。测试团队投入两个人我主要负责前端交互和业务逻辑另外一个同事专职做接口和并发压测。七天看起来时间充裕实际上真正能写用例和执行的时间也就四天。抽奖类项目的特殊性在于每次抽奖都是一次写入操作涉及机会扣减、转盘动画、结果回调、奖品发放、消息通知五个环节任何一个环节断掉都会出问题。所以我一开始就跟产品确认了测试优先级核心验证顺序是抽奖机会扣减正确性、中奖结果一致性、奖品库存准确性、前端动画与回调一致性最后才是界面样式和文案这些细节。这里有个容易被忽略的点测试工期排期必须把“修复后的回归验证”单独拎出来算时间不能跟第一轮功能测试混在一起。我在实际排期里专门留了第六天做二次回归结果第六天真的派上了大用场后面详细说。2. 测试策略与用例设计思路2.1 功能拆解与测试点归纳我先画了一张简单的功能脑图把整个转盘切成四个部分用户侧参与链路、抽奖核心接口、库存与发放、运营配置后台。用户侧的典型链路是授权登录、进入活动页、查看剩余抽奖次数、点击抽奖、转盘转动动画、弹出中奖提示、在“我的奖品”中查看。这条链路看着顺畅实际测试的时候我把每一步都拆成两个维度正常流程和异常打断。比如点击抽奖后网络突然断开前端应该怎么表现转盘转到一半用户退出页面重新进来后奖品到底有没有发这些场景比主流程更容易藏雷。抽奖接口是后端逻辑的重头核心验证点包括抽奖机会校验、频率控制、奖品概率计算、结果落库。这里最麻烦的是概率验证产品需求里写的是“一等奖0.1%、二等奖0.5%、三等奖2%…”你没法真的抽一万次去验证概率准确所以我在测试策略上分了两步前两步用真实调用验证接口参数和返回结构第三步直接在数据库层伪造抽奖次数统计数据用脚本循环调用3000次校验每个奖项的命中次数是否在统计学合理区间。库存和发放模块的测试重点很明确每类奖品的总库存、每日限量、单人限领数量、发放渠道。这里最容易出问题的不是库存不够而是库存并发扣减时出现负数。我在用例设计里专门加了“库存为0时的边界请求”“两个用户同时请求最后一件奖品”这两条果然在后来的并发测试中炸出了真实缺陷。运营后台的测试相对简单主要是奖品配置、概率设置、活动启停。但有一个点必须重点验证如果运营在活动进行中修改了转盘概率或者奖品库存对已经发出去的奖品和正在抽奖的用户会不会产生影响。我在用例设计时特意加入了“动态修改概率后立即抽奖”的场景测试结果确实暴露了Redis缓存未实时刷新导致用户读到旧配置的问题。2.2 用例编写思路与数据准备用例设计上我按照“正向主流程、异常分支、边界场景、数据一致性”四类来组织每条用例都写明前置条件、测试步骤、预期结果、实际结果。抽奖次数上限、奖品库存、概率权重、中奖后发放状态这四个数据维度的组合是核心。数据准备这一块我踩了个不大不小的坑。最开始我直接往数据库里插入了一批库存数据然后用测试账号去抽奖结果发现mock数据和真实运营配置的数据结构对不上。后来我跟开发确认了完整的数据字典整理了五张核心表活动配置表、奖品表、库存表、用户抽奖记录表、奖品发放记录表。每一类奖品我都准备了三种库存状态充足、仅剩1件、已清零保证每一条用例都能覆盖边界。这里分享一个经验抽奖测试环境的造数不能只造“正常数据”必须把“脏数据”也造出来。比如抽奖记录表里插入一条用户中奖但发放失败的记录再让这个用户重新进入活动页看看系统能不能自动补发。我特意造了这种异常数据为的是验证后端是否真正做到了幂等否则用户重复点两次“领取”就可能领到两份奖品。2.3 测试环境与账号准备测试环境用了一套独立的staging环境数据库和Redis都是独立的避免污染生产数据。我准备了20个测试账号按照不同用户身份做了分组普通用户、新用户、老用户、黑名单用户还特别准备了一个“内部白名单”账号。账号再多也有一个问题真实场景中每个用户每天三次抽奖机会而测试时我可能需要一个用户在一个小时里连续抽几十次这时候就要靠后端开“测试白名单”来放开频率限制这个一定要跟开发提前说好否则联调阶段卡流程。转盘项目的测试账号里有几个账号是中奖几率特别高的“灰名单”——这是我在测试环境里故意改的。我把一等奖的概率临时调成30%用这几个账号专门验证中奖后奖品发放、库存扣减和通知触达。等全部测试结束再把配置改回线上的真实值。这种临时改概率的策略在测试抽奖类项目里非常实用能够大幅缩短概率类场景的验证时间。3. 功能测试执行过程与关键场景记录3.1 主流程验证实录第一轮功能测试我优先跑通的是完整主链路登录活动页、看到转盘、点击抽奖、动画结束、弹出结果、奖品到账。这个过程我一共反复跑了大概五十次不是为了追求数量而是为了观察每一次转盘动画停下的位置和后端返回的中奖结果是否一致。这里有一个非常关键的验证点前端展示的结果必须与后端返回的结果完全一致。做过抽奖系统的人都知道前端转盘是种花活真正决定结果的是后端接口。如果前后端结果不一致用户看到的和实际到账的不同这就是重大事故。我在测试中专门对着后端日志核对了每一次请求的中奖返回发现了一个神奇的“指针偏差”问题。转盘动画是用Canvas画的通过旋转角度定位指针停留位置。我测试了十次后发现有三次前端指针显示的格子顺序错了一位。开发修复了两天才找到原因前端根据后端返回的奖品ID反推角度时没有考虑转盘扇区是从90度开始绘制导致计算偏移了45度。这个bug在普通测试流程里很难发现必须前后端结果逐条对比才能暴露。3.2 异常打断场景测试转盘抽奖作为一个移动端H5活动用户随时可能因为来电、切后台、网络切换而打断流程。这块我专门设计了一个异常场景矩阵把打断时机分成四段点击前、转盘转动中、接口请求中、结果弹窗展示中。测试中最有趣的场景是“转盘转到一半突然杀掉进程”。实际操作中发现很多用户会在这时候重新打开页面系统已经发了奖但用户没有看到结果。我们测试了两种处理逻辑一种是前端不展示结果只依赖后端记录另一种是前端在重新进入时拉取最新中奖记录并补弹窗。结论是后一种体验更好但前提是后端必须保证发放成功记录和接口调用之间的一致性。我在转盘转动到一半的时候点击返回退出、重新进入页面发现前端虽然不展示中奖动画但“我的奖品”里已经有了记录。这类“静默发放”算不算合格我跟产品确认后结论是奖品发放不能丢但提示可以后置补弹。开发后来在重新进入活动页时增加了“未读中奖结果弹窗”把这个缺口补上了。对于网络断开的场景我主要通过Charles挂起请求模拟弱网环境连续测试了十次发现部分情况下会出现“转盘明明转完了但服务端没有收到请求”的情况。这个问题归根结底是前端超时重试机制不够完善没有做基于抽奖幂等键的重试策略。3.3 抽奖机会与状态流转验证抽奖机会是用户参与活动的“门票”它的状态流转必须严丝合缝。机会的来源有三种每日登录赠送、完成指定任务奖励、运营后台手工补发。每次抽奖消耗一次抽奖接口返回结果后无论中没中奖机会都已经消耗。我重点测试了这样一个场景用户剩余1次机会点击抽奖后快速再点一次页面还未刷新理论上第二次不应该发起抽奖请求。实测后发现前端按钮在第一次点击后已经置灰没有发生重复扣机会的问题但我在接口层继续测了一个更极限的case——手动用Postman连续发送两次请求后端对同一用户同一时刻的两次请求分别扣减机会并返回了两次结果。这意味着接口层没有加频率锁理论上用户可以绕过前端做并发抽奖。我在测试报告中把这个标记为高优缺陷开发给出的修复方案是在抽奖接口入口增加用户维度的分布式锁同一个用户在锁释放前不允许发起第二次请求同时增加一个抽奖幂等键前端每次进入活动页时生成一个唯一流水号后端接收请求时先查流水号是否已存在避免重复扣减次数。机会状态流转测试中还有一个小坑活动周期的“次日重置”。如果运营配置的是“每天赠送3次”那用户在23:59抽完3次后到00:00到底能不能立刻再抽我验证了两种情况一种按自然日重置一种按24小时滚动重置。两种逻辑都有产品场景支持关键是后端配置的定时任务必须跟产品文档一致我测试时发现staging环境的定时任务用的是UTC时间导致北京时间凌晨重置时间晚了8小时。这种问题在排期紧的时候很容易漏掉建议大家一定把时区校验写进常规测试点。4. 兼容性与性能测试结果4.1 终端与浏览器兼容性实测转盘页面是H5要兼容的终端实在太多。这次选型最终确定为主流Android微信内核、iPhone自带Safari、微信内置浏览器三个方向覆盖了大约全部用户的96%。先说iOS端。我手头有一台iPhone 12跟一台iPhone SE第二代。转盘动画在iOS微信内置浏览器里整体表现稳定但是出现了一个典型的iOS兼容性问题转盘在旋转过程中出现了明显的锯齿感Canvas的帧率只有约30fps低配机型上转盘边缘甚至有残影。开发调整了Canvas绘制的像素比把devicePixelRatio从1强制改成2后问题基本消失。Android端的坑就更多了。华为、小米、OPPO三台机器我都实测过最大的问题是部分WebView对CSS动画的解析不一样。比如转盘指针的transition属性在部分华为机型上不会生效导致指针不是“慢慢停下来”而是瞬间跳到结果上。开发最终用requestAnimationFrame替代CSS transition才解决了这个问题。还要提一下刘海屏和底部小黑条。转盘页面的开始按钮放在底部在iPhone X之后的机型上会被home indicator遮挡。我专门申请了iPhone 13和iPhone 14做验证发现确实存在按钮点击区域被遮挡约40像素的情况。最终修复方案是在页面底部增加safe-area-inset-bottom适配。测试中还发现一款老旧的Android 8.0机型存在WebSocket加载异常导致页面onLoad阶段一直转圈。排查下来是微信7.0.0老版本跟Android WebView的一个已知兼容性问题只能通过升级微信版本解决不过考虑到这类用户占比不足1%最终跟产品确认后决定不修复在页面上增加一个“版本过低提示”就好。4.2 性能压测数据与瓶颈定位性能测试我用JMeter直接打后端抽奖接口重点考察两个指标抽奖接口的QPS上限和高峰期库存扣减的响应时间。压测分了三轮第一轮100并发第二轮500并发第三轮1000并发每轮持续10分钟。100并发的测试结果很理想抽奖接口的平均响应时间在120ms左右P95在180ms库存扣减没有任何异常。500并发的时候开始暴露问题响应时间上升到450ms左右P95接近800ms出现了部分请求超时。随着并发量继续增加到1000并发系统的瓶颈开始出现。通过监控后端日志和数据库慢查询定位到了三个主要瓶颈第一个是登录令牌校验接口承担了与抽奖无关的流量冲击建议增加独立的校验缓存第二个是数据库连接池数量配置偏低200个连接在500并发下已经捉襟见肘第三个是库存扣减操作在数据库层面存在行锁竞争同一奖品在并发请求下出现明显的锁等待。针对压测结果开发团队的优化分了三步首先把用户信息校验改为Redis缓存透传减少数据库查询次数然后调整了数据库连接池的下限和上限配置最后把库存扣减从数据库乐观锁改为Redis的Lua脚本原子操作。优化完成后我用同样的脚本再跑了一轮1000并发下抽奖接口的平均响应时间稳定在220msP95在380ms整体表现可接受。5. 测试中发现的主要缺陷与修复验证5.1 典型缺陷汇总清单整个测试周期共提交缺陷32个按严重程度划分致命缺陷1个、严重缺陷6个、一般缺陷15个、提示类缺陷10个。截止报告提交日已修复并验证通过28个其余4个属于低优先级由产品和开发确认延后处理。最严重的一个缺陷出现在库存并发场景。压测时我分别用两个账号同时抽奖奖品库存只剩1件这时候两个并发请求几乎同时到达后端。最终结果是两个请求都返回了“中奖”对应的奖品发放记录也同时生成了两条库存被扣成了负数。这个问题成功复现后开发定位到扣减逻辑走的是“先查库存再扣减”的非原子操作在并发环境下产生了竞态条件。修复方案是把扣减动作改成了Redis Lua脚本原子操作从根源上杜绝了超发。另一个严重缺陷是用户重复点击抽奖按钮导致的次数重复扣减。正常用户操作时前端按钮置灰阻止了第二次点击但绕过前端直接调接口时同一个用户可以无限次并发抽奖。这个问题的根因是后端接口没有做防重入控制我建议增加基于用户ID的分布式锁每次抽奖设置一个短时限锁锁释放前不响应新的请求。开发采用Redisson实现了分布式锁修复后我用并发脚本重测验证同一用户的重复请求被正确拦截。5.2 缺陷根因分析与回归策略缺陷根因分析是测试报告里最有价值的部分。我按模块统计了一下前端交互的问题占了36%后端并发逻辑的问题占28%数据一致性的问题占21%配置类问题占15%。前端交互类的典型代表是指针偏移和转盘点位不准。这类问题难以通过后端测试发现因此回归时必须在多台设备上反复跑动。并发逻辑类问题类似超发和重复扣次数必须在接口层加并发脚本压力验证。数据一致性类问题比如中奖记录和发放记录不一致必须在回归测试时做数据库层面的数据对比。回归策略上我没有简单地把发现缺陷的用例重跑一遍而是针对每个缺陷补充了额外的边界用例。比如针对库存超发缺陷我额外测试了库存为1、0、负数三种情况下并发请求的表现确保开发在修复超发问题的同时不会引入新的边界bug。第六天的回归测试最终验证了所有严重以上缺陷的修复我也顺带把正常主流程整体回归了一遍确保没有引入新的连锁问题。6. 安全测试与数据一致性检查6.1 前端参数篡改与接口越权测试抽奖类H5活动的安全问题集中在三个方向前端参数篡改、未授权访问、越权操作。我逐一验证过。前端参数篡改方面我用Charles抓到一次抽奖请求尝试修改请求体里的userId字段为其他用户ID看看后端接口是不是会直接处理。实测结果是后端返回了无权限错误说明接口做了登录凭证与用户ID的绑定校验。但随后我发现请求里还带了一个“activityId”字段我改成另一个测试环境的活动ID后接口竟然正常返回了抽奖结果。测试环境里多个活动共用同一个抽奖接口校验逻辑只验证了登录态没有验证用户是否有权限参与该活动。这个问题虽然没有直接危害但暴露了权限校验的缺失。如果是线上环境用户通过API直接指定一个尚未上线的活动ID就能提前参加活动并领取奖品。开发修复的方式是在抽奖接口增加活动的启用状态校验和时间窗口校验活动未开始或已结束的请求直接拒绝。越权测试还要关注运营后台。我用一个普通用户账号尝试调起运营后台的奖品配置接口确认后端是否有管理员权限校验。实测确实返回了401说明后端框架层面的权限控制还是到位的但这类接口的安全性不能只靠框架测试一定要覆盖到万一开发在写业务代码时跳过框架的权限拦截后果不堪设想。6.2 库存与发放记录一致性校验发奖链路是后端写数据库的核心操作任何一个环节异常都会导致用户奖品丢失或者超发。我重点检查了三张表抽奖记录表、奖品库存表、发放记录表。在100并发压测结束后我写了一条SQL把抽奖记录里中奖的奖品ID和发放记录里的奖品ID做全量比对看有没有中奖但未发放或者未中奖但发放了的数据。压测后数据一致性校验发现了一个隐藏问题部分中奖记录有对应的发放记录但商品ID对不上。排查对比之后发现是抽奖过程里有一批奖品已经被清理下架后端在发放时改成了等价奖品却没有在发放记录里更新奖品ID。这个问题的表现是用户看到的“已发奖”商品和“中奖记录”里的商品不一致投诉率高。针对这类一致性问题的常规做法是在抽奖发奖的事务里加入状态机校验每一笔中奖记录和发放记录必须通过同一个事务提交不允许出现跨事务写入。开发后来把发奖逻辑全部收敛到一个事务里并增加了对账脚本对账通过率从原来的99.97%提升到了99.999%以上。这个对账脚本每周自动跑一次把异常数据输出成报表便于运营排查。安全测试里我还上线了一轮防盗刷测试。针对抽奖机会的发放规则我反复修改系统时间尝试跨天多领机会结果后端没有做时间戳校验直接信任客户端传过来的时间。后来把时间基准改为服务器时间前端只展示不具备决定权风险才算堵上。这个案例也提醒了测试同事凡是涉及用户权益的字段一定不能信任客户端上送的参数。7. 常见问题与排查技巧实录7.1 转盘结果与页面显示不一致这是测试期间被问得最多的问题运营自己也经常遇到用户明明抽中了某奖品页面上转盘指针却指向了旁边一格导致用户认为系统黑了。排查这种问题要先分清责任边界。我先抓后端接口返回确认中奖结果那块的数据再看前端转盘的起始角度、扇区大小跟奖品列表的映射关系。测试中我发现前端拿到奖品ID之后需要一个本地“奖品格子顺序表”来计算指针应该停在哪里。如果这个表跟后端配置的奖品顺序不一致指针就会偏。实际的修复思路是后端在返回中奖结果时同时返回该奖品的格子序号前端只按序号计算角度不再依赖本地表。我验证后由于数据源统一指针偏移bug基本清零。这里也建议有条件的团队在转盘接口增加一个“调试模式”返回结果里包含角度和格子序号的明细测试时排查效率会高很多。7.2 奖品发放延迟与用户投诉测试中遇到另一种典型情况用户抽中奖品中奖记录里已经有数据但券码或者实物发货状态迟迟没有更新。排查流程上我先确认发放记录表的状态字段再看后端队列里的消费情况。这个问题的根因往往在发放环节。我这次测试中遇到的是奖品发放依赖了一个外部电子券平台外部接口响应超时导致发放任务在队列里堆积。测试环境中外部平台不稳定经常模拟出这种超时情况。我的建议是后端必须为发放链路增加退避重试机制重试三次仍然失败的要进入“人工补偿队列”给运营留一个手动补发的入口。重试机制带来的新问题是重复发放。我在测试中验证了退避重试三次的情况下是否能确保每个用户的奖品只发一次。经过排查发现需要引入“发放流水号”做幂等校验同一笔发放流水在数据库中只能出现一次成功状态后续重复请求都返回已发放。这个方案不仅对电子券有用对实物发货同样适用。7.3 测试数据千万记得还原这是测试过程中我个人最想强调的一点测试结束后所有临时修改的配置和脏数据必须全部还原。我这次为了让灰名单账号更容易中奖把一等奖概率临时调到了30%测试完成后如果没有还原回0.1%就上线活动第一天就会因为一等奖超发造成巨大损失。建议在项目测试开始时专门建一个“测试变更登记表”记录所有临时修改的配置项包括数据库中有影响的字段、缓存里修改的key、运营后台调整的开关等。测试结束当天逐项核对还原再让开发在预发环境做一轮冒烟测试确认一切正常后才正式放量。这个习惯非常重要尤其是有多个测试同事同时操作的环境还原遗漏的概率很高。8. 其他值得关注的测试细节8.1 消息通知与文案合规检查转盘中奖后的消息通知是一个容易被测试忽略的点。我这次测试专门做了通知覆盖中奖后是否推送模板消息、推送延迟要不要控制在30秒以内、通知文案里是否包含奖品名称和有效期。实测发现如果奖品是优惠券通知文案里必须写清楚使用规则否则投产后很容易被投诉。文案合规这一块提醒大家关注抽奖页面里的活动规则、奖品说明、概率公示等文案不要出现“绝对”“百分之百中奖”等违规字样。这类文案问题在生产环境会被平台方下架影响比想象中大测试阶段一定要细看。8.2 埋点数据监测验证抽奖活动的核心运营指标是参与率、中奖率、奖品转化率。这些数据都依赖前端埋点。我的测试中对接了数据平台的埋点方案验证了三个关键事件的埋点上报活动页展示、转盘点击抽奖、结果弹出。每一类事件需要校验的参数包括活动ID、用户ID、奖品ID、渠道来源等。埋点测试中常出现的问题是前端弹窗结果正常但埋点事件压根没有上报。我跟数据平台同事确认后发现部分WebView环境默认屏蔽了本地存储导致上报请求无法带cookie事件被丢掉。这类问题测试阶段排查困难建议开发把埋点上报做成失败重试的机制并且提供一个可视化查看埋点上报内容的debug工具在测试环境开启后可以看到每条埋点的实时上报日志。8.3 灰度发布与线上监控准备测试全部通过后通常会安排灰度发布。我的建议是灰度范围先放5%的流量观察抽奖成功率、发奖成功率、接口RT这三个指标是否正常运行四个小时后再逐步扩大到30%、100%。我在上线前给开发提了几个监控指标建议抽奖接口调用量、抽奖成功率、发奖成功率、库存更新延迟、异常告警阈值。特别是库存扣减失败这种异常必须在发生的一分钟内触发告警。测试阶段积累的压测数据可以作为线上告警策略的参考值比如抽奖接口平均RT超过400ms时告警成功率低于98%时告警这些阈值线上运营时可以不断校准。9. 测试总结与个人复盘心得“开心大转盘”这个项目给我的整体感受是抽奖类活动看着简单真正测下来牵扯的逻辑链路比想象中复杂得多。核心难点不在界面而在并发一致性、金额权益安全、异常补偿机制这些都是极容易出问题的地方也是最需要提前设计测试策略的部分。我个人在测试过程中最大的体会是抽奖项目测试要从“用户视角”切入把每一次抽奖操作都当成一次不可回退的真实交易来测。用户抽奖的次数记录、库存扣减、奖品入库这三步必须像银行转账一样精确。测试时时刻问自己如果线上出现100个人同时对最后一件库存发起抽奖系统会不会崩溃如果用户抽奖成功但断网了奖品会不会丢这些问题提前想清楚测试才算真正有效。最后想分享一个后续扩展的建议这类转盘项目的测试方法完全可以复用到大转盘之外的其他营销活动比如签到打卡、积分刮刮乐、盲盒抽取、邀新有礼等。核心验证逻辑都是权益数量校验加奖品发放一致性区别只是活动表现形式不同。测试策略、并发脚本、库存对账方案、异常补偿机制这些资产都可以沉淀成团队的通用测试方案库下一次新活动来了不用从零开始设计用例拿这套方案改改就能用效率能提升不少。
