目录

前言

简介

什么是API测试？

API测试的必要性

API测试的类型

优势

API测试的挑战

【自动化测试工程师学习路线】

---

前言

在这篇文章中，我将带你轻松入门接口测试并掌握实用技巧，让你能够与后端开发人员更加顺畅地合作。相信我，当你的接口测试技能变得娴熟，你的后端开发人员将“心甘情愿”地配合你，让项目的开发变得更加高效和顺利。赶快开始吧！

简介

本章介绍应用程序编程接口（API application programming interface）和 API测试。API测试是软件测试活动的一个重要方面（在典型的基于服务的软件开发过程中）。它包括测试应用程序的业务组件，通常表示为API，然后再开发UI。一个微服务处理单一需求的API。

什么是API测试？

API对应用层进行抽象，并提供资源供客户端使用。API是任何典型的Web应用、多层Web应用或移动应用的骨干，它隐藏了系统的内部细节，例如如何为消费者处理在线支付。

API是应用程序的中间层，它与后端打交道，通常通过ORM（对象关系映射Object-Relational Mapping）或其他工具，或直接与数据库和前端打交道。API在后端和前端之间充当代理。API根据用户的要求/请求从后端读取数据，并将响应发送到前端。

没有前端的API提供服务，例如支付网关、天气预报等。

上图显示了典型的基于服务的软件应用结构。它在有数据库，中间层的API，以及从浏览器或移动应用程序发出的请求。

微服务是处理单一需求的API，该服务可以独立运作/部署。微服务是定义典型软件应用程序的业务逻辑的API，实现快速开发和可扩展的软件开发理念。

API测试涉及到业务工作流程。这可能被归类为黑盒测试，但从技术上讲，它更像是一种灰盒测试，测试人员简单地了解一些内部实施的细节，但不深入。他们通过对API内部使用的代码路径或逻辑的技术方面的了解，单独测试API。

API有约定的格式，比如JSON/XM）。它接受给定格式和所需参数的请求，并提供规定格式的正确响应。这种测试直接与应用服务器打交道。它可能涉及测试应用程序的单个组件或组合几个组件。标准测试技术适用于测试API时，如等价类、边界值分析、大请求、无效请求、未授权请求等。

API测试需要特定的工具，如httpie、curl、火狐和Chrome插件restclient、Postman和RestAssured等，它们支持请求方法和用于检索API的协议。常用的协议是HTTP(S)。测试人员用所需的请求方法键入URL，在API测试工具中以与API消费者相同的方式请求参数，然后在应用程序的上下文中验证响应/输出。

测试计划或用例是必要的，就像用户工作流测试一样。测试计划有输入，预期输出，和前提条件等。

上述段落中的概念将在以后的章节中更详细地介绍。

API测试的必要性

API测试使用之前发现功能/性能/安全/（更多类型）错误的最快方法。

在软件开发过程中，早期测试的投资回报率较高。由于API测试具有更大的代码/功能覆盖面，与前端测试相比，测试的效率往往要高很多。在单个API层面上识别错误的速度更快，因为与在前端层面上发现错误相比，复杂性更低，发现错误的可能性更高。

不测试API和在前端层面测试只会使测试更加复杂和乏味，而且通常需要更多的测试时间和资源。只测试前端是容易出错。由于前端的变化频率往往比后端/中间层高得多，失败率也往往更高。因此识别错误是后端/API的错误还是前端的错误是很耗时的。

有效地实施API测试可以帮助减少测试工作，节省时间和成本。

API测试的类型

API对消费者/前端的请求做出响应。响应应该是快速的。API不应允许未经授权的用户访问。当并发用户访问API时，它应该在规定的时间内响应。对API的无效请求应适当处理，并应返回错误信息。API应该遵守当地的法律。如果API是作为一种服务提供的，那么它应该保持与消费者的合同，参数不应改变，等等。

API最容易出现的问题

• 61%的可靠性

• 22.2%的安全性

• 16.7%的性能

以下是API测试的类型：

功能测试

解决API的功能问题，例如按照业务要求返回响应。涉及控制流和数据流等。

发送和返回都符合接口设计；正确地实现了功能，比如能创建或删除用户，数据库和缓存数据处理正确等。

参数：参数的边界值和等价类划分；组合可选参数；参数为空字符串、null等特殊值；参数长度；参数类型；sql注入；包含特殊符号和编码的参数。

重复与时序测试

多次重复测试返回结果正常且一样。由于API是非常松散的耦合，乱序、丢失、重复调用如何应对？竞争和加锁的情况如何处理？时序与生命周期特别重要。

重复添加或删除用户，不会对数据库和缓存等造成不良影响，提示的错误码与文档一致。

性能测试

解决负载下的响应时间。当在同一时间点上对给定的API提出多个请求时，API应该按照服务提供商和消费者之间商定的SLA定义，在允许的时间范围内返回响应。 需要考虑多个API的组合，以及多个微服务共享服务器、DB等情况。

• 预计API将如何被使用？
• 如果它突然变得流行，会发生什么？
• API是否有全球24/7使用的高可用性？
• 是否有可能出现使用高峰的时候（例如比如全民做核算）？
• 响应时间、并发、吞吐量等指标。

局域网内单次调用在50ms内完成、在1000并发的情况下最大相应时间不超过60ms、资源占用正常等。是否有峰值，过量是否会产生不良效果。资源消耗与容量等。重点关注响应时间、吞吐量、并发数、可靠性、 cpu、io、内存、gpu、网络等资源占用。

安全测试

解决了通过获取会话、参数篡改等方式对API进行未授权访问的问题。API不应允许任何匿名/未经授权的用户通过自身获得数据的访问。

• 蠕虫病毒和其他负载攻击。

• 无效的认证。

• SQL注入。

• 加密级别不够。传递和存储的敏感数据和日志需要加密，并且难以破解。

• 未经授权的访问控制。 黑白名单：非授权的主机不能访问接口

• 云问题。如果API位于云端，安全问题可能更严重，因为通常对物理网络安全的有效控制很少。

• 意外的误用。调用方非预期滥用、文档不佳或编程错误等造成，也可能是恶意攻击。

噪声测试

解决请求中的无效或故障数据。API应该相应地、及时地做出响应。如果数据是无效的，API应该用适当的错误代码/消息来回应。

弱网

双向通信能否正常完成。尤其要考虑丢包，延迟、2G等差网络场景。可以使用linux的防火墙及tc命令或facebook的ATC框架模拟。

错误代码和消息测试

解决不正确的输入数据，并以适当的错误代码和消息进行响应。通常错误的产生是由于参数传递不正确（例如，不按顺序）或超出范围。

扩展测试

与基础设施有关，这是DevOps的常规工作，但API在这种情况下也会被测试。这主要是在微服务架构中，特定的API被更频繁地使用。API应该是可扩展的，因为并发访问将更加频繁，而且API应该一直可用。经常在性能测试中验证。

合规性测试

属于API被消费的地方管辖。例如，如果API要求提供个人信息（手机号码、出生城市等），那么这些信息应该由供应商保护，不允许任何试图获取这些信息的行为，并且应该保持审计日志。

许多行业要求软件必须符合各种法规和标准。法规可能来自政府和准政府实体，如FDA或EPA。标准可能来自于国际组织或行业团体。例如，如果软件处理信用卡或借记卡，它必须符合PCI标准。以任何方式处理健康信息的系统必须符合HIPAA标准。API可能受制于服务水平协议（SLA）或其他技术协议。如果不能满足这些协议，可能会给组织带来大量的惩罚或罚款。

CDCT（消费者驱动的合同测试）

意味着服务提供者总是保持相同的请求有效载荷。这对服务提供者的业务至关重要。如果有效载荷被改变，那么消费者请求将开始失败，这将是业务的损失。即稳定性。

变更管理

你的API是否依赖于其他API？当这些改变时，你将如何知道？API的数据模式是至关重要的。即使是对模式的一个小的改变--例如，将一个整数改为实数--也可能导致缺陷和失败。

API通常是由不同的小组开发的。试图确保所有参与者的时间表是一致的，一个小组做了一些改变，然后这些改变就像海啸一样波及所有的开发小组。

失败管理

API在生产中出现故障，你将如何知道？当（以及如果）外部组织停止使用你的API时，你是否能够找出原因和发生的时间？

数据

API的创建、查询、更新和删除等正确。数据库事务、大量数据、数据迁移等。

组合

边界值和API组合场景等。

业务组合：比如扣费需要综合考虑闲时、忙时、节假日、集团用户优惠等各种因素。注意接口的水平和垂直组合。

协议

比如SNMP协议与其他厂商的互通，私有部分的实现。又如私有协议。

可移植性问题

你的API有可能需要在不同的层面上工作。它们可能被直接调用，也可能被其他API调用，而这些API又被其他API调用，再由ESB控制。

文档

文档必须进行正确性测试。由于大量的开发者需要与你的API进行交互，文档必须为所有的开发者提供足够的信息。而文档的质量是至关重要的。文档中的数据顺序、数据类型、格式、甚至大写字母都是至关重要的，必须正确。

易用性

软件开发者是否能真正学习和理解如何成功地使用API？是否容易调用、简洁、语法一致等？

可测试性

使API的人很可能想用他们自己的API层来测试它。这可能需要特殊的环境(沙箱)供他们发挥，。这些测试是否正确，而不干扰生产环境？

甚至可以考虑使用mock伪造返回。

• 其他：更多需要关注的点请参考ISO/IEC 25010:2011

优势

在软件开发的早期阶段发现bug是有好处的。在实施API之前，在后端找到一个bug，可以节省开发API的时间。在中间层/API中发现错误，可以节省前端开发的时间。在产品交付的软件开发模式中，越晚测试，测试工程师在紧迫的期限内找到bug就越复杂，越有挑战性。

在业务层找到bug有利于交付高质量的产品。如果API测试得足够好，对产品开发团队有明显的好处。

以下是做API测试的几个优势。

• 容易实现自动化
• 能更快地找到bug
• 独立于GUI
• 较大的代码路径覆盖率

API测试的挑战

• API测试中的主要挑战是参数组合，参数选择和调用排序
• 没有GUI可用于测试
• 验证和验证不同系统中的输出对于测试人员来说很难
• 测试人员需要了解参数选择和分类
• 异常处理功能需要测试
• 开发技能

作为一个过来人，对学习过程中的困难深有体会。

如果你也在往自动化测试开发方向发展，在适当的年龄，选择适当的岗位，将自己的优势都发挥出来！

我的自动化测试之路，一路走来都离不每个阶段的计划，因为自己喜欢规划和收集总结，所以，我和朋友特意花了一段时间整理编写了下面的《自动化测试工程师学习路线》，也整理了不少【网盘资源】，需要的朋友可以点击文末小卡片获取网盘链接。希望会给你带来帮助和方向。

【自动化测试工程师学习路线】

1、自动化测试必备Python编程内容

2、Web UI 自动化测试基础内容

3、Web UI 自动化测试实战内容

4、APP UI 自动化测试基础内容

5、APP UI 自动化测试实战内容

6、API 接口自动化测试基础内容

7、API 接口自动化测试实战内容

8、CI/CD持续集成专项技术

9、自动化测试框架实战技术

上面就是我为大家整理出来的一自动化测试工程师发展方向知识架构体系图。希望大家能照着这个体系在3-4个月完成这样一个体系的构建。可以说，这个过程会让你痛不欲生，但只要你熬过去了。以后的生活就轻松很多。正所谓万事开头难，只要迈出了第一步，你就已经成功了一半，等到完成之后再回顾这一段路程的时候，你肯定会感慨良多。如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们的裙：194117263大家一起讨论交流学习。

我们身处知识爆炸，竞争激烈的时代，学习是对自己最好的投资，所以加油吧，测试人们！