《让LoadRunner走下神坛》

这几天碰到这么几件事情，觉得挺有意思的：
1.        有个朋友问了我一个问题：LoadRunner的缺点在哪？然后我反问她：LoadRunner的优点在哪？她一时语塞，后来说：感觉都是优点没有什么缺点呀？
2.        一个网友跟我说：我觉得会用LoadRunner的人很强。我说：LoadRunner只是一个工具，并且功能也很有限。

对于大部分测试人员来说，学习从工具入手都不是坏事，但是过于在意工具肯定是件坏事，也许我们经常从工作几年人的嘴里听说过这样的话：工具仅仅是工具而已，主要是思路。这种话让我们有种忽悠的感觉。下面正面谈一下LoadRunner。

1.        LoadRunner 阻碍了性能测试人员对通信过程的理解
我
希望做性能测试的人能忘掉这个工具。我们都知道VuGen有录制的功能，其实录制这个功能对于测试来说是个非常不好的选择，就是跟后面的场景执行带来很多
的不定的因素。因为一些人对脚本的不理解，或者说根本就不知道脚本是什么意思，导致了出现一些性能问题的时候，束手无策。也不知道如何去查找原因。所以我
觉得性能测试人员手写脚本是最好的选择，但是难道录制功能就不可用吗？当然不是这样，不过如果录，就一定要知道脚本中各个函数的含义，要彻底明白这些函数
想完成什么功能，能实现什么，不能实现什么。这样才能在出现某些问题时，知道如何去解决。并且问题的解决过程要依赖其他的知识，并不是会了LR，找了帮助，就可以解决得了的。所以依赖工具要有个度，不然做的性能测试也不可信。
我
们都知道LR支持了很多网络协议，并且根据这些具体网络协议衍生出各自的专用语言，这个应该是它最大的优点了，但是LR也并不是对这些它声明了支持的语言
都支持的很好的。我们知道在8.0版本的时候，LR里面就已经有了Java
ajax的协议，但是如果不修改配置文件是不显示出来的。那到现在9.5的版本，早已经把这个协议公开出来了，但是用这个协议还是感觉遇到很多这样那样的
问题。同样，其他有些协议也是这样。会用工具，和会做性能测试，绝对是两回事，所以不要太依赖LR。我们都知道Mercury提
出了BTO的概念，所以很多LR里的概念设计也是从business的角度来解释的。做测试的专业人员，要了解它的这些概念和我们具体的环境之间的关系，
否则只能照搬照套。所以也可以这么说，LR的重点在于对协议的掌握程度，不一定都会，但是要特别精通某些一些跟自己测试密切相关的。其实我们的测试人员很
多都不太了解上述的 ajax架构，所以即使做了性能测试也是“止于外表，不及其里”，那么就浪费资源了。
再说一点，LR对数据库的
支持。一直以来，我们知道，在LR里要想直接面对数据库测试，是比较麻烦的（相对http协议来说）。前几天，看了一下其他的工具，有些工具中把和数据库
通信做成了相应的模块，操作起来，很简单，需要编写的代码也比较少。这样的功能就比LR中做的要好。但是我们也要理解，LR是
BTO概念下的产品。值得注意的是，开发很多都会用到类映射数据的模式进行相应表操作（例如hibernate），这样在性能测试的时候需要特别注意对应
用服务器的进程设置，也许会出现这样的场景，数据库服务器无压力，应用服务器已经提前“阵亡”了。

2.        LoadRunner简化了性能测试过程
从
Mercury的性能测试执行流中可以看到，它分成了这么几个部分：计划测试、创建脚本、创建场景、执行场景、分析结果。这种分法，可以说代表了性能测试
过程中的主要部分。但是这个过程也会导致结果混乱。首先，性能测试需要调研，并且需要调研的很细，可能在大部分的公司里都没有做到这样，但是，这不能说明
调研这部分是可以忽略的。我们经常会遇到性能测试做完了，还在讨论性能测试需求的现象。这对于我们来说不能不说是难受的事情。还有建模，LR的方法论和执
行流中都没有提到建模这一过程，而在实际的应用环境中，我们还是要考虑这一过程，只有这一过程才是场景设置的前提。应该说，在LR中做不到建模，但是应该
在执行流和方法论中提到它。在一个完整的性能测试过程中，还有很多的管理上的因素制约，当然，这个不能依赖工具。我们后面再谈相关的问题。
在LR
的市场如此强大之下，我觉得应该只考虑到它是一个工具，而不是可以完成性能测试整个过程中的事情的万能产品。我在遇到很多初学性能测试和已经做过一段时间
的性能测试的朋友，经常被问到类似这样的一些问题：我会用LR了，我可以做性能测试了？我们公司有LR了，我们可以推广性能测试了吗？或者更严重的，有了
LR，性能测试就有了保障的感觉。它并不是尚方宝剑，我们拿了谁都能砍。实际上，知道如何砍或者怎么砍才是最重要的，竹叶也是利器。
我碰到过好几
次这样的现象，客户认为给了两天的时间或者一天时间就可以把一个性能测试做完了，因为你用的是工具，并且它又能自动生成结果。而往往，一个非常非常熟悉工
具的人，对过程和结果的分析都不是很清楚。并且写报告时也只能描述表面的现象。这样的性能测试只能说有个警示的作用，对实际的系统质量提升意义都不大。有
一个80年代就开始写程序的同事说：“这种性能测试方式，对系统质量一点都起不到保障作用，只是忽悠客户。”并且系统级别的性能测试已经不可能从大局上去
改变什么了，只能寻找一下系统的缺陷，也谈不到对调优有什么建设性的指导意义。而LR的设计主要还是面对系统级的性能测试，所以我们使用它，要了解它能给
我们带来什么。也许有人要钻牛角尖，我就用它来做更细的代码和集成的性能测试不可以吗？也不能说完全不能，用牛刀杀鸡也是行的，就是挥着过重，搞不好鸡没
杀好反而平添肩周炎。

3.        LoadRunner的监控弱点
前几天被问到LR对数据库和应用服务器的监控问题，我
一直在建议他们用其他的工具去做。因为LR的监控只是一个壳子，并且个人认为，是个效率不是很高的壳子。就拿对oracle的监控来说，我们都知道LR在
连接了oracle之后，会有两个表可以选择，里面有很多的计数器，对性能测试工程师来说，选择什么计数器，都是很为难的事情，因为不知道这些计数器是什
么意思。所以大部分情况下，我们看到一些人的推荐就是选择默认的那些（在help里有一些说明）。如果我们遇到的问题正好在我们选择的那几个计数器里有体
现，还真是太幸运了。不过这种现象就像走在路上捡了一百块钱一样不稳定。所以我们还要反复的去执行场景以判断问题出现的瓶颈。这对我们性能测试来说是很痛
苦的事情。因为有些场景可以执行了好几个小时，好几天，甚至一周时间。监控Weblogic也是一样，我宁可肯定用WebLogicScripting
Tool去写脚本监控，也不是很推荐用LR的监控功能。就算排除工具之间的兼容性不说，我觉得LR做到的监控也比性能测试过程中想达到的效率要差不少。当
然，有些商业工具已经做的相当好了，并且资源占用还可以接受。对unix的监控也是这样，我们如果用LR来做，可能不知道什么时候，RPC就倒塌了。我们
不得不重头再来，这一点对我们长时间的场景执行来说，都是致命的伤害。用LR监控unix，尽量的可不用就不用。用nmon或者使用UNIX自带的性能监
视工具都可，什么top啊glance啊有的咱们都上，不过最后提醒一句，它们的运行也都是需要申请主机资源的。
因为很多人喜欢在一个结果里看到
所有的数据，目的是为了保证数据的同步性，所以不遗余力的在LR中完成这样那样的监控功能。但是不管数据在结果中有多全，对结果的分析还是要靠自己敏锐的
嗅觉和丰富的经验，并且，LR中实现的这样的监控点其实效率并不高，所以我推荐的是，用最少的资源做最多的事情。不要太依赖某个工具。我现在的工作中，做
一次完整的性能测试，都会用到很多个工具，组合这些工具的结果，一起分析。并且有些功能的实时查看功能要比LR强很多。再加上，LR的结果直接生成的报
告，也不可能做为我们的最终报告来用，所以让所有的数据都在分析器里的做法，只具有无意义的个人完善感，对实际的结果意义不大。

4.        LR是个前端工具
（这里说的前端工具，不是指页面的展现，而是为了强调在一个应用中LR工具所在的位置）
通
常情况下，在LR中能够体现出来的问题，已经是经过了系统中一系列的处理之后抛到LR上的，所以，我们再讨论LR的某个错误代号和打印出来的那一串串红色
的字符串已经没有实质的意义了。还需要进一步去分析应用的整个通信过程，才能找到最终问题本质。例如某些程序员喜欢把原始SQL语
句直接写到代码中，几百万行你哪里找得到？性能出来了就很难看，
LR肯定会告诉你机器IO吞吐的厉害，再细分原因就啥都没有了，与其这样还不如自己写性能分析器呢。就像昨天刚给一个朋友解决的一个思考时间放到for循
环内部和外部就出现不同的错误一样，如果仅仅看LR，肯定只能描述这个问题的现象，而找不到问题的原因。
在LR的场景执行过程中，所有的默认获取
的数据，都是从LR这个工具本身得到的，也就是说这些数据，都不能直接反应服务器的性能状况。我们分析这些数据的时候，一定要给出相应的服务器端的数据，
以证明我们的这个数据是有意义的。单独说TPS有多少，响应时间有多大，吞吐量有多高，一点意义都没有。因为这些数据是有前提的，而这些前提，LR都提供
不了。
当然，所有的压力产生的工具，也都是前端工具。把它单独拎出来说的原因是要说明，性能测试并不是一个前端工具，可以做得完的。它只能是一个承载现象的工具。真正要做的还是后面的分析。

5.        关于分析和调优
在
分析这一块，analysis还是给出了不少好用的工具的，当然这些工具对数据的处理，也是有一定的原因和规律的。我们还要了解到这些，才能对一个结果做
非常完善的分析。就拿一个简单的例子来说，LR中提供的响应时间在summary里为什么是最大、最小、平均、标准方差、90%这几个值？我们要了解这些
的原因，再去做详细的分析，从而可以完善的对前端的数据做分析了。但是这些分析，都不能成为报告中的关键数据，因为还需要对一个系统的所有层面做分析才能
在报告中写上有建议性意义的部分。我们做性能测试，不能说，可能是什么原因引起了什么问题，我经常看到这样的报告。这样的报告，如果是写给我看的话，我肯
定是打回去重写。我们面对客户的时候，也会出现这样的问题，前一阵子刚做了一个项目，另一个同事写的报告，就让我从头到尾的改了一遍，因为原来的报告中只
是数据的罗列。
相对来说，LR在罗列数据这一块，做的还是最好的。但是，LR不会告诉你你测试的结果怎么样，当然你可以设置SLA，但是也没有什
么用，因为这个设置是在你知道你的目标的前提下，这里仅是拿SLA和测试结果做个对比，以供写报告时好看而已。当然分析数据中包括DB、APP、
Middleware等等的数据时，我们还要查看相应的监控结果。分析是一个顺藤摸瓜的过程，千万不能断，断了就只能描述过程，而得不到结果了。上面说监
控时，我强调的是用一些厂商自己的监控功能，这时就会有非常好的效果了。我们不能让LR告诉我们Top 5 of
SQL，但是Statspack可以告诉我们。其他的监控工具类似。所以如果你想做好分析，还是用更好的监控工具，这里言下之意就是：LR在很多方面都不
是最好的监控工具。
调优，同样，LR绝对做不到调优，因为它连分析都做不到。只有靠我们自己顺着藤摸到了瓜之后，再想办法把它摘下来。如果这个过程中用LR的监控功能，很容易断线，所以调优靠这些数据，会更累。

6.         软件性能工程
前几天，我在修改自己的7点测试论坛中的性能分区名称的时候，一直想不起来给性能测试这个大分区取一个合适的名字。最后终于定位到一个词：软件性能工程。
在
每一个软件性能测试项目中，这都是一个工程，工程就要有角色划分，有职责划分，有时间进度控制，有风险控制，等等内容。而这些都不是一个工具可以代表的，
管中窥豹，永远不知道它长什么样子。我们也不能拿着LR到处去说，我可以做性能测试。而在整个软件性能工程中，我们要做的更多的是管理和控制的工作，这些
才是我们性能测试关注的重点。一上来就拿着LR录制脚本加压的性能测试工程师，我认为肯定不是好的性能测试工程师。但是每个人都要从拿着工具去录制脚本加
压这个过程认认真真的学习过来。也要对每一个操作和步骤认真的思考和理解，以完善对软件性能工程的认识。也许有一天性能测试版块里能加入一些真正的系统专
家，那确实是性能测试领域之福了。
软件性能工程，是一个完善的整体的概念，需要有大局观的认识。要从需要到最后的产品交付的每个阶段去关注性能
（这里不包括运维的阶段），也要明确的知道性能测试所占的整个软件性能工程的位置。从框架设计、模块设计、数据库设计，编码都要关注性能，往往发现性能瓶
颈后，由于整个系统设计上的问题，无法改变，所以性能无法调优，只能起到评价的作用。在这样的时候，即使性能测试人员能力再强，也翻不出什么花样来。
另外，软件性能工程是需要配合的，并不是一个拿着工具的性能测试工程师可以完成的事情，上面已经说到工程要有角色划分、职责划分，那我们的软件性能工程需要什么？软件性能工程需要的是：操作系统人
员、数据库人员、网络人员、中间件人员、应用服务器人员等等的配合，这一过程中，哪里有了问题，就需要相应的人去检查原因和解决问题。而有些公司和客户认
为一个或几个会工具的性能测试工程师就能完成一个完整的性能工程，我只能说，这些人都是全才（这样的人应该很值钱）。应用测试知识和技术手段，在多角色相
互配合之下，使得软件性能工程实施起来更具有可操作性，一个软件系统的性能才能更有保障。

仅以此文，记录我所理解的的性能测试和LoadRunner之间的关系。

-------我向来是看书很慢，看帖子，也都是细细的看的，尤其碰到好的帖子，没有体会的，估计也看不太明白