如何简单设计接口测试用例,接口测试用例怎么编写

本文讲述了如何简单设计接口测试用例,接口测试用例怎么编写。

阿里妹导读：在所有的开发测试中，接口测试是必不可少的一项。有效且覆盖完整的接口测试，不仅能保障新功能的开发质量，还能让开发在修改功能逻辑的时候有回归的能力，同时也是能优雅地进行重构的前提。编写接口测试要遵守哪些原则？测试代码的结构应该是什么样的？接口测试有哪些实践技巧？本文分享作者在接口测试上的实践总结。

一线开发同学，可能都或多或少地造成过线上bug甚至故障；也会遇到这样的场景，某同学在开发某功能的时候重构了代码，造成了线上bug或者故障；在开发某个功能时，发现需要修改公共逻辑，害怕影响到其他功能，非常不雅观地拷贝代码，重新写套单独逻辑来支持。

上面这些情况，都包含了一个关键的问题，无论是功能开发还是逻辑重构，如何来保障代码开发的质量。保障的手段，每个人都知道，就是测试。首先是新功能测试，保障新功能逻辑正确；其次是回归测试，保障原有业务功能逻辑正确。测试的方式，一般是两种，人工测试和自动化测试。随着测试技术和工具的持续发展，人工测试比例逐步降低，被自动化测试逐步替代。自动化测试是可持续和可重复的，甚至是可AI化的。

一 测试分层

测试也是分层的，如下图所示：

在一个系统内，自动化测试一般分单元测试、模块测试和接口测试。

单元测试

目前我的应用代码基本都是基于spring框架面向接口这种编程模式，单元测试已被弱化。单元测试的要求基本上是单个类单个方法的测试，在我们当前模式下，编写成本太高。当然，如果是一个工具或者一段比较内聚而又复杂的逻辑(例如算法逻辑)，还是应该使用单元测试来保障逻辑的正确性。

模块测试

在系统比较大、模块比较多的情况下，可以建立模块测试层，保障各模块功能的正确性。不过当前的系统发展趋势是微服务架构，因此模块测试层并非十分必要，可以通过接口测试层来覆盖。

接口测试

个人觉得准确来说应该叫入口测试，这一层，是从系统入口出发进行集成测试。应用入口通常是HSF（一个分布式RPC服务框架）服务，消息，定时任务。

作为开发，测试手段千万条，接口测试不可少。在我们应用的接口测试有效且覆盖完整的情况下，不仅能保障我们新功能的开发质量，还能让我们在修改功能逻辑的时候有回归的能力，同时这也是我们做代码重构的前提。同时，易测性也是代码结构合理的一个指标，如果发现一段代码编写测试脚本困难或者无法测试，那就说明当前代码结构不合理需要重构。接下来，我将主要谈一谈接口测试的有效性。

二 测试原则

基础原则：

自动化：接口测试是非交互式的自动化执行，不需要人参与。

独立性：接口测试之间不应该相互依赖。

可重复：接口测试可重复执行，不受环境影响。

接口测试遵守BCDE原则，保障接口交付质量。

Border：边界测试。Correct：正确的输入，正确的预期输出。Design：按照需求和设计文档编写测试逻辑。Error：错误输入，预期输出。

数据准备：数据准备通过系统服务进行，不能通过直接插入db方式。

可测性：对于不可测的代码需要进行重构成合理的结构。

覆盖性：接口测试需要覆盖所有UC，同时代码覆盖率和分支覆盖率应达到一定标准，新增代码必须被覆盖。

持续性：如果代码修改导致已有接口测试执行失败，必须修复代码问题或者测试代码逻辑。

时间要求：接口测试应该在项目发布之前完成，不应放到项目发布之后补充。

以上的基本原则应适用于所有层的自动化测试用例，在编写接口测试时，除了上面这些原则，还有其他原则需要遵守，先看一张图：

从系统角度来分析入口调用，以HSF服务为例：

外围系统调用由我们系统提供的服务。

系统执行了一堆代码逻辑，其中包含有分支逻辑。

系统执行过程中依赖外部HSF服务，进行了调用，并得到了返回值。

系统执行过程中依赖DB查询或者落地了数据，依赖缓存查询或者落地了数据。

系统执行过程中对外发送了消息。

给上游系统返回HSF执行结果。

有效接口测试的关键原则是要覆盖所有入口，mock所有依赖，校验执行过程中所留下的痕迹，总结如下：

入口覆盖：接口测试用例必须覆盖HSF服务入口、消息入口、定时任务入口。

依赖mock：在基本原则中，有可重复这个原则，即接口测试不能受环境依赖，需要mock掉对外依赖。但对于db依赖，不建议完全mock掉，一方面mock成本高，另外可能覆盖不到sql和表约束逻辑。

校验完整：有效的接口测试，应该具备完整的校验，没有校验的接口测试是没有意义的。只要执行过程中，留下的痕迹对业务有影响，都要进行完整校验，方能保障接口测试的有效性。

HSF接口返回值校验：按照场景和接口约定进行HSF返回参数校验。

DB校验：校验落地数据的正确性。

缓存校验：校验存入缓存中数据的正确性。

HSF依赖入参校验：通过mock工具获得依赖HSF调用的入参，进行入参校验。

消息校验：通过mock工具获得发送的消息对象，进行消息体校验。

三 测试代码结构

在编写测试代码的时候，也应跟写业务代码一样，考虑代码的可读、可扩展、可复用性。同时也可以根据系统的业务特性，在测试框架的基础上封装适合当前系统的测试组件，提高测试代码编写效率，规范测试代码结构。

一个接口的测试代码，大概的结构如下：

1 测试准备

依赖数据准备

很多时候，我们的测试有数据依赖，可能是配置数据，也有可能是业务数据(例如退款需要依赖支付数据)。

配置数据：可以通过定义配置文件来初始化配置。

业务数据：这类数据，禁止通过直接插入数据方式产生，而是应通过调用业务服务产生。

依赖mock

对于外部依赖，需要对被依赖的服务进行mock，避免真实调用。

接口测试入参准备

准备接口方面的入参。

2 测试执行

调用接口方法，执行业务逻辑。

3 测试校验

返回参数校验：校验接口的返回参数。

DB：校验DB落地数据。

缓存数据校验：校验落地到缓存中的数据。

消息校验：校验对外发送的消息对象。

对外HSF调用校验：校验对外HSF调用的入参。

四 实践技巧

1 执行效率

对于接口测试，执行效率是不得不关注的一个点，若一个接口测试执行3分钟以上才能看到结果，会大大降低开发同学编写接口测试的热情。对于测试执行效率提高，建议的方案为：

最小化启动测试上下文，例如spring boot的应用，启动spring就可以了使用内存数据库，例如h2将中间件依赖mock掉

2 测试框架选择

对于测试框架，建议选择基于testng，能够提供通过配置文件做数据准备的测试框架。如果找不到合适的，可以自己基于testng进行封装。

3 接口测试覆盖度

场景的完整性影响着测试用例的覆盖度，一方面需要开发同学基于业务场景的输入和测试经验枚举出正常和异常情况，另一方面接口方法也有一些固定需要测试的点，例如幂等测试，边界值测试，参数不正确测试等等。

同时也要通过覆盖率工具查看接口未覆盖的代码或分支逻辑，进行针对性的场景覆盖测试。根据我的经验，分支完整覆盖非常重要，特别是异常的分支。

五 总结

要保障系统线上运行稳定，质量保障手段必不可少。虽然现在有很多自动化的保障手段，但接口测试依然是最基本的和最重要的保障手段之一。如能做到持续保障接口测试覆盖度和有效性，很大程度上会降低线上bug的产生，开发同学也会更有积极性去重构代码。

　　接口测试是项目测试的一部分 ，它测试的主要对象是接口 ，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。

　　如何设计接口测试用例？首先，明确出发点，和所有的测试一样 ，接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向 ，你的设计行为就会尽量朝这个方向，更易发现问题

　　其次，选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口 ，每个接口如果分别测试 ，那将是很痛苦的一件事情，而且任何一个内部接口的变动 ，都将导致我们用例的不可用。

　　可将这些最外层的接口分为两类：一类是数据进入系统的接口；一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用 ，模拟外部的使用；而流出的接口则是我们用例真正该验证的点。数据从哪里流出，流出时的状态如何 ，此时系统又是什么状态都是我们所应该验证的。

　　然后，确认完整的测试对象的功能：确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。

　　最后当出发点、对象、功能都确定了，就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。

　　接口测试用例设计和测试用例设计一样，用例设计的内容应该包括：主要测试功能点、测试环境、测试数据、执行操作以及预期结果。

　　1）接口测试环境分为两种：一种是程序内部的环境；一种是程序的所调用外部接口的环境。

　　2）接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据上需要花费更多的心思。要通过好的测试数据使用例查找问题。接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列 ，不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据 ，使用例更容易发现问题。

　　3）测试功能点，如果一个接口功能复杂时推荐对接口用例进行结构划分 ，这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。

　　4）接口测试用例执行操作非常简单，就是所测接口的调用。

　　5）预期结果验证，这也是接口用例设计的很关键的一步 ，应该细而不冗余。每个用例均需验证 ，避免一个用例中重复做相同的验证 ，提高测试用例的效率。

　　如何设计接口测试用例小例子：

　　简单划分可以按照2个基本组成要素进行划分：1. 参数 2. 业务

　　以下为最简单的一种划分用例的方法，可能涵盖不全，但只为说明一种划分接口用例的方法方式以及需要考虑的测试用例的测试点

　　为何要如此设计，是为了更好的将用例分类为程序规定型以及业务限制型，尽量的保证覆盖，尽量细化到点的划分形式来保证工作时间的预估和计划。

　　所有的自动化接口的测试用例  都基本围绕三部曲进行，传数据，执行，校验返回的数据和期望数据是否一致来构成每个简单的测试用例。

　　有清晰的线路和清晰的思维，才能做好整体测试的掌控。

上述是小编为大家整理的如何简单设计接口测试用例,接口测试用例怎么编写。