发表于 | 更新于 | 分类于 ，

在《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报文。

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

在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中的设置方法如下所示。
Controller中的设置

该种方式的优缺点对比：

优点：

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

缺点：

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