记录下之前测试过的一个比较有意义的技术需求，算是一个总结

---------------------------------------------------------------------------------------

背景介绍

我们社区业务模块，存在几个内容类型，酒话、酒评、文章和视频，由于前期需要营造社区的活跃气氛，需要支持部分虚拟数据生成。

为了减少人工操作，做成了配置化的定时任务，即机器人虚拟点赞及浏览两种常见功能。

1. 首先分为点赞和浏览两个独立的功能
2. 每个功能又分两个独立配置：执行时间配置与属性配置

一，配置说明

以点赞为例：

• 执行时间配置：

　　　　包括所属类型，开始时间与结束时间，如article内容类型在1点到早上6点执行

• 属性配置：

　　　　包括所属类型（type），次数最大值（max）与最小值（mix）区间，执行次数（executorTimes），执行状态（status），执行总时间（time），如article内容类型在1小时内执行2次，区间为每次点赞1-3次，则点赞区间为2-6次，30分钟执行一次。

二，定时任务说明

其中点赞涉及二个定时任务：

1. 任务一是把点赞的数据对象存入redis，查询范围1小时，5分钟一次，需要去重已生成的数据，其中key为prefix加时间，value为map，map的key为类型，value为动态ID+次数。
2. 任务二是读取缓存的数据对象新增虚拟数据，一分钟执行一次，要去除已点赞的虚拟用户，需要判断内容上下架状态。

　　　　　　　　　任务一：                                                                                     　　　　任务二：

测试分析

那么如何测试这个功能是否正常？

简单场景来看：对每个内容类型分别生成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是指单次点赞量区间