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调用结果查询接口就可以拿到用例集的测试报告。
在这里还是要推荐下我自己建的软件测试学习Q群: 746506216，群里都是学测试的，如果你想学或者正在学习测试，欢迎你加入，大家都是测试党，不定期分享干货（只有软件测试相关的），包括我自己整理的一份2022最新的Python自动化测试进阶资料和零基础教学，欢迎进阶中和对测试感兴趣的小伙伴加入！