个人抽奖系统测试报告

项目介绍

抽奖系统，使用前后端分离的做法，数据库采用MYSQL进行存储，使用Redis进行缓存，MQ进行减轻后端的高并发压力，最后部署到阿里云服务器上。前端主要由登/注册界面，活动界面，奖品界面，人员界面构成，后端实现的主要功能为强制登录，添加活动，奖品，人员，同时存储到redis，减轻后端数据库的压力，同时把添加了MQ，确保应对高并发的情况，中奖之后，会通过QQ邮箱把信息发送给对应的用户

项目功能

登录功能

1. 用户可以通过手机号，邮箱进行登录，只要数据存在于数据库中，校验通过，即可实现登录
2. 用户可以通过验证码登录，实现了阿里云的短信服务，用户使用验证码登录时，会调用阿里云的短信服务，同时会把这个短信存储到Redis中，有效期为1分钟

注册功能

用户需要输入姓名，手机号，邮箱和密码，输入的格式也是有要求的，后端使用了正则表达式进行校验，如果不符合规则，则会被拒绝注册，同时，邮箱不可重复，注册默认为管理员身份

新建奖品功能

只允许管理员进行操作，允许上传10mb之内的图片

查看奖品功能

管理员可以看到创建的奖品的详细信息

新建人员功能

管理员可以进行新增人员操作，默认身份为普通用户，无法对抽奖系统进行操作，只能被抽

查看人员列表功能

可以看到所有的人员列表，包括管理员，普通人员

新建抽奖活动功能

要求人员必须大于或等于奖品，才允许创建，只有普通用户可以参与抽奖，管理员负责人员的抽人抽中之后，会把消息存储到redis，减轻数据库的压力

查看抽奖活动功能

抽完之后，可以看到活动的情况，人员中奖情况，同时会保存在数据库以及redis中

测试计划

测试用例

正常使用

登录界面

手机号登录

邮箱登录

验证码登录

正常创建奖品

正常查看奖品列表

正常创建人员

正常查看人员列表

正常创建活动

正常查看活动列表

查看中奖名单

自动化测试

个人抽奖系统网址

http://8.163.57.248:8080/blogin.html

测试用例

代码设计

1. 根据测试用例进行编写代码
2. 每个页面一个测试类，确保逻辑清晰
3. 把驱动，截屏，单独创建一个类进行操作
4. 注意添加显示和隐式等待，确保元素加载以及弹窗的处理

使用测试工具

IDEA编译器 selenium依赖，提供自动化操作 common-io依赖，进行屏幕截屏 webdrivermanager依赖负责管理驱动

依赖

分层

测试代码：

https://gitee.com/zhan-yutao/lottery-system/tree/master/tests

公共方法

1. 创建驱动，保存运行截图
2. 图片的命名按照日期时间进行
3. 创建驱动时可以选择有头或无头模式

具体页面测试

1. Login

1. 页面是否正常打开
2. 正常登录

1. 账号密码正确
2. 邮箱密码正确
3. 手机号验证码正确

1. 异常登录

1. 账号为空/密码为空/邮箱为空/

2. 格式错误

3. 不为空账号错误/密码错误/邮箱错误/

4. Register

1. 注册页面是否正常打开
2. 注册成功

1. 手机号，密码格式正确
2. 邮箱号唯一，密码格式正确

1. 注册失败

1. 手机号/邮箱/密码为空

2. 邮箱唯一

3. Createuser

1. 创建用户页面是否正常打开
2. 创建成功

1. 手机号/邮箱/姓名不为空
2. 邮箱唯一

1. 创建失败

1. 邮箱已经注册过

2. 手机号/邮箱/姓名为空

3. Showuser

1. 正常显示人员列表

1. CreatePrize

1. 创建奖品页面是否正常打开
2. 创建成功

1. 奖品名/图片/价格/描述不为空
2. 数据在有效范围内

1. 创建失败

1. 图片大小超过限制
2. 奖品名称/图片/奖品价格/奖品描述为空
3. 上传不为图片

1. ShowPrize

1. 奖品可以正常访问

1. ShowActivity

1. 抽奖活动正常展示

1. CreateActivity

1. 页面是否正常访问
2. 活动/奖品/人员不为空
3. 人员/活动/奖品为空
4. 人员大于奖品数
5. 奖品大于人员数量

总结

1. 需要注意显示等待和隐式等待的区别，一个处理元素，一个处理弹窗
2. 屏幕截屏的保存格式，确保不会出现覆盖的情况
3. 注意无头模式的使用，可以只关注结果，不关注过程
4. 注意高并发的情况，需要交给开发人员处理
5. 注意定位元素的时候，尽量获取固定的，不要获取随机变换的，xpath或css都可以
6. 测试用例并非越多越好
7. 注意需要释放驱动
8. 在打开多个页面时，如果需要切换的话，可以使用swtich to或者切换句柄的方式
9. 静态的定义驱动，这样就可以在任何地方调用，程序一启动就被初始化
10. 需要把测试用例的结果保存下来，确保后续可以查看
11. 页面检查需要仔细，避免元素的选择错误

性能测试

使用jmeter进行简单的性能测试，针对接口进行简单

的性能测试

Jmeter

Jmeter运行脚本

https://gitee.com/zhan-yutao/lottery-system/blob/master/抽奖系统.jmx

设置线程组，防止服务器崩溃

本次压测采用阶梯式加压策略：先等待 3 秒预热，随后一次性启动 2 个并发线程，持续压测 20 秒，最后每 3 秒平滑停止 1 个线程，压测过程稳定可控。

性能测试图

使用jmeter生成完整的报告

测试结果

活跃线程数随时间变化

曲线平稳，没有突然飙升或下跌，证明压测执行过程非常稳定，没有出现线程中断或崩溃的情况

响应时间随时间变化

抽奖系统 4 个核心接口的平均响应时间均保持在 2~9ms 区间，且随压测推进呈平稳下降趋势，最终稳定在 2~4ms。其中抽奖接口响应效率最优，各接口间负载均衡，无性能衰减或异常波动，系统在当前压力下表现稳定高效

每秒点击数

吞吐量

从每秒事务数（TPS）图表可见，在 2 个并发用户的压测场景下，抽奖系统 4 个核心接口的 TPS 随压测推进线性增长，最终稳定在约 59 笔 / 秒，且所有事务均为成功状态，无异常波动或业务失败，说明系统具备高效、稳定的业务处理能力，可可靠承载当前压力下的业务请求。