博客应用程序接口是软件应用程序中最关键的一层。它是连接客户机到服务器（或一个微服务到另一个）、驱动业务流程并为用户提供价值的服务的通道面向客户的公共API向最终用户公开，它本身就是一个产品。如果它崩溃，它将面临风险，不仅仅是单个应用程序，而是围绕它构建的整个业务流程链mikecohn著名的测试金字塔将API测试放在服务级别（集成），这意味着大约20%或更多的测试应该集中在API上（确切的百分比不那么重要，并且根据我们的需求而变化）。一旦我们有了覆盖单个功能的单元测试的坚实基础，API测试提供了更高的可靠性，覆盖了与用户更接近的接口，而没有UI测试的脆性。API测试速度快，投资回报率高，并且简化了对应用程序的业务逻辑、安全性、遵从性和其他方面的验证。在API是公共API的情况下，为最终用户提供了对我们的应用程序或服务的编程访问，API测试实际上变成了端到端测试，并且应该覆盖完整的用户故事图片来源：马丁·福勒所以API测试的重要性是显而易见的。有几种方法和资源可以帮助您测试API—手动测试、自动测试、测试环境、工具、库和框架。然而，不管您将使用什么—Postman、supertest、pytest、JMeter、mocha、Jasmine、RestAssured或任何其他行业工具—在提出任何测试方法之前，您都需要确定要测试什么API测试策略测试策略是对测试需求的高级描述，从中可以派生出详细的测试计划，指定各个测试场景和测试用例。我们首先关注的是功能测试——确保API正常工作。API功能测试的主要目标是：以确保实现按预期正确工作-没有错误！以确保实现按照需求规范（后来成为我们的API文档）的规定工作。以防止代码合并和发布之间的回归。API作为合同-首先，检查规范！API本质上是客户机和服务器之间或两个应用程序之间的契约。在开始任何实现测试之前，务必确保契约是正确的。这可以首先通过检查规范（或服务契约本身，例如Swagger接口或OpenAPI引用）来完成，并确保端点的名称正确，资源及其类型正确地反映对象模型，没有丢失的功能或重复的功能，以及它们之间的关系资源正确地反映在API中上面的指导原则适用于任何API，但是为了简单起见，在本文中，我们假设了使用最广泛的Web API体系结构—RESToverHTTP。如果您的API被设计成一个真正的restfulapi，那么检查REST契约是否有效是很重要的，包括所有httprest语义、约定和原则（这里、这里和这里）如果这是一个面向客户的公共API，那么这可能是您确保满足所有合同要求的最后机会，因为一旦API发布并使用，您所做的任何更改都可能会破坏客户的代码（当然，您可以在某一天发布新版本的API（例如/API/v2/），但即使这样，向后兼容性仍然是一个要求）。那么，我们应该测试API的哪些方面呢？既然我们已经验证了API合同，我们就可以考虑测试什么了。无论您考虑的是自动化测试还是手动测试，我们的功能测试用例都有相同的测试操作，是更广泛的测试场景类别的一部分，并且属于三种类型的测试流。API测试操作每个测试都由测试操作组成。这些是测试在每个API测试流中需要采取的单独操作。对于每个API请求，测试需要执行以下操作：1验证正确的HTTP状态代码。例如，大数据实战，创建资源应返回201个已创建请求，大数据的发展前景，未经许可的请求应返回403 FORBIDDEN，依此类推。2验证响应有效载荷。检查有效的JSON主体和正确的字段名、类型和值-包括错误响应。三。验证响应标头。HTTP服务器头对安全性和性能都有影响。4验证正确的应用程序状态。这是可选的，主要适用于手动测试，或者当用户界面或其他界面可以轻松检查时5验证基本性能正常。如果某个操作成功完成，但花费了不合理的时间，则测试失败。测试场景类别我们的测试用例分为以下一般测试场景组：基本阳性测试（快乐路径）带可选参数的扩展阳性测试有效输入的阴性测试输入无效的否定测试破坏性试验安全性、授权和权限测试（不在本文讨论范围内）Happy path测试检查API的基本功能和验收标准。我们随后扩展了阳性测试，大数据怎么查询，包括可选参数和额外功能。下一组测试是否定测试，我们期望应用程序优雅地处理问题场景，怎么选购云服务器，其中既有有效的用户输入（例如，尝试添加现有用户名）也有无效的用户输入（尝试添加一个空用户名）。破坏性测试是一种更深层次的负面测试形式，我们故意尝试破坏API来检查其健壮性（例如，发送一个巨大的有效负载体，试图使系统溢出）测试流程让我们区分三种测试流，它们构成了我们的测试计划：1单独测试请求-执行单个API请求并相应地检查响应。这些基本测试是我们应该开始的最小的构建块，如果这些测试失败了，没有理由继续测试。2具有多个请求的多步骤工作流–测试一系列请求，这些请求是常见的用户操作，因为有些请求可以依赖于其他请求。例如，我们执行一个POST请求，该请求创建一个资源并在其响应中返回一个自动生成的标识符。然后我们使用这个标识符来检查这个资源是否存在于GET请求接收的元素列表中。然后我们使用一个补丁端点来更新新数据，并再次调用GET请求来验证新数据。最后，我们删除该资源并再次使用GET来验证它不再存在。三。组合API和web UI测试–这主要与手动测试相关，我们希望确保UI和API之间的数据完整性和一致性。我们通过API执行请求，并通过web应用程序UI验证操作，反之亦然。这些完整性测试流的目的是确保尽管资源通过不同的机制受到影响，但系统仍然保持预期的完整性和一致的流一个API示例和一个测试矩阵我们现在可以将所有内容表示为一个矩阵，可以用来编写详细的测试计划（用于测试自动化或手动测试）假设API的一个子集是/users端点，它包括以下API调用：API调用ActionGet/usersList all users GET/users？name={username}按用户名获取用户Get/users/{id}按IDGET获取用户/users/{id}/configurations设置用户的所有配置POST/users/{id}/configurations为userDELETE/users/{id}/configurations/{id}删除userPATCH/users/{id}/configuration/{id}更新用户配置的所有配置其中{id}是一个UUID，所有GET端点都允许可选的查询参数filter、sort、skip和limit用于筛选、排序和分页#测试方案类别测试操作类别测试操作描述1基本肯定测试（快乐路径）使用有效的必需参数执行API调用验证状态代码：1。所有请求都应返回2XX HTTP状态代码2。返回的状态代码符合规范：GET请求为-200 OK，创建新资源的POST或PUT请求为201，DELETE操作为200、202或204，依此类推t平均负荷：1。响应是格式良好的JSON object2。响应结构符合数据模型（模式验证：字段名称和字段类型如预期，包括嵌套对象；字段值如预期；不可为null的字段不为null等）验证状态：1。对于GET请求，请验证系统（幂等性）2中没有状态更改。对于POST、DELETE、PATCH、PUT操作–确保操作在系统中正确执行：–执行适当的GET请求并检查响应–刷新web应用程序中的UI并验证新状态（仅适用于手动测试）验证标题：验证HTTP头如预期，包括content type、connection、cache control、expires、access control allow origin、keep alive、HSTS和其他标准头字段–根据规格验证该信息不会通过报头泄露（例如，不向用户发送X-Powered-By报头）。性能理智：反应是及时接收（在合理预期范围内时间）-如测试计划中所定义。2正参数+可选参数使用有效的必需参数和有效的可选参数执行API调用运行与#1中相同的测试，这次包括端点的可选参数（例如，筛选器、排序、限制、跳过，等等）验证状态代码：如#1Validate有效载荷：验证响应结构和内容如#1所示。此外，免费自助建站软件，请检查以下参数：–filter:确保根据指定的值筛选响应。-sort:指定要排序的字段，测试升序和降序选项。确保根据所选字段和排序方向对响应进行排序。-跳过：确保跳过从数据集开头开始指定的结果数–限制：