随着云计算和移动互联网的发展，前后端分离的开发架构逐渐成为主流，API也逐步成为软件开发的核心之一。确保API的正确性、稳定性和安全性，是保证软件质量的关键因素。通过接口测试，我们可以有效地发现API中的错误和异常行为，确保应用程序各部分能够正确协同工作，从而提升整体软件的可靠性。在众多API协议中，HTTP协议占据了很大的比例，因此本文将以HTTP协议为例，介绍接口测试的基本概念、方法，以及公司自研测试平台的应用效果。
1. 什么是接口？
接口通常可以分为两类：程序内部的接口和系统对外的接口。
- 程序内部的接口：这是指在一个系统内部，方法与方法、模块与模块之间的交互。例如，在一个论坛系统中，用户需要先登录才能发帖，这时登录模块和发帖模块之间就需要进行交互，这种交互通过接口来实现，以便系统内部进行调用。
- 系统对外的接口：当你需要从外部网站或服务器获取资源或信息时，对方不会直接开放其数据库，而是提供一套接口供你调用。通过这些接口，你可以使用对方提供的方法来访问数据，实现资源共享。常见的例子包括我们使用的各种应用程序和网站，它们在进行数据处理时，通常都是通过调用接口来完成的。
2. 常见的接口分类有哪些？
常见的接口主要包括以下几类：
- HTTP接口：通过HTTP协议传输的接口，可以传输文本表单数据、JSON对象数据或XML数据。最常用的请求方式有GET和POST，本文将重点探讨这种接口的测试方法。
- RPC（远程过程调用）：允许应用程序通过网络调用远程计算机上的程序或函数。常见的RPC协议包括XML-RPC、JSON-RPC和gRPC等。
- Web Service：基于SOAP协议的一种RPC实现方案。相比传统的HTTP接口仅传输文本请求和响应，通过Web Service可以直接获取远程对象，并调用其属性和方法，这种方式比HTTP接口更为高级。测试这类接口时通常需要使用特定的工具。
3. 接口的组成部分
一个典型的接口通常由以下几部分组成：
- URL：用于访问和请求接口的地址和资源路径。
- 请求方法：指HTTP协议中定义的请求类型，如GET、POST、PUT、DELETE等。
- 请求头：包含请求的元数据，如用户代理、授权信息、编码格式等。
- 请求体：包含向接口发送的请求参数和数据，通常使用表单、JSON或XML格式。
- 请求参数：传递的数据和参数，常见格式包括表单、JSON和XML。
- 响应头：包含响应的元数据信息，如返回数据类型、缓存控制、跨域策略等。
- 返回体：接口返回的响应结果和数据，通常使用JSON或XML格式。
- 响应码：用于指示请求是否成功的状态码。
4. 什么是接口测试？
接口测试是一种用于验证系统组件之间接口的测试方法。其主要目的是检测系统与外部系统之间、以及内部各子系统之间的交互点。测试的重点在于检查数据的交换、传递、控制管理过程，以及系统间的逻辑依赖关系等。
功能测试通常通过页面输入值，并通过点击按钮或链接将值传递给后端，此外，功能测试还需要测试UI、前端交互等。而接口测试则不同，它不涉及页面操作，而是通过调用接口规范文档中提供的地址和参数，拼接报文发送请求，并检查返回结果。因此，接口测试相对简单，只需测试输入和输出参数。
5. 为什么要进行接口测试？
有人可能会问，既然已经进行了功能测试，为什么还要进行接口测试呢？我们可以通过一个简单的例子来说明接口测试的必要性。
假设我们在测试用户注册功能，要求用户名为6~18个字符，包含字母（区分大小写）、数字和下划线。在功能测试中，我们可能会测试输入超过20个字符、输入特殊字符等情况，这些测试通常只在前端进行校验。然而，如果后端没有进行相应的校验，而有人通过抓包绕过前端校验直接发送数据到后端会发生什么？这种情况下，后端可能接受非法数据，导致安全漏洞，例如用户可以随意登录，甚至获取管理员权限。这就是接口测试的重要性所在：
- 能发现功能测试无法捕捉的隐藏问题
- 检查系统的异常处理能力
- 验证系统的安全性和稳定性
- 即使前端有所变动，后端代码不变的情况下，接口测试可以确保稳定性
在进行接口测试之前，还需要了解以下几点：
-
GET和POST请求：
- GET请求可以直接在浏览器中输入URL进行测试，而POST请求则需要借助工具来发送请求。
- GET请求使用URL或Cookie传递参数，POST请求则将数据放在请求体（BODY）中。
- GET的URL有长度限制，而POST请求的数据可以非常大。
- POST请求比GET请求更安全，因为数据在地址栏上不可见。
- 一般情况下，GET请求用于获取数据，POST请求用于发送数据。
-
HTTP状态码： 每个HTTP请求都会返回一个状态码，用以标识请求的成功与否。
常见状态码包括：
- 200：请求成功，服务器返回了预期的响应。
- 302：请求被重定向到其他位置。
- 400：客户端请求有语法错误，服务器无法理解。
- 401：请求未授权，用户需要认证。
- 403：请求被拒绝，服务器理解请求但拒绝执行。
- 404：服务器无法找到请求的资源。
- 500：服务器内部错误，无法完成请求。
- 504：网关超时，服务器未能在规定时间内响应。
-
Cookie与Session的区别：
- Cookie数据存储在客户端浏览器上，Session数据则保存在服务器上。
- Cookie的安全性较低，容易被分析和攻击，建议使用Session进行敏感数据的存储。
- Session会在服务器上占用资源，访问量大时会影响服务器性能，因此需要平衡使用Cookie和Session。
- 单个Cookie的存储数据不能超过4K，且大多数浏览器限制一个站点最多保存20个Cookie。
6. 如何进行接口测试？
接口测试的核心在于通过模拟请求并验证响应，确保接口按照预期工作。以下是常见的接口测试方法和策略：
通用接口测试用例设计
- 功能验证： 首先需要确保接口的基本功能正常工作，即进行通用的功能测试。按照接口文档提供的参数，传入合法的输入值，检查是否能返回正确的结果。
- 参数组合测试： 例如，有一个操作商品的接口，其中有一个字段
type：当type传1时，表示修改商品，此时商品ID、商品名称和价格中的至少一个是必填项；当type传2时，表示删除商品，此时商品ID是必填项。对于这种情况，需要测试各种参数组合。例如，type传1时，单独传商品名称是否能修改成功，或者同时传商品ID、名称和价格是否能成功修改。 - 接口安全测试：
- 绕过验证：例如，当购买一个价格为300元的商品时，测试是否能在提交订单时将价格篡改为3元，后端是否能识别并拒绝这种非法请求；更进一步的测试是将价格改为-3元，验证系统是否错误地增加用户的余额。
- 绕过身份授权：例如，测试商品信息的修改接口是否限制为只有卖家才能操作，验证是否存在普通用户或其他卖家也能修改的漏洞。
- 参数加密：例如，检查登录接口中，用户名和密码是否进行了加密传输。如果未加密，拦截请求的攻击者可能会获取到用户的敏感信息。同时，验证加密规则是否足够安全，难以被破解。
- 密码安全规则：测试密码的复杂性校验，确保密码强度符合安全要求。
- 异常处理验证： 异常验证指的是不按接口文档要求输入参数，以测试接口对异常情况的处理。例如：
- 必填项为空：验证接口在必填参数缺失时是否能返回适当的错误信息。
- 参数类型错误：传递整数类型的参数时，测试传入字符串类型是否能被正确识别并处理。
- 参数长度超出限制：如果规定参数长度为10，测试传入长度为11的值时，接口能否正确处理并返回错误。
基于业务逻辑的用例设计
基于业务逻辑设计测试用例是根据系统特定的业务需求来进行的，测试重点也会有所差异。这部分的测试设计类似于功能测试的用例设计，但更侧重于接口之间的交互和业务逻辑的准确性。
例如，在一个论坛系统（BBS）中，可以设计以下测试场景：
- 登录失败次数限制：用户连续登录失败5次后，需等待15分钟才能再次尝试登录。测试此功能是否能准确执行。
- 新注册用户发帖限制：新注册用户必须经过实习期后才能发帖。测试系统是否正确限制新用户的发帖权限。
- 删除帖子扣除积分：删除帖子时应扣除用户的积分，测试该功能是否执行正确。
对于这些测试点，需要列出相应的测试用例，并根据业务需求生成测试数据，确保每个测试场景都能被准确验证。
7、接口测试场景的工具有哪些？
以下是几种常用的接口测试工具及其优缺点：
| 工具名称 | 优势 | 缺点 |
|---|---|---|
| POSTMAN | (1)可以发送 HTTP/HTTPS 请求 (2)提供了一个易于使用的图形化界面 (3)可以对请求进行分组和分类，方便管理和组织 (4)可以对请求进行自动化测试和集成测试 (5)可以导出测试结果和请求文档 | (1)功能较为单一，只适合于接口测试 (2)不支持自动化测试 |
| JMETER | (1)支持多种协议，可以模拟多种网络场景 (2)可以通过分布式测试提高测试效率 (3)支持多线程测试，可以模拟多用户同时访问服务器的情况 (4)可以通过插件扩展功能 | (1)学习曲线较陡峭，需要一定的编程能力 (2)界面不够友好，需要手动配置很多参数 (3)配置比较繁琐，需要对服务器有一定的了解 |
| SOAPUI | (1)支持 SOAP 和 RESTful 接口测试 (2)提供了一个直观的图形化界面，易于上手 (3)支持自动化测试和集成测试 (4)可以对请求进行性能测试 | (1)界面复杂，需要一定的学习成本 (2)对于复杂的测试场景，需要手动编写脚本 (3)对于一些特殊的接口类型支持不够全面 |
扫一扫
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
