《接口测试入门》 学习笔记
接口测试为什么重要？
“测试要尽早介入，测试进行得越早，软件开发的成本就越低，就越能更好地保证软件质量。”
测试金字塔模型
你可以看到，单元测试在测试过程中，占据了绝大部分的比重，这表示单元测试需要你投入更多的时间和人力成本。但是，单元测试并非测试工程师的本职工作，它属于开发工程师的工作范筹。说到这你可能会问了：“如果开发工程师从来不写单元测试怎么办？”毕竟大部分开发人员都不爱写测试。
其实，我也会问自己这个问题。不可否认，开发工程师不只很少写单元测试，更很少写出好的单元测试代码，很多时候，工期的压力让他们放弃了单元测试。
但是，一个产品的交付质量更多时候却是由测试工程师来保障的，面对这一实际现状，我们又该怎么办好呢？我们聪明的测试工程师提供了两种解决手段：一种是用一些智能化框架补充单元测试工作（如果你对智能化单元测试感兴趣，可以参考我在 2019 年 TiD 上的演讲内容“自动的自动化测试智能化一站式 API 测试服务”）；另外一种，就是加大我们自己主导的接口测试的工作投入比重，来弥补单元测试的不足，这样，上面那个金字塔模型就会逐渐演变成菱形模型。
那之所以出现从“金字塔模型”到“棱形模型”这种变化，并不是有人刻意提高测试工程师在整个交付流程中的地位，这其实是随着工作的不断进行，逐渐形成的结果。
在质量保障过程中，我们的测试工程师会不断增大接口测试的测试深度和测试广度，往下逐渐覆盖一些公共接口的单元测试内容，往上则逐渐覆盖应该由 UI 层保障的业务逻辑测试，这么做的主要目的，就是为了更好地完成质量保障工作，交付一个可靠的、高质量的项目。
所以，从接口测试这一环节开始，测试工程师就变成了质量保障工作的主要推动者，接口测试也变得愈发重要。
那它有什么好处和优越性呢？我觉得可以从下面这 3 个角度来看：
接口测试更容易和其他自动化系统相结合；
相对于界面测试，接口测试可以更早开始，也可以测试一些界面测试无法测试的范围，因此它使“测试更早的投入”这句话变成现实；
接口测试还可以保障系统的鲁棒性，使得被测系统更健壮。
现在，我相信你已经意识到接口测试在质量保障中的重要地位了，那么，你知道究竟什么是接口吗？接口测试又在测些什么呢？我们又为什么要做接口测试呢？
下面我就逐一把这些讲解给你。
接口是什么？
接口就是有特定输入和特定输出的一套逻辑处理单元，而它不用知道自身的内部实现逻辑，这也可以叫做接口的黑盒处理逻辑。
由于服务对象不同，接口又可以分为两种，一种是系统或服务的内部接口，一种是外部依赖接口。
内部接口简单来说，内部接口就是系统内部调用的接口。
在软件系统中，内部接口是怎么一回事呢？其实，你在网上购物时，要先登录系统，然后将商品加入购物车，再接下来支付订单。那么，从添加商品到购物车，再到支付订单，这一长串的流程之间，就是通过系统内部接口来完成的。
在系统上，外部接口又是怎么回事呢？你在购物后点击付款时，页面会跳转到支付系统，等你完成支付流程后，再跳转回订单页，在这样的流程中，都会涉及系统对外的接口，还有，比如说付款工程的支付接口、配送过程的物流接口等等。
现在我来总结一下接口的本质，它其实就是一种契约，遵循这样一种形式：在开发前期，我们约定接口会接收什么数据；在处理完成后，它又会返回什么数据。
如果调用方和被调用方都遵从了这种契约，那么就可以达到共同开发的目的，开发完成后，联调完成系统逻辑的前期预期，提高研发效能。
接口测试其实就是模拟调用方，比如 Client 端，通过接口通信来检测被测接口的正确性和容错性。
在测试手段上，接口测试算是技术驱动和业务驱动双管齐下的工作（界面测试却是业务驱动为主的工作），因此，你需要借助一定的工具来完成它。这个工具既有可能是成熟的工具，也有可能是你自己写的代码，因此，测试技术会在接口测试阶段，变得和业务知识一样重要。
在工作范围上，接口测试影响的范围会更广一点，它会覆盖一部分单元测试的内容，也会覆盖一部分业务测试的内容，但是，无论是哪一部分的内容被它侵占，相对应部分的工作投入其实都减少了。
你也有可能记住的并不多，但我希望下面这三点你一定要烂熟于心：
接口测试是通过设计输入和预期输出来完成测试验证的，你之前掌握的测试用例设计方法等测试基本功，在这里还是有用武之地的；
接口测试是一个技术知识和业务知识相结合的工作，可以更好地提升你自己的技术实力，让那些说我们是“点工”的人早早闭嘴；
接口测试也是功能测试，要说有和界面测试不同的地方，仅仅是和我们交互的，不再是开发工程师设计的界面，而是测试工具或者代码。在很多人眼里，接口测试是技术，业务测试是业务，但它们其实是不可分割的。
不同协议形式的测试
HTTP 协议的接口
RESTful 格式的接口
WebService 的接口
RPC 协议的接口
其实无论是哪一种形式的接口，它们都是通过某一种传输协议，在 Client 端和 Server 端之间来完成数据传递的。
假如测试的是 Web 端网站，那么 Client 端就是浏览器，Server 端就是 Web 服务，那么浏览器和 Web 服务之间，就是通过 HTTP 协议传输的；
测试的是移动端的 app，那么 Client 端就是你的设备上安装的极客时间应用，Server 端就是 RESTful 格式的接口服务，那么极客时间的应用和 RESTful 格式的接口服务，就是通过 JSON 格式的数据来传递的。
结论：接口测试其实就是模拟调用方，比如 Client 端，通过接口通信来检测被测接口的正确性和容错性。
一个理想的提测项目
一个理想的提测项目，在提测的过程中应该既包含前期参与的产品需求、原型设计，这些是由产品经理来提供的；也包含后端接口文档、代码单元测试脚本，这些是由开发工程师提供来的。它们都是你开展测试的必要输入内容，具体有这些作用：产品需求。它描述了系统的业务逻辑，通过这个文档，你才能知道怎么来设计测试用例；原型设计。它会更加直观地告诉你系统的使用逻辑，这对测试用例的设计、对系统的前期认知都是有辅助作用的。接口文档。它详细地描述了后端接口的访问方式和参数说明，使用这个输入项才能开展接口测试用例的设计、测试脚本的准备和测试数据的构建。单元测试脚本。它是保障提测质量的必要环节，是研发工程师自测的一个有效手段，可以保障提测项目的提测质量。
如果开发工程师没有给我们任何有价值的文档，那么要开始接口测试，你可以通过工具辅助、分析问题、询问解惑这三个步骤来完成。
具体的工作模式如上图所示：借助一些工具的辅助来完成接口分析；通过工具截获一些接口信息；通过分析接口的访问方式、参数等信息整理出一些问题，和研发工程师沟通这些问题，将一些不知道的参数含义、参数取值范围等问题问清楚。
工具辅助
postman，fiddler , jmeter
分析问题
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，它表示接受的语言。
询问解惑
针对每一个参数，你都要从下面的几点详细询问，并保证你已经真的理解了这些内容。那么，都询问些什么呢？我认为主要有三点。
参数的含义以及来源
你要搞清楚每一个参数的含义，也就是这个参数对应的实际自然语言的名字，通过记录每一个参数的中文语义，也会让更你容易记住这个函数是干什么的。同时，你也要知道这个参数的赋值是从哪里来的，是从其他页面的返回值中得到的？还是 JS 生成的？如果是其他页面或者接口返回的，那么，是哪一个接口返回的哪个字段？这样，当你开始做接口测试的时候，你就知道去哪里拿到这个参数的赋值了。如果是另一个接口的返回字段，那么，你还需要维护一份返回该参数接口的接口信息文档，以便于自己下一次创建对应的参数，如果不可以创建，那么你就要知道这个参数的生成规则，也要知道如何手动构造它。
参数的作用域
参数的作用域指的是这个参数在这个接口中是做什么用的，它在哪一个访问周期里是一直存在的，它是否导致了业务逻辑分支等。比如说，这个参数是用来验证用户权限吗？它的验证算法是什么？之所以要搞清楚这些内容，是为了你在做接口测试的时候，可以设计更小的参数组合来覆盖更多的业务逻辑，这是测试用例去除冗余的一个很好的方法。
返回值的含义。针对上面一大串的返回 JSON，你要搞清楚在返回值中，每一个 JSON 的 Key 所对应的含义，这样，当你需要和这个接口产生交互的时候，就可以快速地拿到对应参数的含义，完成业务逻辑上下文的参数串联了。
总地来说，Request 的全部参数和 Response 的全部参数对于接口测试来说，都是必要的输入项，因此我们有必要花费很多精力完善并且留存它们。
多个接口串行分析
在大部分的测试场景中，我们都需要串行多个接口，才能完成一个完整的业务逻辑；多个接口之间并不是随意组合的，而是按照业务逻辑、通过数据传递来完成的。所以要完成整体业务逻辑的接口测试，需要理清每个流程的数据流程，而数据流程驱动了业务流处理.
彻底理解接口测试的关键逻辑
单接口的测试
单接口测试的重点，其实就是保证该接口的正确性和健壮性，也就是说，你既要保证这个接口可以按照需求，正确处理传入的参数，给出正确的返回；也可以按照需求，正确的拒绝传入非正确的参数，给出正确的拒绝性返回。
业务流程接口测试
业务流程接口测试，主要是保障通过多个接口的串联操作可以完成原来需求中提出的业务逻辑，这也是它主要关注的内容。
在接口测试中，我们通过单个接口测试完成了全部异常状态的覆盖；而在业务流程中，我们更需要关心业务流和数据流的关系，并不需要再过度关心如何用业务流的方法覆盖更多的代码逻辑异常，这也是分层测试中为什么在单元测试和界面测试之间要加入一层接口测试的主要原因之一。
通过单接口测试，可以更加接近于单元测试；通过业务流的接口测试，可以更加接近于界面所承载的交互中的业务流验证。
先从单个接口的测试开始，保障单个接口的正确性和健壮性，然后通过单个接口的测试完成多个接口的业务逻辑串联，站在业务逻辑的角度完成业务逻辑的正确性检测。
如何把流程化的测试脚本抽象为测试框架？
用什么工具或代码解决测试问题并不重要，拥有接口测试思维才更重要。
希望你记住从测试脚本到测试框架的转化过程：不断撰写测试脚本，所有的抽象和封装都是站在已有的测试脚本基础之上的；多观察已经写好的测试脚本，找出其中的重叠部分，最后完成封装；以上两步是一个不断循环又循序渐进的过程，你要在你的工作中始终保持思考和警惕，发现重复马上进行框架封装。
版权声明: 本文为 InfoQ 作者【骆俊】的原创文章。
原文链接:【http://xie.infoq.cn/article/2d1df600ecb8ec7755458379f】。文章转载请联系作者。
还未添加个人签名 2017.11.30 加入
还未添加个人简介
评论