软件测试基础十九 （接口相关知识详解）

接口相关知识详解

一、接口概述

（一）接口定义

接口是指系统或组件之间的交互点，是实现数据交互的通道。它就像是不同部分之间沟通的桥梁，使得数据能够在各个系统或组件之间顺畅地流动。

（二）接口的类型

1. 按范围划分

• • 系统之间的接口：

• • • 多个内部系统之间的交互，例如企业内部不同业务部门的系统之间需要进行数据共享和业务协作，就通过这些接口实现。比如财务系统和人力资源系统之间可能会通过接口传递员工薪资等相关信息。
    • 内部系统与外部系统之间的交互，比如企业的电商系统与第三方支付系统的接口，用于完成支付流程。

• • 程序内部的接口：

• • • 方法与方法之间的交互，在一个软件模块中，不同的方法可能需要相互调用并传递数据，这就通过接口来完成。例如，一个图像处理模块中，图像缩放方法和图像裁剪方法之间可能通过接口传递图像数据和相关参数。
    • 模块与模块之间的交互，不同功能模块之间为了协同工作，通过接口进行数据交换和功能调用。比如在一个游戏开发中，角色控制模块和场景渲染模块之间的接口，用于传递角色的位置、状态等信息，以实现角色在场景中的正确显示和操作。

二、接口测试

（一）接口测试定义

接口测试是对系统或组件之间的接口进行测试，主要是校验数据的交换、传递和控制管理过程，以及相互逻辑依赖关系。它就像是对接口这个“桥梁”的质量检测，确保数据能够安全、准确地通过。

（二）接口测试原理

模拟客户端向服务器发送请求，服务器接收请求后进行相应的业务处理，并向客户端返回响应数据，然后检查响应数据是否符合预期。例如，在一个用户登录接口测试中，模拟用户输入用户名和密码发送请求，服务器验证后返回登录成功或失败的信息，测试人员检查返回的信息是否与预期一致。

（三）接口测试的特点

1. 测试提前介入与Bug发现

• • 可以提前介入，提早发现Bug，符合质量控制前移的理念。在软件开发的早期阶段，接口一旦确定，就可以进行接口测试，及时发现接口设计和实现中的问题，避免问题在后期集成或系统测试时才暴露，减少修复成本和时间。
  • 能够发现一些页面操作发现不了的问题。因为页面操作可能受到前端界面的限制，有些底层的逻辑问题或接口数据处理问题在页面上无法直接体现，而通过接口测试可以直接针对接口进行深入的测试，发现这些隐藏的问题。

1. 低成本高效益与自动化

• • 接口测试低成本高效益。底层的一个Bug能够引发上层8个左右Bug，通过接口测试可以在底层发现问题，避免问题在系统上层扩散，从而减少修复成本。而且接口测试可以实现自动化，提高测试效率，降低人工测试的成本和工作量。
  • 不同于传统的单元测试，接口测试是从用户的角度对系统进行全面的检测。它更关注系统整体的功能和接口之间的交互，能够更全面地验证系统的正确性和稳定性。

（四）接口测试的实现方式

1. 使用接口测试工具

• • 比如JMeter，它可以用于模拟各种请求，对接口进行性能测试和功能测试。可以设置不同的请求参数、并发用户数等，来测试接口在不同负载下的性能表现，以及验证接口的功能是否正确。
  • Postman也是常用的接口测试工具，它提供了友好的界面，方便用户创建、发送请求，并查看响应结果。可以用于快速测试接口的基本功能，以及进行接口调试。

1. 通过编写代码实现

• • 例如使用Python + Requests。Python是一种强大的编程语言，Requests库则提供了方便的HTTP请求功能。通过编写Python代码，可以灵活地构建各种请求，处理请求和响应数据，实现更复杂的测试逻辑。比如可以编写自动化测试脚本，对多个接口进行批量测试，对响应数据进行深度验证和分析等。

三、接口自动化测试

（一）概念

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。接口自动化测试则是让程序或工具代替人工自动地完成对接口进行测试的一种过程。它可以提高测试效率，减少人工测试的重复性工作，并且能够在无人值守的情况下持续运行测试，快速发现接口的问题。例如，在项目的持续集成过程中，每次代码提交后都可以自动运行接口自动化测试，及时反馈接口是否受到代码变更的影响。

四、HTTP协议

（一）HTTP协议介绍

HTTP（HyperText Transfer Protocol）超文本传输协议，是一个基于请求与响应模式的、应用层的协议，也是互联网上应用最为广泛的一种网络协议。它是Web通信的基础，负责在客户端和服务器之间传输超文本数据，如网页、图片、视频等。

（二）HTTP协议的特点

1. 支持客户端/服务器模式

• • 客户端（如浏览器）向服务器发送请求，服务器接收请求并处理后返回响应给客户端。这种模式使得资源的分布和管理更加高效，客户端可以专注于用户界面和交互，服务器则负责数据的存储和处理。

1. 简单快速

• • 协议设计简单，使得它在传输数据时效率较高。客户端和服务器之间的通信过程相对简洁，能够快速地完成请求和响应的交互，适用于互联网上大量的信息传输。

1. 灵活

• • 支持多种类型的数据传输，如文本、图片、音频、视频等。可以通过不同的请求方法和头部信息来适应不同的应用场景和需求。

1. 无连接

• • 每次连接只处理一个请求，服务器处理完客户端的请求并收到客户端的应答后，即断开连接。这种方式可以节省服务器资源，但对于需要频繁交互的应用，可能会导致一定的连接开销。

1. 无状态

• • 服务器不会保存客户端的状态信息。每个请求都是独立的，服务器不会因为之前的请求而对后续请求有特殊的处理。这使得服务器的处理更加简单高效，但对于需要保持状态的应用（如购物车），需要通过其他方式（如Cookie、Session）来实现状态管理。

（三）URL

1. 定义

• • URL（Uniform Resource Locator）统一资源定位符，是互联网上标准资源的地址。HTTP使用URL来建立连接和传输数据。

1. URL格式

• • 协议部分：“http”，常见的协议还有HTTPS、FTP等。HTTPS用于安全的网络通信，FTP用于文件传输。
  • 域名部分：“www.weather.com.cn”，也可以使用IP地址作为域名使用。域名是为了方便用户记忆和访问，而IP地址是网络中设备的实际地址。
  • 端口部分：“8080”，端口可以省略，默认端口（HTTP:80，HTTPS:443，FTP:21）。不同的端口用于区分不同的服务或应用程序在服务器上的监听位置。
  • 资源路径部分：“/weather1d/101010100.shtml#search”，指定服务器上的具体资源路径。
  • 查询参数部分：“uid=123&page=1”，可以允许有多个参数，多个之间用“&”作为分隔符。用于向服务器传递额外的信息，例如在查询数据库时传递条件参数。

1. 示例

• • 查询天气信息：北京天气预报,北京7天天气预报,北京15天天气预报,北京天气查询

（四）HTTP请求

1. 组成部分

• • HTTP请求由三部分组成，分别是请求行、请求头、请求体。

1. 请求行

• • 用来说明请求方法、要访问的资源以及所使用的协议版本。
  • 常用请求方法：

• • • GET：从服务器获取资源（一项或多项），常用于获取网页内容、查询数据等。例如在浏览器中输入网址访问网页，就是使用GET方法向服务器请求网页资源。
    • POST：在服务器新建一个资源，常用于提交表单数据、上传文件等。比如用户注册时，将用户信息提交到服务器创建新用户记录。
    • PUT：在服务器更新资源（客户端提供改变后的完整资源），用于更新已有资源的全部内容。
    • DELETE：从服务器删除资源，用于删除服务器上的指定资源。

• • 其他请求方法（了解）：

• • • HEAD：请求获取由Request - URI所标识的资源的响应消息报头，常用于获取资源的元信息，而不获取实际内容，可用于检查资源是否存在、获取资源的修改时间等。
    • TRACE：请求服务器回送收到的请求信息，主要用于测试或诊断，可用于查看请求在网络中的传输路径和处理情况。
    • CONNECT：保留将来使用，通常用于代理服务器或隧道技术。
    • OPTIONS：请求查询服务器的性能，或者查询与资源相关的选项和需求，可用于了解服务器支持的请求方法、头部信息等。

1. 请求头

• • 紧接着请求行，请求头部由键值对组成，每行一对。请求头部通知服务器有关于客户端请求的信息。
  • 典型的请求头：

• • • User - Agent：产生请求的浏览器类型，服务器可以根据这个信息来优化响应内容，例如为不同类型的浏览器提供不同格式的网页。
    • Accept：客户端可识别的内容类型列表，告诉服务器客户端能够接受的响应数据类型，如text/html表示客户端能够接受HTML格式的网页，image/jpeg表示能够接受jpg图片格式等。
    • Content - Type：请求体数据的类型，常见的类型有：

• • • • text/html：HTML格式，用于传输网页内容。
      • text/plain：纯文本格式，用于传输简单的文本数据。
      • image/jpeg：jpg图片格式，用于传输图片数据。
      • application/json：JSON数据格式，常用于前后端数据交互，具有简洁、易读、易于解析等特点。
      • application/x - www - form - urlencoded：form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据格式），常用于传统的网页表单提交。
      • 7/form - data：在表单中进行文件上传时使用，它可以将文件和其他表单数据一起提交。

1. 请求体

• • 不在GET方法中使用，经常在POST、PUT方法中使用。
  • 请求体的数据可以是：表单数据、文本、XML、JSON等。例如在POST请求中，可能会将用户输入的表单数据（如用户名、密码等）作为请求体发送给服务器。与请求数据相关的最常使用的请求头是Content - Type和Content - Length，Content - Type用于指定请求体数据的类型，Content - Length用于表示请求体数据的长度，服务器可以根据这些信息来正确处理请求数据。

（五）HTTP响应

1. 组成部分

• • HTTP响应也由三个部分组成，分别是状态行、响应头、响应体。

1. 状态行

• • 由协议版本号、状态码、状态消息三部分组成。
  • 状态码：

• • • 有三位数字组成，第一个数字定义了响应的类别：

• • • • 1xx：指示信息，表示请求已接收，继续处理，例如100 Continue表示客户端应继续发送请求。
      • 2xx：成功，表示请求已被成功接收、理解、接受，如200 OK表示服务器成功返回用户请求的数据，201 CREATED表示用户新建或修改数据成功。
      • 3xx：重定向，要完成请求必须进行更进一步的操作，例如301 Moved Permanently表示资源已被永久移动到新位置，客户端应使用新的URL访问。
      • 4xx：客户端错误，请求有语法错误或请求无法实现，如400 Bad Request表示客户端请求有语法错误，不能被服务器所理解，404 Not Found表示请求资源不存在。
      • 5xx：服务器端错误，服务器未能实现合法的请求，如500 INTERNAL SERVER ERROR表示服务器发生错误，用户将无法判断发出的请求是否成功，503 Server Unavailable表示服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

1. 响应头

• • 用于描述服务器的基本信息，以及数据的描述，服务器通过这些数据的描述信息，可以通知客户端如何处理响应数据。例如，Content - Type响应头告诉客户端响应体数据的类型，以便客户端正确解析；Cache - Control响应头用于控制缓存策略，指示客户端是否可以缓存响应数据以及缓存的时间等。

1. 响应体

• • 响应的消息体，数据可以是普通文本、XML、JSON、HTML源码等。服务器将处理请求后得到的数据以响应体的形式返回给客户端。例如，当客户端请求一个网页时，服务器将网页的HTML源码作为响应体返回；当客户端请求一个数据接口时，服务器可能将JSON格式的数据作为响应体返回，客户端可以根据需要解析和使用这些数据。

（六）状态码（Status Codes）[科普]

服务器向用户返回的状态码和提示信息，常见的有：

状态码	状态消息	动词	说明
200	OK	[GET]	服务器成功返回用户请求的数据
201	CREATED	[POST/PUT]	用户新建或修改数据成功
202	Accepted	[]	表示一个请求已经进入后台排队（异步任务）
204	NO CONTENT	[DELETE]	用户删除数据成功
400	Bad Request	[POST/PUT]	客户端请求有语法错误，不能被服务器所理解
401	Unauthorized	[]	表示用户没有权限（令牌、用户名、密码错误）
403	Forbidden	[]	表示用户得到授权（与401错误相对），但是访问是被禁止的
404	Not Found	[]	请求资源不存在，eg：输入了错误的URL
406	Not Acceptable	[GET]	用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）
410	Gone	[GET]	用户请求的资源被永久删除，且不会再得到的
500	INTERNAL SERVER ERROR	[*]	服务器发生错误，用户将无法判断发出的请求是否成功
503	Server Unavailable	[*]	服务器当前不能处理客户端的请求，一段时间后可能恢复正常

五、接口规范

RESTful

RESTful 是 “Representational State Transfer”（表述性状态转移）的衍生词，它是一种软件架构风格，用于构建分布式超媒体系统（如 Web 应用程序）。

“Representational State Transfer” 这个术语描述了一种架构原则，在这种架构中，资源（如数据对象、服务等）通过统一的接口（通常是基于 HTTP 协议）进行访问和操作，并且系统的状态变化通过资源的表述（如 JSON、XML 等数据格式）在客户端和服务器之间进行转移。

1. RESTful架构特点

• • 资源的标识与访问：RESTful架构强调通过统一的接口来访问和操作资源。资源通过URL进行标识，每个资源都有一个唯一的URL地址。例如，一个用户资源可以用/users/{userId}的URL来表示，其中{userId}是用户的唯一标识。通过不同的HTTP方法（如GET、POST、PUT、DELETE）对资源进行相应的操作，如GET请求用于获取资源，POST请求用于创建资源，PUT请求用于更新资源，DELETE请求用于删除资源。
  • 无状态性：服务器不保存客户端的状态信息。每个请求都是独立的，包含了服务器处理该请求所需的所有信息。这使得服务器可以更轻松地扩展和处理大量并发请求，同时也提高了系统的可靠性和可维护性。例如，在用户登录后，后续的请求中不会在服务器端保存用户的登录状态，而是通过在请求中携带认证信息（如Token）来进行身份验证。
  • 可缓存性：RESTful架构鼓励对资源进行缓存。客户端可以缓存服务器返回的响应数据，以提高性能和减少网络带宽的使用。服务器可以通过设置合适的缓存控制头（如Cache - Control）来指示客户端如何缓存数据。例如，对于不经常变化的资源，服务器可以设置较长的缓存时间，让客户端在下次请求相同资源时直接使用缓存数据，而不需要再次向服务器发送请求。
  • 分层系统：RESTful架构通常是分层的，客户端和服务器之间可以有中间层（如代理服务器、缓存服务器等）。这有助于提高系统的可扩展性和性能。中间层可以对请求和响应进行处理，如缓存数据、负载均衡、安全验证等。例如，代理服务器可以缓存经常访问的资源，减少服务器的负载；负载均衡器可以将请求分发到多个服务器上，提高系统的并发处理能力。
  • 统一的接口：客户端和服务器之间通过统一的HTTP协议进行通信，使用标准的HTTP方法和状态码。这使得不同的客户端和服务器可以相互理解和交互，提高了系统的互操作性。例如，无论使用哪种编程语言编写的客户端，都可以按照相同的方式向服务器发送请求并处理响应。同时，开发者也可以更容易地理解和维护系统，因为接口的规范是统一的。

六、接口测试流程目标

（一）接口测试流程

1. 需求分析

• • 接口测试的第一步是需求分析，这主要依据详细的需求文档进行。测试人员需要认真研读需求文档，深入理解系统的整体功能以及各个接口在系统中的作用和相互关系。例如，在一个电商系统中，需求文档可能描述了用户注册、登录、商品浏览、购物车操作、订单提交等一系列功能流程，而接口测试人员需要从中梳理出涉及这些功能的接口，明确每个接口的输入和输出要求，以及接口在整个业务流程中的逻辑关系。通过对需求的分析，确定需要测试的接口范围，为后续的测试工作奠定基础。

1. 接口文档解析

• • 通常情况下，接口文档由开发人员编写，也被称为 API 文档。它详细描述了接口的各种信息，是接口测试的重要依据。测试人员要仔细阅读和理解接口文档的内容，包括接口的地址、请求方法（如 GET、POST、PUT、DELETE 等）、请求参数（参数名称、类型、是否必填、取值范围等）、响应格式（数据结构、字段含义、状态码等）。以一个用户信息查询接口为例，接口文档可能会说明其地址为https://api.example.com/user/{userId}，请求方法为 GET，其中{userId}为路径参数，表示要查询的用户 ID，必须为正整数。响应格式为 JSON，包含用户的基本信息如姓名、年龄、性别等字段。测试人员只有准确理解了这些信息，才能正确地设计测试用例和执行测试。

1. 设计测试用例

• • 根据需求分析和接口文档解析的结果，进行测试用例的设计。测试用例应全面覆盖各种情况，包括正常情况和异常情况。正常情况的测试用例用于验证接口在符合预期输入时的正确功能，如输入合法的用户 ID 查询用户信息，应返回正确的用户数据。异常情况的测试用例则用于检查接口对各种错误输入的处理能力，例如输入无效的用户 ID（非整数或负数）、缺失必填参数、参数值超出合法范围等情况，接口应返回相应的错误提示信息。同时，还需要考虑边界值测试，如查询用户信息时，使用最小和最大合法的用户 ID 值进行测试。此外，对于一些涉及多个参数组合的接口，还需要进行参数组合测试，以确保不同参数组合下接口的功能正确性。

1. 执行测试

• • 使用接口测试工具实现：

• • • 有许多专门的接口测试工具可供选择，如 JMeter、Postman 等。以 Postman 为例，测试人员可以在其界面中创建请求，填写接口地址、选择请求方法、设置请求头和请求参数等，然后发送请求并查看响应结果。对于需要进行性能测试或并发测试的场景，JMeter 则是一个强大的工具。它可以模拟多用户并发请求，设置不同的线程数和循环次数，测量接口的响应时间、吞吐量等性能指标，以评估接口在高负载情况下的性能表现。

• • 通过编写代码实现：

• • • 例如使用 Python + Requests 库来编写测试代码。Python 具有丰富的库和强大的灵活性，Requests 库使得发送 HTTP 请求变得非常简单。测试人员可以使用 Python 编写脚本来自动化执行测试用例，实现更复杂的测试逻辑和数据处理。比如，可以编写代码从文件中读取大量的测试数据，然后循环发送请求并对响应进行断言验证。还可以结合其他库，如 unittest 或 pytest 来进行测试框架的搭建，实现测试用例的组织、执行和结果报告。

1. 接口缺陷管理与跟踪

• • 在测试过程中，一旦发现接口存在问题或缺陷，需要及时进行记录和管理。通常会使用缺陷管理工具，如 Jira、Bugzilla 等，将发现的缺陷详细记录下来，包括缺陷的描述（如在什么情况下出现，具体的错误表现是什么）、重现步骤（如何操作可以复现该缺陷）、预期结果和实际结果等信息。然后，将缺陷分配给相应的开发人员进行修复。测试人员需要跟踪缺陷的修复进度，在开发人员修复后，及时进行回归测试，以确保缺陷已经被正确修复，并且没有引入新的问题。通过有效的缺陷管理与跟踪，可以保证接口的质量不断提高，减少系统中的潜在风险。

1. 生成测试报告

• • 测试完成后，需要生成测试报告来总结测试的结果。测试报告应包含测试的基本信息，如测试的接口范围、测试时间、测试环境等；测试用例的执行情况，包括通过的测试用例数量、未通过的测试用例数量及原因分析；接口的缺陷情况，列出发现的所有缺陷及其严重程度和修复状态；以及对接口整体质量的评估和建议。测试报告可以以文档形式（如 Word、PDF）或在测试管理平台上生成，以便相关人员（如项目经理、开发团队、质量保证人员等）能够清晰地了解接口测试的结果，为项目的决策和后续工作提供依据。

1. 接口自动化持续集成（可选）

• • 在一些项目中，会采用接口自动化持续集成的方式来提高测试效率和质量。这涉及将接口自动化测试脚本集成到持续集成工具（如 Jenkins）中，每当代码发生变更时，自动触发接口自动化测试的执行。通过持续集成，可以及时发现代码变更对接口功能的影响，快速反馈问题，减少人工干预，提高软件开发的迭代速度和质量。例如，在一个敏捷开发项目中，开发人员每次提交代码后，Jenkins 会自动拉取最新代码，执行接口自动化测试脚本，并将测试结果发送给相关人员。如果测试失败，开发人员可以及时了解情况并进行修复，确保代码的质量和稳定性。

（二）技术架构（了解）

1. 技术栈

• • 前端：采用以 Node.js 为核心的 Vue.js 前端技术生态架构。Vue.js 是一种流行的前端框架，它具有轻量级、高效、易于上手等特点，能够帮助开发人员构建交互式的用户界面。Node.js 则在服务器端运行，用于处理前端的请求和数据交互，提供了强大的异步 I/O 和事件驱动编程模型，使得前端和后端的通信更加高效。在这种架构下，前端可以通过发送 HTTP 请求与后端接口进行通信，获取数据并展示给用户，同时也可以将用户的操作数据发送回后端进行处理。例如，在一个电商网站的前端页面中，用户点击商品搜索按钮，前端会通过 AJAX 请求将搜索关键词发送到后端接口，后端接口查询数据库后将搜索结果返回给前端，前端再将结果展示在页面上。
  • 后端：

• • • 使用 Spring Boot + Spring Cloud + Spring MVC + Spring Data（Spring 全家桶）作为后端开发框架。Spring Boot 简化了 Spring 应用的初始搭建和开发过程，它提供了自动配置功能，使得开发人员可以快速创建独立的、生产级别的 Spring 应用。Spring Cloud 则用于构建分布式系统，提供了服务注册与发现、配置管理、断路器、路由等功能，方便了微服务架构的开发和管理。Spring MVC 是 Spring 框架中的一个模块，用于处理 Web 请求和响应，实现了模型 - 视图 - 控制器（MVC）模式，使得代码结构更加清晰，易于维护。Spring Data 则为各种数据存储提供了统一的访问接口，简化了数据库操作。
    • 搭配 MySQL + Redis + RabbitMQ 作为数据存储和消息队列组件。MySQL 是一种关系型数据库管理系统，用于存储系统中的结构化数据，如用户信息、商品信息、订单信息等。Redis 是一种内存数据库，它具有快速的读写性能，常用于缓存热点数据、减轻数据库压力，以及实现一些需要高性能读写的功能，如会话管理、排行榜等。RabbitMQ 是一种消息队列中间件，用于实现异步通信和系统解耦。例如，在一个订单处理系统中，当用户下单后，订单信息可以先发送到 RabbitMQ 队列中，然后由后台的消费程序逐步处理，这样可以提高系统的响应速度和吞吐量，同时也避免了因订单处理过程中的复杂业务逻辑导致系统阻塞。

通过这样的技术架构，前端和后端能够协同工作，实现系统的各种功能，并且在接口测试过程中，测试人员需要了解这些技术架构的特点和交互方式，以便更好地设计和执行测试用例，确保接口的质量和系统的稳定性。