从全局视角来看接口测试

开门见山，什么是接口？通常情况下分为如下两种:

程序内部的接口：方法与方法、模块与模块之间的交互，程序内部抛出的接口；如登录发帖场景，发帖前必须要执行登录动作，因此发帖和登录这两个模块之间存在交互，交互会抛出一个接口，供内部系统进行调用。

程序内部封装的一些方法，模块供程序内部调用。如Java 封装 jar包 ，C++ 封装dll 文件 等。需要通过白盒测试方法进行测试。主要还是通过对模块及方法的调用，输入正向的，异常的测试数据，检验其功能的完整性。

图1.内部接口示例

图中框1中java写一个示例add(int a,int b)方法做加法运算，这个方法供程序内部使用；框2使用Junit对方法进行测试，addtest用例判断1+2=3是否正确，addtest1判断1+2=4是否正确；框3中时执行的结果，addtest1用例测试失败。可见符合我们的预期的测试测试结果。（PS不要关心用例的合理，这里只是示例让大家能够了解）。框4是展示C#封装的一个dll，左边是类右边是里面的对应的方法，这些方法供程序内部使用进行调用。

系统对外的接口:从别的服务上获取资源或信息，对方不会提供数据库共享，只能提供一个写好的方法来获取数据，如购物网站和第三方支付之间，购物网站支付时可选择第三方支付方法，但第三方不会提供自己的数据库给购物网站，只会提供一个接口，供购物网站进行调用。

对于前端而言，无论是App以及浏览器；给用户展现数据从何而来？通过调用我们的API获取数据，前端进行渲染呈现给用户。这部分可以供外部用户调用的接口就是我们外部接口。下图左边为后端代码提供的接口服务，右端是我们前端HTML页面展示，通过抓包我们可以发现，页面的数据渲染通过调用queryall接口来进行展示。

图2.外部接口应用示例

刚刚通过示例，了解内部接口和外部接口的区别，本文主要针对外部接口测试进行讲解。

“杠精”来了(褒义词，说明在思考)？前端执行功能测试就已经调用接口了，后端继续做是不是重复测试了？来上图

接口测试和app测试的活动有部分重复的内容，主要集中在业务功能测试方面。除此之外，针对各自特性的测试都不一样，需要分别进行有针对性的测试，才能确保整个产品的质量。

接口测试更关注于服务器逻辑验证，而UI层测试可以关注于页面展示逻辑及界面前端与服务器集成验证。

了解接口当然必须了解协议HTTP/HTTPS

超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。定义啥的看多了也没意义直接上图

可以看到左边请求部分包括，请求行、请求头、请求数据（这个抓包Get请求方法所以请求部分不存在）；右边部分响应部分内容，状态行、响应头、响应正文。当然关于协议这块大家可以百度网上一大把这里讲的只是一带而过让大家了解报文组成，然后在我们测试工具中应用，测试工具postman上图：

在我们的测试工具中，输入我们接口相关信息就可以进行测试了。工具类的操作了解协议后大家会上手很快的后面部分才是重点。

接口测试第一步需求分析

我们对接口测试做了一个脑图的需求分析，图中的测试点都是我们需要在用例设计时候需要进行关注和覆盖的。同时下面也是我们测试人员在用例设计时候需要注意的。

关注需求：测试过程中从需求角度出发设计测试用例，不必过度的设计我们异常测试用例。如某需求接口增加请求头，目的是根据请求头字段过滤对应查询信息，我们关注是新增字段业务功能以及老功能点兼容性，而非过度异常测试场景。

必填项校验：测试过程中不填并不是传“”或者空格，对于json数据而言是不传整个Key : Value 这段键值对如：必填项参数{"userid" ："123"}则我们测试不传场景应该传{}而非{"userid"：""}或者{"userid"：" "}

边界值校验：对于String而言有字符长度限制，对于Int、Double等数值型要了解其限制最大值。如Int取值范围-2147483648~2147483647

必测点：业务返回码以及枚举值全量覆盖。如：返回参数中有枚举值分别为交易成功、交易失败、校验中。必须对状态进行全覆盖。

性能测试：性能测试时应对改服务的网络拓扑、服务架构及链路进行梳理，根据产品或开发提供指标进行需求分析，制定测试方案评审通过后方可进行测试。

安全测试：可通过安全测试工具进行扫描测试如AppScan、 sqlmap等

设计方法：等价类、边界值、判断表等用例设计方法的应用

有了前排的需求分析，我觉得应该覆盖率应该很高了吧，经历过的人都知道无论你怎么去头脑风暴，千丝万缕的系统复杂度还是会让我经常会遗漏一些测试场景或者经常收到线上故障困扰。

覆盖率工具的应用

Jacoco：即 Java Code Coverage，是一款开源的 Java 代码覆盖率统计工具。可以帮助我们在测试过程中统计到我们用力覆盖率。

图3.JacocoDemo示例

Jacoco部署及应用网络上有很多相关文章，这里只是做了一个demo演示。框1Jacoco报告展示部分，能够细化到方法层面的维度，框2是我们执行过程中的方法，绿色部分框3代表我们用例执行时候相对应的代码执行到了，框4代表没有执行到的代码。

至此，我们通过工具和技术，来完成用例的设计以及覆盖率的保证；后面就考虑执行和效率了，提到效率肯定就是自动化了。

测试金字塔模型：

Ø 1.越底层，越稳定。金字塔主要观点认为单元测试的稳定性高，需要多投入。

Ø 2.越底层，越高效。程序的问题，最终还得落在具体的代码上，所以底层的测试更容易发现问题。

Ø 3.越底层，越低成本。问题，越早发现问题，修复的成本自然越低。

Ø 4.越底层，越难实施。越底层的实现对技术专业性要求越高，这点跟第三点有点矛盾，往往越专业的人才也意味着人力成本越高

低投入，高产出；自动化维护成本低，测试效率高，贯穿整个产品生命周期，即构建-测试-发布-监控，更快更早发现问题。从“时间”、“人力”、“收益”方面，值得去实现接口自动化。

设计思路：数据驱动层收集测试数据及测试行为，核心层进行实习测试手机测试结果。

平台展示：

接口测试在持续测试体系中的应用

接口测试在我们持续测试质量体系中应用无处不在，可以应用到我们CI/CD中，作为一种准入准出的标准。

思考：有了上面的这些思路精准测试实现还难吗，欢迎留言讨论~