接口自动化测试的思考和实现

思考

什么是自动化测试？

自动化测试是把人为驱动转换成计算机驱的测试行为。

人对于接口的测试行为：

第一步：理解业务需求，一般来说可以从需求理解接口的行为和描述，行为：当什么情况，做什么操作，发生什么事情。描述：情况是什么，操作是什么等

第二步：查看（评审）接口文档的入参和返回是不是符合需求描述

第三步：根据业务需求构造前置数据

第四步：根据接口文档的入参请求接口

第五步：查看返回值是不是符合需求行为和描述，对于接口有更新数据库的行为还要检查数据库的变化是否符合需求描述

如何将人的行为最小成本的自动化？

设想了两种方案

第一种：

思路

将整个集成起来的大系统视为被测试对象，将所有接口视为对于这个系统的操作控制器，但是将接口本身视为黑盒。这样我们从处于业务流程最顶部的第一个接口起，传递参数就会生成第一个业务数据或者业务行为，然后用这个产生的初级的业务数据调用相对来说处于业务下游的接口，从而产生更下游的业务数据以及业务行为。依次类推通过此种方式最终覆盖整个系统的所有接口

意义（这样做的意义是什么？）

对于一个集成起来的复杂系统，这样不仅可以比较真实模拟业务的行为，还可以产生相对完整的业务数据

问题和挑战

1：测试场景颗粒度不够。一个自动化case涉及到多个接口的调用，所以一个自动化case其实就是一个业务流程，这样的自动化颗粒度就是一个业务流程，如果case设置过多，就可能造成case膨胀，从而找不到测试重点，后期维护高成本。所以case量就不能设置太多，只能设置一些宏观层面主线业务case，一些支线业务case无法纳入进来。

2：问题定位不准确。自动化测试发现问题不能准确的定位是哪一个接口产生的，由于我们将接口视为黑盒，case中断言的就是一个个接口的返回值，那么就有可能一个接口的行为可能出现了异常，但是这个接口返回值是正确的。例如这个接口少更新了一个数据库字段的数据，少调用了一个第三方接口等。所以会导致这个问题继续向下游业务潜伏行进，直到真的影响自动化测试断言到的业务行为时才能被发现。

3：场景无法闭环。我们目前的系统还没有形成完备的接口体系，由于有些执行业务行为的接口缺失，不能仅仅通过调用一个个接口去完成业务操作。

第二种

思路

由于第一种的挑战，我们把测试对象由整个系统变成一个个单个的接口，这样我们对于这一个接口设置的各种正常和异常的测试用例，业务数据不在由上游模块提供，而是采用一步直达的方式将业务数据精确的注入至接口依赖的数据表，为了能够使自动化case稳定的持续执行，这个数据一步直达的步骤就要纳入到自动化测试用例。同时我们把接口白盒化，在理解业务需求的同时要阅读接口代码，获取到接口对于业务数据的处理细节，这样就能在业务逻辑和开发逻辑两个层面丰富测试场景，以及设置一些更加临界的测试用例。

意义（这样做的意义是什么？）

1：这样做可以和单元测试有效的形成互补关系。单元测试会预设一个个的方法可以组装成一个模块或接口，然后单元测试关注每一个个的单体方法是否正确。而单接口测试借鉴了单元测试的思路，单接口测试预设一个个的接口可以组装成一个系统，然后单接口测试关注一个个的单体接口是否正确。

2：性价比高，由于测试对象从一个业务系统缩小到一个接口，通过注入数据屏蔽了上下游依赖，一个接口可以很低成本的有大量case产出

问题和挑战

1：技术投入大。这样写的显然有一定的复杂度，所以投入较大。由于要做数据一步直达以及接口白盒化测试，需要对系统结构、第三方中间件的进行掌握，所以需要做较高的技术投入和时间投入。

2：收资收益比待衡量。有些业务发展迅速，产品形态尚未稳定，接口的产出数量和变更数量都很大，对于业务产生的价值和自动化测试的投入成本需要衡量。

3：case膨胀之后对于测试用例工程的代码组织结构、自动化测试系统架构等case本身的代码质量层面是一个挑战

实现

在实现之前，我们调研了市面上一些开源的框架、技术和解决方案，目前自动化测试解决方案目前分两个阵营

第一个阵营是无代码型，这种方式希望从一个界面设置URL、参数、请求数据、预期返回的数据就会形成一条case。这种方式的case通常对数据库中存留的业务数据以及当前数据状态有很强的依赖性，所以数据的变更对case的稳定性有很大的影响，而且由于自动化用例编辑器本身的限制，对于测试场景的丰富和接口返回值的验证无法做到全面、有效。如果去实现一个功能强大的、可编程的自动化用例编辑器，成本巨大。

第二个阵营是通过代码实现一个case的自动化执行过程。借鉴UnitTest框架，测试用例分为准备数据过程，请求接口过程，返回值断言过程，清理数据过程。这种方式编写的case由一行行的代码组成，一组对于一个系统的自动化测试case，就是一个代码工程。case数量少的时候，编写效率和执行效率都没有太大问题，当case量增多，量变引起了case编写维护效率和执行效率的质变，如何组织代码架构、增强代码可复用性、设计模式就成了挑战。

根据投入成本、灵活性、编写和执行效率、测试场景的多样性等因素，业界大部分公司选择了通过代码编写自动化case。所以综上述考虑决定选择第二个阵营的自动化方案。我们将要实现的自动化用例实现程度是对于接口测试的全过程自动化测试，包括数据的构造、入参定义、预期返回值定义、接口请求、接口返回值断言、数据清理。

我们预期自动化测试用例拥有这些特性

使用python脚本语言描述接口测试用例。

每个python脚本文件内包含一个测试类，该类被称为测试套件。

每个测试类（测试套件）只测试一个接口。

该测试类（测试套件）中包含针对该接口测试的若干用例。

该测试类中为了便于处理数据和制造前置场景应该包含以下几种方法：

所有用例执行前应该执行的“套件起始方法(suite_setUp)”。

所有用例执行后应该执行的“套件拆卸方法(suite_tearDown)”。

每个用例执行前应该执行的“用例起始方法（case_setUp）”。

每个用例执行后应该执行的“用例拆卸方法（case_tearDown）”。

以test开头测试用例方法“测试用例（test_xxx）”。

执行机制

用例工程结构

针对每个被测工程可以创建一个对应的测试工程，测试工程里按照模块自由的划分目录，目录里每接口对应一个测试suite（一个py文件），每个suite中包含若干针对该接口的case。

通过树形case组织结构，解决了case间的依赖问题，可以单独执行一个case或者一个接口的测试或者一个测试套件集，同时实践发现这样的结果也比较易于case的调试，排错和维护。

编写测试用例

每个测试用例通过一套类似于这样的模板去编写

测试用例一般是在在定义的以test开头的测试方法中编写，针对不同类型的接口采用不同的测试思路

get类型的接口自动化case编写步骤

1：通过直接读写数据库或者调用上游接口制造测试数据/重用数据库现有数据

2：定义一个字典表示要发起请求的数据

3：定义一个字典表示预期返回数据（一般返回数据是json）

4：使用HttpRequest类库发起请求接口

5：使用Should类库中的断言方法比对接口返回的json和定义的字典数据是不是一样

6：通过操作数据库清理测试过程中产生的测试数据

post类型的接口自动化case编写步骤

1：定义一个字典表示要发起请求的数据

2：定义一个字典表示预期返回数据（一般返回数据是json）

3：由于post接口会对数据库又操作仅仅查看接口返回值不足以证明接口行为的正确性所4、以还要定义一个字典表示数据库中的预期数据

5：请求接口使用HttpRequest类库发起请求接口

6：使用Should类库中的断言方法比对接口返回的json和定义的字典数据是不是一样

7：使用DB类库查询到数据库中需要验证的数据，这个数据是数据库中实际数据

8：使用Should类库中的断言方法比对数据库中的实际数据库和数据库中的预期数据是不是一样

9：通过操作数据库清理测试过程中产生的测试数据

接口自动化测试框架整体组成

自动化框架提供了两个端的使用方式，左边绿色的部分是向自动化用例开发者提供的SDK，右边蓝色的部分是case的管理、执行和结果查看的可视化系统。

其中，SDK为开发者提供了数据定义、数据驱动、场景切入、执行策略、工具库、断言等开发规范和功能。

开发完成的case可以被加载到运行容器上执行，执行的结果可以在web可视化系统上展示。

web可视化管理系统提供了执行控制、策略配置、结果展示、问题分析的功能，web管理端通过调用Jenkins接口在Jenkins生成job，通过Jenkins的任务编排机制调用运行容器执行相应的自动化测试用例或者测试套件集。

case结果关注着在查看到case执行结果后，对于执行失败的case进行问题分析，并且将分析结果通过web可视化管理系统标记记录。

以上就是我在实际工作中对接口自动化测试的一些思考和部分技术方案，如有不同见解欢迎大家在下面留言讨论。

欢迎大家关注【自动化测试笔记】公众号一起交流自动化测试技术。