mod

极客时间专栏/接口测试入门课/初级技能篇/01 | 基础：跳出细节看全局，接口测试到底是在做什么？.md

@@ -0,0 +1,139 @@
+<audio id="audio" title="01 | 基础：跳出细节看全局，接口测试到底是在做什么？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ea/7e/ea965cf717561a641dbe7addf6d0867e.mp3"></audio>
+
+你好，我是陈磊。
+
+今天开始，我们就来聊一聊接口测试的那些事儿，这是我们专栏的第一节课，在讲解如何做好接口测试之前，我想先给你讲讲它的必要性，再讲讲什么是接口、什么是接口测试。
+
+## 接口测试为什么重要？
+
+我相信你一定听说过这样一句话：“测试要尽早介入，测试进行得越早，软件开发的成本就越低，就越能更好地保证软件质量。”
+
+但是如何尽早地进入测试，作为软件测试工程师的你，是不是也没办法说得清楚呢？其实上面那句话中的“测试”，所指的并不是测试工程师这个人，而是指包含了单元测试、接口测试、界面测试等一系列质量保障活动的测试工作。
+
+说到单元测试、接口测试和界面测试，你是不是马上就想到了“测试金字塔模型”呢？
+
+<img src="https://static001.geekbang.org/resource/image/54/26/54babe3ca1b8baf147d6b83486f86b26.jpg" alt="">
+
+在这个金字塔模型中，界面测试、接口测试和单元测试，每一个阶段所占面积的大小，代表了它们在测试过程中的投入和工作量占比。
+
+你可以看到，单元测试在测试过程中，占据了绝大部分的比重，这表示单元测试需要你投入更多的时间和人力成本。但是，单元测试并非测试工程师的本职工作，它属于开发工程师的工作范筹。说到这你可能会问了：“如果开发工程师从来不写单元测试怎么办？”毕竟大部分开发人员都不爱写测试。
+
+其实，我也会问自己这个问题。不可否认，开发工程师不只很少写单元测试，更很少写出好的单元测试代码，很多时候，工期的压力让他们放弃了单元测试。但是，一个产品的交付质量更多时候却是由测试工程师来保障的，面对这一实际现状，我们又该怎么办好呢？
+
+我们聪明的测试工程师提供了两种解决手段：一种是用一些智能化框架补充单元测试工作（如果你对智能化单元测试感兴趣，可以参考我在2019年TiD上的演讲内容“[自动的自动化测试智能化一站式API测试服务](https://mp.weixin.qq.com/s?__biz=MzUxOTg3NzA4Mg==&amp;mid=2247485068&amp;idx=4&amp;sn=dcabc199c0f9ba03319ecfdbe07a0b62&amp;chksm=f9f3be39ce84372f78d00a691559cdedef1e54355d12243efc5821c74f39def0d78164bd9296&amp;token=2056996305&amp;lang=zh_CN#rd)”）；另外一种，就是加大我们自己主导的接口测试的工作投入比重，来弥补单元测试的不足，这样，上面那个金字塔模型就会逐渐演变成菱形模型。
+
+<img src="https://static001.geekbang.org/resource/image/af/60/afec8e77c9fc22d448f9b2885d278b60.jpg" alt="">
+
+那之所以出现从“金字塔模型”到“棱形模型”这种变化，并不是有人刻意提高测试工程师在整个交付流程中的地位，这其实是随着工作的不断进行，逐渐形成的结果。
+
+在质量保障过程中，我们的测试工程师会不断增大接口测试的测试深度和测试广度，往下逐渐覆盖一些公共接口的单元测试内容，往上则逐渐覆盖应该由UI层保障的业务逻辑测试，这么做的主要目的，就是为了更好地完成质量保障工作，交付一个可靠的、高质量的项目。
+
+所以，从接口测试这一环节开始，测试工程师就变成了质量保障工作的主要推动者，接口测试也变得愈发重要。那它有什么好处和优越性呢？我觉得可以从下面这3个角度来看：
+
+1. 接口测试更容易和其他自动化系统相结合；
+1. 相对于界面测试，接口测试可以更早开始，也可以测试一些界面测试无法测试的范围，因此它使“测试更早的投入”这句话变成现实；
+1. 接口测试还可以保障系统的鲁棒性，使得被测系统更健壮。
+
+现在，我相信你已经意识到接口测试在质量保障中的重要地位了，那么，你知道究竟什么是接口吗？接口测试又在测些什么呢？我们又为什么要做接口测试呢？
+
+下面我就逐一把这些讲解给你。
+
+## 接口是什么？
+
+如果你想要知道接口测试在测什么，首先就要知道接口是什么。
+
+在这里我不想告诉你书本上是怎么定义接口的，从那些晦涩的语言中，你可能读几次都不能真正理解它的含义，我准备用一个实际生活中的例子，来告诉你接口究竟是什么。
+
+我相信你肯定去过麦当劳，那每次在你去麦当劳吃东西时，你是否细心观察过它为你准备订单商品的过程呢？
+
+如果你的订单上有一个汉堡，工作人员会先找到汉堡的原材料如面包片、肉饼和生菜等，按照规定步骤，将这些原材料组合成一个汉堡，然后送给你；如果你的订单上有一份薯条，那么工作人员会进入另外一个工作流程，先找到薯条原材料和炸薯条的锅，把薯条炸好后，送到你面前。
+
+那么在上面的例子中，汉堡以及薯条的原材料就是接口中必要的条件入参，也就是接口的特定输入；制作汉堡或烹饪薯条的过程，就是接口内部的处理逻辑；送到你面前的汉堡和薯条，就是接口的处理结果和特定输出，也就是返回参数。
+
+**所以我们可以看到，接口就是有特定输入和特定输出的一套逻辑处理单元，而它不用知道自身的内部实现逻辑，这也可以叫做接口的黑盒处理逻辑。**
+
+而从上面的例子你也可以看到，由于服务对象不同，接口又可以分为两种，一种是系统或服务的内部接口，一种是外部依赖接口。
+
+<li>
+<h3>内部接口</h3>
+</li>
+
+简单来说，内部接口就是系统内部调用的接口。
+
+在上面麦当劳的例子中，内部接口有两个：
+
+- 汉堡订单。服务员在接到订单后，输入汉堡的原材料，将汉堡做好后，放到后厨和前台之间的一个中间储存柜里，作为输出，为下一个中间储物柜接口提供输入参数。
+- 中间储物柜。服务员从中间储物柜拿出汉堡，这就是这个内部接口的特定输入，最后送到你面前的汉堡，就是这个内部接口的特定输出。
+
+那么在软件系统中，内部接口是怎么一回事呢？
+
+其实，你在网上购物时，要先登录系统，然后将商品加入购物车，再接下来支付订单。那么，从添加商品到购物车，再到支付订单，这一长串的流程之间，就是通过系统内部接口来完成的。
+
+<li>
+<h3>外部接口</h3>
+</li>
+
+刚刚说了内部接口，那什么是外部接口呢？其实它是相对于内部接口而存在的一个概念，上面你在麦当劳点餐的场景就是一个外部接口，它又可以分为两部分：
+
+- 出订单前，你的点餐过程。这个外部接口特定的输入是你在点餐时，告诉服务员你想点什么，这也是你输出给麦当劳的参数。
+- 出订单后，服务员送餐的过程。它的特定的输出是服务员把汉堡送给你，这也是麦当劳返回给你的处理结果参数。
+
+在系统上，外部接口又是怎么回事呢？
+
+你在购物后点击付款时，页面会跳转到支付系统，等你完成支付流程后，再跳转回订单页，在这样的流程中，都会涉及系统对外的接口，还有，比如说付款工程的支付接口、配送过程的物流接口等等。
+
+**现在我来总结一下接口的本质，它其实就是一种契约，遵循这样一种形式：在开发前期，我们约定接口会接收什么数据；在处理完成后，它又会返回什么数据。**
+
+如果调用方和被调用方都遵从了这种契约，那么就可以达到共同开发的目的，开发完成后，联调完成系统逻辑的前期预期，提高研发效能。
+
+## 什么是接口测试？
+
+**还是以麦当劳的汉堡为例，接口测试，其实就是要验证制作汉堡的过程是否正确。**这里所说的“正确”其实有两方面的意思：
+
+- 一方面，是要验证输入了汉堡的原材料，经过制作汉堡的处理流程，最后交付给你的是一个汉堡；
+- 另外一方面，是要验证在输入的汉堡原材料不对或者不全的情况下，经过制作汉堡的处理流程后，不能给你交付一个汉堡。
+
+你一定要注意，**这两方面的验证是都要进行的，对于一个测试工程师来说，这两种流程都是正向流程。只有理解了这个思维，你才能把自己从客户思维里拉出来，形成测试工程师思维。**
+
+我相信你在工作中，已经接触过各式各样的接口了，比如说HTTP协议的接口、RESTful格式的接口、WebService的接口、RPC协议的接口等。其实无论是哪一种形式的接口，它们都是通过某一种传输协议，在Client端和Server端之间来完成数据传递的。
+
+- 假如你现在测试的，是Web端的极客时间，那么Client端就是浏览器，Server端就是Web服务，那么浏览器和Web服务之间，就是通过HTTP协议传输的；
+- 如果你测试的，是移动端的极客时间，那么Client端就是你的设备上安装的极客时间应用，Server端就是RESTful格式的接口服务，那么极客时间的应用和RESTful格式的接口服务，就是通过JSON格式的数据来传递的。
+
+**看到这，我想你也能理解了，接口测试其实就是模拟调用方，比如Client端，通过接口通信来检测被测接口的正确性和容错性。**
+
+但是请你放心，我现在所说的模拟调用方，并不是让你开发一个浏览器或者极客时间的手机应用，而是让你模拟这些客户端上的前端逻辑，调用Server端提供的接口，你完全可以借助一些工具或代码来完成这项工作。
+
+这些相关的工具或代码技巧，也就是我设计这个专栏的主要思路。但我不想把这些工具一次都罗列给你，让你马上就失去兴趣，这是由于两个原因：
+
+- 当你看到一个好几页的工具列表或者技术列表式时，你可能会觉得，自己需要翻越无数个高峰才能学会接口测试；
+- 另一方面我也觉得，在接口测试中，工具或代码并不是它的核心内容，接口测试思维才是你应该重点关注的问题。
+
+所以，我会在做一些工作或者任务的过程中，把这些工具介绍给你，让你知道哪些工具能够解决哪些问题，用什么样的代码可以解决什么样的问题。我也更希望你知道，工具和代码并不是相互排斥的，而是相互依存和相互辅助的。
+
+其实，接口测试和你以前最熟悉的业务测试一样，都是关注输入和预期是否一致，尤其是输入数据中有一些非法输入的时候，接口的处理和逻辑控制是否合理，这些都是通过返回值来判定的。
+
+还有一些小概率逻辑的处理也是我们设计输入的关注重点，比如一些代码中的异常情况，我们也要想办法，通过输入参数来触发这种逻辑分支，通过返回值来判定对应接口内部实现的处理逻辑是否合理、是否健壮。
+
+这样看来，接口测试对于你来说，也不是一个全新的工作内容，但它还有自身的特别之处的，比如说：
+
+- 在测试手段上，接口测试算是技术驱动和业务驱动双管齐下的工作（界面测试却是业务驱动为主的工作），因此，你需要借助一定的工具来完成它。这个工具既有可能是成熟的工具，也有可能是你自己写的代码，因此，测试技术会在接口测试阶段，变得和业务知识一样重要。
+- 在工作范围上，接口测试影响的范围会更广一点，它会覆盖一部分单元测试的内容，也会覆盖一部分业务测试的内容，但是，无论是哪一部分的内容被它侵占，相对应部分的工作投入其实都减少了。
+
+## 总结
+
+今天我们一起聊了聊接口测试，有人说，从吃的开始聊起就很容易打开谈话的僵局，所以我们从麦当劳的汉堡开始，讲述了接口为什么重要、接口是什么以及接口测试在测些什么。我还讲了接口测试和业务测试的区别和联系，那就是“相互依存，不可分割”。
+
+虽然我今天洋洋洒洒给你讲了很多内容，你也有可能记住的并不多，但我希望下面这三点你一定要烂熟于心：
+
+1. 接口测试是通过设计输入和预期输出来完成测试验证的，你之前掌握的测试用例设计方法等测试基本功，在这里还是有用武之地的；
+1. 接口测试是一个技术知识和业务知识相结合的工作，可以更好地提升你自己的技术实力，让那些说我们是“点工”的人早早闭嘴；
+1. 接口测试也是功能测试，要说有和界面测试不同的地方，仅仅是和我们交互的，不再是开发工程师设计的界面，而是测试工具或者代码。
+
+在很多人眼里，接口测试是技术，业务测试是业务，但它们其实是不可分割的。所以在这个专栏中，我会通过先介绍方法再引入工具，到最后用代码引入封装框架，一步一步教你完成接口测试。
+
+## 思考题
+
+我们今天的课程到这里就结束了，现在我想请你思考一下，你还能举出其它实际的例子，证明接口测试是质量保障环境中，必不可少的一个测试阶段吗？
+
+我是陈磊，欢迎你在留言区留言分享你的观点，如果这篇文章让你有新的启发，也欢迎你把文章分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/接口测试入门课/初级技能篇/02 | 方法论：没有任何文档，怎么才能快速了解接口的信息？.md

@@ -0,0 +1,190 @@
+<audio id="audio" title="02 | 方法论：没有任何文档，怎么才能快速了解接口的信息？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/24/6c/24d0b367fbca4a856dfd538b1281fe6c.mp3"></audio>
+
+你好，我是陈磊。
+
+我相信在学习完上一节课后，你已经明白了接口测试是在测什么，我们为什么需要做接口测试。那么，当你面对一个接口测试任务的时候，你知道该如何开始吗？其实，任何事情从0到1都是一个门槛，你只要跨过这个门槛，后面就会一马平川。今天我就来告诉你，如何开始接口测试，让你面对一个项目不再束手无策，也不再面露难色。
+
+说起接口测试，我想你并不陌生。作为一名测试工程师，尤其是做了多年业务测试的测试工程师，在开始接触接口测试时，无论开发工程师是否提供了接口文档，我相信你都会对下面几种场景似曾相识：
+
+1. 开发工程师提交测试的项目，附带着一个几十页的Word文档，里面是一行一行的访问地址和路由，面对这样的Word文档，不知道如何开始验证；
+1. 开发工程师在即时通讯工具上，甩给你有好几页的这么一个传输消息，里面有各种嵌套的参数，你不知道这些参数都是干什么用的；
+1. 开发工程师口头告诉你需要测试的接口地址，然后就什么都没再多说，你问了他几句话后，他就借口说自己忙，不再理你，而你看到那个又长、又复杂的地址，束手无策。
+
+难道，面对这些状况，测试工程师就没办法自己分析接口，完成测试吗？我现在告诉你，当然不是。
+
+接下来，我就带你一起看看，一个理想的提测项目是什么样的，在实际工作中，绝大部分的提测项目又是什么样的，然后我们一起看看，如何一步一步解决一个不理想的提测项目。
+
+## 一个理想的提测项目
+
+一个理想的提测项目，在提测的过程中应该既包含前期参与的产品需求、原型设计，这些是由产品经理来提供的；也包含后端接口文档、代码单元测试脚本，这些是由开发工程师提供来的。它们都是你开展测试的必要输入内容，具体有这些作用：
+
+- 产品需求。它描述了系统的业务逻辑，通过这个文档，你才能知道怎么来设计测试用例；
+- 原型设计。它会更加直观地告诉你系统的使用逻辑，这对测试用例的设计、对系统的前期认知都是有辅助作用的。
+- 接口文档。它详细地描述了后端接口的访问方式和参数说明，使用这个输入项才能开展接口测试用例的设计、测试脚本的准备和测试数据的构建。
+- 单元测试脚本。它是保障提测质量的必要环节，是研发工程师自测的一个有效手段，可以保障提测项目的提测质量。
+
+这些内容不限制SUT（System Under Test，被测系统）的类型，SUT既可以是一个手机App，也可以是一个Web服务，甚至还可以是一个微服务接口。
+
+所以，对于接口测试阶段来说，一个非常理想的接口测试，就是从完美的接口文档开始的。开发工程师在设计和开发接口的过程中，就在不断维护和更新接口文档，这其中包含了每一个接口的访问方式、访问路由、输入参数含义、返回参数含义，以及一个完整的例子。
+
+这种接口文档可能是以Word文档形式存在，也有可能是以类似Swagger这种工具形式存在。说到Swagger，它是我推荐给你的一个接口文档的存在形式，是一个从代码生成的、以Web服务形式存在的接口文档，它可以伴随代码的变更同步变化，这就减少了很多开发工程师和测试工程师之间的沟通成本。
+
+由Swagger生成的接口文档的例子如下图所示，从图中你可以看到它对接口的访问方式、访问路由、参数都有着详细的描述。
+
+<img src="https://static001.geekbang.org/resource/image/de/64/de22757455c405cd60f5490801c8ef64.jpg" alt="">
+
+这样，当你拿到接口文档时，就可以快速使用各种工具或者代码来完成你的单个接口测试任务了。与此同时，你还可以通过一些参数设计、参数上下文传递，来完成接口的流程测试。
+
+## 理想的情况很难发生
+
+上面我说的是很理想的情况，现实却往往并不总如人意，我相信你也肯定遇见过下面这些情况：
+
+- 根据产品经理的一句话需求，开发工程师便开始任意发挥，“所见系统即需求”的情况普遍存在，这就更别说后续的单元测试和接口文档了；
+- 开发工程师从来不写单元测试脚本，提测项目质量无法保障，接口文档更无从谈起，你不知道如何开始完成接口测试；
+- 你在拿到提测项目后，从部署测试环境到开始测试，一直都是摸黑前进，由于接口测试没有充分的输入条件，只能从UI层开始测试，结果导致交付质量大打折扣。
+
+就像墨菲定律说的那样：可能发生的事情必将会发生。所以，上面我列举的接口测试难以推行的一些常见情况，都是你在工作中会碰见的问题。
+
+那么，如果一个项目没有接口文档，我们就无法开始接口测试了吗？当然不是。
+
+测试工程师的工作本质上是一个由表及里的工作，如果你还是每次工作都处在和终端用户使用行为几乎一致的流程上，那么只能说明你还不算一名合格的测试工程师。
+
+其实，无论开发工程师给我们的输入项是否包含了接口文档，我们都可以通过一些技术手段和工作方法，完成接口测试必要的输入项接口文档的创建。
+
+那么这样的工作如何开始呢？下面我就来和你一起完成这样一项任务，教你如何开始第一个接口测试。
+
+## 开始第一个接口测试
+
+在拿到一个SUT环境的时候，你首先就要进行接口测试，这是因为单元测试不是由测试工程师来完成的，而是由开发工程师编写、并由持续集成系统自动完成执行的。
+
+如果开发工程师没有给我们任何有价值的文档，那么要开始接口测试，你可以通过工具辅助、分析问题、询问解惑这三个步骤来完成。
+
+<img src="https://static001.geekbang.org/resource/image/52/0c/52483652c86dc2ce7f3459a1d773c30c.jpg" alt="">
+
+具体的工作模式如上图所示：
+
+1. 借助一些工具的辅助来完成接口分析；
+1. 通过工具截获一些接口信息；
+1. 通过分析接口的访问方式、参数等信息整理出一些问题，和研发工程师沟通这些问题，将一些不知道的参数含义、参数取值范围等问题问清楚。
+
+通过这三步的循环，你就可以完成对SUT系统接口信息的完善和维护，最终得到一份完整的、接口测试需要的输入—接口文档。
+
+下面我会结合一个案例，带你看看这三步具体该如何进行。
+
+### 工具辅助
+
+当你第一次拿到一个被测项目，无论它是一个App服务还是一个Web服务，你都可以通过一些HTTP代理完成接口分析，这里我推荐你使用Fiddler这款工具。
+
+> 
+<p>**注意：**<br>
+Fiddler既支持Windows操作系统，也支持MacOS操作系统，但是在MacOs上的版本并不好用，这是因为Fiddler使用了.Net开发。如果你是一个MacOS深度用户，那么我推荐给你两款工具，一款是Charles，另外一款是mitmproxy。其中，Charles是商业软件，mitmproxy是开源软件，但是Charles使用起来更简单，mitmproxy的使用则稍微复杂一些，你可以依据自己的喜好来选择。</p>
+
+
+简单来说，Fiddler（[在这里下载](https://www.telerik.com/fiddler)）是一个HTTP的调试代理，也就是一个HTTP协议的抓包工具，运行时会在本地建立一个代理服务，默认地址为127.0.0.1:8888。当浏览器和被访问的服务之间发生交互的时候，Request（请求）和Response（响应）都会经由Fiddler代理，这样就可以截获下全部的访问信息流了。
+
+在接下来的内容中，我会带你使用Fiddler来完成接口的分析任务，**但是，我并不打算手把手的把Fiddler这个工具的使用细节讲述给你，因为除了Fiddler，其实还有很多工具可以完成对应的任务，每一种工具又都有其具体的使用方法，这里我真正想告诉你的，是通过具体的方法来解决问题的思维。**
+
+### 分析问题
+
+在解决问题前，我们首先要分析问题，这也是我们开始接口测试的第二步。
+
+下面我们一起来使用Fiddler，分析一下极客时间Web端首页（极客时间Web端首页地址https://time.geekbang.org）。
+
+首先，打开Fiddler，然后启动浏览器访问极客时间Web端首页，我们可以看到Fiddler截获了很多消息，找到刚刚输入的https://time.geekbang.org，如下图所示，在右侧上方Inspectors的标签页下，你就可以看到Request请求的内容和Response请求的内容了。
+
+<img src="https://static001.geekbang.org/resource/image/59/bd/599426c3540b73b0bb673dda2ae0ebbd.jpg" alt="">
+
+为方便你查看，我将Request的消息体复制出来如下：
+
+```
+POST https://time.geekbang.org/serv/v1/column/topList HTTP/1.1
+Host: time.geekbang.org
+Connection: keep-alive
+Content-Length: 0
+Accept: application/json, text/plain, /
+Origin: https://time.geekbang.org
+User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36
+Sec-Fetch-Site: same-origin
+Sec-Fetch-Mode: cors
+Referer: https://time.geekbang.org/
+Accept-Encoding: gzip, deflate, br
+Accept-Language: zh-CN,zh;q=0.9
+Cookie: _ga=GA1.2.2063652238.1573441551; _gid=GA1.2.1275017383.1573441551; Hm_lvt_022f847c4e3acd44d4a2481d9187f1e6=1573441551; GRID=b0a2570-01c8b13-90b002b-568dc07; MEIQIA_TRACK_ID=1TS7HZW4C6OWaPSu5VGIj7uN4pM; MEIQIA_VISIT_ID=1TS7HWSYajeZyS29IqNNyvW9cyY; SERVERID=1fa1f330efedec1559b3abbcb6e30f50|1573441580|1573441549; _gat=1; Hm_lpvt_022f847c4e3acd44d4a2481d9187f1e6=1573441790
+
+```
+
+从这段消息体中我们可以获知，它的访问方式是POST，访问的URI是“[https://time.geekbang.org/serv/v1/column/topList](https://time.geekbang.org/serv/v1/column/topList) ”。这里面的具体属性内容，你可以自行查看，但是，我希望你重点关注如下这几个属性：
+
+- HOST，它表示指定访问的服务器域名；
+- Connection的值为keep-alive，这表示需要持久连接；
+- Accept，它表示客户端可以接受的内容类型为application/json, text/plain, **/** ；
+- User-Agent，它说明请求是从什么浏览器发出去的；
+- Sec-Fetch-Site和Sec-Fetch-Mode，它们是JS中对跨域的一些设置；
+- Accept-Encoding设置为gzip、deflate、br，这表示可以支持的Web服务器返回内容压缩编码类型；
+- Accept-Language，它表示接受的语言。
+
+这其中的Cookie的内容，是你需要特别非常关心的，因为Cookie中传递的参数很多都是用来确认用户身份、鉴定角色权限等需要的参数。这样，通过上面的分析你就可以自己绘制如下的表格，这里我也给出了一张表格。
+
+<img src="https://static001.geekbang.org/resource/image/08/68/08453bfd82584f4fce9c1c16140d0468.jpg" alt="">
+
+在这个表格中，被标注为白色背景的部分，是这次访问的基本信息；被标注为黄色背景的部分，是访问的头信息，同时也是我们已知的内容；被标注为红色背景的部分，就是Cookie信息，是我们未知的内容。同时你可以看到，本次消息访问的body是空的，是没有内容的。
+
+接下来我们再看看这个请求的Response信息，由于返回的消息比较长，我在这里就不贴出来了，但是通过下面这个图你可以看出，这次返回的主体是一个很长的JSON，这里面包含了各个专栏或者课程的信息。
+
+<img src="https://static001.geekbang.org/resource/image/6b/76/6b177a4d543c1799875ca3417f9ada76.jpg" alt="">
+
+这些返回值包含了很多参数，你也需要关注这些参数，因为很多时候，一个接口的返回值会是另外一个接口的入参，也就是我常说的串联业务逻辑上下文的参数。
+
+现在，在你绘制的接口信息表中还有一些未知的Cookies内容，就如我前面说的，Cookie内容是完成接口测试必须要模拟并传递的一些信息，因此，我们必须要尽可能完善它，使它成为接口测试的必要输入条件之一。
+
+这样，拿着这张接口信息表，我们就进入了第三步，询问解惑。
+
+### 询问解惑
+
+对于本次访问的Cookies的参数，从参数语义上来说，我们无法知道这些参数是用来干什么的，他又起到了什么作用，作为测试人员，我们也无法只靠自己知道每一项具体的含义、表示的内容以及参数的作用。
+
+因此，我们需要拿着上面的那张表格，找到对应的开发工程师，去问清楚表格中标红部分的参数。
+
+针对每一个参数，你都要从下面的几点详细询问，并保证你已经真的理解了这些内容。那么，都询问些什么呢？我认为主要有三点。
+
+1. **参数的含义以及来源**。你要搞清楚每一个参数的含义，也就是这个参数对应的实际自然语言的名字，通过记录每一个参数的中文语义，也会让更你容易记住这个函数是干什么的。同时，你也要知道这个参数的赋值是从哪里来的，是从其他页面的返回值中得到的？还是JS生成的？如果是其他页面或者接口返回的，那么，是哪一个接口返回的哪个字段？这样，当你开始做接口测试的时候，你就知道去哪里拿到这个参数的赋值了。如果是另一个接口的返回字段，那么，你还需要维护一份返回该参数接口的接口信息文档，以便于自己下一次创建对应的参数，如果不可以创建，那么你就要知道这个参数的生成规则，也要知道如何手动构造它。
+1. **参数的作用域**。参数的作用域指的是这个参数在这个接口中是做什么用的，它在哪一个访问周期里是一直存在的，它是否导致了业务逻辑分支等。比如说，这个参数是用来验证用户权限吗？它的验证算法是什么？之所以要搞清楚这些内容，是为了你在做接口测试的时候，可以设计更小的参数组合来覆盖更多的业务逻辑，这是测试用例去除冗余的一个很好的方法。
+1. **返回值的含义**。针对上面一大串的返回JSON，你要搞清楚在返回值中，每一个JSON的Key所对应的含义，这样，当你需要和这个接口产生交互的时候，就可以快速地拿到对应参数的含义，完成业务逻辑上下文的参数串联了。
+
+总地来说，Request的全部参数和Response的全部参数对于接口测试来说，都是必要的输入项，因此我们有必要花费很多精力完善并且留存它们。
+
+OK，到现在，你已经借助工具、通过分析问题明确了未知参数，也通过询问解决了未知参数的中文含义、作用域，以及对应返回参数的中文含义，现在，即使面对没有接口文档的提测项目，你也能收集明确的、足够的信息了。
+
+那么接下来，你就可以利用这些信息，完成业务逻辑的接口测试了。
+
+## 多个接口串行分析
+
+在质量保障过程中，测试的主要任务，是保障SUT的业务逻辑正确性，而单一接口的测试却很难完成一个业务逻辑，所以，在大部分的测试场景中，我们都需要串行多个接口，才能完成一个完整的业务逻辑。
+
+然而，即使我们按照上述三个步骤完成了全部单个接口的分析，也并不能马上开始进行接口测试。这是因为，一个测试的业务逻辑是由多个接口的串行完成的，而多个接口的串行逻辑是由业务逻辑规定的，因此，多个接口之间并不是随意组合的，而是按照业务逻辑、通过数据传递来完成的。
+
+这其实就和拼图游戏一样，我们有一堆拼图碎片，很多拼图碎片都可以连接到一起，并不会有明显的不适合，但是，依据拼图的最终图形，这些拼图碎片就是不能放到一起。你要想把拼图完成，就不仅要考虑各个拼图碎片是不是可以链接到一起，还要考虑这些碎片放到一起后是不是对原来图形的正确拼接。
+
+那么，你前面整理好的、各个单一接口的信息表，就是拼图游戏里的一个拼图碎片，业务逻辑就是拼图组成的最终图形，而其中的参数，就是拼图碎片的缺口和每一个碎片上的图形。
+
+所以，要想使用接口测试完成业务逻辑，你就要制作一个流程中所有接口的接口信息表，同时，还要理清每一个流程的数据流程，数据流程驱动了业务流处理，这样，才能开始业务逻辑的接口测试。
+
+关于怎么完成一个业务逻辑的接口测试，我会在下一节课中详细的解释给你。
+
+## 总结
+
+好了，今天的内容就到这里了，不知道你是不是已经掌握了分析一个接口并整理接口信息表的方法呢？现在我来总结一下。
+
+在今天的课程中，我带你一起分析了一个理想的提测项目都包含哪些要素，但是，这种乌托邦式的提测项目在现实中却很难遇见。所以，我给你推荐了“三步走”的方法，你可以通过工具辅助、分析问题和询问解惑这三步来建立接口信息表，建立和维护自己的接口知识库。我也通过拼图游戏的例子，告诉你接口测试的业务逻辑验证思路。
+
+随着被测系统的不断迭代，当你不断地按照这个步骤积累起自己的接口知识库时，你就会拥有自己负责的业务线的业务知识积累，变成这条被测业务线的业务专家；同时你也会拥有每一个接口的输入和输出全部参数、每一个业务逻辑的数据流、每一个驱动业务分支逻辑的参数条件，你也会成为接口测试的技术专家，在你自己的工作中变成一个不可或缺的质量保障者。
+
+在一个团队中，有很多时候，测试工程师和开发工程师之间就是一个矛盾的共同体，既相互依存又不可分割，在团队中缺一不可，要想摆脱“测试非技术岗位”的帽子，就需要测试人员有自己的技术功底和技术素养。
+
+无论你在工作中，遇到的是能很好相互支持的开发工程师，还是不好合作的开发工程师，你都要保持自己的技术能力，尽最大努力完成自己能够完成的所有事情，只有这样，你才能提高自己在团队中的话语权。
+
+## 思考题
+
+最后，我想请你来思考一下，你能用本节课讲述的Fiddler还有接口测试分析方法，完成一个你自己项目的老旧接口的分析吗？
+
+我是陈磊，欢迎你在留言区留言分享你的观点，如果这篇文章让你有新的启发，也欢迎你把文章分享给你的朋友，我们一起沟通探讨。

极客时间专栏/接口测试入门课/初级技能篇/03 | 思维方式：用一个案例彻底理解接口测试的关键逻辑.md

@@ -0,0 +1,107 @@
+<audio id="audio" title="03 | 思维方式：用一个案例彻底理解接口测试的关键逻辑" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a1/2b/a1e3e5e90012b07edc08d205ceba8e2b.mp3"></audio>
+
+你好，我是陈磊。
+
+在前面的课程中，我们聊到了如何开始一个接口测试，我相信你一定掌握了整个过程的推进方法，这包括如何分析一个不理想的提测项目的接口，并在自己的能力范围内完善和维护接口文档，最终设计一个流程化接口测试用例。
+
+你还记得这其中的关键点吗？其实就是：
+
+1. 工具辅助。借助一些工具的辅助来完成接口分析。
+1. 分析问题。通过分析接口的访问方式、参数等信息整理出要解决问题。
+1. 询问解惑。针对问题和研发工程师进行沟通，把一些不知道的参数含义、参数取值范围等问题沟通清楚。
+
+那么，这些都准备好后，你又如何通过一个实际方法落地接口测试呢？这里面就涉及到怎么做单接口的接口测试，怎么完成业务逻辑接口测试，以及用什么手段来完成接口测试等问题。接下来我会为你详细解答这些问题。
+
+今天，我会带你一起利用[Postman](https://www.getpostman.com/)这款工具来测一个系统。
+
+简单来说，Postman就是一个HTTP协议客户端工具。但它只是我们完成这次任务的手段，接口测试用例的设计和实现过程才是我今天想告诉你的重点内容，所以，我在这里不会给你讲它的详细使用方法，而是会花更多时间告诉你怎么利用接口测试的思维方式来使用它。你也不用担心，今天我们这节课涉及的Postman的功能都很简单，不会因为你没有基础而显得晦涩难懂。
+
+## 明确被测系统
+
+有了被测系统我们才能开始聊接口测试，但是，目前网络上可以看到的系统例如极客时间的手机应用、百度网站等并不适合做接口测试的讲解，这是因为我们需要知道接口的每一个参数，以及一些接口的处理逻辑。
+
+所以，我给你准备了我自己专门制作的一个小型系统**Battle**，它是一个理想的被测系统，你可以在[GitHub](https://github.com/crisschan/Battle)中下载它的详细系统代码。
+
+我先来简单介绍一下它，它是一个类似回合制的游戏，通过接口测试的方法和服务器发生交互，模拟两个角色进行决斗，最后可以知道到底是谁赢了。详细的说明和代码都在GitHub上，你可以自行查看。除了GitHub上你可以看到的单个接口的说明以外，还有一个就是业务流程，这个系统的业务流程是：**进入系统后，选择武器，然后和你选择的敌人决斗。**
+
+## 开始接口测试
+
+在开始业务逻辑接口测试之前，你要先通过接口测试的方法，测试每一个接口都是正确的，既要保证单接口的正确性，也要保证接口的业务逻辑正确性，这里所说的“正确”指的是“正确接受合法Request入参，正确拒绝非法Request入参”。
+
+### 单接口的测试
+
+单接口测试的重点，其实就是保证该接口的正确性和健壮性，也就是说，你既要保证这个接口可以按照需求，正确处理传入的参数，给出正确的返回；也可以按照需求，正确的拒绝传入非正确的参数，给出正确的拒绝性返回。
+
+现在，我就带你一起使用Postman来检测单接口的测试。
+
+首先，打开Postman，你可以看到它的UI结构很简单，为了可以检测首页接口，你需要设定HTTP的访问方式为GET，URL是[http://127.0.0.1:12356/](http://127.0.0.1:12356/)，点击发送按钮后，就可以在工具下面的Body部分看到接口返回的说明性文本内容了，这个内容是“please input your username(your english name) and password(your english name)”。<br>
+<img src="https://static001.geekbang.org/resource/image/ac/86/ace3d078b5459228043dd7eecd664786.png" alt="">
+
+对于一个GET请求的接口，我们在上面已经完成了单个接口的测试工作。那么接下来，我们就要检测第二个接口：登录接口，它的访问方式是POST，参数是username和password，这两个参数均不可以为空，也不可以超过10个字符；如果username和password这两个字符串相同，会登录成功并返回后续的说明性文本，否则，就会正确拒绝登录。所以在这一步，我们会多检查一项Request的参数设计，用边界值方法设计的参数如下图所示：<br>
+<img src="https://static001.geekbang.org/resource/image/3f/5d/3ff05cc8a18353e991b376449d34cc5d.jpg" alt="">
+
+在获取了参数后，下面你就要借助Postman这个工具，选择Post访问方式，输入登录接口的URL，在Request的Body中输入username=criss&amp;password=criss的参数，然后点击发送，接下来，你就会在Response的Body中对应返回内容。如下图所示：<br>
+<img src="https://static001.geekbang.org/resource/image/47/5a/471dacd98d5ee7f5e714ec42aa4d925a.png" alt="">
+
+按照上面的方法，依次完成剩余两个接口的测试用例设计和测试用执行过程后，你就完成了单个接口的测试工作。
+
+然而完成了这一步，只能算是把接口测试工作完成了一半，另外一半就是要按系统的业务逻辑来完成“正确的流程可以完成处理，不正确的流程可以正确拒绝处理”这个验证。
+
+### 业务流程接口测试
+
+业务流程接口测试，主要是保障通过多个接口的串联操作可以完成原来需求中提出的业务逻辑，这也是它主要关注的内容。
+
+在前面，我已经告诉过你这个系统的主要业务逻辑：“进入系统后，选择武器，然后和你选择的敌人决斗。”
+
+依据上面这种业务逻辑描述，还不能完成业务流程的接口测试，我们需要对其做进一步的分析和细化。依据这个业务需求，至少有下面这几个业务流程：
+
+- 正确登录系统后，选择武器，与敌人决斗，杀死了敌人；
+- 正确登录系统后，选择武器，与敌人决斗，被敌人杀死；
+- 正确登录系统后，选择武器，与敌人决斗，两个人同归于尽；
+- 正确登录系统，选择武器，没有选择敌人，自尽而死；
+- 正确登录系统，选择一个未提供的武器编号，选择一个敌人，自尽而死；
+- 正确登录系统，选择武器，选择一个未出战的敌人（不在返回提示列表中），自尽而死。
+
+那么针对这些业务流程，我们设计的参数如下：<br>
+<img src="https://static001.geekbang.org/resource/image/e5/a4/e50eb34d177c6c22573a4f13235783a4.jpg" alt="">
+
+接着你就可以利用Postman，将过程参数手动传递给下一步接口，这样，你就可以建立一个业务流程的接口测试，并最终完成测试了。Postman也提供了参数化的方法，如果你对此感兴趣，也可以自行学习。
+
+继续按照上面的流程，用Postman将上述其它五个流程完成，你就完成自己的接口测试了。如下图：<br>
+<img src="https://static001.geekbang.org/resource/image/ed/a1/ed82fd824750154617eef7bbe80e08a1.png" alt="">
+
+现在，你已经有五个业务逻辑接口测试用例了，但是通过观察上面的业务流测试，你会不会感觉与你自己平时手动写的业务测试相比，好像少了点什么？
+
+没错，它和业务测试的测试用例相比，确实少了很多异常状况，比如正确登录、正拒绝登录、正确登陆选择的装备参数是字符串等等，这一系的业务流中的反向用例都没有进行验证。
+
+这也是接口测试和业务测试在设计测试和执行测试过程中的差异点，在接口测试中，我们通过单个接口测试完成了全部异常状态的覆盖；而在业务流程中，我们更需要关心业务流和数据流的关系，并不需要再过度关心如何用业务流的方法覆盖更多的代码逻辑异常，这也是分层测试中为什么在单元测试和界面测试之间要加入一层接口测试的主要原因之一。
+
+通过单接口测试，可以更加接近于单元测试；通过业务流的接口测试，可以更加接近于界面所承载的交互中的业务流验证，这也是为什么现在很多人在提倡将测试模型由原来的金字塔形往菱形转变的依据之一了。
+
+**而完成了这一系列流程，其实你也就掌握了接口测试的思维：先从单个接口的测试开始，保障单个接口的正确性和健壮性，然后通过单个接口的测试完成多个接口的业务逻辑串联，站在业务逻辑的角度完成业务逻辑的正确性检测。**
+
+## 你的接口测试也可以和持续集成结合到一起
+
+通过Postman这个工具完成从单接口测试用例的设计到业务逻辑接口测试用例的设计，你就已经掌握了接口测试的思维以及具体的实现方法。但是到目前为止，你还处在手动测试的阶段，虽然已经和以前基于界面的业务测经有了很大区别，但是距离自动化的接口测试还有一定的差距。不过你不用担心，因为这个差距仅仅是一个工具的距离。
+
+我相信你一定听说过持续集成，在持续集成中，有一个很重要的环节就是要持续测试，通过持续集成平台调取自动化测试，完成质量保障工作。现在你已经有了Postman，已经完成了基于Postman的接口测试脚本，那么如何将其赋能给持续集成平台呢？
+
+这里我们要借助Newman这款工具，它就是shell下的Postman，我们将Postman的业务逻辑接口测试脚本导出后，push到本地的Git仓库中，持续集成平台就可以通过pull对应的接口测试脚本，然后通过Newman执行，这样就可以完成持续集成平台的赋能了。
+
+在这里我只提供给你一个思路，具体的完成方式，你可以通过学习持续集成平台Jenkins和Newman运行Postman脚本完成对应的内容。
+
+## 总结
+
+我相信今天的内容你一定可以挪为己用了，如果你和我一起完成了这些操作，同时在课后，你也弥补了我在课上跳过去没有讲到的一些接口测试脚本，那么我相信你现在肯定被成功的喜悦所围绕了。
+
+走到这一步，你已经掌握了接口测试的思维，在这种思维的指导之下，用什么技术手段或者工具去完成接口测试，也就显得没那么重要了，这也是为什么我并没有将Postman这个工具一步一步教你怎么用的原因，因为你既可以选择我推荐给你的Postman，也可以找到一个你自己喜欢的工具或技术方式完成接口测试。
+
+接口测试的执行方式、设计思维都和业务测试不完全一致，它们既有交集又有差异。交集部分是它们都会涉及到业务逻辑测试，但是接口测试更加关注有数据流驱动的业务流程，而不再着眼于代码异常、代码边界等，这些边界问题在接口测试过程中已经由单接口测试完成了。
+
+接口测试在单接口测试的设计思维上也更加贴近于代码的单元测试，但它还是站在Client端的角度来完成测试；而接口测试的业务逻辑测试更加靠近手工业务测试，但却更加聚焦于业务逻辑本身，不再将一些非法业务异常放到该部分进行测试。
+
+## 思考题
+
+今天我并没有将全部测试用例都用Postman完成，那么你自己完成了吗？如果你已经完成了，那么你能用Newman驱动执行单接口测试脚本和业务逻辑测试脚本了吗？如果单接口测试中登录测试用例有一条执行失败了，你可以告诉我是哪一个测试用例吗？
+
+我是陈磊，欢迎你在留言区留言分享你的观点，如果这篇文章让你有新的启发，也欢迎你把文章分享给你的朋友，我们一起探讨和学习。