如何在Loadrunner进行可靠性测试或者稳定测试

好久没在QQ上谈论这么长时间的测试了，而且今晚碰到了很多的老朋友，以下是关于讨论LR进行稳定测试性的一次交流：

windy 19:57:56
还准备跟你讨论个问题呢
Zee 19:58:05
什么？
windy 19:58:08
家里电脑坏了，现在上网真不方便  

Zee 19:58:20
呵呵，偶在家里都不上网。
windy 19:58:28
你有做过稳定性测试么？就是可靠性测试
Zee 19:58:45
嗯。
Zee 19:58:54
做过，怎么了。
windy 19:59:27
你在做稳定性测试的时候所选的案例里，会不会选提交类的业务
Zee 19:59:57
会，不过一般用户不会太多。看具体的客户需求了。
windy 20:00:29
如果选提交类的业务的话，会存在一个问题，稳定性测试一般要求运行72个小时，可是如果有提交业务，72小时运行下来，数据库会膨胀的
windy 20:00:48
这样越到后面事务的响应时间肯定会越差
Zee 20:01:13
为什么会越来越差？膨胀到什么程序？
windy 20:01:15
如果数据量增长呈数量级别的话，一般都会这样
Zee 20:01:17
什么程度？
windy 20:01:38
一般从几万条记录到百万级别的记录了
Zee 20:02:33
那要看后面的响应时间慢是因为什么了。提交往数据库里写数据。不会查询。
Zee 20:03:19
可能会判断重复数据的时候，时间时间会增长。你们的应用是什么样的？
windy 20:03:22
TPS若为3.5的话，那么一个小时就会提交3.5*60*60条记录，72小时会提交907200条记录，这是一个提交脚本的
windy 20:04:12
会有查询是操作的，一般我选的案例是组合场景，既有查询操作也有提交操作
Zee 20:04:20
哦，
windy 20:04:34
选的脚本大约有20个，组成一个组合场景
Zee 20:05:19
哦，你做的时候，是不是响应时间超过了用户的要求？
windy 20:06:15
稳定性测试的原则是在给服务器加压大约70%~90%之间，持续运行72小时无中断，无报错，事务响应时间波动率我们要求<8%,服务端资源利用率波动率要求<20%

 
windy 20:06:56
不是的，稳定性测试的指标一般对单个业务的事务响应时间要求不大
Zee 20:08:01
你们的应用要求挺细致呀。
Zee 20:08:31
你们的用例是从用户的需求中转化来的吗？
windy 20:09:32
上一个大版本我做稳定性测试时，没有选择有提交业务的脚本，因为当时我觉得从稳定性测试的原则和目标来看，只要对服务端施加的压力足够就OK，而不必要考虑具体你加压的是哪类业务的脚本
Zee 20:10:06
看客户的应用了。
windy 20:10:08
但是这一个大版本，有人提出要求要接近客户的真实场景，那么就得把提交类的业务也加上去
windy 20:10:38
当然，用例是根据实际业务场景设置的
windy 20:10:49
我们是做产品的，因此用例一般比较固定
Zee 20:10:51
嗯。那问题是什么？
windy 20:11:54
问题是，如果加了提交的业务，那么数据膨胀起来，势必是越到后面性能会比前面的差
Zee 20:12:54
你看，你的应用是有这种需求的，如果后面响应时间超过了，那就分析原因了。如果放到具体的环境里，也会有这样的数量级的数据增长。
windy 20:13:07
因为我们的数据量增加太大了，一条记录通常会有上百条分录，像上面我所说的，一个提交业务72小时运行下来大约会增长90万条记录，那么分录的表增长就是90*100条
windy 20:13:58
分析环境也没用的，oracle的优化机制并没错，而且所走的索引也是合理的
Zee 20:14:05
所以用例是没有问题的，就看结果中哪里的时间更长了，有没有调优或者应用程序调整的需要。
windy 20:14:43
我的想法是，对于提交类的业务做提交即删除处理，这样既测试到了提交操作，同时数据库也是稳定的
Zee 20:14:57
那环境最优只能这样了，还能怎么办？增加硬件吧。
windy 20:15:04
这个不是应用程序的问题，也不是调优的问题
Zee 20:15:06
但是你到了实际环境中，其他的提交也有。
windy 20:15:12
是数据量增长的问题
windy 20:15:28
实际的环境中数据量增长不会有这么大啊

 
kernzhang 20:15:31
Zee，你是在所答非所问
kernzhang 20:15:36
呵呵
Zee 20:15:39
哦？
Zee 20:15:56
我理解可能有问题。
kernzhang 20:15:58
他问得是这个可靠性场景设计的问题
kernzhang 20:16:09
你在解释出了问题该如何分析
windy 20:16:16
KERNZHANG 
Zee 20:16:33
我的意思是。
Zee 20:16:47
如果具体的应用环境中有这样的数据量的提交，那就做。
kernzhang 20:16:56
我来问windy几个问题
windy 20:17:01
 我不是问怎么分析的问题
Zee 20:17:12
如果没有的话，就做符合具体环境的提交场景设计。
windy 20:17:21
kernzhang，请讲
kernzhang 20:17:23
1、真实业务中正常运转时数据库中有多少数据
kernzhang 20:17:31
估计1年之后
windy 20:18:19
一年时间的话，最大的表应该有700万左右的记录
 
kernzhang 20:18:22
对比的表是你做稳定测试时涉及到的表
windy 20:18:28
是
kernzhang 20:18:49
那么稳定性测试时，你的表中最多有多少？
kernzhang 20:19:10
条记录

 
windy 20:19:25
暂时的是50万多
kernzhang 20:19:41
那么你这种担心是不成立的
windy 20:20:11
也就是说应该按照客户真实场景设置，对吗
kernzhang 20:20:30
是的！稳定性测试是疲劳测试的一种
kernzhang 20:20:37
而不是压力测试
windy 20:20:47
对于我的这些指标呢，会不会有影响：
稳定性测试的原则是在给服务器加压大约70%~90%之间，持续运行72小时无中断，无报错，事务响应时间波动率我们要求<8%,服务端资源利用率波动率要求<20%
kernzhang 20:21:05
你这个有问题
kernzhang 20:21:21
不管压力测试或者稳定性测试肯定有出错
kernzhang 20:21:43
但是你要制定好出错的比率以及出错不能导致应用中断
windy 20:22:22
稳定性测试的目标就是连续运行72小时无中断无报错呢
windy 20:22:39
上一个版本我测试了25次，才成功
kernzhang 20:22:42
没有这样定义的
kernzhang 20:22:54
在现实操作也可能出错！
kernzhang 20:23:10
但是不能因为出错导致应用中断这是必须的
kernzhang 20:23:53
比如说：某一些操作超时也很正常
kernzhang 20:24:33
稳定测试实际你应该关注3个方面的东西
windy 20:24:40
是可能出错，但是出错的比率应该在一个范围内。是我说错了，应该是连续运行72小时出错比率<8%,响应时间和服务器计数器波动率<20%，不好意思是我说错了
kernzhang 20:24:52
呵呵
windy 20:25:09
俺现在终于找对人了 
kernzhang 20:25:32
不是哦！刚才是Zee没理解你的意思

 
Zee 20:25:37
那偶就到旁边听着了。哈，
Zee 20:25:47
还是张大哥，有经验。
windy 20:25:57
kernzhang，方便的话能给个电话不 
Zee 20:26:09
偶一边看电影，一边说话。一心二用。哈。
windy 20:26:11
恩，是我表达没表达清楚，不好意思
kernzhang 20:26:47
你要关注第一个是要模拟客户的真实操作，别想压力测试那样给与过大的压力
kernzhang 20:26:58
第二、避免测试过程中的缓存
Zee 20:26:59
应该是偶理解力不够强。哈
windy 20:27:57
对，我给服务器端施加的压力大约在70%~90%之间
windy 20:28:26
你的意思是要把所有的缓存机制取消吗
kevin.hg 20:28:26
。。。一边潜水学习。。。看高手过招。。。
kernzhang 20:28:33
第三、因为稳定性测试时，你必须要考虑到测试结果的收集导致测试的不准确，因为此时的测试会导致大量测试数据的收集
kernzhang 20:29:05
可能的结果是服务器没死！你的测试机快完蛋了
windy 20:29:46
目前我的案例是采用了缓存机制的，因为客户实际场景也是这样，事实上，我现在的是C/S架构，是采用的胖客户端的机制
kernzhang 20:30:05
缓存是必须
kernzhang 20:30:20
的！但是你不能产生额外的缓存
windy 20:30:51
额外的缓存不会有的，这一点我在设计用例的时候就注意到了
windy 20:31:10
这一点还不是很明白：
kernzhang(275624143) 20:28:33
第三、因为稳定性测试时，你必须要考虑到测试结果的收集导致测试的不准确，因为此时的测试会导致大量测试数据的收集
kernzhang(275624143) 20:29:05
可能的结果是服务器没死！你的测试机快完蛋了
takiro 20:31:19
额外的缓存,可以举个例子吗?
kernzhang 20:31:26
重复的数据

 
kernzhang 20:31:35
缓存杀手！哈哈
windy 20:32:04
比如？
kernzhang 20:32:37
kernzhang(275624143) 20:31:30
重复的数据
takiro 20:32:54
不过重复的数据产生也需要通过服务端做压力过滤吧
takiro 20:33:08
过程上还是处理了啊?
windy 20:33:12
是不是像数据库的trace一样，当我把跟踪开启后，这个trace本身就要消耗一定的资源
windy 20:34:00
我想想
kernzhang 20:34:14
呵呵！比如说：我们在做稳定性测试时，我们的数据准备不足！那么我只好采用数据循环
windy 20:34:36
哈，明白了，谢谢 
kernzhang 20:34:43
一旦循环多了！那么结果就可能变得请求越来越快
takiro 20:34:48
恩
takiro 20:34:49
对.
kernzhang 20:34:52
而不是你说的越来越慢了！呵呵
takiro 20:35:16
相当于咋们看网页.也会保存cookies
 
windy 20:35:21
但是所启的线程不一样啊
takiro 20:35:45
线程?
windy 20:36:23
这个我试过，一般来说首次登录会较慢，一旦登录成功后后面的操作时间都差不多，不会越来越快的
windy 20:36:35
应该是session