一次数据仓库报表测试（2）

1.背景

      最近终于将这个项目测试结束了，之前写过一篇文章，写的是测试过程中遇到的问题，感兴趣的同学可有先去看看上一篇文章。

2.目的

      项目结束后问题也没有得到根本解决。宝路由此引发了一些列的思考，今天想跟大家聊聊。

3.引发的思考

     前一篇文章写了压测报表系统时的问题，问题抛给某厂商后，厂商人员来了两次做现场支持，然而效果并不理想。深问其产品底层原理，为什么内存回收后会导致，报表系统的“不可用现象”，然而。。。。。。

     在这里吐槽下，派来支持的人，远程桌面怎么最小化都TM的不清楚，我也是醉了。

思考1：脚本采用匿名登录的方式来查询报表。

    先解释下这里所说的匿名登录，其实就是个白名单，将执行脚本的机器的ip增加值白名单，然后可以通过指定的url来获取token，再拿这个token来访问指定报表。这样就避免了登录系统的步骤。（因为他们自己都没解决登录系统的密码加解密问题，当时也跟他们聊了为不能提供登录密码的加密方式，然而回复却是，目前他们自己测试也是采用匿名登陆方式）。

    这样的脚本就极其简单，发送请求获取token，再发一个请求（带token)来查看报表，这种方式是否合理？试想真实环境中用户是这种场景么？显然不是。。。。。试想下这样的方式与真正用LR录制出的脚本相比是不是会少了好些页面请求？

思考2：忽略思考时间这种压测方式到底有没有问题

   这又要说到，前篇文章测试中提到的压测问题。采用忽略思考时间这种方式压测，报表系统长时间压测就会出现前篇文章中所说的问题。这里又要说到OLTP，OLAP

什么是OLAP：联机分析处理

什么是OLTP：联机事务处理

   我们常见的接口压测（说的再范围一些就平常的增、删、改、查）都是属于OLTP , 然而OLAP 一般就是数据仓库系统的主要应用，用来分析大量OLTP形成的数据，说白就是对这些历史数据进行加工分析，读操作较多。

   最后解决方案就是，增加pacing值，3s , 4s ,5s 分别进行了尝试。其实就是对之前的脚本进行了弱化（从发起压力角度来说），这样更贴近真实的业务场景。本来在线用户就少，其实远未达到忽略思考时间的那种查询密集度。现实中也不可能存在业务人员疯狂在不停的查询报表。

  但最后还是要说下，忽略思考时间的这种方式本身没有问题。确实不太合适当前的场景，假如真的就是存在这种场景，或者说我就要看你系统在高点击率下的性能表现，那么就要采用这种方式了。

   问题又来了，在这种高点击率下，长时间（大概20min）的压测，系统却出现了不可用的现象且短时间不可恢复，需要手动重启产品的某个服务才可以，这种现象我觉得是不ok的。这就需要产品人员深挖其原因，是不是产品缺陷导致的。