如何做接口自动化测试？接口自动化测试基本流程和思路

与UI相比，接口一旦研发完成，通常变更或重构的频率和幅度相对较小。因此做接口自动化的性价比更高，通常运用于迭代版本上线前的回归测试中。

手工做接口测试，测试数据和参数都可以由测试人员手动填写和更新。

因此我们在考虑将接口用例实现自动化的时候，主要思路就是在单个接口请求的测试用例已经完成的前提下，我们如何解决以下问题：

❝业务测试场景会调用不止一个接口，下一个接口的请求依赖于上一个接口的数据，需要解决接口依赖问题token等鉴权数据有过期时间，多个接口用到该参数，需要解决一次修改，多处生效的问题一个接口要用到多个测试数据做覆盖批量测试下，需要知道某个接口返回的参数/数据是否符合预期❞

本文使用的自动化接口测试工具为Apifox,官网下载地址：http://www.apifox.cn 直接下载注册安装后即可使用。接下来依次讲解下上述问题如何使用apifox解决。

一.接口传参

举一个常见的场景说明。查询接口请求获取数据的时候，需要带一个access_token的参数，而access_token参数需要另外的鉴权接口获取。因此需要鉴权接口将获取到的token参数传递给查询接口，查询接口才能发起请求。

另一个常见的场景是，用户需要先登陆，才能将选中的商品加入购物车。这个接口顺利发起请求依赖于上一个接口获取数据。手动测试的情况下，直接人工复制即可。

解决方案：需要将上一个接口返回的数据进行识别提取出目标参数，保存为全局变量，下一个接口直接调用参数。

步骤：1）在apifox的接口tab-后置操作tab，选择提取变量

2）填写变量名称，变量类型和提取的表达式。提取表达式符合json path 语法。在本接口数据中由于返回数据只有一层，因此采用$.目标参数的方式提取。如果有多层参数，可以点击提取表达式旁边的问号，查看详细的json path语法。

获取到的参数以变量的形式存储，点击接口tab右上角的设置图标，可以查看到获取到的环境变量的值。

接着就可以在下一个接口，以参数的方式调用：

二. 外部数据源

一些post数据给后台处理的接口，需要对上传不同的数据来测试接口的返回和异常兼容，一个接口参数需要多次使用不同的数据。手动情况下我们可以直接在参数里填数据，之后每次手动改。

但如果实现自动化的话，像上述的测试方式难以实现。常用的解决方案是先编辑好csv文件，将测试数据一一写好保存，最后传入到接口请求参数中。Apifox在这个问题上提供的解决方案为：a.对于少量的测试数据，可在界面内填好测试数据集供接口每次调用；如果是大量的数据，才使用csv文件；更少量的数据则可以直接写在全局变量中。

以全局变量的方式导入和上节讲到的接口传参类似，区别只在于测试数据不是从上一个接口获取到而是的我们自己填进去的。若是使用外部测试数据集，在测试管理tab>用例界面右侧，有一个测试数据的开关项，打开即可导入测试数据。当然首先需要先把用例导入到测试步骤中来。

如图所示，我已经将OCRtest（文本识别接口，功能为识别图片上的文字）接口导入用例步骤中，启用了外部测试数据，

接着点击管理测试数据，跳转到测试数据tab：

在这个界面开始 新建/导入测试数据。此处数据集名称是给测试人员识别的，不会传入到接口里，一个数据集（1行）代表该次运行中所有需要传入的测试数据，列名作为接口参数，接口每次发起请求，会依次调用该列下的其中一个值。

运行时，每一条测试数据都会当成一条测试用例来运行。

在上面讲到的“接口参数传递”和“传入测试数据”两个的思路是一样的，依赖于apifox提供的参数化功能，上传的数据参数以外部数据集的形式与接口分隔开来，将关键字段，不断变化的数据抽取出来独立于单个接口；

配置完成之后，接口每次运行都能够自行生成，传递和导入关键数据，如果需要修改，只需要在一个地方，一个文件内批量修改就能够全局生效。这其中有软件工程中的抽象和封装思想，而接下来会讲到的断言是另一种思路。

三. 测试断言

手工运行测试人员可以自行看接口请求是否成功，数据是否正常，但在自动化实践中，我们则需要代码帮我们判断实际返回和期望返回是否匹配。

http响应文本是高度结构化的，因此我们的期望返回无非是header和body中的响应状态码，关键字段，和关键值应该为某个值。只需要判断这些字段是否我们想要的即可。

断言是专门用来验证输出与期望是否匹配的工具，在测试实践中，我们一般通过比较实际输出值和输入值来校验的，即我们要判断返回数据“是否存在”“是否包含”“数据是否等于”“文本是否等于”。

因此判断用例请求结果的实现方案可分为三个要素：判断对象，校验方法，校验值与期待值。

思路明确了，接下来看如何用脚本/功能实现。Apifox的断言功能面板（路径：接口tab>运行>后置操作>断言）的可断言对象包括了响应数据中的JSON，html和xml，header，cookie，基本上可以满足我们的要求。

校验的方法为断言对象的值是否符合测试人员规定的值范围

被校验的值可通过json path 表达式提取

那么像对状态码的判断，某个确定返回值的校验这个，可以直接使用apifox提供的功能面板进行操作就行了。如果测试人员想要更加灵活的断言方式需要在后置操作里选择自定义脚本。

对于不太熟悉脚本的测试人员，可以使用Apifox右侧提供的代码模板，点击就会添加到左侧的脚本编辑面板里，基本上只需要修改断言的期望值就行了，难度不大。

如果是对单个接口做测试，断言结果会直接在响应tab返回

如果是批量测试，在测试结果里会显示断言结果：

这样我们构建接口自动化用例中的“结果判断”的问题就解决了。

四. 环境切换

接口在测试服测试通过之后还需要一轮线上验证，测试任务才算完成。

通常测试服和正式服的的区别只在于前置URL不同。为了让线上验证环节不耗费太多重复活动，我们这里可以在自动化项目开始构建的时候就先利用apifox提供的功能进行配置。将项目里所有接口共用的http协议和域名配置到前置URL中，接口地址只填资源路径和参数。

进行线上验证时，将参数配置和数据配置同步更新/切换为线上数据配置之后，只需要在运行环境里切换环境，就可以进行线上验证。

五. 批量测试

1.用例组织形式 apifox里，用例是以测试用例--用例组--测试套件的形式组织的。一个测试用例可容纳多个测试步骤，一个接口请求为一个步骤。接口用例可直接从接口用例导入。如果设置和接口同步，那么接口一旦变更，测试用例这边也会同步变更。

一个常规用例步骤如下，涉及多个接口，接口之间存在参数传递，多个接口完成一个业务场景的测试。

接口用例导入完毕之后，进行测试参数配置，点击运行即可自动运行。

2.用例执行顺序

在一条测试用例里，接口请求的顺序由上到下依次执行，如果需要变更接口请求的步骤，只需要拖动接口移动到新的位置上去即可。

3.测试套件运行 一个接口用例完成一个业务场景/一个业务流程的测试，一个测试套件包含多条用例，可将相同模块的用例集中到一起执行。这种用例组织模式和测试人员常用的用例管理软件testlink的组织方式实质是一样的。这样只要点击运行，就可以一键完成一个业务模块的接口测试。

测试完毕后会显示用例测试结果，上方面板为整体执行情况，下方分条列出具体用例执行结果。如果需要导出测试报告，点击按钮可一键生成html格式的文件。

总结

一.接口自动化的工具思维和测试思维
我们这个接口自动化项目的搭建和执行基本都是围绕Apifox提供的功能进行的。和postman相比，用起来的感觉是特别顺手，用例的组织和测试的思维模式基本上也是几个大中厂都在用的，也符合国内测试组的工作流程，程，是工具来适应人，而不是人去适应工具，在理解门槛和思维切换这点上成本大大降低。

项目一路构建下来，基本都是功能界面的操作，几乎没有需要脚本的地方，对于不熟悉脚本的测试人员来说，可以用它来短时间快速完成测试任务。

如果大家不怎么熟悉那些英文测试术语，用起这个本土接口测试软件，理解成本少点，可能效率会更加高一点。

二.贯穿整个接口自动化项目的三个基本思路：
a.单个接口的测试数据和变量参数化，接口测试结果进行断言
b.单个接口用例以业务测试场景为框架搭建，接口依赖通过参数传递&接口执行顺序解决
c.用例组织以业务模块和业务流程、逻辑为框架组织成测试组和测试套件，方面后期迭代和更新维护

本文用APifox做接口自动化测试的具体流程和思路就介绍到这里，希望对大家有帮助。

接口自动化大致步骤：

1、发送请求

2、解析结果

3、验证结果

定义三个和业务相关的类

1、一个用来封装HTTPclient，用来发送请求

2、解析结果xml的类

3、一个用于比较测试结果和期望值的类，用于验证

4、自动生成报告的类：自动发送报告之类的

（locust的python工具）

服务级：Web server（服务） Database（持久化工具-数据库）、Cache（短时间持久化工具-缓存）

接口测试：

1、构造数据

（1）通过接口构造

比如获取一个blog的文章信息，怎么构造数据呢？（文章哪里来？？）—返回blog信息

通过添加文章的接口，临时构造数据（blog文章），然后断言的时候看看是不是自己造的数据——会造成接口耦合（两个程序模块有关联就叫做耦合。）—和造文章的接口耦合（如果创建文章的接口挂了，那返回blog信息的接口也就挂了）

公交卡充值依赖支付宝的支付接口服务，调用支付接口会有代价，所以模拟一个支付接口，所有通过mockserver（测试桩）去模拟支付接口的服务----不管输入是什么，返回一直成功或是固定的

如何进行mock？？
mockserver介绍：https://www.cnblogs.com/fnng/p/7511539.html
使用：https://blog.csdn.net/qq_35049819/article/details/77839495 （未验证）

（2）通过持久化层构造（更好）

意思就是在数据库直接插入数据

2、调用接口

postman/jmeter–win

CURL-linux

Paw–mac

3、对接口返回进行断言

通过不同的输入-判断不同的预期----数据驱动（输入数据）
断言参考方法：对比数据库值，code验证

4、接口测试的用例设计

功能测试用例
业务逻辑设计
业务逻辑方面的测试用例主要是针对服务端接口的处理逻辑进行的用例设计，这种用例设计不是针对某个功能点是否实现，而是对接口的处理逻辑以及一些相互依赖的业务进行验证，通常依照接口的逻辑流程图来进行。举一个例子，购物系统中的两个动作：登录和下单操作，这两个业务是相互依赖的，下单操作必须在登录完成后（登录状态下），否则无法完成下单，这个时候我们就可以设计这样一条case：没有登录的状态下进行下单操作，看服务端如何处理。

可以看到这一块有两个判断，我们需要对不同的判断分支都设计用例，以保证流程图中涉及到的分支我们都有测试用例覆盖。图中涉及到的不同的分支有：
1.abdf；
2.acg;
3.abdeg;
相应的，我们的用例就应该是：
1.userInfo != null && value(userGroup) != 0;
2.userInfo == null;
3.userInfo != null && value(userGroup) == 0;
业务逻辑的用例设计主要是以服务端接口内部的逻辑流程图为基础，针对流程图中的判断和分支进行用例设计，保证服务端接口的每一种逻辑下都有测试用例覆盖。

异常处理情况
服务端接口和客户端之间通常是通过HTTP请求来传递数据，在发送请求的时候，客户端会携带各种不同的参数，此时服务端会根据不同的参数进行不同的处理，所以异常处理主要是针对请求中的参数情况：比如参数增加和缺省、参数的数据类型错误，参数携带错误的值、参数为空等等，这需要我们根据接口文档中各种不同的参数去构造不同的参数异常，检查服务端的响应情况。

性能和安全性方面
服务器的性能往往是个非常重要的关注点，在实际的测试中我们主要关注的是接口的QPS数值，以及CPU和内存占用等性能指标，通常借助于其他工具比如LoadRunner进行性能测试。安全性方面，主要考虑一些常见的安全策略比如请求加密、sql注入等等。

二、接口测试实例

1、postman测试

2、python测试

 # coding:utf-8
  import requests,unittest
  class V2ETestCase(unittest.TestCase):
     def test_ger_node_api(self):
          python_node_id = 90
          url = "https://www.v2ex.com/api/nodes/show.json"
          node_name = 'python'
         querystring = {"name":node_name}
         res = requests.request("GET", url, params=querystring).json()
        print res
        self.assertEqual(res['id'],python_node_id)
         self.assertEqual(res['name'], node_name)123456789101112