LoadRunner性能测试工具实战视频教程【全套26集】
随机函数
在软件测试工具中如何巧用LoadRunner的随机函数。
LoadRunner有自带的随机函数，如果巧妙的加以采用，能解决一些看似很困难的实际问题。
一个项目的性能测试。与数据库直连，根据外部传入的SQL ID和SQL参数，从指定数据库中读取SQL模版，拼装成真实的SQL语句、执行，并将得到的结果放入缓存中。目的是减少数据库的压力。
该系统将支撑大量的SQL操作，性能自然成为备受关注的焦点之一。
由于它跟SQL语句相关，在真实环境下，同一时间可能执行着不同类型的SQL，即便是同一类型，其参数也各式各样。那么，怎样才能模拟出最符合实际情况的性能测试场景呢？
首先设计场景，即，在LoadRunner中按照比例随机取到某一类型的SQL，再随机传入参数给它，让最终的每条SQL都是随机生成，各不相同。
从场景中，可以看到，此处涉及双重随机。只采用loadruner的参数设置是无法实现的。此时需要想办法先按设定好的比例随机取到SQL，然后在每条SQL上随机取参数列表中的参数。
于是想到了loadrunner的随机函数。先实现随机取SQL ID，之后再在特定的SQL中随机取参数列表中的参数。
LoadRunner中，随机函数是rand()，它用来产生0到rand_max之间的随机整数。函数原型是
int rand (void);
然而调用rand之前，必须给随机数产生一个随机种子。这个种子由srand()函数产生。其原型是
int srand (seedTime);
<sup>2</sup>
分析占用率
1. 平均事务响应时间
Average Transaction Response Time
优秀：<2s
良好：2-5s
及格：6-10s
不及格：>10s
2. 每秒点击率
Hits per Second
LoadRunner分析页面
LoadRunner分析页面
当增大系统的压力（或增加并发用户数）时，吞吐率和TPS的变化曲线呈大体一致，则系统基本稳定。若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是网络出现带宽瓶颈，同理若点击率/TPS曲线出现变化缓慢或者平坦，很可能是服务器响应时间增加，观察服务器资源使用情况，确定是否是服务器问题。
3. 请求响应时间
Time to Last Byte
4. 每秒系统处理事务数
Transaction per second
5. 吞吐量
Throughout
6. CPU利用率
Processor / %Processor Time
好：70%
坏：85%
很差：90%+
7. 数据库操作消耗的CPU时间
Processor / %User Time 如果该值较大，可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器， Processor\%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。
8. 核心态CPU平均利用率
Processor /%Privileged Time 如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统
9. 处理队列中的线程数
Processor / Processor Queue Length 如果该值保持不变（>=2）个并且%Processor Time 超过90%，那么可能存在处理器瓶颈。如果发现超过2，而处理器的利用率却一直很低，那么或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。
10. 文件系统缓存
Memory / Cache Bytes 50%的可用物理内存
11. 剩余的可用内存
Memory / Avaiable Mbytes 至少要有10% 的物理内存值
12. 每秒下载页数
Memory / pages/sec
好：无页交换
坏：CPU每秒10个页交换
很差：更多的页交换
13. 页面读取操作速率
Memory / page read/sec 如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
14. 物理磁盘利用率
Physical Disk / %Disk Time
好：<30%
坏：<40%
很差：<50%+
15. 物理磁盘平均磁盘I/O队列长度
Physical Disk / Avg.Disk Queue Length 该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘
16. 网络吞吐量
Network Interface / Byt
3
993
175.62MB
2021-03-06
0
