五千字聊一聊接口测试

关注

原创 2022-10-14 16:13:17 1.4k 阅读 AI 写同款· GEO 优化 ›

APIAuto大规模接口测试性能优化实战：从2小时到28分钟的效能提升 接口测试是软件质量保障的核心环节，其核心原理是通过模拟客户端请求验证服务端API的功能、性能与可靠性。随着微服务与中台架构的普及，接口测试用例数量呈指数级增长，传统串行执行模式面临严重的效率瓶颈，直接影响CI/CD的交付节奏与快速反馈能力。其技术价值在于通过并发执行、智能调度与资源优化，将自动化测试从流程负担转变为研发效能加速器。典型的应用场景包括数据中台、电商系统等具有海量接口回归验证需求的复杂业务系统。本文聚焦于APIAuto测试框架，针对**大规模用例集**与**性能瓶颈**，深入剖析从测试架构设计、阅读详情

优快云话题挑战赛第2期
参赛话题：学习笔记

今天我们再来介绍接口测试。话不多说，开始整干货，老规矩，首先全图镇楼。

1. 什么是接口？

什么是接口，接口测试就是对接口进行测试。我们可以先看一个例子，比如说你通过浏览器查询天气，浏览器有一个搜索引擎，在搜索引擎里面写入某某地的的天气，然后他就会返回该地的天气状况。浏览器请求天气信息，向天气系统发送请求。天气系统知道你的请求之后，会把天气信息返回给你。

这时候你对这个天气系统发送的是一个 URL，而天气系统返回给你的是关于天气的各种各样的信息。

这个响应结果比较原始，还没有经过前端同学的加工。比如说江苏南京，温度，是否阵雨，风向等信息，在前端同学那里，他会把这些数值都取出来，结合html、css和js就可以在页面上进行显示。

像这样你发一个 URL ，天气系统就返回给你一个天气信息，就那么一去一回的过程，就是接口请求的过程。就好像你去电影院买票一样，你给他钱，他给你票。

这个URL就是请求信息，如下图：

（1）HTTP

HTTP 是指协议，这个协议是客户端和服务端都互相遵守的契约，打个比方就是，租客和房东签的租房合同。

（2）域名

www.webxml.com.cn是指服务器地址，其实服务器地址是一个IP 地址和一个端口号组成，IP地址加端口号组成的一串数字，但是很多人记不住这一串数字，你也没办法记。但是你可以通过这种域名的方式www.webxml.com.cn，就不用记一长串的数字了，就相当于ip地址加端口号的别名昵称。

域名与 IP 地址加端口号是绑定的，实际上在网络传输的时候，域名会自动翻译成那个 IP 地址加端口号形式，根据IP 地址加端口号可以找到服务器到底在哪。

（3）资源路径

在这个 URL 里面，域名后面是资源路径，“/WebServices/WeatherWebService.asmx/getWeatherbyCityName”，你知道为什么吗？通过域名找到了这个服务器，服务器里运行这应用，在应用里就是通过资源路径指向具体的应用代码在哪里，应用代码完成响应的功能，比如查找天气信息等。

（4）参数

资源路径后面是参数。你要哪个城市的天气信息，就以这个城市作为一个参数，这还是比较灵活的，只要符合参数的取值范围，都可以查询。

所以说了这么多到底什么是接口？接口就是天气系统提供给外界访问的一个窗口，就叫接口。这个天气URL就是我的外界可以访问接口。其实这个天气系统它有很多很多的接口，有成百上千个接口就供天气系统内部使用。因为天气系统它不止只有一个功能，比如查询天气信息，查询天气预报，还可以总结以往的天气和去年的对比，甚至预测明年的天气等等，各种各样的功能都有了，每个功能都点都对应的一个接口。查询城市天气是它成百上千的接口中的一个，并且是对外开放的，他有很多不对外开放的。

2. 接口测试

接口测试就是针对于接口的测试，就针对于这个 URL 进行测试，就是你拿到这个 URL 之后，然后返回这个结果，这就是接口测试。

接口测试首先就是先拿到一个接口文档，接口文档里都写明了需要进行哪些测试，基本上都是包含一个接口请求的URL，请求方式POST还是GET，重点的是参数的类型和数值，以及返回值。

我们要做的就是拿这个URL在Postman上运行一下，看看运行后的结果和接口文档里的期待结果是否一致，一致则测试通过，没通过就给开发人员提BUG了。

（1）接口测试的本质

接口测试的本质就是传输数据，获得结果。传输的是啥？传输的是URL，传输的是你的一个参数，是你要查南京的这个天气的参数，获得结果就是把你南京的这种天气，这个温度，风向，还有阵雨什么的，返回给你。

（2）接口测试的意义

接口测试的意义是什么吗？就是你通过这个 URL访问这一个天气系统。首先它这个天气系统的代码肯定是写好的，这样才能对你的请求进行处理，这个代码里具体怎么做的，就要问开发人员了，我们只要能获得结果，就证明接口是可用的。开发人员把这功能开发好之后，然后你才能进行接口测试。这个在先后顺序上是不能反的，就像饭做好了才能吃饭，巧妇难为无米之炊。

当前已经获得了结果，这个结果是比较原始的形式，可能是json类型或者xml类型的，并不是我们期待的直接返回一个页面，因为前端人员还没有来得及处理。

所以接口测试就是在后端人员开发功能，前端人员还没有来得及处理的档口进行的活动，这样做它有什么好处呢？早于前端，晚于后端，就是它能早发现问题，早发现早预防。比如针对一个接口，你测试发现问题了，那你就可以让程序员立马改正。如果等到前端人员写好界面了，再测，出现了问题，后端人员不仅要改，前端人员也要改，真是牵一发而动全身。接口测试的意义就是，前端人员拿到结果直接解开发页面，而不是在不确定的结果下开发一个不确定的页面，既能早预防早发现，又能降低成本，何乐而不为呢。

其实等到前端开发的时候都已经到了这个开发的最后几个阶段了。这时候接口还不通的话，只能靠加班来解决了。如果这时候趁早把这个接口都跑通的话，那前端直接拿过来就用了，这样的话就能保证产品的准时上线了。

所以趁后端刚开发好的一个功能，就通过这个接口测试，测试一下是否能返回结果。之前的一些软件测试都是针对于前端已经开发好的界面，一旦发现bug，可能是前端的锅也可能是后端的锅，然而这种接口测试的方式，更进一层，先于前端，晚于后端，这样将bug的范围分隔开来，接口测试只测后端，等到前端写好界面，剩下的就针对前端进行测试，避免扯皮。

（3）接口文档

其实你可能会有点疑问，就是后端人员刚开发好一个接口，你这边就投入了测试，实时性上是保证了，可是接口数量一多，尤其是传递的参数千奇百怪，返回结果也各有千秋，不一会就全乱了，有没有一个像需求文档那样的东西，可以按图索骥，毕竟测试工作拼的是体力而不是拼记忆力。

其实是有这么一个文档即接口文档，接口文档是接口测试的一个依据，这个文档也就是开发人员写的。当他他写好一个功能之后，紧接着就要把这个功能接口，请求方式，参数，期待结果写进文档里。这样的每条记录就是测试用例。

在接口文档中，请求方式大多数情况下是GET或者POST。 GET就是跟着URL一起传过来的那个参数，但是它有一个坏处，就你把这个 URL 放在浏览器上，别人能看得你传的是什么内容。这样的话数据就不保密了。比如你通过接口使用GET方式传一个用户名，别人就可以直接从这个 URL上面获得你的用户名，用户名是不是就泄露了。所以针对这种不安全的状态就出现了POST请求方式，POST和GET的相同点就是都会传一个URL，不同点是GET的URL里会带参数，POST的URL里不带参数，参数放在消息体里，别人看不见摸不着，别提多安全了。

POST的好处除了安全，还能传递大数据量的参数，表现的形式更丰富，GET就依赖URL传递信息，传的信息少还不安全，当前并不是说GET请求方式就万恶不赦的，只是应用场景不同，没有优劣之分，GET适合读取信息，POST适合修改信息。

在获得服务器的响应结果的时候，通常都会附带一个响应码，这个响应码就是HTTP状态码，可以根据HTTP状态码的取值，可以判断是成功响应还是发生了异常，一般情况下HTTP状态码为200代表成功响应，除200以外的其他状态码都是异常状态，为了更清楚的表明到底发生了何种异常，异常状态码取值也会不同，以下是具体的状态码以及代表的意义：

（1）200：代表你发送的请求成功了，服务端成功响应了你的请求。

（2）202：代表你发送的请求已接受，但服务端还未完成处理。

（3）301：你请求的资源已被永久地移动到新的URL，网页会跳转到新的地址。

（4）302：URL临时移动，与301类似。但资源只是临时被移动，客户端应继续使用原有URL。

（5）400：客户端请求的语法错误，服务器无法理解。

（6）403：资源不可用，服务器理解客户的请求，但拒绝处理它，通常是由于服务器上文件或目录的权限设置导致的Web访问错误。

（7）404：服务器无法根据客户端的请求找到资源（网页），也就是代表着你请求的资源（网页）不存在了。

（8）500：服务器的内部产生了错误，无法完成客户端的请求。

（9）501：服务器不具备完成请求的功能，无法完成此请求。

（4）怎么做

首先从开发人员获得一个接口文档，接口文档的内容就是你的测试用例，你要做的就是通过PostMan或者自动化脚本执行这些接口，获取实际结果与接口文档的预期结果进行对比，符合预期就算测试通过，不符合则通过禅道提BUG。注意一般针对出现的不符合预期的结果，在提BUG的时候，除了写好测试步骤，最好再加一个截图，一图胜千言。

3. 使用Postman执行接口测试用例

（1）通过GET方式发送HTTP请求

发送此HTTPS请求，并采用GET方式进行发送

操作步骤如下。

1：在左侧下拉框选择GET的请求方式。

2：在地址栏输入URL请求：http://autodev.openspeech.cn/csp/api/v2.1/weather?openId=aiuicus&clientType=android&sign=android&city=南京

3：Query Params中的参数是系统自动填充的。

4：当单击“Send”按钮时，就可以将请求发送给服务器。

单击完“Send”按钮后，Postman就会把服务端返回的内容以json的形式呈现在下方区域

（2）通过POST方式发送HTTP请求

当采用POST方式发送HTTP请求时，为了安全起见，其传递的参数不能直接放在URL中，而是放在消息体里

1：在左侧下拉框选择POST的请求方式:

2：在地址栏输入不带参数的请求的URL：http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName

3：选定“Body”单选框。-> 选定“x-www-form-urlencoded”单选框，以KEY-VALUE的方式写入参数"theCityName"和参数值"南京"

4：单击“Send”按钮，获取服务端的响应内容。

总结：

post请求方式中参数并不是写在url上，而是写在请求体body中，这和get请求方式的不同之处

这里的请求天气的接口恰好都支持get或post请求，但是这并不能说明get和post就能互换使用，到底使用post还是get，最终还是要看接口文档中的要求。

4. python执行接口测试用例

（1）get请求

【getWeather.py】

01 import requests
02 test_params = 'theCityName=南京'
03 r = requests.get('http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName', params=test_params)
04 print(r.status_code)
05 print(r.headers)
06 print(r.text)

【代码分析】

● 第02行代码，将参数“theCityName=南京”赋值给变量test_params。

● 第03行代码，调用requests模块中的GET方式来发送此请求，即requests.get()方法。在此方法中加入了一个params参数，并将变量test_params的值赋给params这个参数，最后把请求回来的结果赋给变量r。

● 第04行代码，print(r.status_code) 表示打印出系统返回的HTTP协议状态码。

● 第05行代码，print(r.headers) 表示将响应头的信息打印出来。

● 第06行代码，print(r.text)表示以文本格式返回正文信息，并打印出来。

【结果】

（2）post请求

【postWeather.py】

01 import requests
02 test_params = {'theCityName':'南京'}
03 r = requests.post('http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName', data=test_params)
04 print(r.status_code)
05 print(r.headers)
06 print(r.text)

【代码分析】

● 第02行代码，将参数“theCityName=南京”以JSON的格式进行书写“{'theCityName':'南京'}”，并将此字符串赋给变量test_data。

● 第03行代码，调用requests模块中的POST方式发送此请求，即requests.post()方法。在此方法中加入了一个data参数，并将变量test_data的值赋给data这个参数，最后把请求回来的结果赋给变量r。

● 第04行代码，print(r.status_code)表示打印出系统返回的HTTP协议状态码。

● 第05行代码，print(r.headers)表示将响应头的信息打印出来。

● 第06行代码，print(r.text)表示以文本格式返回正文信息，并打印出来。

【结果】