01 基础：跳出细节看全局，接口测试到底是在做什么？

你好，我是陈磊。

今天开始，我们就来聊一聊接口测试的那些事儿，这是我们专栏的第一节课，在讲解如何做好接口测试之前，我想先给你讲讲它的必要性，再讲讲什么是接口、什么是接口测试。

接口测试为什么重要？

我相信你一定听说过这样一句话：“测试要尽早介入，测试进行得越早，软件开发的成本就越低，就越能更好地保证软件质量。”

但是如何尽早地进入测试，作为软件测试工程师的你，是不是也没办法说得清楚呢？其实上面那句话中的“测试”，所指的并不是测试工程师这个人，而是指包含了单元测试、接口测试、界面测试等一系列质量保障活动的测试工作。

说到单元测试、接口测试和界面测试，你是不是马上就想到了“测试金字塔模型”呢？

在这个金字塔模型中，界面测试、接口测试和单元测试，每一个阶段所占面积的大小，代表了它们在测试过程中的投入和工作量占比。

你可以看到，单元测试在测试过程中，占据了绝大部分的比重，这表示单元测试需要你投入更多的时间和人力成本。但是，单元测试并非测试工程师的本职工作，它属于开发工程师的工作范筹。说到这你可能会问了：“如果开发工程师从来不写单元测试怎么办？”毕竟大部分开发人员都不爱写测试。

其实，我也会问自己这个问题。不可否认，开发工程师不只很少写单元测试，更很少写出好的单元测试代码，很多时候，工期的压力让他们放弃了单元测试。但是，一个产品的交付质量更多时候却是由测试工程师来保障的，面对这一实际现状，我们又该怎么办好呢？

我们聪明的测试工程师提供了两种解决手段：一种是用一些智能化框架补充单元测试工作（如果你对智能化单元测试感兴趣，可以参考我在2019年TiD上的演讲内容“自动的自动化测试智能化一站式API测试服务”）；另外一种，就是加大我们自己主导的接口测试的工作投入比重，来弥补单元测试的不足，这样，上面那个金字塔模型就会逐渐演变成菱形模型。

那之所以出现从“金字塔模型”到“棱形模型”这种变化，并不是有人刻意提高测试工程师在整个交付流程中的地位，这其实是随着工作的不断进行，逐渐形成的结果。

在质量保障过程中，我们的测试工程师会不断增大接口测试的测试深度和测试广度，往下逐渐覆盖一些公共接口的单元测试内容，往上则逐渐覆盖应该由UI层保障的业务逻辑测试，这么做的主要目的，就是为了更好地完成质量保障工作，交付一个可靠的、高质量的项目。

所以，从接口测试这一环节开始，测试工程师就变成了质量保障工作的主要推动者，接口测试也变得愈发重要。那它有什么好处和优越性呢？我觉得可以从下面这3个角度来看：

接口测试更容易和其他自动化系统相结合；
相对于界面测试，接口测试可以更早开始，也可以测试一些界面测试无法测试的范围，因此它使“测试更早的投入”这句话变成现实；
接口测试还可以保障系统的鲁棒性，使得被测系统更健壮。

现在，我相信你已经意识到接口测试在质量保障中的重要地位了，那么，你知道究竟什么是接口吗？接口测试又在测些什么呢？我们又为什么要做接口测试呢？

下面我就逐一把这些讲解给你。

接口是什么？

如果你想要知道接口测试在测什么，首先就要知道接口是什么。

在这里我不想告诉你书本上是怎么定义接口的，从那些晦涩的语言中，你可能读几次都不能真正理解它的含义，我准备用一个实际生活中的例子，来告诉你接口究竟是什么。

我相信你肯定去过麦当劳，那每次在你去麦当劳吃东西时，你是否细心观察过它为你准备订单商品的过程呢？

如果你的订单上有一个汉堡，工作人员会先找到汉堡的原材料如面包片、肉饼和生菜等，按照规定步骤，将这些原材料组合成一个汉堡，然后送给你；如果你的订单上有一份薯条，那么工作人员会进入另外一个工作流程，先找到薯条原材料和炸薯条的锅，把薯条炸好后，送到你面前。

那么在上面的例子中，汉堡以及薯条的原材料就是接口中必要的条件入参，也就是接口的特定输入；制作汉堡或烹饪薯条的过程，就是接口内部的处理逻辑；送到你面前的汉堡和薯条，就是接口的处理结果和特定输出，也就是返回参数。

所以我们可以看到，接口就是有特定输入和特定输出的一套逻辑处理单元，而它不用知道自身的内部实现逻辑，这也可以叫做接口的黑盒处理逻辑。

而从上面的例子你也可以看到，由于服务对象不同，接口又可以分为两种，一种是系统或服务的内部接口，一种是外部依赖接口。

内部接口

简单来说，内部接口就是系统内部调用的接口。

在上面麦当劳的例子中，内部接口有两个：

汉堡订单。服务员在接到订单后，输入汉堡的原材料，将汉堡做好后，放到后厨和前台之间的一个中间储存柜里，作为输出，为下一个中间储物柜接口提供输入参数。
中间储物柜。服务员从中间储物柜拿出汉堡，这就是这个内部接口的特定输入，最后送到你面前的汉堡，就是这个内部接口的特定输出。

那么在软件系统中，内部接口是怎么一回事呢？

其实，你在网上购物时，要先登录系统，然后将商品加入购物车，再接下来支付订单。那么，从添加商品到购物车，再到支付订单，这一长串的流程之间，就是通过系统内部接口来完成的。

外部接口

刚刚说了内部接口，那什么是外部接口呢？其实它是相对于内部接口而存在的一个概念，上面你在麦当劳点餐的场景就是一个外部接口，它又可以分为两部分：

出订单前，你的点餐过程。这个外部接口特定的输入是你在点餐时，告诉服务员你想点什么，这也是你输出给麦当劳的参数。
出订单后，服务员送餐的过程。它的特定的输出是服务员把汉堡送给你，这也是麦当劳返回给你的处理结果参数。

在系统上，外部接口又是怎么回事呢？

你在购物后点击付款时，页面会跳转到支付系统，等你完成支付流程后，再跳转回订单页，在这样的流程中，都会涉及系统对外的接口，还有，比如说付款工程的支付接口、配送过程的物流接口等等。

现在我来总结一下接口的本质，它其实就是一种契约，遵循这样一种形式：在开发前期，我们约定接口会接收什么数据；在处理完成后，它又会返回什么数据。

如果调用方和被调用方都遵从了这种契约，那么就可以达到共同开发的目的，开发完成后，联调完成系统逻辑的前期预期，提高研发效能。

什么是接口测试？

还是以麦当劳的汉堡为例，接口测试，其实就是要验证制作汉堡的过程是否正确。这里所说的“正确”其实有两方面的意思：

一方面，是要验证输入了汉堡的原材料，经过制作汉堡的处理流程，最后交付给你的是一个汉堡；
另外一方面，是要验证在输入的汉堡原材料不对或者不全的情况下，经过制作汉堡的处理流程后，不能给你交付一个汉堡。

你一定要注意，这两方面的验证是都要进行的，对于一个测试工程师来说，这两种流程都是正向流程。只有理解了这个思维，你才能把自己从客户思维里拉出来，形成测试工程师思维。

我相信你在工作中，已经接触过各式各样的接口了，比如说HTTP协议的接口、RESTful格式的接口、WebService的接口、RPC协议的接口等。其实无论是哪一种形式的接口，它们都是通过某一种传输协议，在Client端和Server端之间来完成数据传递的。

假如你现在测试的，是Web端的极客时间，那么Client端就是浏览器，Server端就是Web服务，那么浏览器和Web服务之间，就是通过HTTP协议传输的；
如果你测试的，是移动端的极客时间，那么Client端就是你的设备上安装的极客时间应用，Server端就是RESTful格式的接口服务，那么极客时间的应用和RESTful格式的接口服务，就是通过JSON格式的数据来传递的。

看到这，我想你也能理解了，接口测试其实就是模拟调用方，比如Client端，通过接口通信来检测被测接口的正确性和容错性。

但是请你放心，我现在所说的模拟调用方，并不是让你开发一个浏览器或者极客时间的手机应用，而是让你模拟这些客户端上的前端逻辑，调用Server端提供的接口，你完全可以借助一些工具或代码来完成这项工作。

这些相关的工具或代码技巧，也就是我设计这个专栏的主要思路。但我不想把这些工具一次都罗列给你，让你马上就失去兴趣，这是由于两个原因：

当你看到一个好几页的工具列表或者技术列表式时，你可能会觉得，自己需要翻越无数个高峰才能学会接口测试；
另一方面我也觉得，在接口测试中，工具或代码并不是它的核心内容，接口测试思维才是你应该重点关注的问题。

所以，我会在做一些工作或者任务的过程中，把这些工具介绍给你，让你知道哪些工具能够解决哪些问题，用什么样的代码可以解决什么样的问题。我也更希望你知道，工具和代码并不是相互排斥的，而是相互依存和相互辅助的。

其实，接口测试和你以前最熟悉的业务测试一样，都是关注输入和预期是否一致，尤其是输入数据中有一些非法输入的时候，接口的处理和逻辑控制是否合理，这些都是通过返回值来判定的。

还有一些小概率逻辑的处理也是我们设计输入的关注重点，比如一些代码中的异常情况，我们也要想办法，通过输入参数来触发这种逻辑分支，通过返回值来判定对应接口内部实现的处理逻辑是否合理、是否健壮。

这样看来，接口测试对于你来说，也不是一个全新的工作内容，但它还有自身的特别之处的，比如说：

在测试手段上，接口测试算是技术驱动和业务驱动双管齐下的工作（界面测试却是业务驱动为主的工作），因此，你需要借助一定的工具来完成它。这个工具既有可能是成熟的工具，也有可能是你自己写的代码，因此，测试技术会在接口测试阶段，变得和业务知识一样重要。
在工作范围上，接口测试影响的范围会更广一点，它会覆盖一部分单元测试的内容，也会覆盖一部分业务测试的内容，但是，无论是哪一部分的内容被它侵占，相对应部分的工作投入其实都减少了。

总结

今天我们一起聊了聊接口测试，有人说，从吃的开始聊起就很容易打开谈话的僵局，所以我们从麦当劳的汉堡开始，讲述了接口为什么重要、接口是什么以及接口测试在测些什么。我还讲了接口测试和业务测试的区别和联系，那就是“相互依存，不可分割”。

虽然我今天洋洋洒洒给你讲了很多内容，你也有可能记住的并不多，但我希望下面这三点你一定要烂熟于心：

接口测试是通过设计输入和预期输出来完成测试验证的，你之前掌握的测试用例设计方法等测试基本功，在这里还是有用武之地的；
接口测试是一个技术知识和业务知识相结合的工作，可以更好地提升你自己的技术实力，让那些说我们是“点工”的人早早闭嘴；
接口测试也是功能测试，要说有和界面测试不同的地方，仅仅是和我们交互的，不再是开发工程师设计的界面，而是测试工具或者代码。

在很多人眼里，接口测试是技术，业务测试是业务，但它们其实是不可分割的。所以在这个专栏中，我会通过先介绍方法再引入工具，到最后用代码引入封装框架，一步一步教你完成接口测试。

思考题

我们今天的课程到这里就结束了，现在我想请你思考一下，你还能举出其它实际的例子，证明接口测试是质量保障环境中，必不可少的一个测试阶段吗？

我是陈磊，欢迎你在留言区留言分享你的观点，如果这篇文章让你有新的启发，也欢迎你把文章分享给你的朋友，我们一起来探讨和学习。

精选留言（15）

桃子 👍（33） 💬（7）
参数符合和不符合接口入参形式都是正向测试，那么接口测试的异常流是什么呢？有点不太好理解，能给个具体例子吗
2020-02-04

苦行僧 👍（17） 💬（3）
我觉得今天最大的收获就是金字塔到菱形这个图的转换，正是印证了我们公司的现状（开发参差不齐，单元覆盖不高或很少，领导果推接口测试，有远见）
2020-02-03

roychris 👍（13） 💬（4）
希望老师能对不同协议的接口，如“ HTTP 协议的接口、RESTful 格式的接口、WebService 的接口、RPC 协议的接口等。”分别举一个例子，并说明有哪些不同点，谢谢。
2020-02-03

陈岳鑫 👍（11） 💬（4）
在工作中，经常遇到，传入错误参数，开发说你不能这样传参，或者说每个接口都这样做防呆，会导致代码很累赘，这种情况要怎么取舍才好呀
2020-02-10

东东 👍（11） 💬（9）
我现在做的主要是web页面测试，在验证页面数据的时候，会用F12查看前端的入参跟后端接口返回的json分别是什么，在跟数据库查询结果比对，我认为这种就是业务跟接口相结合的情况
2020-02-03

小太阳Angel 👍（9） 💬（3）
考试，请问用户多次频繁发红包后，余额会变成负数，这个问题该从哪里入手比较容易复现呢
2020-03-26

happychap 👍（6） 💬（1）
就综合收益而言，还是觉得单元测试比接口测试更多一些的，毕竟单元测试跑的次数更多，入场的时间也更早，但实际的问题是确实很少开发人员乐于做单元测试，不过随着效能提升的普及，感觉单测迟早还是会大行其道。接口测试相比于ui测试，其功能的稳定程度好了很多，更适合自动化测试，加之目前单元测试还没有得到大范围普及，接口测试有较大的开发空间，在整个cicd流水线中，作为集成测试主要阵地的接口测试，肯定也会长期占用一席之地的。期待跟着老师学习，提升、夯实接口测试的视野、思维和能力。已经盯上aat了，相信老师会在授课过程中介绍一下其诞生过程吧｡◕‿◕｡
2020-02-04

灰神 👍（5） 💬（3）
我现在做一些金融项目的时候，都是一些内部开发好的接口提供给第三方公司使用，包括放还款等接口，我们用不了第三方的前端APP，只能内部先接口测试。不过我用的是postman工具，不太了解工具的深层逻辑，或者代码接口测试，希望可以学到。
2020-02-04

我 👍（4） 💬（1）
有些接口逻辑不会和页面直接相关，想验证这些逻辑不能通过界面测试，只能通过接口测试；一些接口的空值输入无法通过界面测试，因为前端代码会判断空值，但是这些也是必须的验证的，也只能通过接口测试；另外，接口测试很快，能够集成到开发流程中，提高效率和质量
2020-02-03

Benson 👍（3） 💬（1）
现公司后台PHP转java，开发每改完一个接口，之前的接口自动化就可以马上派上用场了。
2020-02-16

Tyhom 👍（3） 💬（1）
浅显易懂，给出的接口测试的定义和解释很容易让初级测试人员快速理解
2020-02-05

书 👍（3） 💬（2）
转行做了一年点点点，公司没钱被裁，面试都是等通知。花4个多月吃自己，学c和java基础，买selenium课程学习摸索到皮毛能忽悠下，最终面了好些才找到一份外包，但大叔混入到大学生同事中根据接口文档能学到一些接口方面知识，ui自动化一般用不上。现在能做简单接口测试，比如jmeter，移动端抓包改出入参数据，挡板测试等，希望系统学习接口测试思维和一些方法，查缺补漏，能提高能力。学的越多发现越多不会。另外，能学到这课程，还是作者那句用selenum自娱自乐给点到了，确实挺麻烦的，用处又不是很大，面试有时用的上。
2020-02-04

darange 👍（2） 💬（2）
异步接口有比较好的测试方式么，比如我调用可能只返回true或false，但后台会做很多操作，比如数据库读写或者写文件之类的，这类也可以算接口测试么？还有测试数据往往需要提前在db中准备。这种场景有比较合适的测试自动化测试方式么？
2020-05-04

吃草🐴~ 👍（2） 💬（1）
之前写接口时，一直戏谑测试是接口破坏大王~ 陈老师汉堡的例子让我这个吃货流口水，哦不对，是让我对接口的印象更深刻😝 这篇文章我目前听了两遍，给我印象最深刻的一点用我的话说就是：测试不但要看传入错误参数时的返回是否正常报错或处理，更要看传入正确或合理参数时的返回是否正确。因为我自测接口时偶尔会遗漏某一方面，有时候是因为工作任务多，有时候是因为偷懒😳 作为开发，单元测试还是要多写，这样在完成任务的时候可以少提交一些 Bug~
2020-02-04

可可 👍（2） 💬（2）
小团队里面都是开发测试是一个人的，这种情况该如何做的更好呢？
2020-02-04