什么是接口测试？python怎么做接口测试工具

本文目录

• 什么是接口测试
• python怎么做接口测试工具
• 通过http访问测试API的单元测试代码什么意思
• 什么是接口测试
• Jmeter发送SOAP请求对WebService接口测试
• 接口测试和系统测试区别
• http接口测试与webservice接口测试有什么区别
• 如何测试一个api调用耗时
• 软件开发接口测试的常见问题
• 如何正确执行功能API测试

什么是接口测试

什么是接口测试
接口测试是测试系统组件间接口的一种方式，接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是检查数据的增删改查操作，以及系统之间的逻辑关系等。
***隐藏网址***
接口的类型包括：post ，get，put，和delete等。
post和get的区别：post的参数是存在webfrom，以表单的形式存在，get的参数是存在在url中
get：请求获取request-url所标时的资源
post：在request-url所标识的资源提交数据或者附加新的数据。
put：和post很像，也是想像服务器提交数据，put指定了资源在服务器上的位置，post没有
delete：删除服务器上的某个资源

python怎么做接口测试工具

之前使用过urllib和urllib2做接口测试，在做的途中，感觉使用urllib2直接进行的get，post 请求并没有那么好用。作为测试人员，所需要的测试工具应当以方便为第一要务，测试的耗时只要是真正的无人值守，耗时不是太久的都可以接受。所以，本人又尝试了一个新的包：requests。　　

Requests 是用Python语言编写，基于 urllib，采用 Apache2 Licensed 开源协议的 HTTP 库。它比 urllib 更加方便，可以节约我们大量的工作，完全满足 HTTP 测试需求。Requests 的哲学是以 PEP 20 的习语为中心开发的，所以它比 urllib 更加 Pythoner。更重要的一点是它支持 Python3 ！推荐一篇文章，上面有该包的详细说明 传送门，以下只会写到我用到的部分，所以更多的了解需要自己去搜资料

好了，我们开始吧！！

接口测试中重要的部分：

1.get和post方法

2.用到的参数

3.请求头

4.cookie

5.日志输出

6.如何调试你的程序--借助fiddler

按照以上的顺序，我将一一说明我的搞法，因为编码能力有限，所以可能看着很low

一、get和post

requests包很好的实现了post和get方法，示例：

1 import requests2 response_get = requests.get(url, data, headers, cookies)3 response_post = requests.post(url, data, headers, cookies)

其他的访问方式如put，head等等，用法几乎都是如此，因为没用到，所以省略

现在一般的接口返回值有页面和json俩种，按照需求，可以分别使用response.text或者response.content获取，text获取的是unicode类型的返回值，而content返回值是str类型，所以我一般使用content来获取返回值，因为这样获取的返回值可以直接使用正则或者in的方式来验证返回值结果是否正确。

我自己为了实现接口的自动访问，所以又在requests上面加了一层封装，就像下面这样：

1 def main_get(list_result, cookies): 2     """ 3     用于模拟get请求，返回结果 4     :param list_result:空列表，用于存储结果 5     :param cookies: 登陆后的cookie 6     :return:访问结果 7     """ 8     # List_interface_get写在接口文件里，文件是py格式，然而它本身是字典类型 9     for key in List_interface_get:10         try:11             f1 = requests.get(key, cookies=cookies)12             if f1:13                 print f1.content14                 print List_interface_get)45         except AssertionError:46             print ’One Error in post’47             pass48     return result_list

二、用到的参数以及请求头

我用的方法是把这些都存放于一个py文件中，当然也可以使用excel或者xml文件，甚至于使用DB。项目紧急，凑合了一下，这里的数据结构主要为了符合上面封装的函数，直接上代码看吧

***隐藏网址***

三、cookie

一款产品的接口测试中必定会使用登录状态，需要使用cookie实现，之前写过使用cookiejar获取cookie，requests中获取cookie的方法更为简单，不过首先你得知道是哪个接口set了cookie，不过一般是登录啦。登录接口访问之后set了cookie，那好，就去调用登录接口，然后拿到搞回来的cookie:

# 只需要这样！！login = requests.post(login_url, data=login_data, headers=login_header)
cookie = login.cookies

这个cookie就是登录状态了，拿着随便用，需要登录的就直接cookies=cookies

四、日志输出

这里注意看第二步中接口数据，有接口描述，也有接口是啥，第一步中又把content做成返回值了，具体拼接方式自己想吧，东西全有了，想写啥写啥，还可以加上获取本地时间的api获取接口运行时间，log文件该长啥样是门学问，这里就不献丑了。

五、借用fiddler调试你的脚本

requests允许使用代理访问，这有啥用，真有！fiddler是一款截包改包的工具，而且通过扩展可以进行请求间的比对，这样让你的程序访问的请求和真正正确的请求作对比，为啥我的程序访问出错？是不是缺了请求头？参数是不是丢了？cookie是不是少了？很容易看出来。写法如下：

***隐藏网址***
requests.post(url, proxies=proxies)

这样就可以走代理了，除fiddler以外还有charles和burp suite可以使用，具体看个人喜好吧。

通过http访问测试API的单元测试代码什么意思

通过HTTP访问测试API的单元测试代码，是指针对一个API的单元测试代码，使用HTTP协议模拟请求和响应，测试API的功能是否符合预期。
一般来说，API的单元测试可以使用测试框架，例如JUnit（Java）、pytest（Python）等，编写测试用例，模拟输入数据，调用API的接口，检查输出结果是否符合预期。而通过HTTP访问测试API的单元测试代码，是在测试框架中，使用HTTP客户端模拟发送请求，并验证API返回的HTTP响应状态码、头部信息、响应正文等内容，从而测试API的正确性、健壮性、性能等方面。
举个例子，假设有一个API接口用于查询某个用户的信息圆旦，请求方式为HTTP GET，请求URL为/api/users/{id}，其中{id}为用户ID。那么针对这个API的单元测试代码，可以通过HTTP客户端模拟发送GET请求，请求URL为/api/users/123，其中123为具体的用户ID，然后验证API的返回结果是否包含该用户源罩的正确信息。测试代码可以使用类似以下的Python代码实现：
import requests
def test_get_user_info():
***隐藏网址***
headers = {"Accept": "application/json"} # 请求头部，指定返回格式为JSON
response = requests.get(url, headers=headers) # 发送HTTP GET请求
assert response.status_code == 200 # 验证HTTP响应状态码是否为200
assert response.headers == "application/json" # 验证返回格式是否为JSON
user_info = response.json() # 解析JSON格式的响应正文
assert user_info == 123 # 验证返回结果是否包含指定用户的正确信息
assert user_info == "John Doe"
assert user_info == "johndoe@example.com"
# ... 其他验证操作
====================
当然可以使用Java语言实现通过HTTP访问测试API的单元测试代码。下面是一个简单的示例，假设有一个API接口用于查询某个学生的信息，请求方式为HTTP GET，请求URL为/api/students/{id}，其中{id}为学生ID。那么可以使用Java的HTTP客户端库如HttpClient或者OkHttp等，编写单元测试代码，模拟发送GET请求，请求URL为/api/students/123，其中123为具体的学生ID，然雹腔闹后验证API的返回结果是否包含该学生的正确信息。具体代码如下：
***隐藏网址***
***隐藏网址***
***隐藏网址***
***隐藏网址***
***隐藏网址***
import org.junit.Test;
import static org.junit.Assert.*;
public class StudentControllerTest {
***隐藏网址***
private static final String API_PATH = "/api/students";
@Test
public void testGetStudentById() throws Exception {
// 构建请求URL
int id = 123;
String url = BASE_URL + API_PATH + "/" + id;
// 创建HTTP客户端
***隐藏网址***
// 创建HTTP GET请求
HttpGet request = new HttpGet(url);
// 发送HTTP GET请求并获取响应
***隐藏网址***
// 验证HTTP响应状态码是否为200
assertEquals(200, response.getStatusLine().getStatusCode());
// 验证返回格式是否为JSON
assertEquals("application/json", response.getEntity().getContentType().getValue());
// 解析JSON格式的响应正文，并验证返回结果是否包含指定学生的正确信息
String responseBody = EntityUtils.toString(response.getEntity());
Student student = new ObjectMapper().readValue(responseBody, Student.class);
assertEquals(id, student.getId());
assertEquals("John Doe", student.getName());
assertEquals("johndoe@example.com", student.getEmail());
// ... 其他验证操作
}
}
}
在上面的示例中，首先构建了请求URL，然后创建了一个HTTP客户端，发送HTTP GET请求并获取响应。接下来验证了HTTP响应状态码是否为200，验证返回格式是否为JSON，最后解析JSON格式的响应正文，并验证返回结果是否包含指定学生的正确信息。这样，就可以编写针对API的单元测试代码，通过HTTP协议模拟请求和响应，测试API的正确性、健壮性、性能等方面。

什么是接口测试

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
　　接口测试的目的是为了测试接口（听起来怪怪的），尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
　　不是所有的团队都可以在一个隔离的测试环境中进行测试工作的，因此使得对外部接口的测试显得困难。我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来来测试。等等这些都增加了实际测试执行中遇到的风险，但有些时候是可以避免的。
　　
假设/预处理
　　项目的责任人/开发人员必须已经成功完成了单元测试、功能测试和集成测试，一些错误都已经被列出。测试策划人员拿到的是最新版本的源代码
　　期望
　　² 正如前面提到过的那样，最重要的是关于外部接口的测试，这需要依赖于外部接口的相关数据，而这可能是极其复杂的
　　² 测试项目需要一系列的测试计划以及和外部组织的协调工作，主要包括：
　　l 负责人选
　　l 预定的测试时间
　　Ø 如果没有合适的测试环境，测试可能需要在周末或者工作时间以外的时间里进行
　　l 需要什么类型的测试用例，需要多少以及这些用例分别是用来测试什么的
　　Ø 提供测试用例的副本及相关文件给相关合作人员
　　Ø 如果外部组织有一些特殊用例需要执行，我们也需要拿到相关副本及文件
　　l 谁将提供测试数据，这些测试数据包括哪些方面的内容，是以什么形式给出的（纸质，电子档还是只是一些数据的底稿并且需要相关的人员整理成可用的数据）
　　l 谁将对测试结果进行确认并且判别这些数据就是我们所需要的
　　l 每隔多久时间我们需要各路人马需要聚在一起讨论测试中遇到的问题以及测试进度
　　² 所有正常的情形和异常的情形都需要测试，测试的各个方面（数据的各个出口，路径，入口）都需要尽可能考虑周全。我们不仅需要用一般大小的数据量去测试，也需要用预期的或者规定的最大数据量去测试
　　² 如果允许的话，我们还可以测试各个部分处理一批数据的时间数据
　　² 如果因修复bug等改动代码从而改变了接口的某一端，相关的决定，到期时间，再测试等过程都应该被记录在案，并且分发到各个相关组织或人员。
　　职责划分
　　² 测试的建立------开发人员，数据库和/或系统的负责人， 或者测试人员
　　² 测试的执行-------测试人员
　　² 测试结果的确认，测试结束的决定------开发组长，测试组长，质量保证组长，架构人员，项目负责人，外部组织负责人（如果可以的话）
　　测试环境
　　² 系统测试环境和外部组织的测试环境
　　数据类型
　　² 真实的数据------被处理过的用于测试的数据
　　测试结束
　　² 依照某某文档

Jmeter发送SOAP请求对WebService接口测试

1. 建立WebServiceTest Plan
1) 添加ThreadGroup
右键单击Test Plan选择Add --》 ThreadGroup，配置
Number of Threads、Ramp-UpPeriod、Loop Count可随测试不同随时修改。
三种参数解释如下：
Number of Threads为发起线程总数。
Ramp-Up Period 指定了JMeter开启Number ofThreads个线程所需的时间。例如，如果待发起30个线程（即模拟用户），Ram-Up Period为15秒，则每秒增加2个线程（30个用户/15秒）。如果设置为0，则JMeter会自动启动所有模拟用户。
Loop Count为循环次数。
2. 添加 WebService Requests
右键单击“WebService线程组”，Add --》 Sampler --》 WebService(SOAP)。
注：灰色“线程组”为其它测试使用过的线程组，此处这设置为Disabled线程组，在本次测试中不使用。
配置
将发布好的Service的 WSDL URL粘贴到WSDL URL中点击Load WSDL之后，WebMthods自动弹出，
只需自己选择Method然后单击Configure即可完成绝大部分自动配置
但是里面会涉及Soap/XML-RPC Data的编写，我编写的如下：
view plain copy
《?xml version="1.0" encoding="utf-8"?》
《soap:Envelope
***隐藏网址***
***隐藏网址***
***隐藏网址***
《soap:Body》
《ns1:simpleMethod
***隐藏网址***
《name xsi:type="xsd:string"》Yerasel《/name》
《/ns1:simpleMethod》
《/soap:Body》
《/soap:Envelope》
这个XML中绝大部分都是固定的。其余解释如下:
simpleMethod是WebService发布的方法；
***隐藏网址***
name是simpleMethod的参数名，参数类型是string；
Yerasel是输入的实参。
SimpleService服务端源程序如下：
view plain copy
// SimpleService.java
package com.deltaj.server;
public class SimpleServer {
/**
* 简单的测试方法
*
*/
public String simpleMethod(String name) {
return name + "Say this is a Simple method ^-^";
}
}
注意：
《arg0 xsi:type="xsd:string"》Yerasel《/arg0》也可以，
在发布成wsdl时候, 方法的参数名称被自动的映射成arg0, arg1, 解决方法如下:
view plain copy
Java代码
public User create(
@WebParam(name = "user")
User user);
因此SimpleService服务端源程序改写如下：
view plain copy
// SimpleService.java
package com.deltaj.server;
public class SimpleServer {
/**
* 简单的测试方法
*
*/
public String simpleMethod(@WebParam(name = "personname")String personname) {
return personname + "Say this is a Simple method ^-^";
}
}
Soap/XML-RPC Data 如下：
view plain copy
《?xml version="1.0" encoding="utf-8"?》
《soap:Envelope
***隐藏网址***
***隐藏网址***
***隐藏网址***
《soap:Body》
《ns1:simpleMethod
***隐藏网址***
《personname xsi:type="xsd:string"》Yerasel 《/personname》
《/ns1:simpleMethod》
《/soap:Body》
《/soap:Envelope》
注：
发布SimpleServer时，需要写xml，这是发布WebService的一般步骤，内容如下：
view plain copy
《serviceGroup》
《service name="SimpleServer" scope="application"》
《description》
SimpleServer
《/description》
《messageReceivers》
***隐藏网址***
***隐藏网址***
《/messageReceivers》
《parameter name="ServiceClass"》com.deltaj.server.SimpleServer《/parameter》
《/service》
《/serviceGroup》
文件名为META-INF/services.xml。
文件布局
com里面是包以及.class
然后，在bin目录下运行"jar cvf SimpleServer.aar . "即可
将aar放入Tomcat的services目录中即可发布。

接口测试和系统测试区别

接口测试和系统测试区别：
1、接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
2、系统测试是将已经集成好的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、数据、某些支持软件和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行的一系列测试活动。系统测试目的：验证软件是否满足需求规格说明书要求。

http接口测试与webservice接口测试有什么区别

***隐藏网址***

webservice接口测试流程：

1. 开发人员要到接口的wsdl地址和接口设计说明书。

2. 在soapui中新建工程，导入wsdl地址。

3. 选择自己要测试的接口的方法，选择request。

4. 根据接口设计说明书选择要测试方法的xml请求，并粘贴到soapui的请求栏，然后用自己的测试数据替换原有的xml请求中的参数。

5. 点击运行，查看返回的xml响应，并参照接口设计说明书及自己的输入参数，确定接口返回的xml响应是否是预期结果，以判断接口是否是通的 。

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

如何测试一个api调用耗时

请求发送过慢导致耗时增加；
DNS解析过慢导致耗时增加；
恶劣的网络环境导致耗时增加；
一直在排队导致响应过慢；
服务端响应过慢导致耗时增加；
响应体积过大导致耗时增加；
等等……
一般从感官上觉得API接口响应慢，大部分人会直接归结于服务端处理慢，其实是不合理的。通过在内网环境下的API耗时分析和外网环境下的API耗时分析的对比，一般会认识到原因所在。

软件开发接口测试的常见问题

对于一款程序来说，接口除了有对接外部的以外同时还有对程序内部的接口，下面电脑培训就一起来了解一下，关于软件开发接口测试的常见问题。

一、常见接口：

***隐藏网址***

***隐藏网址***

二、前端和后端：

在说接口测试之前，我们先来搞清楚这两个概念，前端和后端。

前端是什么呢，对于web端来说，咱们使用的网页，打开的网站，这都是前端，这些都是html、css写的;对于app端来说呢，它就是咱们用的app，android或者object-C(开发ios上的app)开发的，它的作用就是显示页面，让我们看到漂亮的页面，以及做一些简单的校验，比如说非空校验，咱们在页面上操作的时候，这些业务逻辑、功能，比如说你购物，发微博这些功能是由后端来实现的，后端去控制你购物的时候扣你的余额，发微博发到哪个账号下面，那前端和后端是怎么交互的呢，就是通过接口。

前面说的你可能不好理解，你只需记住：前端负责貌美如花，后端负责挣钱养家。

三、什么是接口测试：

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

如何正确执行功能API测试

测试曾经在GUI级别进行，但开发人员已经意识到它是多么脆弱。本文将讲述更多API测试以及如何使其最佳运行。

API或应用程序接口是一种通信方法系统，它使开发人员和非开发人员能够访问程序，过程，函数和服务。API中使用的最常见协议是HTTP以及REST架构。使用REST编程的开发人员可以轻松理解他们的代码。他们和其他人知道他们将使用哪种语言，功能如何工作，可以使用哪些参数等。

开发API的流行框架包括Swagger，WADL和RAML。理想情况下，在编程时，开发人员会形成一个“API契约”，它描述了如何使用API 中开发的服务。

在此标准化之前，编程就像狂野西部的草原放飞自我。开发人员以他们认为合适的方式访问他们的代码，并且很难开发公共服务并使其可用，因为有许多方法可以编写代码。SOAP是标准化的第一次尝试，但现在REST是主导者。

API测试可创建更可靠的代码。但从 历史 上看，测试更多在在GUI级别进行。当开发人员完成他们的工作时，他们会将其交给QA工程师。测试工程师的时间有限，因此他们会在最高级别的GUI上测试代码。测试工作将涵盖前端和后端开发。

这适用于手动测试和自动化测试的开始，但不适合敏捷和连续测试的时代。GUI测试过于脆弱，GUI自动化脚本很容易奔溃不稳定。此外，团队不能等待整个系统更新，并且在测试发生之前准备好GUI。

在敏捷时代，测试必须在较低级别进行，即在API级别进行。开发人员甚至可以自己完成。由于“API契约”，API测试甚至可以在开发完成之前测试准备阶段。这意味着开发人员可以根据预先编写的测试（又称测试驱动开发）验证他们的代码。

但尽管已经知道API测试的重要性，但并不总是这样做。敏捷开发人员没有时间。平均而言，开发人员每周只有很少的时间写代码，剩下的时间用于测试，文档，验证和会议。所以他们更倾向于强行冲刺，进行手动测试，但这只需要太长时间。在两周内完成功能性API测试非常困难，还需要开发，测试，验证并完成文档编写。

自动化API测试可以加快开发速度，并节省开发人员做其他事情的时间，比如编写代码。自动化还可以更轻松地覆盖整个测试范围：正面，负面，边缘情况，SQL注入等。这样可以确保没有任何机会，所有参数和排列都经过测试。试图测试其API的敏捷开发小组可能会测试一个或两个正面测试流程，或者一个正面测试流程和一个负面测试流程，并称之为成功。但这不是彻底的API测试，并且为不必要的发布风险打开了大门，因为错过了许多变体并且未实现完全验证。

例如，假设API采用作者姓名和图书发布日期。将测试名称和日期，看看它们是否有效。一旦正确收到响应，API就可以运行。

但是负面和边缘情况呢？例如，插入一个正确的日期但没有书，或更改日期格式，或一年中不存在的正确日期格式，或长名称，或插入向数据库授予数据的SQL代码等。这些仅是需要测试的许多变体中的一些示例，即使它们未在合同中涵盖。

开发人员和测试人员需要一种简单的方法来创建涵盖所有这些方面的测试。我们建议您寻找可以获取Swagger或其他框架文件的解决方案，根据您的API合同对其进行全面测试，并将其作为持续集成流程的一部分进行运行。这可确保您专注于开发强大而耐用的代码。