如何设计接口测试
优秀的后端测试开发最基础的素养就是懂得如何设计接口测试用例。下图简述了如何做好接口测试。本文不做展开
接口测试痛点
测试数据难准备 – - 定制数据复杂且庞大，测试场景更是千变万化，测试场景难以穷举
测试数据难维护 - - 同样是因为定制数据的复杂性，新功能迭代会导致原有case预期不正确，且输入数据需要同期更新。可能某一个字段的小改动，会导致80%以上的接口失败。这就表明这些测试数据的生命周期可能就只有一个礼拜，但是测试却需要花上可能一天的时间更新用例。case越多，时间成本越高。投入产出比不成正比
测试结果校验不精准 – - 一般简单的数据校验 ，可能是针对测试场景中的测试结果数据中的某个字段进行比较，或者测试数据全量校验，但是定制结果相同请求很可能每次的请求结果都不一致。这就要求我们去做json降噪处理，从而达到正确比对测试结果。
测试结果同开发沟通不方便 - - 接口测试数据展现会是某个body，body内容是纯json文本。很难通过body去全面的认识该case的测试场景。只是单纯的将比对结果告知开发，复现问题会比较麻烦。
接口测试不同阶段的表现
测试数据准备
测试数据维护
测试结果校验
测试结果同开发沟通不方便
让开发下载接口测试代码测试？---- 不太现实，繁琐且效率低
对比结果截图甩给开发？---- 可能比较懵逼，不知道如何复现问题
将对应接口，请求参数，以及测试结果和预期结果，通通发给开发？---- 数据都有了，就是自己累得慌。CV太多次也是体力活
tips：
1、使用一些小的工具，自动上传测试结果至oss
2、将测试数据作为存在模型或者方案中，甩个模型&方案链接
3、维护一个公共区域，记录接口测试变更。沟通可在该文档反馈
定制接口测试是如何做的
案例：
1、如编辑器modeleditor服务3D接口改造
3D接口作为定制编辑器modeleditor服务中预览接口，其承载了编辑器中几乎所有数据，该接口若存在问题，其模型将无法构建。保障该接口的正确性即保证了建模过程中80%以上操作的正确性。
改造前：通过从编辑器前端直接获取3D请求的数据，存入到接口测试的post body数据中，每次数据（新增减少字段，修改数据结构）的变动都会造成body数据不可用，或者数据不够新，测试结果也不可完全信任
改造后：通过维护模型去维护接口数据，将所需要的场景数据直接保存到模型中，再通过打开模型，获取3D接口中的Editordata获取所需要的body数据，改造后可直接作为3d接口的发送数据。再将获取到的结构同上一次稳定版本比较，得到变动内容，看是否符合预期。
2、parameter-model包拆分测试
parameter-model包拆分包含底层数据的变更和改动，定制服务一半以上都依赖该包，其涉及相关服务广，范围大，牵一发而动全身。要做到前端无感知拆分，这就必须保证后端提供给前端的数据结构的一致性。简单的API返回数据的校验无法满足测试需求。因而采用对象层级的校验、在内存中对model层数据进行全量校验，保证拆分前后各对象的一致性。
测试结果：
上面是我收集的一些视频资源，在这个过程中帮到了我很多。如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们群【902061117】，里面有各种软件测试资源和技术讨论。
当然还有面试，面试一般分为技术面和hr面，形式的话很少有群面，少部分企业可能会有一个交叉面，不过总的来说，技术面基本就是考察你的专业技术水平的，hr面的话主要是看这个人的综合素质以及家庭情况符不符合公司要求，一般来讲，技术的话只要通过了技术面hr面基本上是没有问题（也有少数企业hr面会刷很多人）
我们主要来说技术面，技术面的话主要是考察专业技术知识和水平，上面也是我整理好的精选面试题。
加油吧，测试人！如果你需要提升规划，那就行动吧，在路上总比在起点观望的要好。事必有法，然后有成。
资源不错就给个推荐吧~