接口自动化测试框架实践1：接口测试概述

软件质量保障

专注于测试圈：测试质量保障、自动化工具/框架、平台开发、算法测试、BAT/TMD大厂测试岗面试题/面经分享、测试团队建设与管理、测试新技术的分享。 偶尔也聊聊个人工作的收获与经验。可以帮忙内推字节、阿里、百度等大厂。

1. 专栏目的

 

很久之前就有开一个接口自动化专栏的想法，得益于我在前东家有丰富的服务端测试经验，并且在大团队内部率先推动接口自动化实践，通过实践和同事一起申请了几个关于框架设计、用例自动生成的专利，推动了团队同学向自动化测试转型。详情可以看我的另一篇文章。【干货】如何推动业务测试团队转型自动化测试？

接口测试也是每个测试同学都必须掌握的测试技术，而想更近一层，接口自动化测试也是必途之径。

希望通过这个专栏，能让大家对接口自动化测试有新的认识，每人都能开发出适用于自己团队的接口自动化测试框架。

2. 如何进行接口测试？

 

2.1 接口测试工具介绍

我第一次接触接口测试并非来源于项目需要，而是来源于团队KPI需要。当时校招刚入职没多久，团队内部有测试相关知识与技能培训，测试技能更多的是测试工具的使用，而我接触的第一个测试工具就是JMeter-一款Java开发的 开源接口/性能测试工具。还记得我同事通过一个word文档给我介绍JMeter的一些常用组件，然后就给我安排上了一个任务-将团队xx平台接口代码覆盖率提升至40%以上。当时还不知道代码覆盖率是什么，但是只晓得通过JMeter开发更多单接口/业务场景组合的用例就是了，于是乎就开始通过针对单接口的入参类型、边界、是否必传做各种组合，而场景组合用力 就根据 业务流做接口间的笛卡尔积。

 

2.2 接口用例三要素

一个完整的接口用例，必须包含测试数据、HTTP请求、断言。

1. 测试数据：测试用例都是数据驱动的，接口测试属于黑盒测试范畴，所以输入决定输出。而数据不仅仅要包含正向的，也要包含反向和异常的数据。

2. HTTP请求：包含接口名、域名、请求体、请求头内容

3. 断言：怎么确定你的测试用例是通过的还是不通过的呢，断言就显得至关重要。断言内容就是你要的预期结果。断言包含对接口响应内容做断言、也包含对落DB的数据做断言。

下面我简单介绍一下JMeter常用组件。主要分为三大类：预值类、测试类、后置类。

2.3 JMeter组件介绍

预值类

蓝色圈内属于预置类组件。何为预置，可以理解为测试用例run之前需要准备的工作内容，例如查询sql前需要先进行数据库连接；调用接口前需要准备好接口参数等。

1. JDBC Connection Configuration

数据库连接组件，可以进行数据库配置，配置信息如下。重要内容有连接池。

1. HTTP Header Manager

大家都知道，HTTP请求头比较重要的几个内容，如content-type、cookie、user-agent，针对同一个项目下的API请求头基本上是一致的，可以将所有接口的请求头定义到一个模板中。而这个组件就是这样的作用。

1. HTTP Request Defaults

同样一个系统下所有接口的域名是一致的，所以域名信息也可以定义到模板，供所有接口使用。

1. User Parameters

前文说到测试用例三要素，其中重要的就是数据，而我们在测试过程中，有些数据可以供所有接口使用，抑或是多个接口需使用相同的一个变量值（例如cookie），这样的话，我们就可以将这个变量值参数化，定义到这个组件，供所有接口调用。

 

测试类

1. HTTP Request

组装/发送http请求的组件，包含请求方法、请求体、协议类型、接口路径等

1. JDBC Request

发起sql操作的组件

后置类

1. JSON Extractor

http响应成功后（一般响应体是Json结构），我们需要对其响应内容做断言，则这个组件可以提取出我们需要的信息。

1. Regular Expression Extractor

当然除了第一种方法提取信息，也可以使用正则表达式来提取我们想要的内容。

1. Response Assertion

这个就是断言组件，可以将我们的预期结果放到组件里。

1. Debug Sampler

这个组件是辅助我们开发用例的，在我们调试用例时候，可以通过此组件查看用例执行过程定义的所有变量值。

1. View Results Tree

这个组件的作用和上一个是一样的，但是这个让我们获取的信息更多，例如请求体、响应体内容都可以在结果树中看到。

 

当然，本文重点不是介绍JMeter，只是强烈建议刚接触接口测试的同学学会使用这个工具。更简单的意思就是学会了这个工具的使用就掌握了如何编写接口测试用例。工具让抽象的测试用例通过它提供的各个组件给实例化，让你能看得见。同样，postman也是一款优秀的接口测试工具，但是JMeter更适合自动化，还能根据自己的需求扩展自己想要的JMeter插件，而postman更多用于单接口调试。

​3. 为什么接口测试更适合自动化实现？

 

大家都知道分层测试理论，从金字塔自底向上看，相同投入成本下边际收益是越来越低的，而越是金字塔底部越适合自动实现。在《Google软件测试之道》一书中有介绍到Google 70%的自动化测试工作集中于单元测试，20%集中于接口测试，剩下10%才是UI测试。虽然很多公司没有谷歌的工程师文化，但是我们能晓得标杆公司对于对于单测和接口测试的重视程度。

而界面相比于接口，变动更频繁，用例的开发和维护成本相当高，非常不利于自动化实现，而接口层面，接口契约一般变化不大，更多的是接口输出可能变化比较多，所以我们开发好的自动化用例维护成本相对较低。

 

4. 为什么需要自动化测试框架？

 

即使开源接口测试工具能够拿来即用，但是这些工具往往满足不了更多的测试诉求。

1. 测试工具开发的测试用例往往不易于维护，试想一下当你维护JMeter生成的各种JMX文件场景。

2. 大量的测试用例可重用性差，例如登陆模块，每个接口调用前都要获取cookie，而登陆则是前置模块，使用JMeter开发用例需要每个JMX文件都要包含登陆，重复度太高。

3. 无法满足自动化平台诉求，短期内确实可以快速实现自动化，但是这些工具对于平台非自动化能力的拓展成本较高，毕竟改动开源工具的成本比自研高很多。

4. 使用开源工具不利于提升团队在自动化技术方面的成长。自动化能力的提升离不开编程能力的提升，使用开源工具能提升工具学习使用能力，最终你的成长无外乎又掌握了一个测试工具的使用。

5. 无法最大化提升自己解决问题的能力。

 

往期推荐

如何有效提升软件测试质量？

allpairspy一款高效的正交实验法生成用例工具