让loadrunner走下神坛(转载)
作者： sunshinelius
Loadrunner无疑是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果图表显示，拆分组合。相信有人这样想象过：拿着一张性能指标标准列表和测试数据相比较，如同PH试纸一样，遇碱则蓝，遇酸则红，一目了然，之后就可以大声地喊道：我找到了软件系统的性能瓶颈！
然而，我们无论在loadrunner前面加多少个“强大”、“智能”的形容词，别忘了其最终修饰的只是一个名词－“工具”。《大话西游》中也有相当精辟的论断：官兵？最多也只是个长了痔疮的官兵！把loadrunner比喻成长了痔疮的官兵有点粗俗，但loadrunner它是个工具，那么是否能够找到性能瓶颈就取决于使用工具的人，而不是工具本身。要做一个成功的性能测试，仅读懂和精通了loadrunner的使用手册是不够的，还需要对被测软件系统的方方面面都要有了解，比如软件体系构架，网络拓扑等知识。这就如同一个技艺高超的木匠，并不是因为他背熟了凿子，锤子的说明书，而是他能结合木材的质地和尺寸，用凿子和锤子这些工具做出一把精巧的椅子来。那么在性能测试中，人的智慧活动体现在哪里呢？
一．首先性能测试也是测试的一种，这就意味着做性能测试也要写测试案例。你所作的性能测试能不能足以支持找出性能测试瓶颈，和你在初期设计的测试案例关系甚为重要。我曾写过对一个软件系统的不下十个性能测试场景案例，等后来运行时却发现我必须增补几个案例才能找到瓶颈，而原来十多个案例其实重复甚多。如果你要写出好的不重复的性能测试案例来，你就得对被测软件系统有一定的了解。
在这里，我顺便插一句，在目前测试界总在争论测试人员需不需要懂编程，需不需要有开发经验这种问题，这完全是本末倒置，忘记了测试人员的目标是什么，测试目标就是写出好的测试案例，好的测试案例就是发现了一个原来未曾发现的软件bug。那么一个测试人员知识体系是否够用的标准就是能不能写出一个好的测试案例。而针对不同类型的测试，所需的知识深度是不一样的，有的是不需编程知识，比如界面测试；有的是必须有开发经验的，比如接口测试，不能一概而论。
对于性能测试来讲，我个人认为，测试人员倒不一定非要有开发经验，但是应该有一个对软件体系结构了解全面的知识。为什么呢？做性能测试时，如果从客户端施压一次就符合性能指标，碰到这种情况您就偷着乐吧，因为在你的指标场景下，软件系统中就不存在性能瓶颈，您也就不用费心去找了。但是大多数情况下，我们在做性能测试时，都不能顺利达到性能指标，可能server响应超时了，也可能是用户死掉了，在日志里抛出了一堆error，这种情形是非常常见，所以在我们在一开始设计性能测试方案时，就应该考虑为寻找性能瓶颈而设计测试案例。这时我们就需要知道在整个软件系统中，有哪些节点，在哪些地方可能存在瓶颈，比如一个B/S系统就有IE client→物理网络→web server→app server→DB这样的一个压力流串。每个节点的每个模块都有可能成为瓶颈。瓶颈的产生可能由于模块配置引起，也可能由于模块本身引起。这都需要我们设计测试案例来发现的。一般地，我自己常用的感觉也比较方便的方法是，设计一组性能测试案例来验证一个节点是否存在瓶颈，这组case中尽量保持其他节点不变，来改变这个节点的配置，并监控此节点的各种指标。这里说起来就有很多话了，不是一言两语能说得清的。以后有时间可以找个专题来慢慢跟大家讨论。
二．使用loadrunner的VU生成脚本。脚本的生成方式就两种，一种是自写或嵌入源代码，一种是录制生成。常常听见有人说，这两种方式中首选录制生成脚本，因为它简单且智能化。但我个人总觉得手写脚本要好一些，因为：
1．可读性好，流程清晰，检查点截取含义明确。业务级的代码读起来总比协议级的代码更易让人理解，也更容易维护，必要时可建立一个脚本库。而录制生成的代码大多没有维护的价值，现炒现卖。
2．手写的程序相比录制的脚本更能真实地模拟应用运行。因为录制的脚本是截获了网络包，生成了协议级的代码，而略掉了client端的处理逻辑。举个例子，用VU录制一个运行script和applet的IE行为，它只会生成http协议的API，在IE中运行的applet和script不会被模拟到，这就不是一个完整的系统。
3．手写程序相比录制脚本更能增加测试人员的技术含量。开发和测试能力双重提高，何乐而不为呢？loadrunner提供了java user，vb user，c user等语言类型的脚本，就是给我们开发脚本用的，而不是录制用的。
脚本不管录制也好，还是手写也好，选择的时候应该以脚本模拟程序真实有效为准，结合项目进度，开发难易程度等因素考虑。
在这里我想要说的是，开发一个好的脚本是成功性能测试的必要条件。一个好的脚本应该能够最大程度再现client程序行为。如上面那个例子，脚本只模拟了client端的部分行为，有一些没有模拟到，那么client的瓶颈就有可能被忽略了。我曾吃过一个亏，自己写了一个java socket脚本去联server，但是忽略了client端的界面下的业务逻辑，用我的脚本做性能测试通过，全部OK，但是真实用户一上线，client终端界面接受了大量的server信息，导致client进程死掉了。痛哉，痛哉。
三．组建并执行性能测试场景。场景是把虚拟用户和交易数按一定规则组织起来去模拟真实世界的业务行为。这其实是把单个用户的行为复制，连接。场景的组织通常和真实世界的业务规则有很大关系。
场景就像导演，脚本就像演员，多少个演员，怎么演，都由导演说了算，而剧情又不能离谱，脱离现实，否则就要砸锅了。
Loadrunner无疑是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果图表显示，拆分组合。相信有人这样想象过：拿着一张性能指标标准列表和测试数据相比较，如同PH试纸一样，遇碱则蓝，遇酸则红，一目了然，之后就可以大声地喊道：我找到了软件系统的性能瓶颈！
然而，我们无论在loadrunner前面加多少个“强大”、“智能”的形容词，别忘了其最终修饰的只是一个名词－“工具”。《大话西游》中也有相当精辟的论断：官兵？最多也只是个长了痔疮的官兵！把loadrunner比喻成长了痔疮的官兵有点粗俗，但loadrunner它是个工具，那么是否能够找到性能瓶颈就取决于使用工具的人，而不是工具本身。要做一个成功的性能测试，仅读懂和精通了loadrunner的使用手册是不够的，还需要对被测软件系统的方方面面都要有了解，比如软件体系构架，网络拓扑等知识。这就如同一个技艺高超的木匠，并不是因为他背熟了凿子，锤子的说明书，而是他能结合木材的质地和尺寸，用凿子和锤子这些工具做出一把精巧的椅子来。那么在性能测试中，人的智慧活动体现在哪里呢？
一．首先性能测试也是测试的一种，这就意味着做性能测试也要写测试案例。你所作的性能测试能不能足以支持找出性能测试瓶颈，和你在初期设计的测试案例关系甚为重要。我曾写过对一个软件系统的不下十个性能测试场景案例，等后来运行时却发现我必须增补几个案例才能找到瓶颈，而原来十多个案例其实重复甚多。如果你要写出好的不重复的性能测试案例来，你就得对被测软件系统有一定的了解。
在这里，我顺便插一句，在目前测试界总在争论测试人员需不需要懂编程，需不需要有开发经验这种问题，这完全是本末倒置，忘记了测试人员的目标是什么，测试目标就是写出好的测试案例，好的测试案例就是发现了一个原来未曾发现的软件bug。那么一个测试人员知识体系是否够用的标准就是能不能写出一个好的测试案例。而针对不同类型的测试，所需的知识深度是不一样的，有的是不需编程知识，比如界面测试；有的是必须有开发经验的，比如接口测试，不能一概而论。
对于性能测试来讲，我个人认为，测试人员倒不一定非要有开发经验，但是应该有一个对软件体系结构了解全面的知识。为什么呢？做性能测试时，如果从客户端施压一次就符合性能指标，碰到这种情况您就偷着乐吧，因为在你的指标场景下，软件系统中就不存在性能瓶颈，您也就不用费心去找了。但是大多数情况下，我们在做性能测试时，都不能顺利达到性能指标，可能server响应超时了，也可能是用户死掉了，在日志里抛出了一堆error，这种情形是非常常见，所以在我们在一开始设计性能测试方案时，就应该考虑为寻找性能瓶颈而设计测试案例。这时我们就需要知道在整个软件系统中，有哪些节点，在哪些地方可能存在瓶颈，比如一个B/S系统就有IE client→物理网络→web server→app server→DB这样的一个压力流串。每个节点的每个模块都有可能成为瓶颈。瓶颈的产生可能由于模块配置引起，也可能由于模块本身引起。这都需要我们设计测试案例来发现的。一般地，我自己常用的感觉也比较方便的方法是，设计一组性能测试案例来验证一个节点是否存在瓶颈，这组case中尽量保持其他节点不变，来改变这个节点的配置，并监控此节点的各种指标。这里说起来就有很多话了，不是一言两语能说得清的。以后有时间可以找个专题来慢慢跟大家讨论。
二．使用loadrunner的VU生成脚本。脚本的生成方式就两种，一种是自写或嵌入源代码，一种是录制生成。常常听见有人说，这两种方式中首选录制生成脚本，因为它简单且智能化。但我个人总觉得手写脚本要好一些，因为：
1．可读性好，流程清晰，检查点截取含义明确。业务级的代码读起来总比协议级的代码更易让人理解，也更容易维护，必要时可建立一个脚本库。而录制生成的代码大多没有维护的价值，现炒现卖。
2．手写的程序相比录制的脚本更能真实地模拟应用运行。因为录制的脚本是截获了网络包，生成了协议级的代码，而略掉了client端的处理逻辑。举个例子，用VU录制一个运行script和applet的IE行为，它只会生成http协议的API，在IE中运行的applet和script不会被模拟到，这就不是一个完整的系统。
3．手写程序相比录制脚本更能增加测试人员的技术含量。开发和测试能力双重提高，何乐而不为呢？loadrunner提供了java user，vb user，c user等语言类型的脚本，就是给我们开发脚本用的，而不是录制用的。
脚本不管录制也好，还是手写也好，选择的时候应该以脚本模拟程序真实有效为准，结合项目进度，开发难易程度等因素考虑。
在这里我想要说的是，开发一个好的脚本是成功性能测试的必要条件。一个好的脚本应该能够最大程度再现client程序行为。如上面那个例子，脚本只模拟了client端的部分行为，有一些没有模拟到，那么client的瓶颈就有可能被忽略了。我曾吃过一个亏，自己写了一个java socket脚本去联server，但是忽略了client端的界面下的业务逻辑，用我的脚本做性能测试通过，全部OK，但是真实用户一上线，client终端界面接受了大量的server信息，导致client进程死掉了。痛哉，痛哉。
三．组建并执行性能测试场景。场景是把虚拟用户和交易数按一定规则组织起来去模拟真实世界的业务行为。这其实是把单个用户的行为复制，连接。场景的组织通常和真实世界的业务规则有很大关系。
场景就像导演，脚本就像演员，多少个演员，怎么演，都由导演说了算，而剧情又不能离谱，脱离现实，否则就要砸锅了。
posted on 2004-12-16 16:55 reokok@net 阅读(2267) 评论(0) 编辑 收藏 举报
