抽奖系统 Web 端测试用例报告测试范围9 个 Web 页面、JWT 登录态、文件上传、CSV 导出、邮件通知覆盖维度功能、性能、兼容性、界面、易用性、安全项目内容类型Web 端系统测试对象管理员登录、注册、奖品管理、活动管理、抽奖、中奖名单、分享与导出分布功能 68、性能 14、兼容性 16、界面 18、易用性 15、安全 30说明测试设计与用例报告性能指标为建议基线执行结果需在测试环境回填一、先看系统抽奖不只是“点一下按钮”这个抽奖系统的业务链路并不复杂管理员注册并登录后台创建奖品上传奖品图片创建活动圈选奖品、设置奖项等级与数量再圈选参与人员管理员按奖项等级依次抽奖系统记录中奖名单活动完成后展示、分享、导出中奖名单系统异步给中奖者发送邮件通知。但真正要测的地方远不止页面上的几个按钮。这个系统同时存在四类状态活动状态RUNNING→COMPLETED奖品状态INIT→COMPLETED活动人员状态INIT→COMPLETED中奖记录按活动、奖品、中奖者、时间落库并写入 Redis 缓存。再叠加 JWT 登录态、Redis 缓存、RabbitMQ 异步抽奖、邮件线程池测试难度就从“表单能不能提交”上升为“状态是否一致、并发是否幂等、权限是否可信、失败是否可恢复”。所以我把测试拆成三条主线业务正确性主链路能跑通边界和异常能兜住非功能质量性能、兼容性、界面、易用性安全与公平性抽奖系统最不能妥协的部分。二、测试目标与范围2.1 测试目标验证系统在真实业务链路中的功能正确性、性能表现、兼容性、界面一致性、易用性与安全性识别高风险缺陷为上线、演示和后续迭代提供可执行的质量依据。2.2 范围内页面登录、注册、后台框架、活动列表、新建活动、奖品列表、创建奖品、人员列表、抽奖页共 9 个接口注册、登录、人员列表、活动创建/列表/详情、奖品创建/列表、图片上传、抽奖、中奖名单共 11 个业务接口依赖MySQL 数据、Redis 缓存、RabbitMQ 异步链路、邮件通知、JWT 登录态、文件上传、CSV 导出。2.3 范围外短信验证码当前代码未实现、支付与物流、移动 App/小程序、基础设施容量规划、深度渗透利用、真实邮件服务商可达性、生产数据迁移。说明本文的预期结果按“应然行为”设计不代表当前实现已经满足执行时若与现状不一致应按缺陷记录而不是把现状当成正确结果。三、测试策略六个维度三条主线161 条用例不是平均分配的而是按风险分层维度用例数设计重点功能测试68主链路、表单校验、分页、状态流转、事务回滚性能测试14并发、响应时间、稳定性、Redis/RabbitMQ 故障降级兼容性测试16浏览器、系统、分辨率、缩放、CSV、剪贴板界面测试18布局、样式、对齐、空状态、响应式易用性测试15引导、反馈、键盘、无障碍、错误恢复安全测试30认证授权、越权、XSS、上传、CSV、配置优先级按“业务影响 × 发生概率”划分P0核心链路、数据错乱、严重安全必须 100% 执行并通过P1主要功能、常用边界、重要兼容目标通过率 ≥95%P2次要功能、体验优化、极端边界可按版本裁剪。执行顺序建议冒烟登录 → 创建奖品 → 创建活动 → 抽奖 → 名单功能全量接口与安全先 P0性能与兼容失败项回归 核心链路回归。四、功能测试把主链路拆成 68 个检查点4.1 登录与注册登录页是管理员入口注册页同时承担“管理员注册”和“后台创建普通用户”两种职责。编号场景关键步骤预期结果F-001管理员手机号登录输入手机号、密码点击登录返回 ADMIN token写入 localStorage跳转后台F-002管理员邮箱登录用邮箱替代手机号登录成功身份与 token 正确F-003密码错误正确账号 错误密码不签发 token提示明确停留登录页F-008普通用户走管理员入口普通用户账号 mandatoryIdentityADMIN返回“身份错误”不进入后台F-011管理员注册填写姓名、邮箱、手机号、密码新增 ADMIN密码存哈希注册后可登录F-012后台创建普通用户管理员进入“注册用户”密码字段隐藏身份为 NORMAL列表自动刷新F-013邮箱重复使用已注册邮箱返回“邮箱已被使用”不新增记录F-017密码边界5 位、13 位、含符号按 6–12 位字母数字规则拒绝或通过这里有两个容易被忽略的断言注册成功后数据库里的密码必须是哈希值不能是明文普通用户从管理员入口登录时必须失败不能只靠前端隐藏入口。4.2 奖品与活动奖品和活动是抽奖的“数据底座”重点测三件事字段校验、业务规则、事务一致性。奖品侧的代表性用例如下编号场景关键断言F-022上传 JPG 创建奖品图片以 UUID 文件名保存列表首行出现新奖品F-024不选图片直接提交前端提示“请上传奖品图片”后端不能抛 500F-026价格为 0、负数、三位小数按业务规则拒绝不能只依赖前端minF-02912 个奖品、每页 5 条首页/上一页/下一页/尾页/跳页均正确F-031快速双击创建只生成一条奖品、一个文件按钮提交期间应禁用活动侧的核心规则是至少选择一个奖品至少选择一个人员参与人数 ≥ 奖品总数量奖品等级只能是FIRST_PRIZE / SECOND_PRIZE / THIRD_PRIZE关联的奖品、人员必须真实存在任一校验失败活动、活动奖品、活动人员三张表都不能留下半条数据。对应的测试用例覆盖了正常创建、未选奖品、未选人员、人数不足、数量为 0/负数、奖级非法、关联 ID 不存在、重复 ID、活动列表分页、活动详情排序等场景。其中“人数不足”是最典型的业务规则用例2 个人、3 份奖品必须返回业务错误并且事务回滚。只验证接口返回还不够还要查三张关联表是否都没有新增记录。4.3 抽奖流程抽奖页是整个系统最值得投入测试资源的地方。它同时涉及前端随机展示、确认弹窗、后端异步消息、状态扭转、记录落库和邮件通知。编号场景关键断言F-043点击开始后取消不进入滚动动画不发送抽奖请求状态不变F-044单奖项抽奖中奖人数 奖品数量中奖者不重复记录落库F-045一等奖 → 二等奖 → 三等奖按奖级顺序推进同一人员不重复中奖F-048抽到一半刷新页面已抽奖项展示已有名单未抽奖项可继续F-049已完成活动只读展示名单隐藏抽奖按钮F-051同一奖品重复抽奖应返回明确业务失败不能静默成功F-052中奖人数与奖品数量不一致应拒绝请求不写记录、不改状态F-053中奖者不在活动人员列表应拒绝不能把非参与者写成中奖者抽奖结果至少要有四个断言人数一致中奖人数等于该奖项设置的奖品数量人员合法中奖者必须属于该活动且未中过奖状态一致奖品INIT → COMPLETED活动在全部奖品抽完后RUNNING → COMPLETED记录可追溯中奖记录包含活动、奖品、奖级、中奖者、时间刷新和重新查询后仍然一致。这里还要特别关注“异步不等于不用测”。抽奖接口把消息投递给 RabbitMQ 后就返回成功真正的校验、状态扭转、记录落库发生在消费端。页面上的“成功”只是“消息已发送”并不等于“抽奖已完成”。因此必须补一条端到端断言接口返回后轮询或重新查询中奖记录确认最终状态一致。4.4 中奖名单、分享与导出中奖名单是抽奖系统的“结果页”也是对外分享的页面。测试点包括按奖项分组同组按中奖时间排序显示总人数空名单显示“暂无中奖记录”分享链接自动带上validfalsehideButtontrue打开后隐藏抽奖按钮未登录访客通过分享链接可以查看名单导出 CSV 包含 UTF-8 BOMExcel/WPS 打开中文不乱码无记录时不允许导出空文件姓名中含逗号、换行、双引号时CSV 列不能错位姓名以、、-、开头时要防止 Excel 公式注入。4.5 接口与异常接口层单独设计了 8 条用例覆盖无 token、错误 token、篡改 token 返回 401非法 JSON、缺失必填字段返回 400状态变更接口限制为 POST错误方法返回 405分页参数currentPage0/-1/99999、pageSize0/-1/100000的边界处理不存在的路径返回 404。这些用例的价值不在于“接口能不能通”而在于验证错误码语义是否稳定、前端是否能根据错误码做正确的交互。五、性能测试抽奖系统的瓶颈不只在数据库性能测试设计了 14 个场景核心指标如下均为建议基线不是实测结果场景负载通过标准登录接口50 并发5 分钟P95 800msP99 1.5s成功率 100%10 万活动列表100 并发10 分钟P95 500ms深分页不出现全表扫描1 万奖品列表100 并发P95 600ms图片缓存命中率 80%5000 人员全量列表单请求 前端渲染接口 P95 1s渲染 2s滚动不卡顿50 奖品 1000 人创建活动20 次取均值P95 3s关联表完整落库100 份奖品抽奖单次端到端接口 1sMQ 消费 5s记录落库 10s同一奖品 20 并发抽奖20 并发 × 10 轮仅一组中奖记录其余返回冲突1000 条中奖名单200 并发首次 1s缓存命中 P95 200msRedis 故障停止 Redis详情/名单回源 MySQL不返回 500RabbitMQ 故障停止 MQ5s 内明确失败不出现“假成功”8 小时稳定性100 并发混合场景错误率 0.1%无 OOM、无连接泄漏前端加载Lighthouse 桌面Performance ≥ 80LCP 2.5sCLS 0.1性能测试最容易漏掉的是“异步链路”和“故障降级”抽奖接口很快返回不代表用户体验完成要测 MQ 消费时延、状态扭转时延、记录落库时延Redis 挂掉时活动详情和中奖名单能不能回源数据库RabbitMQ 挂掉时抽奖接口会不会返回“假成功”邮件发送慢会不会把异步线程池打满反过来影响抽奖主链路。六、兼容性测试别让“能打开”等于“能用”兼容性覆盖 16 个场景矩阵如下类型覆盖范围重点检查桌面浏览器Chrome、Edge、Firefox、Safari、360/QQ 极速模式全流程、控制台报错、下载、剪贴板移动端iOS Safari、Android Chrome登录、活动列表、抽奖页、分享页分辨率1366×768、1920×1080、2560×1440、4K表格、分页、模态框、iframe 高度缩放100%、125%、150%、200%文字截断、按钮重叠、横向滚动文件CSV 在 Excel、WPS、Numbers 中打开中文、列数、行数、特殊字符环境限制HTTP 非安全上下文、禁用 JS、禁用 localStorage剪贴板降级、页面提示、重定向循环其中有两个很容易被忽略的点抽奖页设置了min-width: 1000px在平板竖屏和手机上会出现横向滚动或内容裁切。如果产品不支持移动端抽奖应该给出明确提示而不是让用户看到半个按钮。分享复制使用了navigator.clipboard在 HTTP 非 localhost 环境下不可用需要验证execCommand兜底是否真的能复制成功。七、界面与易用性管理后台的“最后一公里”界面测试关注“看起来对不对”易用性测试关注“用起来顺不顺”。这两部分一共 33 条用例主要发现集中在以下位置后台使用 iframe 承载子页面容易出现外层与内层双滚动条活动列表、奖品列表、人员列表在空数据时基本是空白没有“暂无数据”引导分页在第一页/最后一页没有禁用态用户仍可点击“上一页/下一页”成功、失败、未登录分别使用alert、toast、页内文本三种提示风格不统一抽奖页标题固定 100px活动名称过长时可能溢出“查看上一奖项/开始抽奖”使用span模拟按钮键盘无法聚焦中奖时间只显示HH:mm:ss跨天记录会产生歧义普通用户没有登录入口无法自助查看自己的中奖记录只能依赖公开分享链接。这些问题不一定会阻断主流程但会直接影响演示效果和真实用户的操作效率。尤其是“普通用户无法自助查询”这一条本质上是业务闭环缺失不只是 UI 问题。八、安全测试抽奖系统最不能省的一章安全测试设计了 30 条用例。结合源码走查以下几个风险需要优先关注。风险测试方法期望结果中奖名单接口未鉴权不携带 token直接请求名单接口并枚举活动 ID应要求登录或签名分享 token不能批量读取缺少角色校验用普通用户 token 调用创建活动、创建奖品、抽奖接口管理接口返回 403不能只验证 JWT 签名公开注册管理员不登录直接调用注册接口identityADMIN只能创建普通用户管理员创建需邀请/审批客户端指定中奖者构造winnerList传入非活动人员或伪造中奖时间服务端应自行随机抽取忽略客户端名单与时间JWT 密钥硬编码从源码获取密钥伪造 ADMIN token密钥应来自环境变量/密钥管理伪造 token 返回 401密码进入日志登录/注册后检索日志日志不得出现明文密码手机号/邮箱应脱敏密码哈希强度不足查询数据库中的密码字段使用 bcrypt/Argon2 等慢哈希带随机盐存储型 XSS在活动名、奖品名、人员姓名中注入脚本所有输出点转义CSP 生效脚本不执行任意文件上传上传 html/svg/js/php 文件并直接访问仅允许图片类型校验 MIME 与文件头强制下载CSV 公式注入中奖者姓名以、、-、开头导出时加前缀按 RFC4180 转义另外还有两类“工程侧”风险数据库、邮箱、短信、RabbitMQ 的凭据以明文写在配置文件里且存在默认弱口令登录接口没有失败锁定、验证码或限流6–12 位字母数字密码可以被持续暴力尝试。安全测试只能在获得书面授权的测试环境进行禁止对生产系统扫描或利用。对抽奖系统来说安全不只是“防黑客”更直接关系到抽奖公平性和中奖结果的可信度。九、缺陷分级与准出标准建议使用以下分级等级定义示例S1阻断、数据错乱、严重安全未授权可改中奖名单、抽奖重复落库、活动状态错乱S2主要功能失败、高风险创建活动事务不回滚、上传可执行文件、存储型 XSSS3一般功能/体验问题分页越界、空状态缺失、提示不统一S4建议优化文案、间距、图标、动效准出标准建议P0 用例 100% 通过P1 用例通过率 ≥95%安全高危项有明确修复或风险接受结论性能指标达标兼容性矩阵覆盖完成核心链路回归通过。十、总结测试用例的终点是“可复现的质量共识”这次测试用例设计给我最大的感受是抽奖系统的测试重点不是“能不能抽”而是“抽得对不对、能不能复现、出了事能不能解释”。具体来说有三点值得反复强调第一状态机要用矩阵测不要用路径测。活动、奖品、人员三个状态组合很多只测“正常抽完”会漏掉“抽到一半刷新”“重复抽同一奖项”“活动完成后再次调用接口”等关键场景。第二异步链路必须端到端断言。接口返回成功只是消息投递成功真正的结果在消费端。测试要覆盖 MQ 消费失败、重试、死信、Redis 故障和最终一致性。第三安全就是业务。中奖名单谁能看、谁能抽、中奖者由谁决定这些问题如果不在测试阶段暴露就会在活动上线后变成公平性事故。161 条用例最终会沉淀成一张可执行的检查表维度用例数建议执行顺序功能68第 1–2 轮性能14第 4 轮兼容性16第 4 轮界面18第 2 轮易用性15第 2 轮安全30第 3 轮优先 P0