版权声明：本文为原创文章，转载请先联系并标明出处
关于接口测试的理解，主要有两类，一类是模块与模块间的调用，此类接口测试应该归属于单元测试的范畴，主要测试模块与模块之间联动调用与返回。此类测试大多关注于流程性与正确性，通过设置不同的输入，得到相应的返回与对应输入数据的预期输出目标比较是否一致，来确认接口的正确性和流程性。
另一类是系统的调用，如登录调用认证系统的接口，如本系统调用第三方系统的接口等等，这类针对由web端发起的调用的测试也是一种接口测试，这类测试关注点更着重放在效率和健壮性上。
对于第一种，比较好的实践是将输入数据做成参数，在HyperPacer的数据池中进行维护，而接口调用则做成自动化进行。目前HyperPacer已经很好的能实现此类测试的需求。作为性能测试的专题，我们不在此展开赘述。我们重点来说第二种接口测试。
在这类web接口测试中，最多的就是WebService的测试。
关于WebService，soap，XML，rpc，wsdl等一系列概念，有不清楚的可以参考下面链接中给出的一些概念解释：
虽然解释的不够详细，但是基本的概念大概解释清楚了。
对于WebService的测试，我们在网上比较容易查找到LoadRunner的实践资料，LoadRunner在这方面确实方便，基本不需要太多这方面的知识，直接图形化界面就可以自动生成相应方法的调用和参数输入。
而Jmeter和HyperPacer对于WebService的测试资料相对较少，而且也没有便捷的方式能自动生成相应方法，所以导致很多新人在使用这两个工具进行WebService测试的时候感觉无从下手。这里以HyperPacer为例，讲解一下用HyperPacer编写脚本调用WebService进行性能测试。
首先我们，在网上找到一个公开的天气预报的WebService接口，该接口的描述文档如下：
这是一个WSDL文档的片段截图，在一个WSDL文档中
一个WSDL文档由以下几部分部分组成：
- types
指定了WebService用到的所有数据类型。
- message
指明一个操作所用到的数据类型。
- portType
指出了这个WebService所有支持的操作，就是说有哪些方法可供调用。
- binding
transport指明传输协议，
operation 指明要暴露给外界调用的操作。
use属性指定输入输出的编码方式，这里没有指定编码。
- services
指定服务的一些信息，主要是指定服务的访问路径。
在我们的片段截图里面我们可以看到提供了很多的方法，由于我们是举例子，这里我们只选择其中的一个方法getWeatherbyCityName来进行演示，我们可以看到在这个方法里只有一个参数theCityName，顾名思义，这个接口的这个方法是实现我们输入一个城市名或者编号，就可以得到该城市的天气情况。
下面我们来用HyperPacer来实现这个WebService的调用，首先添加一个工程，interface_demo和一个叫接口测试的并发场景，在场景内增加一个WebService取样器，取样器的界面如下：
可以看到在WebService发送的请求体中主要信息就是我们要调用的方法和方法的参数数据。
在过去接触的很多新人中，大多都是在这个请求体的地方不知道该如何编写。这里给出模版如下：
首先请求体先是XML的声明，然后是soap envelop对象。这个没有为什么，soap请求内容能够必须以envelope作为根节点，以及envelope中的各个命名空间内容也都是固定的，有兴趣详细了解的可以点击下面的链接进行查看：就是我~~~，里面有Envelope的schema的相关定义。
在envelope的根节点下分别是Header元素和Body元素。
Header这个是可选的，如果需要添加Header元素，那么它必须是Envelope的第一个元素。Header的内容并没有严格的限制，我们可以自己添加一些和应用程序相关的内容，但是客户端一定要记得处理这些Header元素。
而Body就是请求的主体了，如请求调用的方法，方法包含哪些参数等信息。在调用中没有指定参数和返回类型，这里不需要指定，因为提供服务的一方自己已经规定好了数据类型，在调用时指定数据类型没有任何意义，可以回过头查看上面WSDL文档截图中关于根据城市获取天气这个的方法。
而一般情况下，我们用标签来表示我们调用的方法，然后用子标签来表示它的参数。如上面我们调用的是getWeatherbyCityName这个方法，所以在Body元素中，我们这样写：
<getWeatherbyCityName xmlns="http://WebXml.com.cn/">
<theCityName>58367</theCityName>
</getWeatherbyCityName>
在上面，我们用黑色粗体标识的标签就是方法名，而用斜体标识的标签就是该方法的参数。
所以拼起来请求体就是如下格式：
<XML声明>
<soap:Envelope>
<Header>
</Header>
<Body>
<方法名>
<参数名>参数value</参数名>
</方法名>
</Body>
</soap:Envelope>
按照上面的模版拼出来请求体以后，我们的WebService采样器就编写完成了，执行一下，结果如下：
我们可以看到执行完成后，已经可以获取到上海的天气情况了。
实际执行测试的时候，我们当然不会这么简单，只测试一个方法。很多时候是需要将多个方法联动串联起来进行测试。譬如，这里我们用到的获取天气的接口，我们可以看到还有获取支持的城市列表的方法。感兴趣的小伙伴可以在看完本文档后，自己试着完成先调用获取城市列表的方法取到支持的城市列表，然后每个用户分别取到一个城市名，再根据取到的这个城市名在获取该城市的天气，并且根据取到的天气信息中，如果低于5摄氏度则将该城市名输出到控制台。
有小伙伴自己实现了该脚本的话，可以加群将脚本发给我们运营组的小伙子，他验证通过后会给你发红包哦，不用在意我们会不会给他报销，因为我们绝对绝对不会给他报销的，就酱，本文完工收摊了。
参考文章： Loadrunner调用Webservice接口进行性能测试时的方法及优化总结 原文出处