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

最新推荐文章于 2024-09-12 20:02:06 发布

隐居人家的炊烟

最新推荐文章于 2024-09-12 20:02:06 发布

阅读量550

点赞数 2

文章标签：软件测试接口测试自动化测试测试工程师性能测试

本文链接：https://blog.csdn.net/m0_53918927/article/details/113559533

版权

一、思考

什么是自动化测试？

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

人对于接口的测试行为：

第一步：理解业务需求，一般来说可以从需求理解接口的行为和描述，行为：当什么情况，做什么操作，发生什么事情。描述：情况是什么，操作是什么等。
第二步：查看（评审）接口文档的入参和返回是不是符合需求描述。
第三步：根据业务需求构造前置数据。
第四步：根据接口文档的入参请求接口。
第五步：查看返回值是不是符合需求行为和描述，对于接口有更新数据库的行为还要检查数据库的变化是否符合需求描述。

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

设想了两种方案

第一种思路：

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

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

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

问题和挑战

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）”。