本节书摘来自异步社区《LoadRunner 12七天速成宝典》一书中的第1章，第1.6节第一个性能测试案例，作者陈霁，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.6 第一个性能测试案例
云云：接着我们来做个简单的性能测试，测试50个用户在论坛上发帖，平均每个用户发帖的响应时间和对应的服务器资源占用率。
恋恋：听起来好酷哦！
云云：首先需要搭建一个测试环境，这里使用新版的DiscuzX 1.5论坛作为案例（由于版本较旧，下载地址参考本书网盘），这里选择简体UTF-8版本。只下载了论坛还不够，这个论坛是基于PHP开发的，所以我们还需要配置一个简单的PHP+MySQL的平台，为了方便讲解，这里使用WAMP 2.2（Windows+Apache+MySQL+PHP）整合平台。双击安装包启动安装。
弹出版本说明，单击“Next”，如图1-39所示。
选择“I accept the agreement”，单击“Next”，如图1-40所示。
使用默认目录，单击“Next”，如图1-41所示。
不添加快捷菜单，单击“Next”，如图1-42所示。
单击“Install”开始安装，如图1-43所示。
安装结束时会询问默认启动的浏览器应用，这里就默认使用IE浏览器，如图1-44所示。
由于Apache服务器需要占用80端口，所以Windows 10的防火墙会提示是否允许该进程访问网络，单击“允许访问”，如图1-45所示。
默认SMTP邮件服务设置，单击“Next”进行下一步，如图1-46所示。
完成安装，并且启动WampServer 2服务，如图1-47所示。
如果服务正常启动就会在通知区域中看到一个绿色的W图标，如图1-48所示。
接着就可以在浏览器的地址栏中输入 http://127.0.0.1，就可以看到Wamp的主页面了，如图1-49所示。
WAMP安装完成了，接着把下载好的DiscuzX 1.5压缩包中的upload目录内容解压到WAMP安装目录下的www目录下（默认为C:wampwww），这里改名为discuz目录，然后就可以在浏览器中输入 http://127.0.0.1/discuz开始安装了，如图1-50所示。
安装时提醒需要修改文件，这个时候打开WAMP安装目录下的binapacheApache2.2.21 bin目录修改其中的PHP文件；或者在通知区域中单击WAMP的图标，单击PHP菜单下的php.ini打开该文件，找到short_open_tag = OFF这段，修改为short_open_tag = ON保存。接着单击通知区域的WAMP图标选择Restart All Service重启所有服务，如图1-51所示。
再次访问就可以正常访问了。
单击“我同意”，如图1-52所示。
环境和函数正常，单击“下一步”，如图1-53所示。
选择“全新安装Discuz!X（含UCenter Server）”，单击“下一步”，如图1-54所示。
默认的MySQL数据库密码为空，所以这里需要将数据库密码清除，填写管理员密码，单击“下一步”，如图1-55所示。
稍等片刻安装，跳过最后的客户信息填写就完成了论坛的安装，如图1-56所示。
恋恋：装个论坛网站也这么麻烦，接着可以做性能测试了吧？
云云：嗯，我要先问你一个问题。在论坛上发一个帖子，用户需要做几步操作？
恋恋：一般是这几个步骤：
（1）登录。
（2）选择所要发帖的版块。
（3）单击新建主题。
（4）书写帖子正文，然后单击“确定”。
云云：那么接着我们来录制这个操作吧。在电脑桌面上打开“Virtual User Generator”，单击“开始”菜单中“File”下的“New Script and Solution”，新建脚本，如图1-57所示。
在“Create a New Script”中选择“Web-HTTP/HTML”，单击“Create”，如图1-58所示。
接着出现代码的编辑界面，如图1-59所示。
单击“Start Recording”录制按钮，如图1-60所示。
弹出的Start Recording窗口中，在URL address中输入discuz论坛地址（注意避免使用Localhost，有些时候会出现录制不到脚本的问题），录制前还需要调整下默认的录制选项，单击“Recording Options”。
为了保证代码能够生成合理的脚本，确保回放的正确性，这里需要修改Recording中的录制模式。找到“HTML-based script”单击右侧的“HTML Advanced”，在弹出的选项中将默认的“A script describing user actions”修改为下面的“A script containing explicit URLs only”，如图1-61所示。
从LoadRunner 12开始，录制的模式通过证书代理的模式了，录制开始时会弹出CA证书提示，要求安装该证书，如图1-62所示。
单击“是”，确认证书，并且同意Windows 10的防火墙访问提示。
这个时候会看到有一个Recording工具条，并且一个IE 11会被启动，自动访问论坛，接着我们在这个论坛中进行发帖的操作，如图1-63所示。
这里我们使用admin身份用户登录后在默认版块发了一个帖子，如图1-64所示。
单击录制条的停止录制按钮，结束这次脚本的录制，如图1-65所示。
单击停止录制后会看到有提示删除证书的说明，如图1-66所示。
单击“是”确定，稍等片刻代码生成弹出Design Studio设计中心。
设计中心提供了对脚本关联处理的支持，但是个人并不太推荐使用这样自动的体系，所以直接单击“Close”，如图1-67和图1-68所示。
这里我们完成了脚本的录制工作，保存脚本后，接着我们单击工具栏上的Run按钮或者快捷键F5运行一下这个代码，如图1-69所示。
回放完成后，你会在论坛上看到多了一个新的帖子，也就是说通过录制，我们得到了发帖用户的行为，这个行为用一个脚本来说明（虽然你看不懂怎么回事，但是这个在现在不关键），而回放这个脚本可以实现对前面行为操作的重复，那么可以基本认为该脚本录制是成功的。
恋恋：原来简单几步就能完成用户行为模拟了啊！
云云：你又骄傲了是吧！这个例子简单么，换一个系统你就不能简单地录制回放了，别翘尾巴！
恋恋：翘尾巴不是你的特长么，看我怎么把它压下去！
云云：Stop！接着来说怎么添加监控。监控其实包括两部分，一部分是我们需要的操作的响应时间，另外一部分是在这个操作下的资源利用率。先到脚本中找到发帖的操作。
恋恋：发帖应该是在最后吧，我来看看代码。是不是这一段呢？
云云：不错哦，那么快就找到了，介绍一下经验。
恋恋（得意状）：当初的HTML不是白学的，填写表单不就是个submit操作么，代码上面有Action和Method，这不就是表单处理么，而且还有好多个属性和一堆乱码，只有这段了。只是为什么是乱码但回放后帖子显示还是正常的中文啊？
云云：这个问题是编码的问题，英文的软件对中文的识别总归是不好的，这里先不和你纠结这个问题，我们是做性能测试不是做功能测试，哪怕回放是乱码也无所谓的。
恋恋：哦，也是，反正操作成功了，显示不正确也没有关系。
云云：接着我们需要知道发帖所需要消耗的时间，这里需要添加一个叫做事务的函数。把光标切到发帖函数的前面，单击工具栏上的“Start Transaction”或者组合键Ctrl+T，如图1-71所示。
接着在代码中直接就会添加一段代码lr_ start_transaction(“”)，在双引号中添加事务名称，如图1-72所示。
接着我们将光标移动到发帖函数的后面，单击“End Transaction”或者组合键Ctrl+Shift+T。
同样在代码中添加了一句lr_end_transaction(“”,LR_AUTO”)，这里需要和前面的事务名填写一样的内容，如图1-73所示。
恋恋：是不是两个函数要成对，然后他们会计算函数间的时间差？
云云：哎哟，不错哦。
恋恋：那是，也不看看我是谁。
云云：好了，我们完成了脚本的开发工作，接着我们要把这个脚本变成50个用户来运行，并且还要监控在这个负载下资源利用率的情况。
恋恋（期待的眼神）。
云云：打开菜单“Tools”，单击“Create Controller Scenario”创建一个新的场景，如图1-74所示。
弹出创建场景的窗口，我们这里把“Number of Vusers”值从1改为50，单击“OK”启动场景，如图1-75所示。
稍等片刻Controller就会弹出来。
这里就是Controller场景界面了，接着将界面底部的标签切换到Run上，如图1-76所示。
接着在右侧的Windows Resources窗口中单击鼠标右键，在弹出的菜单中单击“Add Measurements”项，如图1-77所示。
单击“Add”按钮，如图1-78所示。
这里输入“localhost”监控本机的Windows 资源信息（使用IP地址可能会被防火墙拦截），单击“OK”按钮，如图1-79所示。
这里可以在下面看到有很多内容，其中“%Processor Time”是我们的CPU占用率，如果达到100%就说明CPU很忙，被完全使用了，单击“OK”按钮完成资源监控添加，如图1-80所示。
稍等片刻可以看到Windows Resources中出现线条，而相关数据会显示在底部（会看到有4个Errors信息，主要是因为Windows 10有些计数器已经取消了，导致无法读取）。这样我们就完成了资源的监控，如图1-81所示。
恋恋：有点像心跳仪，是不是一边运行LR（LoadRunner简写）就会一边监控。
云云：嗯，是这样的。完成了场景中的监控和50个人负载的设置后，就可以运行了，单击F5键等结果吧，这个要运行接近16分钟呢，坐了那么久起来活动活动吧，场景运行如图1-82所示。
恋恋：好累啊！
**小结
了解如何使用Vugen录制脚本，回放确认脚本录制是否成功，掌握在脚本中添加事务函数及生成场景添加资源监控。**
20分钟过去。
云云：场景运行完成，我们可以来看结果并且生成性能测试报告了。
恋恋：等我再去吃个水果，晚饭后吃水果对身体好。
云云：场景执行完毕后，所有的用户会处在Stop状态，现在我们完成了50个用户在论坛上不停发帖的负载，接着我们来看看论坛上多了多少帖子，如图1-83所示。
看看吧，多了400多个帖子哦，这是50个人按照某种策略在上面发帖的结果，如图1-84所示。
恋恋：好多帖子啊，用这个来灌水岂不是很方便，我可以成为“灌水女王”了。
云云：基本上这个是可行的，我已经承认你是女王了。
云云：最后我们要生成性能测试报告了，来对这次测试进行一个说明，单击“Results”菜单下的“Analyze Results”，调用Analysis对这次性能测试中的数据进行分析，如图1-85所示。
单击以后Analysis启动，等待数据收集以后会看到以下界面，如图1-86所示。
这是Analysis给我们提供的一份报告总结。
恋恋：我看不懂，都是数据怎么办。
云云：别急，抓住重点就行了。首先看我们关注的发帖的响应时间，在这个Summary里面显示了posttopic事务的Average时间是10.574秒，你觉得速度快吗？
恋恋：我觉得有些慢。
云云：通常我们使用2/5/8的原则来说明用户体验。即如果事务时间在2秒以内是很快，5秒以内是还不错，8秒以上用户就受不了了。
恋恋：那么现在就是说速度完全不行喽。
云云：这里先卖个小关子，这个时间并不是发帖操作的时间哦，不过你就先当整体看好了，以后谈时间细分的时候再给你详细介绍。
恋恋：那么我们知道时间是10秒多点，又怎么样呢？
云云：单击左边的“Average Transaction Response Time”，会出来一个图，这个图是随着时间的推移事务时间的变化规律，如图1-87所示。
注意，posttopic中的数据就是比较低的那根线，在这个图里面你可以看到负载的过程中响应时间是如何变化的。
恋恋：4分钟以前的时间都不长，4分钟以后的时间波动却很大。
云云：这个问题要分析了，你现在是做入门性能测试，所以知道结果就行了。然后我们单击一下“Running Vuser”，如图1-88所示。接着可以看到用户负载的趋势，并不是50个人都一直在运行，而是一个递增趋势，逐渐到达50个用户稳定一段时间后再下降，想到什么了吗？为什么要这样做？
恋恋：让我想想，好像一开始就在说负载应该是逐渐递增的，这样才能找到拐点。
云云：还算记得不错，用户运行的趋势是在场景中设置的，这里我们使用了系统的默认值而已。最后我们可以看一下资源情况图，这个图要手工添加。
在Graph上单击鼠标右键，在“Add New Item”下选择“Add New Graph”，如图1-89所示。
弹出的窗口中选择“Windows Resource”，单击“Open Graph”，如图1-90所示。
这图看的头晕吧（如图1-91所示）。
恋恋：这怎么看啊？
云云：你先别管，直接看Processer Time，是不是发现平均值是63.5%，最大值是100，说明CPU有一定的占用率。
恋恋：是不是就能说有CPU瓶颈了？
云云：CPU是常见瓶颈的一种，但是这里并不能完全说是CPU一定是导致响应时间慢的关键。接着我们编写一份性能测试报告，下面是模板，你照着填一下。
恋恋开始认真填写，最后生成了这样一份性能测试报告。
Discuz性能测试报告
目的：
测试Discuz发帖的性能。
环境：
红太羊的笔记本
Windows 10操作系统+Wamp+Discusx 1.5
负载方式：用户逐渐增加，持续，然后下降的方式，如图1-92所示。
响应时间：开始平稳，3分钟44秒以后响应时间迅速上升，超出用户能够接受的8秒时间上限，如图1-93所示。
资源情况：从一开始CPU占用率就非常高，然后逐渐下降稳定，响应时间变慢和CPU有一定的关系，具体瓶颈原因不详，如图1-94所示。
综上所述，在50个用户负载发帖的情况下，系统的CPU资源有明显的瓶颈，响应时间后期波动较大，超出用户能够接受的8秒最大时间，性能测试不通过。
**小结
了解如何使用Analysis整合数据，通过对用户执行，平均响应时间和资源利用率3张图对系统性能进行简单分析，掌握最简单的性能测试报告编写方法。**
云云：第一天就到这里吧，辛苦啦。
恋恋：晚安。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
