共计 1891 个字符，预计需要花费 5 分钟才能阅读完成。
文章起源：本文节选自 TesterHome 社区爱好者合力编写的《2021 接口测试白皮书》。
01 Why 接口测试
一、提高效率
关键词：QA 职责保质保量的实现需要测试工作 在保证质量的前提下提高效率，要保证质量，首先须要先弄清楚这次需要的测试范畴，针对性的应用不同的测试方法，而接口测试就是其中的一种；保障效率，降本增效是一个老成长谈的话题，也是 QA 始终的谋求，推动技术自测是一个形式，应用自动化代替人工也是一个形式，但不论哪种形式，都须要保障业务主流程的正确执行，而自动化就是解决这个问题的。
二、减少对业务的了解
关键词：分明需要的目标和技术实现计划
近期高频词：测试左移。
在需要立项的时候，就去理解需要的目标，从 QA 角度给出倡议；同样的技术计划评审时，QA 也须要从本身角度登程，从风险意识登程，指出技术计划上可能存在的问题，如果 QA 一点不理解技术，在技术评审时，就会无从下手。
关键词：与 RD 建设共同语言
交换的前提是：须要有共同话题。当 RD 说的细节你都不懂时，RD 就会说“就这样测就行了，你依照我说的做吧”——QA 就处于一个被动的位置了。印象粗浅的一件事，一个共事指出了 RD 代码上逻辑的谬误，从此之后推动一些事件就会特地顺利。
三、投入产出比拟高
从自动化金字塔来看，接口测试算是投入产出比拟好的一个形式.
02 How 怎么做？利用机会
一、需要测试过程中
1.1 中台自身须要对接很多业务方，有些需要业务方的开发工作量会很大，中台只须要做一些配置或者很少的代码开发工作。这个时候，如果中台的 QA 也追随业务侧的测试排期，就会存在资源分批不合理的状况。接口测试就能够肯定水平上解决这个问题。中台 RD 提测后，中台 QA 实现接口测试；业务 RD 提测时，中台 QA 只须要配合业务 QA 进行测试就能够了；
1.2 大我的项目的周期会很长 ，而这个时候，测试人员个别也会是多人参加，如果流程不通，影响的就是单个工夫 x 人员个数。目前有些业务正在履行的就是联调期间，QA 进行接口测试；提测后，进行功能测试。这样能够保障主流程是通的，QA 也能够更快的进入状态。 二、需要上线后，补充用例 自动化场景用的最多的还是流程回归和监控，隔一段时间进行业务梳理，并以文档和自动化用例的形式积淀下来是惯例的做法。
03 需要测试过程中
以 XXX 我的项目为例进行介绍，XXX 业务线新增回收业务模式，于订单侧来说须要新增业务线 id、并配置状态机等改变较少，业务方须要做大量开发工作。
04 性能拆解
UI 交互：不波及 功能测试：业务侧测试 接口测试：订单创立，订单状态流转 埋点：无 性能回归：无，新增业务线
05 技术评审
重试弥补机制 参数校验等异样场景
06 接口用例设计
新建、流转、重试、幂等，
接口测试理论状况举例：
07 接口测试的实现形式
一、应用 RD 单测代码
存在以下弊病：
治理不不便
不能在其余工程复用
不能提交到 gitlab
二、投入人力编写自动化用例
三、自动化测试平台
二、三 比照如下：
应用平台，缩小了编码之外的反复工作，用例能够自在拼装，不会存在人员 交接后，之前的代码就废除的状况。
08 APITest 接口测试平台
两个入口：需要维度、工程维度，别离解决需要测试中和服务上线后，补充用例两种场景。
举例：需要入口
要想做好接口测试，就不能把接口孤立起来。业务场景上，也是接口、mq、sql 语句、redis 等串联起来的。独自的接口测试，只能笼罩孤点，不能笼罩整 个流程。要想做好接口测试，接测试平台就须要把用到的工具放在一个立体上。目前 apitest 的思路如下 为一个用例，用例汇集起来就是用例集。
09 测试汇合示意图
用例依照在用例集中的程序顺次执行，目前还不反对单个用例失败就中断整个用例集。
10 参数化
提到自动化，就会遇到参数传递的问题。各个公司的 qa 因为接触的工具不 一样，思路也会不一样。apitest 是应用 jsonPath 解析入参和出参的形式，让数据能够在用例之间流动。
11 断言
apitest 也是同样应用 jsonPath 进行后果的解析，来进行断言的。
12 测试报告
测试报告如下，分为两个局部：总览和详情。总览展现用例集维度的信息，详情展现单个步骤的执行后果和断言后果。
13 Beetle 联动
用例集的触发反对两种形式：定时执行、触发执行。定时执行不再详述，触发执行借助 beetle 的被动调用，apitest 会返回惟一执行记录 id，后续 beetle 调用后果查问接口就能够拿到用例集的测试报告。
下集预报：转转交易业务场景接口测试实际
本文节选自 Testerhome 社区爱好者合力编写的《2021 接口测试白皮书》，点击链接可查看并下载完整版《2021 接口测试白皮书》。