抽奖系统的测试报告

背景

无论是线上电商，线下门店，品牌活动还是互联网平台，都需要一种有效的手段来吸引用户，激发用户的活跃度，有效刺激用户的消费神经，从而实现销量的增加，扩大品牌的曝光度以提升品牌的影响力从而进一步为社会做出贡献。而抽奖系统活动以其近乎无参与门槛，高趣味性和极大的不确定性带来的刺激感，充分调动用户的情绪，使其成为了一种极其受欢迎且高效的营销手段。可以快速聚集人气，制造话题，并在短时间产生大量的用户互动，使用户的情绪与交际获得极大的满足。但是传统的线下抽奖（比如抽奖箱，转盘等）存在效率低下，透明度低，易出错，等等难以控制的缺点。随着互联网的进一步发展，线上的抽奖系统孕育而生。它刚刚好能够克服传统线下抽奖的缺点（也就是线上系统的优点）实现自动化，规模化，数据化的运营。

而线上抽奖系统通过算法的随机性，记录的保存和过程的不可篡改，过程可追随，规则公开透明，从而打消了用户对于“暗箱操作”疑虑。而用户只需要输入自己的代号和极其简单的几下点击就可以实现线上的抽奖，并且即时完成抽奖，这种即时反馈极大的满足了用户的参与感。

系统功能

在如此的社会需求之下，抽奖系统的开发就孕育而生。本项目清晰的展示了抽奖的活动海报，奖品信息，活动时间等，吸引用户参与。而参与方式页的设计方式也是以最适合现代人的设计方式来设计的——高效。用户只需要输入自己的代号，然后就可以等待主办方，进行抽奖，而抽奖过程中，姓名的随机变化，以及主持人的随时点击，从而进一步的完善了抽奖系统的随机性。而点击的瞬间，用户的代号出现，即时表现出了中奖者的身份。给予用户极大的即时满足，而不在现场的用户，我们页推出了短信，邮箱提醒的机制。使不错过每一个中奖者的同时，也可以分享给自己的朋友与朋友一起享受幸福的瞬间。

如何开发

本项目在使用了SpringMVC的同时，还通过了通过了解了阿里的开发约定手册进行了进一步的开发约定，比如通过把数据库映射出来的对象封装为do，把service向外传输的对象的封装为dto，使得项目的可读性得到了进一本的提升。

同时通过了SpringBoot框架的拦截功能，拦截下来外部对网站的不法访问，也通过此功能实现了强制登录的操作，而我们不是使用之前的cookie，而是使用了现在流行的jwt令牌，通过jwt令牌，通过验证的方式，不仅把用户的认证信息存放到了用户自己的手中减轻了服务器的压力，同时保护了数据的安全性。而统一数据的返回格式，就实现了对服务器返回的数据进行了进一步的封装，大大的提高了前端对于数据的处理。我们通过把数据封装为状态码，data和错误的文字信息，对前端更加友好的同时，也提高了我们后端对于定位bug的能力，进而提高了我们修改bug的效率。

而数据的封装方面，我使用了MyBatis操作数据库，不仅使用了基本的mysql语句，也进一步的使用了动态sql进行了查询，而我们也使用了加盐加密的方式，通过把用户的数据加一个随机盐值，再通过一个加密算法，变为密文存储再数据库中，使得内部人员泄密的难度大大提升，而我们确认密码也很简单，只需要把用户输入的密码进行同样的操作就可以查询出来，并不需要从数据库中取出正确的用户密码进行对比。但是从数据库中访问数据的效率，我们觉得还是不可以提供给用户足够的体验，所以我们对数据的查询进行了进一步的效率提升，我们使用了redis的缓存机制，把经常需要查询的数据放入的redis中，因此对于同一个用户来说，后面使用的该项目的体验要进一步的提升。

而control，service的实现方式，我以阿里开发手册的标准严格要求自己，进而保障了代码的可读性。

而在实现抽奖接口的时候，因为抽奖接口，需要实现事务的一致性，实现就全部实现，异常就需要全部回滚，但是那时的我还不是很知道因此实现出来的代码仅仅使用了@Transactional，但是这样实现的接口不仅仅数据没有回滚，而且扩展性特别差，还有很强的依赖性，因此在实现这个接口的时候我遇到了一些困难，因此我经常在博客中查询别人的总结，从而知道了两种设计模式，责任链设计模式和策略设计模式而这两种设计模式可以充分的解决代码的扩展性查和依赖性强，我们把每一件事封装成一个类，而我们先对类实现了一个排序，需要先执行我们就返回小的数，而后执行的我们就返回一个较大的数，而每一个要实现的代码都各自放在各自的类中，从而使得代码的扩展性大大提升，也降低了代码的依赖性。同时我们也考虑到执行执行代码所需要的时间可能就比较长的，所以我们使用了rabbitmq队列来对这些操作进行了一个规划，在抽奖结束，我们就把数据接受成功返回给前端，保障客户的体验，而没有进行的操作就存储在队列中，等到服务器空闲的时候处理，而出现异常的话，我们也设置了死信队列来处理，方便我们在后续修改。

而不在现场的用户我们也通过阿里云短信服务实现来短信通知中奖者（但是因为我没有通过阿里云的短信服务的校验，我只是在服务器中看到验证码从而登录），我们还实现了邮箱的通知服务，确保每一位中奖的用户就收到这一份喜悦。

在实现了这些的同时，我也进行了云服务的部署使得大家可以随时随地进行抽奖和查询中奖的中奖数据。

测试用例

当然这个只是基于代码层面的东西，我们的测试用例页远远不止这些。

就比如说我们的界面是否好看，系统的兼容性怎么样，这些操作是不是简单易上手，安全性怎么样，在登录的时候信息的传输有没有加密。这些都是我们需要测试的东西。

而我们还有最后一个性能测试，就把文件上传了，大家看看就好了。

而需要代码的话lottery_system: 抽奖系统 - Gitee.com可以通过这个访问