探索一个软件工程师的无限可能

引言

Pelican默认采用的是Disqus评论系统，但由于Disqus附带的Facebook和Twitter社交功能在国内无法使用，因此我们更希望使用一些国内的SNS平台，比如QQ，新浪微博，豆瓣，人人等。在国产的评论系统中，使用较多的有多说、有言等，本文将介绍如何在Pelican博客系统中采用多说评论系统。

获取多说代码

在多说首页点击【我要安装】，进入创建站点界面；完成站点信息填写后，点击【创建】按钮，即可获得多说代码，大致如下所示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<!-- Duoshuo Comment BEGIN -->
<div class="ds-thread"></div>
<script type="text/javascript">
var duoshuoQuery = {short_name:"leolee"};
    (function() {
        var ds = document.createElement('script');
        ds.type = 'text/javascript';ds.async = true;
        ds.src = 'http://static.duoshuo.com/embed.js';
        ds.charset = 'UTF-8';
        (document.getElementsByTagName('head')[0]
        || document.getElementsByTagName('body')[0]).appendChild(ds);
    })();
</script>
<!-- Duoshuo Comment END -->

在上面的代码中，short_name即是注册的多说域名。

修改模板系统

获得多说代码后，在博客正文末尾对其进行引用，便可使用多说的评论功能。
由于我们采用的是模板，因此只需要在article模板中添加对多说代码的引用，便可以一劳永逸。
针对Pelican的模板系统，需要修改如下几个地方。

在 pelicanconf.py 中开启多说评论功能

模仿Pelican默认的DISQUS，在配置文件pelicanconf.py中添加如下代码。

1

DUOSHUO_SITENAME = "leolee"

需要注意的是，DUOSHUO_SITENAME需要全部字母大写，因为只有这样Pelican才会将其作为全局变量，供其它文件引用。

添加 DuoShuo_Script.html

将获取得到的多说代码保存至单个文件中，方便在其它文件中对其进行引用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{% if DUOSHUO_SITENAME %}
<!-- Duoshuo Comment BEGIN -->
<div class="ds-thread"></div>
<script type="text/javascript">
var duoshuoQuery = {short_name:"{{ DUOSHUO_SITENAME }}"};
(function() {
    var ds = document.createElement('script');
    ds.type = 'text/javascript';
    ds.async = true;
    ds.src = 'http://static.duoshuo.com/embed.js';
    ds.charset = 'UTF-8';
    (document.getElementsByTagName('head')[0]
        || document.getElementsByTagName('body')[0]).appendChild(ds);
})();
</script>
<!-- Duoshuo Comment END -->
{% endif %}

在该文件中，添加了一个if语句，即只有在pelicanconf.py中对DUOSHUO_SITENAME进行设置后才开启多说评论功能。

添加 DuoShuo_thread.html

1
2
3

<noscript>
Please enable JavaScript to view the comments powered by <a href="http://duoshuo.com/">DuoShuo</a>.
</noscript>

添加这个文件的作用是，当浏览器禁用Javascript后，用户无法看见评论框，而这个代码便是对用户进行提示。

修改 article.html

由于评论功能总是出现在文章末尾，因此应该将评论功能模块放在文章模版末尾，即对article.html进行修改，修改内容如下所示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{% raw %}
{% extends "base.html" %}
{% block title %}{{ article.title|striptags }}{% endblock %}
{% block content %}
<div>
  <article class="hentry" role="article">
    {% include '_includes/article.html' %}
    <footer>
      {% include '_includes/article_infos.html' %}
    </footer>
  </article>

  {% if DUOSHUO_SITENAME and SITEURL and article.status != "draft" %}
  <section>
    <h1>Comments</h1>
    <div id="DuoShuoComment" aria-live="polite">
      {% include '_includes/DuoShuo_Script.html' %}
      {% include '_includes/DuoShuo_thread.html' %}
    </div>
  </section>
  {% endif %}
</div>
{% endblock %}
{% endraw %}

通过以上修改，便可在Pelican博客系统中使用多说评论系统。

字符实体的由来

在HTML源文件中，有些字符（如<，>，&等）作为特殊字符不能直接使用，如果直接使用的话HTML将不能被正确解析。但如果HTML内容中需要展示这些特殊字符时该怎么处理呢？这就需要使用转义字符串来对其进行转义。

转义字符串（Escape Sequence）也称字符实体(Character Entity)。在HTML中，定义转义字符串的原因有两个：

• 第一个原因：像“<”和“>”这类符号已经用来表示HTML标签，因此就不能直接当作文本中的符号来使用。为了在HTML文档中使用这些符号，就需要定义它的转义字符串。当解释程序遇到这类字符串时就把它解释为真实的字符。在输入转义字符串时，要严格遵守字母大小写的规则。
• 第二个原因：有些字符在ASCII字符集中没有定义，因此需要使用转义字符串来表示。

转义字符串的组成

转义字符串（Escape Sequence），即字符实体（Character Entity）分成三部分：

• 第一部分是一个&符号，英文叫ampersand；
• 第二部分是字符实体名称（character entity names）或者是#加上实体编号；
• 第三部分是一个分号。

对于实体编号，采用的是字符的Unicode编码序号，并且可以采用其对应的十进制编码或者十六进制编码进行表示，具体形式为#nnnn或#xhhhh。

例如，要显示小于号（<），如果采用字符实体名称进行表示，就可以写成<；如果采用字符实体编号的形式，由于其Unicode编码为60（对应16进制为x3c），因此可以写成<或者<。

同一个符号，可以用“实体名称”和“实体编号”两种方式进行表示，“实体名称”的优势在于便于记忆，但不能保证所有的浏览器都能顺利识别它；而“实体编号”，各种浏览器都能处理，其劣势在于不便于记忆。

提示：实体名称（Entity）是区分大小写的。

如何显示空格？
通常情况下，HTML会自动截去多余的空格，多个空格都将被看做一个空格。为了在网页中增加空格，可以使用 表示空格。

HTML Encode & Decode

对于HTML字符实体的Encode和Decode，即是对字符（character）和其对应的字符实体（Character Entity）进行相互转换。

HTML Encode: 字符(Character) => 字符实体(Character Entity)
HTML Decode: 字符实体(Character Entity) => 字符(Character)

例如，对于汉字“测试”，由于其Unicode编码为\u6D4B\u8BD5（对应的十进制为27979 35797），因此Encode后得到测试；反向地，对测试进行Decode后便得到“测试”。当然，对测试进行Decode同样可以得到“测试”。

博客系统的技术实现

博客系统采用 Pelican + GitCafe Pages 的技术架构。

其中，Pelican是一个由Python开发的用于生成静态页面的程序，可以将markdown等格式的文本生成模版格式化的html静态页面；而GitCafe提供的Pages服务可以通过项目的形式对Pelican生成的html文件进行托管，并可通过域名绑定的形式实现独立域名。

这种实现方式与 Jekyll + Github Pages 的实现方式大致相同，差别在于不同的静态页面生成系统和不同的托管平台。而为什么选择GitCafe而非GitHub，是因为GitHub服务器在国外，访问速度较慢，且存在偶尔无法访问的情况。

博客系统的初始化

创建 Blog 目录

1
2

mkdir 52test.org
cd 52test.org

初始化 Blog

1

pelican-quickstart

根据提示一步步输入相应的配置项，完成配置后在Blog目录下会生成配置文件pelicanconf.py。但通过pelican-quickstart配置的选项较少，更多的配置选项可以参照Pelican官方网站中的教程对pelicanconf.py进行编辑。

配置GitCafe

在使用GitCafe之前，需要对电脑的Git客户端进行配置，使电脑与远程GitCafe服务器完成认证。
通常地，我们采用SSH Key认证方式，这需要我们在使用GitCafe前须先建创自已的SSH key。

进入SSH目录

1

cd ~/.ssh

如果还没有 ~/.ssh 目录的话，请先手工创建一个 mkdir ~/.ssh

生成新的SSH秘钥

输入下面的代码，将命令中的 YOUR_EMAIL@YOUREMAIL.COM 改为你的Email地址，就可以生成新的key文件。当需要输入文件名的时候，点击回车键，即采用默认设置。

1
2
3

$ ssh-keygen -t rsa -C "YOUR_EMAIL@YOUREMAIL.COM"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/your_user_directory/.ssh/id_rsa):<回车就好>

然后系统会要输入加密串（Passphrase）

1
2

Enter passphrase (empty for no passphrase):<输入加密串>
Enter same passphrase again:<再次输入加密串>

最后看到如下的界面，即表示ssh key成功完成设置。

1
2
3
4

Your identification has been saved in /c/Users/your_user_directory/.ssh/id_rsa.
Your public key has been saved in /c/Users/your_user_directory/.ssh/id_rsa.pub.
The key fingerprint is:
15:81:d2:7a:c6:6c:0f:ec:b0:b6:d4:18:b8:d1:41:48 YOUR_EMAIL@YOUREMAIL.COM

SSH 秘钥生成结束后，可以在用户目录 (~/.ssh/) 下看到私钥 id_rsa 和公钥 id_rsa.pub 这两个文件，请妥善保管这两个文件。

添加 SSH 公钥到 GitCafe

用文本工具打开公钥文件 ~/.ssh/id_rsa.pub ，复制里面的所有内容到剪贴板。
进入 GitCafe->【账户设置】->【SSH 公钥管理】设置项，点击【添加新公钥】按钮，在Title文本框中输入标题，在Key文本框粘贴刚才复制的公钥字符串，输入GitCafe账户密码后按【保存】按钮完成操作。

测试连接

以上步骤完成后，就可以通过以下命令来测试是否可以连接 GitCafe 服务器了。

1

ssh -T git@gitcafe.com

如果是第一次连接的话，会出现以下警告，

1
2
3

The authenticity of host 'gitcafe.com (50.116.2.223)' can't be established.
#RSA key fingerprint is 84:9e:c9:8e:7f:36:28:08:7e:13:bf:43:12:74:11:4e.
#Are you sure you want to continue connecting (yes/no)?

正常情况下，显示的RSA key fingerprint应该与GitCafe提供的公钥一致，即84:9e:c9:8e:7f:36:28:08:7e:13:bf:43:12:74:11:4e。

如果没有问题，输入yes按回车就可以了，中间会提示输入 passphrase 口令。

最后，如果连接成功的话，会出现以下信息。

1

Hi USERNAME! You've successfully authenticated, but GitCafe does not provide shell access.

测试通过后，就可以通过Git客户端向GitCafe服务器上传博客内容了。

撰写文章

在 content 目录下用 Markdown 语法来写一篇文章，格式大致如下所示，文件保存后缀为.md。

1
2
3
4
5
6

Title: My First Blog #标题
Date: 2013-10-05 #日期
Tags: test, blog #标签
Slug: my-first-post #URL

文章内容

生成html静态页面

创建输出目录

1

mkdir leolee

生成页面

1

pelican -s pelicanconf.py content -o leolee

上传到 GitCafe

先到 GitCafe 上创建一个与用户名相同的项目，例如GitCafe帐号名称为leolee，则创建一个名为leolee的项目。

进入静态页面输出目录

1

cd leolee

初始化 git 仓库

1

git init

创建一个gitcafe-pages的分支，并切换到该分支

1

git checkout -b gitcafe-pages

添加所有文件

1

git add .

提交

1

git commit -m "init"

添加远程仓库

1

git remote add origin git@gitcafe.com:leolee/leolee.git

push 到 GitCafe 仓库

1

git push -u origin gitcafe-pages

完成
push 完成以后就可以在访问 GitCafe Pages 地址了。 http://leolee.gitcafe.com

注：不要用 make html 来构建 Blog ，它会删除输出目录后重新生成 Blog ，这意味着会删除 .git 库。

更新博客

为了方便更新博客，可以创建了一个shell脚本，放置在Blog根目录下。在此创建的脚本名称为publish.sh，其内容如下所示。

1
2
3
4
5
6

pelican -s pelicanconf.py content -o leolee
cd leolee
git add .
git commit -m "Update"
git push
cd ../

更新博客时，只需要将新增博客的markdown文件放入content目录中，然后运行如下命令。

1

$ ./publish.sh

当然，在正式发布前通常会先利用本地服务器进行预览，确定没问题后再进行正式发布。

Makefile的内容如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

PY=python
PELICAN=pelican
BASEDIR=$(CURDIR)
INPUTDIR=$(BASEDIR)/content
OUTPUTDIR=$(BASEDIR)/output
CONFFILE=$(BASEDIR)/pelicanconf.py
PELICANOPTS=

help:
    @echo 'Makefile for a pelican Web site                                      '
    @echo '                                                                     '
    @echo 'Usage:                                                               '
    @echo '   make clean                Empty the OUTPUTDIR                     '
    @echo '   make generate             Generate static files for the web site  '
    @echo '   make serve                Serve site at http://localhost:8000     '

clean:
    @echo -n 'Cleaning Output folder..............'
    @rm -rf $(OUTPUTDIR)/*
    @echo ''
    @echo 'Done'

generate: clean
    $(PELICAN) $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS)

serve: generate
    cd $(OUTPUTDIR) && $(PY) -m pelican.server

.PHONY: help clean generate serve

要预览时，只需要输入如下命令：

1

$ make serve

然后在浏览器中访问 http://localhost:8000 即可进行本地预览。

参考文章

1
2

[1]: http://riku.gitcafe.com/pelican-gitcafe.html
[2]: https://gitcafe.com/GitCafe/Help/wiki/%E5%A6%82%E4%BD%95%E5%AE%89%E8%A3%85%E5%92%8C%E8%AE%BE%E7%BD%AE-Git#wiki

背景介绍

在性能测试工作中，有时需要对业务系统所能支持的最大在线用户数目进行评估。这与我们接触最多的压力测试不一样，因为用户在线时只是与服务器保持连接，并不一定对服务器有业务请求，从而对服务器不一定会产生压力。然而，在线用户数目并非可以无限增长，当在线用户数目达到应用服务器（或者WebLogic等中间件，或者数据库连接池等）的连接数设置的极限时，业务系统同样可能会发生异常，出现新用户无法登录，或者老用户被挤出系统，甚至业务系统宕机的情况。因此，对业务系统的最大在线用户数指标进行测试是极其必要的。

现有一OA系统，需要测试其支持的最大在线用户数目。已知当使用浏览器登录该系统后，登录用户可持续地保持登录状态，即使长时间不做任何操作也不会自动退出系统；通过该OA系统的在线用户数统计模块可以详细地查看到当前在线的用户。

测试方法分析

为了测试被测系统所能支持的最大在线用户数，需要不断地使用新用户帐号进行登录操作，在此同时查看被测系统的在线用户数目以及系统的响应情况。

在新增登录用户时需要注意，由于考察的是系统在正常情况下所能支持的在线用户数目，而不是系统在并发压力下的性能响应情况，因此登录用户时最好采用单个用户或少量并发用户（如两个或三个）逐步登录的形式，不同登录批次之间最好能有一定时间间隔，务必使新增登录用户的操作对服务器产生尽可能小的业务压力。

在新增登录用户的过程中，需要对被测系统的在线用户数目进行查看，并着重关注以下几个方面：

• 持续新增登录用户的同时，业务系统中的在线用户数目是否相应地进行增长
• 持续新增登录用户的过程中，系统登录操作是否产生连接超时的情况，事务的响应时间是否出现大幅度上升的情况，系统登录事务是否出现失败的情况（这需要在脚本中对登录事务做检查点设置）
• 持续新增登录用户的过程中，定期地在浏览器中手动刷新业务系统界面，查看业务系统是否出现不可访问的情况（如内部服务器错误、宕机等）

相应地，测试脚本需符合如下形式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

lr_start_transaction("进入登录页面");
/*此处为进入系统登录界面的脚本*/
lr_end_transaction("进入登录页面", LR_AUTO);

lr_start_transaction("登录系统");

/*登录脚本--部分1*/

/*对系统登录进行校验
 *若成功，即新页面中包含"重新登录"，reLogin_Count>0
 *若失败，reLogin_Count=0
 */
web_reg_find("Text=重新登录",
    "SaveCount=reLogin_Count",
    LAST );

/*登录脚本--部分2（包含检查点内容部分）*/

//对系统登录结果进行检查
if (atoi(lr_eval_string("{reLogin_Count}")) == 0)
{    //登录失败
    lr_error_message("登录失败!!!--UserName：%s",lr_eval_string("{UserName}"));
     //勾选Fail Open Transations on lr_error_message
     //当执到该lr_error_message时，"登录系统"的Transaction失败
}

lr_end_transaction("登录系统", LR_AUTO);

以上脚本调试成功后，通过检查点函数及日志信息可以判断出系统登录操作已通过脚本回放成功完成。

理论上，只要VuGen采用不同帐号迭代运行该脚本，由于只是进行系统登录操作而未进行系统注销或退出操作，业务系统中的在线用户数将持续增加。

然而在该OA系统中采用此方法时发现，虽然脚本成功运行，但业务系统中的在线用户数并未增长。这说明LoadRunner与浏览器在访问系统的过程中存在差异性。

脚本及场景设计

针对上面的问题，通过抓包工具Fiddler2对系统进行网络流量抓包
分析可知：用户登录系统后，在未进行任何操作的情况下，浏览器与服务器会定期（间隔30秒）进行通讯交互。如下图所示：

这就解释了为什么用户在浏览器中登录系统后可以长期地保持在线，而通过脚本成功地进行系统登录后却无法保持在线状态；因为VuGen不会像浏览器那样定期地与服务器进行通讯交互。

找出其中的差异后，我们便可在VuGen中用脚本模拟浏览器的定期交互功能，简单的实现方法如下所示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

while(1){
    web_url("userAction.struts",
        "URL=http://10.147.15.28:9001/userAction.struts?actionType=refreshDynaInfo",
        "Resource=0",
        "RecContentType=text/html",
        "Referer=http://10.147.15.28:9001/jsp/oa/infocomm/sms/sysShortMsg/sysShortMsgReflesh.jsp",
        "Snapshot=t4.inf",
        "Mode=HTML",
        LAST);

    web_url("userAction.struts_2",
        "URL=http://10.147.15.28:9001/userAction.struts?actionType=refreshDynaInfo&time=Mon%20Aug%2012%2015:42:04%20UTC+0800%202013",
        "Resource=0",
        "RecContentType=text/html",
        "Referer=http://10.147.15.28:9001/jsp/oa/infocomm/sms/sysShortMsg/reflesh.jsp",
        "Snapshot=t5.inf",
        "Mode=HTML",
        LAST);

    lr_think_time(30);    //模拟浏览器与服务器30秒间隔的通讯交互
}

那么，将系统登录脚本和循环函数都放入Action中，在VuGen中采用迭代运行的方式可行吗？

虽然新增登录用户可以逐个进行，即使用VuGen通过Action迭代的形式采用不同帐号逐个地进行登录操作。但由于用户登录后需要持续间隔地与服务器进行通讯交互才能保持在线，而单线程脚本运行至while(1)后便进入死循环，从而使得Action迭代无效。因此，采用VuGen进行Action迭代的方式是不可行的。

正确的做法是，在Controller中采用逐步加载的方式，使各个虚拟用户独立地运行，从而保证了各虚拟用户登录成功后保持在线状态。

在Controller中的具体配置如下所示：

• Run Logic：Number of Iterations设置为1
• Think Time：Replay think time As recorded
• Continue on error：False
• Fail open transactions on lr_error_message：True
• Schedule：Initialize each Vuser just before it runs
• Schedule：Start 1000 Vusers – 1 Vuser every 3 Seconds
• Schedule：Run for 5 minutes

通过以上配置，可以达到如下效果：

• 每个Vuser只登录一次，然后定期30秒与服务器进行一次交互，保持在线状态
• Vuser的登录操作与定期刷新操作不会对服务器造成并发压力，且符合真实业务场景
• 逐步缓慢地增加在线用户数，当系统出现异常时即可查看到当前的在线用户数目

测试方法优化

通过以上方法可以测试得到业务系统所能承受的“初略的”最大在线用户数目。为什么说是“初略的”呢？因为该方法仍存在缺陷，主要体现在如下两个方面：

• 该方法只适用于测试期间无他人使用系统的情况。如果测试期间同时有其他用户登录系统，或者系统中本身已存在在线用户，则会造成测试得到的结果不准确。
• 该方法忽略了系统稳定性对在线用户数的影响。举例来说，也许逐步增加在线用户数至500时，系统并没有发生异常，但这并不意味着500个用户长时间处于在线状态时系统不会出现异常。

针对以上两方面缺陷，可以做出如下改进：

• 在逐步增加在线用户数的时候，定期（比如间隔3秒）查看业务系统自身统计的在线用户数目，并以该数据为测试结果。
• 利用之前的方法测试得到业务系统“初略的”最大在线用户数后，使系统长时间保持该数量的在线用户数目，观察系统在长时间运行期间是否会出现异常；若出现异常后，适当减少在线用户数目后重复地进行测试，直到系统可以保持长时间地稳定运行为止，此时对应的在线用户数目即为业务系统所能承受的最大在线用户数目。

在本文提到的OA系统中，对链接[http://10.147.15.28:9001/countAction.struts?actionType=listOnlineUser]进行请求可以返回得到当前系统在线用户数目的统计信息。对应地，设计如下脚本，即可实现对系统实时在线用户数目的查看。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

Action()
{

    web_add_cookie("USERORGID=db93a2M11f6719ff92Mf528764d624db129b32c21fbca0cb8d6; DOMAIN=10.147.15.28");

    while(1){

        lr_start_transaction("查看在线用户数目");

        web_reg_save_param("OnlineUsers",
                "LB=[在线用户数/总用户数：<font color=\"red\">",
                "RB=</font>]",
                "ORD=2",
                "Notfound=error",
                "Search=Body",
                LAST);

        web_url("countAction.struts",
            "URL=http://10.147.15.28:9001/countAction.struts?actionType=listOnlineUser",
            "Resource=0",
            "RecContentType=text/html",
            "Referer=",
            "Snapshot=t1.inf",
            "Mode=HTML",
            LAST);

        lr_output_message("当前在线用户数目：%s", lr_eval_string("{OnlineUsers}"));

        lr_end_transaction("查看在线用户数目", LR_AUTO);

        lr_think_time(3);

    }

    return 0;
}

在LoadRunner脚本开发中，经常会遇到参数与变量相互转换的情况，本文对常见的转换情形进行了方法总结。

变量的赋值

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

//将字符串赋值给变量
char strTemp[30];
strcpy(strTemp, "Hello World!!");

//错误的字符串赋值方式
strTemp = "Hello World!!";
/* 注：
 * 在LR中若直接将字符串赋值给变量，编译时将会报错
 * 报错信息：operands of = have illegal types `char' and `pointer to char'
 */

//将数值赋值给变量
int x = 10;
/* 注：
 * 在LR中，变量的声明一定要放在脚本的最前面，且声明的语句中不要有其他的脚本代码
 * 若将以上申明放置在脚本中部，将会产生如下形式的报错信息
 * illegal statement termination
 * skipping 'int'
 * undeclared identifier 'x'
 */

参数的赋值

1
2
3
4
5
6
7
8
9
10
11
12
13
14

//将字符串赋值给参数
lr_save_string("Hello World!!","paraStr");

//将变量中的值赋值给参数
char strTemp[30];
strcpy(strTemp, "Hello World") ;
lr_save_string(strTemp, "paraStr");

//将数值直接赋值给参数
lr_save_int(123, "paraNum");

//将变量中的数值赋值给参数
int num = 10;
lr_save_int(num*2, "paraNum");

参数的取值

1
2
3
4
5

//从参数中进行取值，不管参数是字符串还是数值
lr_eval_string("{paraStr}");
lr_eval_string("{paraNum}");
//取出的值均为字符串类型，因此输出时格式需为"%s"
lr_output_message("%s", lr_eval_string("{paraNum}"));

参数=>变量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

//将参数转换为字符串变量，参数paraStr中的值为"Hello World!!"
char strTemp[30];
strcpy(strTemp, lr_eval_string("{paraStr}"));
lr_output_message("%s", strTemp);

//将参数转换为数值变量，参数paraNum中的值为"246"
int num;
num = atoi(lr_eval_string("{paraNum}"));    //将字符串转换为数值
lr_output_message("%d", num);

//将参数格式化输出到变量
SeatPrefListCount = atoi( lr_eval_string("{SeatPrefList_count}") );
sprintf(varRandomSeatPref, "{SeatPrefList_%d}", 1+rand()%SeatPrefListCount);
//将格式化的随机日期写入变量varRandomDepartDate
sprintf(varRandomDepartDate, "%d/%d/%d", 1+rand()%12, 1+rand()%28, 2009+rand()%6);

参数=>参数

1
2

//参数的复制：将参数paraStr_1的值复制到参数paraStr_2
lr_save_string(lr_eval_string("{paraStr_1}"),"paraStr_2");

在《LoadRunner基于WSDL的WebService测试方法》一文中，52test.org基于案例天气预报WebService服务，详细讲解了在只获悉WSDL的情况下，如何采用LoadRunner对WebService进行测试。

然而，在实际项目中基于WSDL来测试WebService的情况并不多，WSDL并不是WebService测试的最佳选择。

最主要的原因还是因为WSDL文档过于复杂。在案例（天气预报WebService服务）中，WeatherWebService虽然只包含5个接口，但是其WSDL对应的XML文档多达近500行；而实际项目中，被测系统往往包含上百个WebService接口，其WSDL文档的规模可想而知。

而且，WSDL文档包含的信息过于全面，其中大部分信息对于WebService测试是没有必要的。虽然采用LoadRunner导入WSDL后可以清晰地看见所有接口函数，但是每次都要在上百个接口中选择被测接口也是一件很麻烦的事情。特别是对WebService进行性能测试时，往往只需要选择少数典型的接口。

那么，除了WSDL，还有什么更好的方式呢？

答案就是SOAP。

SOAP是Simple Object Access Protocol的缩写，从字面上就可以知道它是一种通信协议。在这里我们不对SOAP进行详细讲解，大家有兴趣的话可以参看之前发布的《测试工程师的自我修养–理解WebService》一文。

采用SOAP对WebService进行测试时，大家只需要知道它以WSDL定义的形式对WebService的调用方式进行了具体描述，包括调用的具体WebService接口名称、参数名称和参数数值。每一个SOAP报文对应了一个WebService接口的调用方式，在其中包含相应的测试数据后，完全可以把它等同于WebService测试用例。

这对于测试人员来说真是再适合不过了。特别是对于新接触WebService的测试人员来说，对WebService的调用方式及其合法参数可能不是很清楚，这时如果能获取到被测接口的SOAP报文，那么测试工作将可以大大简化了。正因如此，在实际项目中，基于SOAP对WebService进行测试的方法应用得更为普遍。

本文将继续在天气预报WebService服务的案例基础上，详细讲解如何采用LoadRunner基于SOAP对WebService进行测试。

需要说明的是，本文只针对测试脚本的开发展开描述，对测试场景的设计暂不进行讨论。

本文中采用的LoadRunner版本为V11.0，不同版本可能会存在一定差异。

获取SOAP报文

基于SOAP对WebService进行测试，第一步当然是要先获取到被测接口的SOAP报文，通常可在被测系统的接口设计说明文档（如果有的话）中查询得到，也可直接找开发人员获取。

从测试WebService接口的角度来说，SOAP报文应该至少包含哪些要素呢？

在本文的演示案例中，以接口getWeatherbyCityName为例，大家在getWeatherbyCityName的介绍页面中可以看到，getWeatherbyCityName支持SOAP 1.1和SOAP 1.2。本文采用SOAP 1.1进行演示。

采用SOAP 1.1的请求报文如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

POST /WebServices/WeatherWebService.asmx HTTP/1.1
Host: webservice.webxml.com.cn
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://WebXml.com.cn/getWeatherbyCityName"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <getWeatherbyCityName xmlns="http://WebXml.com.cn/">
      <theCityName>string</theCityName>
    </getWeatherbyCityName>
  </soap:Body>
</soap:Envelope>

将上面这段xml代码保存至一个xml文件，如getWeatherbyCityName.xml，即得到测试所需的SOAP报文。

在报文头中，我们还获取到两个重要信息：

• Service的URL为/WebServices/WeatherWebService.asmx，加上被测系统的域名后得到完整的URL为http://webservice.webxml.com.cn/WebServices/WeatherWebService.asmx
• SOAPAction: “http://WebXml.com.cn/getWeatherbyCityName"

在LoadRunner中导入SOAP报文

在LoadRunner的Web Services协议中，点击【Import SOAP】，加载之前准备好的SOAP报文，即xml文件；加载完成后，在URL和SOAP Action中分别填入获取得到的地址信息；在Response Parameter中填写存储返回内容的参数名称；如下图所示。

点击【OK】后，便能在脚本界面中生成一个soap_request函数，如下图所示。

通过上图可知，SOAP报文中的全部内容已成功转换为LoadRunner的soap_request函数。

回放脚本，查看结果

将脚本中的字段theCityName赋值为“广州”；在“Run-time Settings”中打开日志“Extended log”，勾选“Parameter substitution”和“Data returned by server”。运行脚本后，查看“Replay Log”，如下图所示。

在这里如果将脚本回放得到的结果与在浏览器中调用返回的结果进行对比，会发现内容并不一致。在LoadRunner脚本中将theCityName更改为“深圳”、“上海”等城市后重新回放脚本，会发现内容仍然不一致，且LoadRunner每次回放得到的结果都相同。

回顾报文中的Content-Type信息可知，请求报文与响应报文的编码均为UTF-8。因此可以猜想该问题是由于LoadRunner脚本中的编码不为UTF-8造成的，从而使得脚本中的设置的汉字theCityName不被服务商所识别。

对LR脚本中需传送的汉字进行编码转换，即将脚本中的汉字转换为UTF-8，转换方法如下图所示：

重新回放脚本，查看Replay Log。再次对比LoadRunner的Replay Log和浏览器的返回页面可知，LoadRunner对Web Service实现了正确的调用。

通过该案例可知，调用WebService时需要保证输入参数的编码与WebService服务的编码一致，只有这样才能返回正确的结果，这一点需要在调试脚本时格外注意。

随着WebService技术的广泛应用，项目中对WebService进行测试的需求越来越多，而对WebService的性能测试更是重中之重。

作为测试人员，虽然不需要参与WebService的编码实现，但是对WebService相关概念的掌握仍然必不可少，只有这样，才能在测试工作中游刃有余。

本文将对WebService的概念及其相关名词进行阐述，后续将在此基础上，对如何采用LoadRunner测试WebService进行详细介绍。

什么是WebService

WebService，顾名思义就是基于Web的服务。WebService是一种构建应用程序的普遍模型，可以在任何支持网络通信的操作系统中实施运行，并作为应用组件，采用Web的方式接收和响应外部系统的请求，逻辑性地为其它应用程序提供数据与服务。

无论是简单还是复杂的业务处理，都可以将其封装为WebService，部署成功以后，其它应用程序就可以发现并调用部署的服务。而且，应用程序并不需要关注WebService是基于什么样的系统平台和架构开发实现的，它只需要通过通用的网络协议（如Http）和标准的数据格式（如XML、Soap）来访问WebService，即可通过WebService内部执行得到所需结果。

在实际应用场景中，很多企业用户经过多年的积累，已经部署了很多应用系统，这些应用系统在企业运营中分担着不同的功能或任务。随着企业的发展壮大，由于种种原因，这些企业用户逐渐开始考虑如何对原有的这些旧系统进行整合。使用WebService方式将这些旧的应用系统整合起来，对外部提供一致的接口，不仅可以达到整合已有旧系统的目的，还可以避开因为完全构建一个新系统而产生的风险，这样就大大降低了项目的成本和风险。这也是SOA得以被客户广泛采纳的主要原因。

WebService的相关名词解释：WSDL和SOAP

在对WebService进行测试时，接触到最多的两个名词就是WSDL和SOAP。测试人员在跟开发人员沟通时，可能常常会听到开发人员说：

• “WebService已经部署好了，详细的服务描述你可以参照WSDL”
• “SOAP报文我已经准备好了，你帮我测下这几个接口的性能吧”

对于不了解WebService的测试人员，可能刚开始的时候会一头雾水，不明白WSDL和SOAP的含义，对于WebService测试任务如何开展就更是不知所措了。

经过在网上一番搜索，看见好多帖子都说使用LoadRunner测试WebService可以采用基于WSDL的【Add Service Call】和基于SOAP的【Import SOAP】的方法。看到这里，新手可能会感到更加迷惑了，WSDL和SOAP到底有啥关联，这两种测试方法到底有啥区别？

实际上，WSDL与SOAP只是WebService的两大标准，它们之间并没有必然的联系。我们可以先比较一下较为官方的名词解释。

如下是W3C上关于WSDL的解释。

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.

如下是wikipedia上关于SOAP的解释。

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on XML Information Set for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

对比两者的详细解释，可以得出：

• WSDL描述的是服务本身，它以machine-readable的形式对外界描述了该Web Service提供的服务接口，包括Service的名称，调用Service时需要传入的参数类型和格式，以及返回的数据结构。另外，它还以message formats和network protocols无关的形式对网络传输进行了描述。
• SOAP本身就是一种通信协议，利用它以WSDL定义的形式对Service的调用方式进行描述，包括调用的具体Service名称、参数名称和参数数值。
• 对于WebService来说，WSDL是必须的，而SOAP只是通信协议中较为常用的一种，可以用其它通信协议代替；例如可以直接采用HTTP GET/POST的形式对WebService进行调用。

演示案例

为了便于直观理解，本文选取互联网上常用的天气预报WebService服务作为案例进行讲解。

从介绍页面可知，该WeatherWebService一共提供了5项服务：getSupportCity、getSupportDataSet、getSupportProvince、getWeatherbyCityName和getWeatherbyCityNamePro。

对于该WeatherWebService，服务提供商通过WSDL对服务进行了完整的定义，大家可通过这个链接了解一下WSDL文档的结构。

对于每一项服务，服务商提供了4种调用方式：SOAP 1.1、SOAP 1.2、HTTP GET、HTTP POST，并对每一种调用方式都给出了请求和响应示例。

不管是有了WSDL，还是有了SOAP或HTTP的请求和响应示例，就可以对WebService开展测试工作了。而且，这三者分别对应了3种不同的测试方法，可在项目中根据实际情况进行选择。

后续，52test.org将基于WeatherWebService天气服务，分3篇文章分别对采用LoadRunner测试WebService的方法进行详细介绍，并进行案例演示。

• 《LoadRunner基于WSDL的WebService测试方法》
• 《LoadRunner基于SOAP的WebService测试方法》
• 《LoadRunner基于HTTP的WebService测试方法》

敬请期待！

在《测试工程师的自我修养–理解WebService》一文中，52test.org对WebService的概念及其相关名词进行了阐述，并引入了一个测试案例：天气预报WebService服务。

作为测试人员的你，假设现在接到一个测试任务，需要对WeatherWebService中的getWeatherbyCityName接口进行性能测试。
而开发人员只给你提供了WeatherWebService的WSDL的URL链接（ http://webservice.webxml.com.cn/WebServices/WeatherWebService.asmx?WSDL ），然后啥也没说就消失不见了。
那么，采用测试工具LoadRunner该怎样对指定接口进行测试呢？

本文将围绕如上测试需求，对LoadRunner基于WSDL的WebService测试方法进行详细介绍。需要说明的是，本文只针对测试脚本的开发展开描述，对测试场景的设计暂不进行讨论。

本文中采用的LoadRunner版本为V11.0，不同版本可能会存在一定差异。

选择Web Services协议

采用Loadrunner测试WebService时，在单协议里面选择Web Services即可。当然，这并不意味着Loadrunner测试WebService只能采用Web Services协议，在后续的文章中将向大家介绍如何通过HTTP协议来测试WebService。

导入WebService的描述信息WSDL

WSDL 是基于 XML 的用于描述 WebService 以及如何访问 WebService 的语言，它对具体的 WebService 进行了描述，规定了服务的位置，以及此服务所提供的操作（或方法，或服务调用接口API）。如果你熟悉WSDL的文档结构，可以直接阅读WSDL获取相关信息。

然而，当你尝试直接去阅读WSDL文档时，你会发现这是一件十分痛苦的事情，毕竟WSDL的设计出发点是供程序阅读的，其文档结构对人员的阅读体验不是很好。

值得庆幸的是，采用LoadRunner测试WebService时，测试人员无需和原始的WSDL文档打交道，只需要在LoadRunner中导入WSDL后，即可对其中定义的函数接口进行调用。

导入WSDL主要采用两种方式：

• 通过WSDL的URL地址导入
• 直接导入本地WSDL文件

通过WSDL的URL地址进行导入时，操作方式如下图所示。

需要说明的是，填写的URL地址末尾必须包含?WSDL。换句话说，只有在以?WSDL结尾时才能对应到WSDL文件的路径。大家可以在浏览器中对WSDL的URL地址进行访问，查看WSDL当前是否有效。

如果选择直接导入本地WSDL文件的方式，则需要先将WebService对应的WSDL文件下载至本地。下载时，只需将WebService的地址末尾加上 “?WSDL” 后在浏览器中进行访问，然后对网页进行保存时将文件另存为”.wsdl”的文件即可。如下图所示。

获取到WSDL文件以后，便可在LoadRunner中以文件的进行导入，操作方式如下图所示。

两种导入方式效果都是一样的，采用任意一种方式都能将WebService的描述信息导入至LoadRunner供其调用。

当然，两种导入方式也存在一定的差异。

• 采用Import URL的方式可以方便本地获取到最新的WebService描述，当远程服务器端的WebService发生变动以后，本地端可直接对WSDL进行更新，而不需对WSDL进行重新导入。在LoadRunner中，甚至可以通过设置使LoadRunner每次打开脚本的时候自动更新WSDL，如下图所示。

• 采用Import File方式的优点在于，可以对下载到本地的WSDL文件进行手工编辑后再使用；而缺点则是无法获取到最新的WebService的描述信息，若要更新则需重新下载WSDL文件并重新导入。

明白了两种导入方式的特点之后，大家可以根据实际需求进行选择。

查看WebService服务接口

在成功导入WSDL以后，在【Operation】栏目下即可看到所有可供调用的接口。值得注意的是，在本测试案例中，每个接口均包含2个Port Name，这是因为该WebService为每个服务接口提供了SOAP1.1和SOAP1.2两个版本的SOAP调用方式。

对比下图可知，这和网页上展示的接口是一致的。

创建调用函数web_service_call

在LoadRunner中导入WSDL之后，便可以对WebService接口进行调用。

LoadRunner提供的调用函数为web_service_call。调用该函数时，可以根据其说明文档直接在Editor里面进行编辑，不过更简单且更不易出错的方式还是通过【Add Service Call】进行可视化编辑。帮助文档里对此也有进行说明。

_ web_service_call is a high-level function that lets you modify all the SOAP arguments intuitively. Because editing the arguments is likely to be error-prone, it is recommended that the function be modified in the tree view of Service Test rather than in the script editor._

点击【Add Service Call】后进入Web Service Call的可视化编辑界面，如下图所示。

在【Add Service Call】的可视化界面中，对所需调用的Service、Port Name和Operation进行选择。在Operation列表中，可以看到存在5个可供调用的方法，对于每一个Operation，在Port Name下拉框中均可以选择WeatherWebServiceSoap和WeatherWebServiceSoap12，这和上一步骤在【Operations】中查看到的完全一致。

根据本文首部的测试需求，我们在Operation中选择接口getWeatherbyCityName；而由于开发人员未交代SOAP版本信息，因此我们需要对两个版本分别进行测试；在这里我们先选择WeatherWebServiceSoap。

在【Add Service Call】的可视化界面中可以看出，接口getWeatherbyCityName只有一个输入参数，即theCityName。而该接口则是通过城市名来获取指定城市的天气预报信息。

因此，使用getWeatherbyCityName函数接口时我们需对其传入参数theCityName。具体操作时，选中Input Arguments中的参数名theCityName，勾选其右侧的“Include argument in call”，在Value中输入城市名称即可，此处我们输入的是“广州”，如下图所示。

若需要调用getWeatherbyCityName函数的返回结果，则需要事先将其返回结果保存至参数里面。具体操作时，选中Output Arguments中的参数名getWeatherbyCityNameResult[1]，勾选其右侧的“Save returned value in parameter”，在Parameter中输入参数名即可。如下图所示。

完成对Input Arguments和Output Arguments的设置后，点击【OK】按钮，便可看见脚本中新增了一个web_service_call函数，如下图所示。

通过上图可知，之前我们在可视化界面的所有设置均已转换至web_service_call函数。

回放脚本，查看结果

在“Run-time Settings”中打开日志“Extended log”，勾选“Parameter substitution”和“Data returned by server”。运行脚本后，查看“Replay Log”，如下图所示。

详细结果如下所示。

1

theWeatherInfo = <getWeatherbyCityNameResult XmlType="DynamicParameter"><string>广东</string><string>广州</string><string>59287</string><string>59287.jpg</string><string>2013-8-2 21:50:12</string><string>24℃/30℃</string><string>8月3日 大雨转中雨</string><string>无持续风向微风</string><string>9.gif</string><string>8.gif</string><string>今日天气实况：气温：26℃；风向/风力：东风 2级；湿度：96%；空气质量：优；紫外线强度：弱</string><string>穿衣指数：热，适合穿T恤、短薄外套等夏季服装。\n过敏指数：极不易发，无需担心过敏，可放心外出，享受生活。\n运动指数：较不宜，有较强降水，请在室内进行休闲运动。\n洗车指数：不宜，今天有雨，雨水和泥水会弄脏爱车。\n晾晒指数：不宜，有较强降水会淋湿衣物，不适宜晾晒。\n旅游指数：较不宜，有强降雨，建议您最好还是在室内活动。\n路况指数：湿滑，路面湿滑，车辆易打滑，减慢车速。\n舒适度指数：较不舒适，白天有雨，气温较高，闷热。\n空气污染指数：优，气象条件非常有利于空气污染物扩散。\n紫外线指数：弱，辐射较弱，涂擦SPF12-15、PA+护肤品。</string><string>25℃/32℃</string><string>8月4日 阵雨转晴</string><string>无持续风向微风</string><string>3.gif</string><string>0.gif</string><string>25℃/34℃</string><string>8月5日 晴</string><string>无持续风向微风</string><string>0.gif</string><string>0.gif</string><string>广州是广东省的省会,是中国南方最大的海滨城市，广州位于东经113。17`，北纬23。8`，地处中国大陆南部，广东省南部，珠江三角洲北缘。广州临南海，邻近香港特别行政区，是中国通往世界的南大门，广州属丘陵地带。中国的第三大河----珠江从广州市中心穿流而过。广州是一座历史文化名城。相传在远古时候，曾有五位仙人，身穿五色彩服、骑着嘴衔稻穗的五色仙羊降临此地，把稻穗赠给百姓，祝愿这里永无饥荒。从此，广州便有“羊城”、“穗城”的美称，“五羊”也成为广州的象征。广州既是中国也是世界名城，又是一座古城，因历史上有五羊仙子降临献稻穗的故事，广州又称为“羊城”和“穗城”，简称“穗”；广州一年四季如春、繁花似锦，除夕迎春花市闻名海内外，故又有“花城”的美誉。广州地处低纬,属南亚热带季风气候区。地表接受太阳辐射量较多，同时受季风的影响,夏季海洋暖气流形成高温、高湿、多雨的气候；冬季北方大陆冷风形成低温、干燥、少雨的气候。年平均气温为21.4-21.9度，年降雨量平均为1623.6-1899.8mm，北部多于南部。1982年，广州被国务院选定为全国首批历史文化名城之一，是我国重点旅游城市。1999年1月，广州被评为优秀旅游城市。景观：白云山、莲花山、南海神庙、佛山祖庙、广州动物园等。</string></getWeatherbyCityNameResult>

在浏览器访问该WebService，查询“广州”时得到结果如下图所示。

通过对比LoadRunner的Replay Log和浏览器的返回页面可知，LoadRunner对Web Service进行了正确的调用。

完善脚本

脚本虽已调试成功，可以得到正确的结果。但若要进行性能测试，我们还需对脚本进行参数化，如下图所示。

或者，如果我们是只想利用返回报文的一小部分，而不是全部。在这种情况下，我们可以指定将某部分保存至参数，以便后续的使用。

例如，我们只想获得某个城市当天的最低温度和最高温度。通过返回报文可知，该字段是输出结果中的第6个字段。那么，我们便可以将该字段保存至一个参数，这里指定为Lowest_Highest_Temperature，如下图所示。

生成脚本如下所示：

运行结果如下图所示。

当然，此处只是列举了一个简单的例子。通过对web_service_call函数的灵活应用，可以实现更多复杂、强大的功能。

并发用户数是指：在某一时间点，与被测目标系统同时进行交互的客户端用户的数量。

并发用户数有以下几种含义：

并发虚拟用户数（Concurrent Virtual Users，Users_CVU）

在使用专用的测试工具（如Loadrunner、Jmeter）时用于模拟客户端用户的进程或线程的数量；该参数是针对客户端（generator）而言的。

有效并发虚拟用户数（Effective Concurrent Virtual Users，Users_ECVU）

被评估目标系统实际感受到的等效于业务请求压力的无思考时间的并发用户数；该参数是针对被评估的目标系统（Target System）而言的。

如果使用测试工具对目标系统进行压力加载时设定了思考时间（Think Time），那么实际有效的并发虚拟用户数可使用如下公式计算得出：

Users_ECVU=Users_CVU*Time_ART/(Time_ART+Time_TotalThinkTime)

其中：

• Time_ART — 目标系统实际运行时的平均响应时间
• Time_TotalThinkTime — 虚拟用户执行一次该交易过程中使用的思考时间的总和

由此可见：

• 增加思考时间意味着减少对目标系统的业务请求压力；
• 当思考时间为零时，有效并发虚拟用户数与并发虚拟用户数相等。

内在并发用户数（Limited Concurrent Users，Users_LCU）

目标系统内部能够同时并行处理的客户端用户数。

该参数体现了目标系统的内在并发度，因此当对目标系统进行任何有效的优化和调整之后，其内在并发用户数即内在并发度就会发生变化，通常来讲是指改变目标系统的第一瓶颈后会发生变化。

当 Users_ECVU<=Users_LCU 时，目标系统可以真正地并行处理所有被加载用户的任务请求，此时交易的响应时间会相对保持不变，即交易的实际响应时间，也是交易在目标系统中处理的最快时长；

当 Users_ECVU>Users_LCU 时，目标系统会利用内部的请求调度机制将多出的请求进行排队并在所有的用户请求之间进行任务切换处理，外在表现就是被加载交易的响应时间开始延长。

并发在线用户数（Concurrent Online Users，Users_COU）

一般是指实际生产系统中已经和目标系统建立了会话连接的用户总数，并发在线用户数通常是指实际的客户端操作员的数量，是人工发起的业务会话的数量。

并发在线用户数产生的请求压力可以通过公式计算出目标系统感受到的实际业务请求压力，即有效并发虚拟用户数，公式如下：

Users_ECVU=Users_COU*Time_ART/Time_AverageIntervalRequestTime

其中：

• Time_ART — 目标系统实际运行时的平均响应时间
• Time_AverageIntervalRequestTime — 每个操作员用户发起该交易请求的平均间隔时间

在某个业务场景中，包含数据创建和数据查询两项业务；现需考察数据创建和数据查询两项业务在并发比例为2:1、总并发量为100用户情况下的混合响应时间。

在Vugen端实现

对混合比例的设置，可直接在脚本中进行，即通过随机函数rand实现，脚本设计如下所示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

int num;
Action()
{
    num = rand()%3;
    lr_start_transaction("综合业务--数据创建与数据查询");
    if(num<2){
        Data_Create();  //数据创建
    }
    else{
        Data_Search();  //数据查询
    }
    lr_end_transaction("综合业务--数据创建与数据查询", LR_AUTO);
    return 0;
}

该种方式的优缺点对比：

优点：

• 脚本本身实现了比例控制的功能，Controller端的设置较为简单，即在Controller中只需将该混合业务作为单一业务对待，设置也跟单一业务场景的设置方法完全相同；
• 测试得到响应时间即为混合业务的响应时间。

缺点：

• 在已有数据创建和数据查询脚本的情况下，针对混合业务场景需要单独创建一个混合业务脚本，且混合比例改变时需要重新修改脚本；
• 当需要考察混合业务场景中不同业务类型各自的响应时间时，通过该种方式无法实现。

在Controller端实现

在业务类型较多，混合业务场景较为复杂的情况下，采用修改脚本的方式会比较麻烦。例如，若共有5种业务类型，现需要对其任意两种业务的混合场景进行压力测试，如果仍采用第一种方式，那么我们就必须得针对两两业务的混合情况，创建10个混合业务脚本。当业务类型更多，或者混合场景更为复杂（如需考虑任意三种、任意四种业务等的混合情况）时，脚本的创建量会大大增加，且均为乏味的重复性工作。

针对这种情况，直接在Controller端进行设置会简单得多，只需要加载各个业务脚本，并设置不同脚本的并发数即可。对于本文中的案例，在Controller中的设置方法如下所示。

该种方式的优缺点对比：

优点：

• 无需单独创建混合业务脚本，特别是在业务类型较多的情况时优势更为明显；
• 测试得到的响应时间为各个业务独自的响应时间，可以实现对混合业务场景下各个业务的单独分析。

缺点：

• 计算混合业务的响应时间时，需要提取原始测试数据进行计算（不能直接对各个业务的平均响应时间取平均值来作为混合业务的平均响应时间），计算较为复杂。