接口测试作为当下提升测试效能的利器，逐步被大家所认同。但同时很多团队在落地接口自动化时，又会感觉效果不是很明显，投入了大量的时间，写了很多脚本，但是效果并不是很明显。其中有各种问题，结合某团队的现状，分享一些实践经验，仅供参考。
引入接口测试，希望能够解决如下问题：
1. 突破现有瓶颈，提升测试效能，同时降低人力成本（注意不能把降低人力成本放在核心位置，否则容易适得其反）；
2. 降低人为错误率，规避因为人的疲劳和惯性思维以及投机取巧导致的错误；
3. 提高测试覆盖率：有些场景通过页面操作难以验证到，需要通过接口的方式来触发，比如一些异步请求、定时任务等；
4. 适应持续集成与交付：与流水线结合，当研发提交代码时，可以触发接口测试，作为交付质量的一个验证环节；
并不是所有的场景都适合做接口测试，如上图所罗列的6种场景，就不适合开展接口测试（不是做不了，而是不合适），强调下第二点，对于一些业务规则特别复杂的场景，接口测试是满足验证的，例如优惠券的选择使用，接口仅能验证券能使用，但是是否是最优组合，需要通过结合业务规则在前端验证，或者通过固化测试数据来做自动化验证（类似模型测试中的标注法，有机会另分享）
接口测试也不是什么银弹，很多团队认为引入自动化测试，就能够解决当下的问题，其实并不是这样的。重点澄清以下几点：
1. 为了自动化而自动化：如上文提到的不适合接口测试的场景，就没必要强行为之，不要为了追求测试覆盖率而做自动化；
2. 发现不了BUG：接口测试本身是适用于回归测试，并不适用当前迭代的新内容，所以不要期望接口测试能发现大量BUG，如果真出现这种情况，反而需要反思和检查；
3. 能够快速提效：从短期（当个迭代周期）来看，接口测试反而是降效的。因为它需要更多的投入，但是从更多的时间维度来看，它才能提效。
接口测试用例也是需要经过设计的，而不是简单的接口堆砌，需要遵循基本的分类和设计原则，如上几图所示，比较清晰，不再赘述。
断言的设计是接口测试有效性的基本保障，没有断言、断言不合理的接口用例，写得越多，跑得越多，死得也就越快，希望大家能够重视。Http状态码是替代不了断言的。
光有理论，没有案例是不行的，在分享的时候给出了8个常见错误案例和1个优秀案例，由于篇幅原因，不在文章中放出，文末可下载完整PPT查看。
所有的知识认知都会经历如上曲线。以接口测试为例，当我们刚接触的时候，可能会处于A点，感觉引入接口测试，就能解决大部分的问题，容易产生过高的期望值（特别是管理层，需要做好预期管理）。
团队在实践一段时间的接口测试时，由于落地方法不对、时间投入不足、维护成本高等问题，感觉接口测试也没什么用，进入低潮期。
经过实践，找到正确的方法，重新认知，又会走上正轨。毕竟这条路是行业大多数团队实践并取得成功过的，它一定能解决某些问题。
最后，组织和个人对于接口测试的诉求也是不一样的。越来越多的团队采用统一的测试平台来管理接口测试，因为团队希望得到标准化、可视化的数据沉淀。
而对个人来说，使用平台，可能会失去一个提升代码能力的机会（接口测试平台的实践是测试人员锻炼代码能力的重要路径），其实并不是，作为个人，应该抓住机会去了解平台的具体实现，甚至参与到平台的研发过程中，把别人的开发设计和解决问题的思路变成自己的心得体会。
关注并在公众号回复“接口”，可获得本文完整的PPT。因为做了脱敏处理，所以样式有点不好看，请见谅。
