防止断更 请务必加首发微信：1716143665
关闭
讲堂
部落
算法训练营
前端进阶训练营
企业服务
极客商城
客户端下载
兑换中心
渠道合作
推荐作者
01 | 基础：跳出细节看全局，接口测试到底是在做什么？
2020-02-03 陈磊
接口测试实战课
进入课程
讲述：陈磊
时长14:40大小11.76M
你好，我是陈磊。
今天开始，我们就来聊一聊接口测试的那些事儿，这是我们专栏的第一节课，在讲解如何做好接口测试之前，我想先给你讲讲它的必要性，再讲讲什么是接口、什么是接口测试。
接口测试为什么重要？
我相信你一定听说过这样一句话：“测试要尽早介入，测试进行得越早，软件开发的成本就越低，就越能更好地保证软件质量。”
但是如何尽早地进入测试，作为软件测试工程师的你，是不是也没办法说得清楚呢？其实上面那句话中的“测试”，所指的并不是测试工程师这个人，而是指包含了单元测试、接口测试、界面测试等一系列质量保障活动的测试工作。
说到单元测试、接口测试和界面测试，你是不是马上就想到了“测试金字塔模型”呢？
在这个金字塔模型中，界面测试、接口测试和单元测试，每一个阶段所占面积的大小，代表了它们在测试过程中的投入和工作量占比。
你可以看到，单元测试在测试过程中，占据了绝大部分的比重，这表示单元测试需要你投入更多的时间和人力成本。但是，单元测试并非测试工程师的本职工作，它属于开发工程师的工作范筹。说到这你可能会问了：“如果开发工程师从来不写单元测试怎么办？”毕竟大部分开发人员都不爱写测试。
其实，我也会问自己这个问题。不可否认，开发工程师不只很少写单元测试，更很少写出好的单元测试代码，很多时候，工期的压力让他们放弃了单元测试。但是，一个产品的交付质量更多时候却是由测试工程师来保障的，面对这一实际现状，我们又该怎么办好呢？
我们聪明的测试工程师提供了两种解决手段：一种是用一些智能化框架补充单元测试工作（如果你对智能化单元测试感兴趣，可以参考我在 2019 年 TiD 上的演讲内容“自动的自动化测试智能化一站式 API 测试服务”）；另外一种，就是加大我们自己主导的接口测试的工作投入比重，来弥补单元测试的不足，这样，上面那个金字塔模型就会逐渐演变成菱形模型。
那之所以出现从“金字塔模型”到“棱形模型”这种变化，并不是有人刻意提高测试工程师在整个交付流程中的地位，这其实是随着工作的不断进行，逐渐形成的结果。
在质量保障过程中，我们的测试工程师会不断增大接口测试的测试深度和测试广度，往下逐渐覆盖一些公共接口的单元测试内容，往上则逐渐覆盖应该由 UI 层保障的业务逻辑测试，这么做的主要目的，就是为了更好地完成质量保障工作，交付一个可靠的、高质量的项目。
所以，从接口测试这一环节开始，测试工程师就变成了质量保障工作的主要推动者，接口测试也变得愈发重要。那它有什么好处和优越性呢？我觉得可以从下面这 3 个角度来看：
接口测试更容易和其他自动化系统相结合；
相对于界面测试，接口测试可以更早开始，也可以测试一些界面测试无法测试的范围，因此它使“测试更早的投入”这句话变成现实；
接口测试还可以保障系统的鲁棒性，使得被测系统更健壮。
现在，我相信你已经意识到接口测试在质量保障中的重要地位了，那么，你知道究竟什么是接口吗？接口测试又在测些什么呢？我们又为什么要做接口测试呢？
下面我就逐一把这些讲解给你。
接口是什么？
如果你想要知道接口测试在测什么，首先就要知道接口是什么。
在这里我不想告诉你书本上是怎么定义接口的，从那些晦涩的语言中，你可能读几次都不能真正理解它的含义，我准备用一个实际生活中的例子，来告诉你接口究竟是什么。
我相信你肯定去过麦当劳，那每次在你去麦当劳吃东西时，你是否细心观察过它为你准备订单商品的过程呢？
如果你的订单上有一个汉堡，工作人员会先找到汉堡的原材料如面包片、肉饼和生菜等，按照规定步骤，将这些原材料组合成一个汉堡，然后送给你；如果你的订单上有一份薯条，那么工作人员会进入另外一个工作流程，先找到薯条原材料和炸薯条的锅，把薯条炸好后，送到你面前。
那么在上面的例子中，汉堡以及薯条的原材料就是接口中必要的条件入参，也就是接口的特定输入；制作汉堡或烹饪薯条的过程，就是接口内部的处理逻辑；送到你面前的汉堡和薯条，就是接口的处理结果和特定输出，也就是返回参数。
所以我们可以看到，接口就是有特定输入和特定输出的一套逻辑处理单元，而它不用知道自身的内部实现逻辑，这也可以叫做接口的黑盒处理逻辑。
而从上面的例子你也可以看到，由于服务对象不同，接口又可以分为两种，一种是系统或服务的内部接口，一种是外部依赖接口。
内部接口
简单来说，内部接口就是系统内部调用的接口。
在上面麦当劳的例子中，内部接口有两个：
汉堡订单。服务员在接到订单后，输入汉堡的原材料，将汉堡做好后，放到后厨和前台之间的一个中间储存柜里，作为输出，为下一个中间储物柜接口提供输入参数。
中间储物柜。服务员从中间储物柜拿出汉堡，这就是这个内部接口的特定输入，最后送到你面前的汉堡，就是这个内部接口的特定输出。
那么在软件系统中，内部接口是怎么一回事呢？
其实，你在网上购物时，要先登录系统，然后将商品加入购物车，再接下来支付订单。那么，从添加商品到购物车，再到支付订单，这一长串的流程之间，就是通过系统内部接口来完成的。
外部接口
刚刚说了内部接口，那什么是外部接口呢？其实它是相对于内部接口而存在的一个概念，上面你在麦当劳点餐的场景就是一个外部接口，它又可以分为两部分：
出订单前，你的点餐过程。这个外部接口特定的输入是你在点餐时，告诉服务员你想点什么，这也是你输出给麦当劳的参数。
出订单后，服务员送餐的过程。它的特定的输出是服务员把汉堡送给你，这也是麦当劳返回给你的处理结果参数。
在系统上，外部接口又是怎么回事呢？
你在购物后点击付款时，页面会跳转到支付系统，等你完成支付流程后，再跳转回订单页，在这样的流程中，都会涉及系统对外的接口，还有，比如说付款工程的支付接口、配送过程的物流接口等等。
现在我来总结一下接口的本质，它其实就是一种契约，遵循这样一种形式：在开发前期，我们约定接口会接收什么数据；在处理完成后，它又会返回什么数据。
如果调用方和被调用方都遵从了这种契约，那么就可以达到共同开发的目的，开发完成后，联调完成系统逻辑的前期预期，提高研发效能。
什么是接口测试？
还是以麦当劳的汉堡为例，接口测试，其实就是要验证制作汉堡的过程是否正确。这里所说的“正确”其实有两方面的意思：
一方面，是要验证输入了汉堡的原材料，经过制作汉堡的处理流程，最后交付给你的是一个汉堡；
另外一方面，是要验证在输入的汉堡原材料不对或者不全的情况下，经过制作汉堡的处理流程后，不能给你交付一个汉堡。
你一定要注意，这两方面的验证是都要进行的，对于一个测试工程师来说，这两种流程都是正向流程。只有理解了这个思维，你才能把自己从客户思维里拉出来，形成测试工程师思维。
我相信你在工作中，已经接触过各式各样的接口了，比如说 HTTP 协议的接口、RESTful 格式的接口、WebService 的接口、RPC 协议的接口等。其实无论是哪一种形式的接口，它们都是通过某一种传输协议，在 Client 端和 Server 端之间来完成数据传递的。
假如你现在测试的，是 Web 端的极客时间，那么 Client 端就是浏览器，Server 端就是 Web 服务，那么浏览器和 Web 服务之间，就是通过 HTTP 协议传输的；
如果你测试的，是移动端的极客时间，那么 Client 端就是你的设备上安装的极客时间应用，Server 端就是 RESTful 格式的接口服务，那么极客时间的应用和 RESTful 格式的接口服务，就是通过 JSON 格式的数据来传递的。
看到这，我想你也能理解了，接口测试其实就是模拟调用方，比如 Client 端，通过接口通信来检测被测接口的正确性和容错性。
但是请你放心，我现在所说的模拟调用方，并不是让你开发一个浏览器或者极客时间的手机应用，而是让你模拟这些客户端上的前端逻辑，调用 Server 端提供的接口，你完全可以借助一些工具或代码来完成这项工作。
这些相关的工具或代码技巧，也就是我设计这个专栏的主要思路。但我不想把这些工具一次都罗列给你，让你马上就失去兴趣，这是由于两个原因：
当你看到一个好几页的工具列表或者技术列表式时，你可能会觉得，自己需要翻越无数个高峰才能学会接口测试；
另一方面我也觉得，在接口测试中，工具或代码并不是它的核心内容，接口测试思维才是你应该重点关注的问题。
所以，我会在做一些工作或者任务的过程中，把这些工具介绍给你，让你知道哪些工具能够解决哪些问题，用什么样的代码可以解决什么样的问题。我也更希望你知道，工具和代码并不是相互排斥的，而是相互依存和相互辅助的。
其实，接口测试和你以前最熟悉的业务测试一样，都是关注输入和预期是否一致，尤其是输入数据中有一些非法输入的时候，接口的处理和逻辑控制是否合理，这些都是通过返回值来判定的。
还有一些小概率逻辑的处理也是我们设计输入的关注重点，比如一些代码中的异常情况，我们也要想办法，通过输入参数来触发这种逻辑分支，通过返回值来判定对应接口内部实现的处理逻辑是否合理、是否健壮。
这样看来，接口测试对于你来说，也不是一个全新的工作内容，但它还有自身的特别之处的，比如说：
在测试手段上，接口测试算是技术驱动和业务驱动双管齐下的工作（界面测试却是业务驱动为主的工作），因此，你需要借助一定的工具来完成它。这个工具既有可能是成熟的工具，也有可能是你自己写的代码，因此，测试技术会在接口测试阶段，变得和业务知识一样重要。
在工作范围上，接口测试影响的范围会更广一点，它会覆盖一部分单元测试的内容，也会覆盖一部分业务测试的内容，但是，无论是哪一部分的内容被它侵占，相对应部分的工作投入其实都减少了。
总结
今天我们一起聊了聊接口测试，有人说，从吃的开始聊起就很容易打开谈话的僵局，所以我们从麦当劳的汉堡开始，讲述了接口为什么重要、接口是什么以及接口测试在测些什么。我还讲了接口测试和业务测试的区别和联系，那就是“相互依存，不可分割”。
虽然我今天洋洋洒洒给你讲了很多内容，你也有可能记住的并不多，但我希望下面这三点你一定要烂熟于心：
接口测试是通过设计输入和预期输出来完成测试验证的，你之前掌握的测试用例设计方法等测试基本功，在这里还是有用武之地的；
接口测试是一个技术知识和业务知识相结合的工作，可以更好地提升你自己的技术实力，让那些说我们是“点工”的人早早闭嘴；
接口测试也是功能测试，要说有和界面测试不同的地方，仅仅是和我们交互的，不再是开发工程师设计的界面，而是测试工具或者代码。
在很多人眼里，接口测试是技术，业务测试是业务，但它们其实是不可分割的。所以在这个专栏中，我会通过先介绍方法再引入工具，到最后用代码引入封装框架，一步一步教你完成接口测试。
思考题
我们今天的课程到这里就结束了，现在我想请你思考一下，你还能举出其它实际的例子，证明接口测试是质量保障环境中，必不可少的一个测试阶段吗？
我是陈磊，欢迎你在留言区留言分享你的观点，如果这篇文章让你有新的启发，也欢迎你把文章分享给你的朋友，我们一起来探讨和学习。
© 加微信：642945106 发送“赠送”领取赠送精品课程 发数字“2”获取众筹列表。
上一篇
开篇词 | 把接口测试这件小事做深、做透
下一篇
02 | 方法论：没有任何文档，怎么才能快速了解接口的信息？
写留言
171614 3665 拼课微信(31)
2020-02-03我觉得今天最大的收获就是 金字塔 到 菱形 这个图的转换，正是印证了我们公司的现状（开发 参差不齐，单元覆盖不高或很少，领导果推接口测试，有远见）展开作者回复: 谢谢您，测试的工作从接口测试开始，因此我们做好我们负责的内容，弥补类似无单元测试的不足，交付高质量项目！
1 6
2020-02-03我现在做的主要是web页面测试，在验证页面数据的时候，会用F12查看前端的入参跟后端接口返回的json分别是什么，在跟数据库查询结果比对，我认为这种就是业务跟接口相结合的情况作者回复: 谢谢您留言，您说的是对的，是一种结合方式，虽然方法有点累，但是确实一种更加严谨的做事方法，希望你在课程中学习到让您轻松一点的方法！
5 6- 2020-02-03希望老师能对不同协议的接口，如“ HTTP 协议的接口、RESTful 格式的接口、WebService 的接口、RPC 协议的接口等。”分别举一个例子，并说明有哪些不同点，谢谢。
作者回复: 谢谢您，具体协议的区别有一些提及，例子每个都有。希望我们一起学习进步
1 4 
2020-02-04参数符合和不符合接口入参形式都是正向测试，那么接口测试的异常流是什么呢？有点不太好理解，能给个具体例子吗展开作者回复: 您好，谢谢留言，正向测试相对应的是反向测试，所指的反向测试测试支持流程的反向进行或者是功能的反向测试，这是一个在业务测试里的概念，例如支付付款是正向测试，那么退款是反向测试。
1 3
2020-02-04就综合收益而言，还是觉得单元测试比接口测试更多一些的，毕竟单元测试跑的次数更多，入场的时间也更早，但实际的问题是确实很少开发人员乐于做单元测试，不过随着效能提升的普及，感觉单测迟早还是会大行其道。接口测试相比于ui测试，其功能的稳定程度好了很多，更适合自动化测试，加之目前单元测试还没有得到大范围普及，接口测试有较大的开发空间，在整个cicd流水线中，作为集成测试主要阵地的接口测试，肯定也会长期占用一席之地的。期待跟着老师学习，提升、夯实接口测试的视野、思维和能力。已经盯上aat了，相信老师会在授课过程中介绍一下其诞生过程吧｡◕‿◕｡展开作者回复: 谢谢您，aat不会介绍十分抱歉，因为那是京东的只是产权，aat的关键算法你可以在TID 、TICA、NCTS等会议ppt里面看到。您的观点我也很认同，单测确实最优但是测试工程师真的是难以推动我们做好我们自己能够主导的事情应该可以弥补一部分单测不足的问题。
2
2020-02-05浅显易懂，给出的接口测试的定义和解释很容易让初级测试人员快速理解作者回复: 谢谢tyhom
1
2020-02-04之前写接口时，一直戏谑测试是接口破坏大王~
陈老师汉堡的例子让我这个吃货流口水，哦不对，是让我对接口的印象更深刻😝
这篇文章我目前听了两遍，给我印象最深刻的一点用我的话说就是：测试不但要看传入错误参数时的返回是否正常报错或处理，更要看传入正确或合理参数时的返回是否正确。因为我自测接口时偶尔会遗漏某一方面，有时候是因为工作任务多，有时候是因为偷懒😳
作为开发，单元测试还是要多写，这样在完成任务的时候可以少提交一些 Bug~展开作者回复: 谢谢您的支持，研发和测试是一个团队继续支持才能交付高质量的系统
1
2020-02-04小团队里面都是开发测试是一个人的，这种情况该如何做的更好呢？作者回复: 谢谢您，在团队中如果只有一个人其实很不提倡，很多书上都明确说了不要自己测试自己的代码。不过如果现实又是现实，既然你是一个人在奋斗那么我提倡你多完成一些单测会更有效果！
1
2020-02-04我现在做一些金融项目的时候，都是一些内部开发好的接口提供给第三方公司使用，包括放还款等接口，我们用不了第三方的前端APP，只能内部先接口测试。不过我用的是postman工具，不太了解工具的深层逻辑，或者代码接口测试，希望可以学到。展开作者回复: 谢谢您，一起努力。
1
2020-02-03有些接口逻辑不会和页面直接相关，想验证这些逻辑不能通过界面测试，只能通过接口测试；一些接口的空值输入无法通过界面测试，因为前端代码会判断空值，但是这些也是必须的验证的，也只能通过接口测试；另外，接口测试很快，能够集成到开发流程中，提高效率和质量展开作者回复: 谢谢您，确实接口测试会测试的更加全面，也是更好和持续集成相结合的方式，和现在的敏捷模式、DEVOPS流水线更好契合到一起！
1
2020-02-10在工作中，经常遇到，传入错误参数，开发说你不能这样传参，或者说每个接口都这样做防呆，会导致代码很累赘，这种情况要怎么取舍才好呀展开作者回复: 您好，一切的规则都是团队定出来的，因此在team内部出现这类问题，需要拉上技术、架构师、leader先定下来规则。一些好的实践确实对于写代码或者做设计来说是好的，但是有时候落地到team内部不一定是100%适用的，还是要因地制宜。
2020-02-09打卡20200209！展开作者回复: 加油
2020-02-09不爱写单测的开发进来学习下测试思维，免的老被提bug作者回复: 谢谢您
2020-02-08老师，后面讲框架是基于什么编程语言？展开编辑回复: Python
2020-02-07请问是用java还是python做的接口？展开作者回复: 课程以python为例，语言可以和自己实际情况选择，思维方式一样
2020-02-07想询问下，如何区分内部接口和外部接口呢？为何文中的登陆到添加到购物车是内部接口，而付款和配送又属于是外部接口呢？是否是指在一个服务中？展开作者回复: 内部接口和外部依赖接口是相对一个概念，login和加车是同一个公司的系统。支付挥着配送会经历银联接口和物流接口，因此相对叫做外部依赖接口
2020-02-07没有接触接口测试之前，只能看页面上的输入和输出，但是这样，有很多问题无法确定是前端还是后端的问题，接触之后，可以跳过前端，组合各种输入进行测试，大大增加了代码覆盖率，找出了一些潜在的问题，当然现在前后端问题能清楚的分辨了，不再出现指派错人的情况了展开作者回复: 谢谢您
2020-02-06一直没搞明白http和restful等等，这些接口的区别是啥？选择某种接口类型的参照是啥作者回复: 怎么选择其实主要是架构师定的，其实选择方法有三个方面。第一：系统以前技术栈的延续；第二：系统外部依赖系统的需求；第三：一些公共技术规范让系统更容易扩展
2020-02-05老师，请教一下，对于 预期结果一直都是变化的，且需求文档也没有明确的预期值，要想实现自动化，要如何处理？展开作者回复: 您好，您的问题确实是一个棘手的问题，但是如果你面对的SUT变化频繁建议还是让自动化晚一点进行，要不ROI太低
2020-02-05接口测试在整个质量保证过程中目前看来收益是相对比较大，而且也最容易作为快速验证交付的技术手段作者回复: 谢谢，是这样的
