LoadRunner之所以强大，很大的原因是VU的功能强大。作为虚拟用户的产生器，从横向上看，VU几乎支持模拟当今所有主流的软件客户端，同时还在不断地推陈出新；从纵向上看，每个Vuser脚本的设置也是非常繁多和详细的，达到了精确模拟的效果。
　　因此，了解并熟悉VU是我们“玩转”LoadRunner要做的第一件事情。
　　我们最常听到的关于VU的描述就是：VU通过运行VU脚本模拟了用户对软件的操作行为。
　　如果我们不刨根问底，探究实质，就难以发现上面这句话的奥妙。
　　5.1  序：图灵试验与LoadRunner VU模拟奥秘
　　5.1.1  图灵试验场景
　　伟大的计算机之父阿兰•图灵曾对人工智能设计过一个著名的“图灵试验”，来判断计算机对人类的模拟能力，图灵试验场景如图5-1所示。
　　图灵试验由计算机、被测试的人和主持试验的人组成。计算机、被测试的人和测试主持人分别在三个不同的房间内。测试过程是由主持人提出问题，由计算机和被测试人分别回答。被测试人回答问题是尽可能地表明他是“真正的”人，计算机也尽可能逼真地模仿人的思维方式和思维过程。如果试验主持人听取对问题的回答后，分不清哪个是人回答的，哪个是计算机回答的，则可以认为被测试计算机是有人的智能的。

　　图5-1  图灵试验场景
　　我们从这个试验中可以看到模拟需要有三个要素：模拟者（计算机）、被模拟者（真实的人）和观察者（主持人）。其中观察者是很重要的一个角色，模拟只有对观察者才有意义。而在图灵试验中，观察者通过一定的方式（闻其“答案”不见其人）来判断这个模拟是否成功。
　　5.1.2  LoadRunner模拟揭秘
　　再回头看看那句话：“VU通过运行VU脚本模拟了用户对软件的操作行为。”与之对应，我们能找到VU是模拟者，用户是被模拟者，但这句话里没有指出观察者。那么观察者是谁？我们性能测试工程师是观察者么？显然不对，用户的操作行为是一次次键盘输入，一个个鼠标点击，而VU在我们眼里只是一行行脚本程序和配置文件。
　　想到这里，可能已经有人得到了答案。没错，观察者其实就是性能测试中被测服务器。
　　我们发现，完全可以把图灵试验应用到我们的VU模拟场景中：
　　在软件系统运行时，一个真实的用户通过操作软件客户端来发起和服务器的会话请求，同时，一个VU开始运行它的脚本，也发起了同样的请求。被测服务器在处理各个“交谈”请求并与之分别会话的时候，并不知道哪些请求是来自真实的用户，哪些是来自VU。这样，VU成功地模拟了真实的用户，“骗过”了被测服务器。当然，VU要实现这个目标，之前还需要通过认证，构造合法的请求等步骤，这些VU都要加以实现。
　　我们弄明白了观察者是被测服务器这件事情后，有些知识点就清楚多了。
　　事实：VU是基于网络协议的。
　　很明显，被测服务器是通过各种各样的网络协议与客户端打交道的。VU要“骗过”被测服务器，当然就要遵守这些协议，按规矩、按步骤来动作，否则就会吃“闭门羹”，毫不留情地被服务器拒绝。实际上，如果我们留心的话，可以发现VU每个协议相关的函数都是紧紧围绕其网络协议的实现的。同样，VU录制生成的也是网络协议层次的脚本。在回放时，VU将按照录制下来的网络事件，一一重放。
　　基于网络协议的脚本的一个好处是，我们可以使用相对少的硬件资源，来生成大量的虚拟用户负载。相比之下，WinRunner和QTP的脚本是基于界面事件（GUI）的，它在一台主机上同时只能运行一个虚拟用户的脚本，因为一个虚拟用户会占用整个主机的资源。
　　推论一：VU不关心用户在界面上发生的事情。
　　真实的用户对软件客户端可能有各种各样的操作，有些会触发对服务器的请求，有些则不会。而VU的录制和运行都是基于网络上的事件的，因此VU在录制的时候，只对那些网络事件感兴趣，如果有网络交互发生，就会记录成脚本，没有则只会生成一个空脚本，尽管可能用户在界面上做了很多操作，比如鼠标移动，填写Web form里的数据。
　　推论二：VU中的操作关联与界面上的操作关联是不一致的
　　在我们对软件系统进行测试的过程中，某些操作是相关联的。例如，我们测试“查看客户交易历史明细”这个事务的系统响应时间，按界面测试思路，我们会这么做：
　　首先用客户查询系统，查询出此客户。
　　点击这个客户，打开另外一个页面，展现此客户的基本信息。
　　点击基本信息中的“交易历史明细”，系统经过查询后，刷新此页面，显示明细结果。
　　显然，在UI测试中，我们要测试第三步骤，之前必须要完成第一步和第二步。但在VU中就不是这样了：
　　这三个操作被VU记录成三个函数。如果它们是上下文无关的函数（关于上下文相关和上下文无关函数，可参看LoadRunner函数手册），那么其实，我们完全可以忽略掉第一和第二个函数，只执行和参数化第三个函数。
　　案例
　　疑问：使用LoadRunner录制一个Java applet技术的Web系统，要录制的动作是：
 点击一个按钮后，此时系统调用applet小应用程序。
 applet小应用程序在本地加载完后，弹出一个通过XML文件配置对话框，在这个页面中建立节点树。
无论LoadRunner采用Web协议、Web Service协议还是Windows Socket协议，在脚本录制并回放后，到系统中一检查，发现节点并没有创建，这是怎么回事？
　　解释：
　　根据推论一，我们知道VU只捕捉网络上的事件，在本案例中LoadRunner采用Winsocket协议也无法创建节点，这说明XML树节点的创建是由Java applet完成的，并且很可能只保持在客户端本地，并未有和Server同步的迹象。因此，LoadRunner脚本捕捉和回放的脚本只是网络事件，并不会对客户端本地产生影响，节点自然不会被创建。
　　根据推论二，如果我们的目标是测试服务器的性能，那么完全可以忽略这个问题，继续录制。

　　提示：基于GUI和基于协议的测试工具在实质上是看待同一事物的不同的角度。比如：用户点击一个Web页面上的“无忧测试“的链接文字，在QTP会被记录成link("无忧测试").click的函数，而在LoadRunner中则会被记录成web_link函数。前者是记录“鼠标在此链接上点击一次”这个事件，而后者是“客户端向Web Server发起了一个get URL地址为www.51testing.com的请求”。LoadRunner和QTP如摸象的盲人一样，各自从GUI和网络协议的角度来看用户点击的动作。而实际上它们所记录的只是用户操作整个过程的一部分。

　　提示：LoadRunner 8.1从SP2开始，VU协议族中新增了一个特殊的Vuser类型，叫做Web Click and Script，为什么说它特殊呢？因为它和其他基于网络协议的Vuser不一样，Web Click采用了QTP的技术，使得VU可以录制在界面上的一些操作。比如登录时填写用户名、口令这些动作都可以被记录成脚本。这在本书第10章中将会有所介绍。
把VU的实质弄清楚了之后，我们就可以放心大胆地使用它了。Vugen是个神奇的盒子，我们总能从盒子里拿到我们想要的东西。

连载一 连载二 连载三 连载四 连载五 连载六 连载七 连载八 连载九 连载十 连载十一 连载十二 连载十三 连载十四 连载十五　连载十六

本文选自：《51Testing软件测试作品系列》之一的《性能测试从零开始——LoadRunner入门》，本站经电子工业出版社和作者的授权，近期将进行部分章节的连载，敬请期待！

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。