记录下之前测试过的一个比较有意义的技术需求，算是一个总结
---------------------------------------------------------------------------------------
背景介绍
我们社区业务模块，存在几个内容类型，酒话、酒评、文章和视频，由于前期需要营造社区的活跃气氛，需要支持部分虚拟数据生成。
为了减少人工操作，做成了配置化的定时任务，即机器人虚拟点赞及浏览两种常见功能。
- 首先分为点赞和浏览两个独立的功能
- 每个功能又分两个独立配置：执行时间配置与属性配置
一，配置说明
以点赞为例：
-
执行时间配置：
包括所属类型，开始时间与结束时间，如article内容类型在1点到早上6点执行
- 属性配置：
包括所属类型（type），次数最大值（max）与最小值（mix）区间，执行次数（executorTimes），执行状态（status），执行总时间（time），如article内容类型在1小时内执行2次，区间为每次点赞1-3次，则点赞区间为2-6次，30分钟执行一次。
二，定时任务说明
其中点赞涉及二个定时任务：
- 任务一是把点赞的数据对象存入redis，查询范围1小时，5分钟一次，需要去重已生成的数据，其中key为prefix加时间，value为map，map的key为类型，value为动态ID+次数。
- 任务二是读取缓存的数据对象新增虚拟数据，一分钟执行一次，要去除已点赞的虚拟用户，需要判断内容上下架状态。
任务一： 任务二：
测试分析
那么如何测试这个功能是否正常？
简单场景来看：对每个内容类型分别生成1条数据，查看规定的时间内点赞数与浏览量，对比配置的预期数据，符合则代表功能正常。
实际场景来看：在一个时间段内，每个类型内容的数量是不固定的，发布时间也是随机的，如何验证这种场景呢？
测试过程
基于上面思路，设计了一个大数据量功能测试，思路与设计如下：
第一步，测试设计
结合线上流量数据，使用jmeter生成内容数据，时间为1小时，而虚拟点赞共执行2小时，多出的一小时是保证最后一条内容能被执行到。
第二步，测试执行
1，完成下图的执行配置，先关闭任务执行开关。
2，Jmeter开始执行生成数据，同时打开点赞和浏览量任务开关，执行期间需要避免其他用户使用干扰。
3，1小时后Jmeter数据执行完毕，再等待2小时后虚拟点赞和浏览量任务执行完成。
第三步，数据分析
查询数据库，总计期间共发布2115条酒话（dynamic），2114条酒评（alcoholComment），文章（article）和视频（video）各10条。
统计发布内容的的点赞数或浏览数，判断是否在配置的区间内，下图可以看出酒话与文章数的点赞与虚拟浏览都在指定区间内，功能测试通过。
酒话数据如下：
文章数据如下（剩余其他内容类型略）：
第四步，资源占用分析
在4250条数据下，统计各资源占用：服务占用1.75G，redis内存占用6.5M，点赞执行时间806毫秒，浏览量执行时间为674毫秒，满足线上业务需求
定时任务的服务占用的最高资源如下（约1.75G）：
期间redis占用内存如下（约6.5M）：
日志记录的执行时间如下（点赞806毫秒，浏览量为674毫秒）：
测试注意
James Whittaker说过：“测试今天的项目，准备明天的项目”，以下是相关的测试经验：
1，我们的虚拟数据针对所有内容状态，记得考虑下你的内容下架后是否需要虚拟数据等等
2，我们的虚拟点赞会主动增加相应的浏览量，记得提前问下开发设计
3，需要考虑任务执行不完的情况，目前我们的点赞与浏览量配置，总执行时间不能小于1小时，而每次执行时间不能小于1分钟。
4，如果配置存在开关，需要考虑，关闭开关后，之前已生效的数据是否会继续执行
5，我们的内容在重复上下架内容期间，损失的虚拟点赞数不会补偿
6，我们的虚拟浏览量的max与min是指浏览量总和区间，虚拟点赞的max与min是指单次点赞量区间