接口测试 接口测试这么玩才明白

CKL的思考 · 2023年04月25日 · 最后由 CKL的思考 回复于 2023年05月22日 · 16887 次阅读

接口测试作为当下提升测试效能的利器,逐步被大家所认同。但同时很多团队在落地接口自动化时,又会感觉效果不是很明显,投入了大量的时间,写了很多脚本,但是效果并不是很明显。其中有各种问题,结合某团队的现状,分享一些实践经验,仅供参考。

引入接口测试,希望能够解决如下问题:

  1. 突破现有瓶颈,提升测试效能,同时降低人力成本(注意不能把降低人力成本放在核心位置,否则容易适得其反);

  2. 降低人为错误率,规避因为人的疲劳和惯性思维以及投机取巧导致的错误;

  3. 提高测试覆盖率:有些场景通过页面操作难以验证到,需要通过接口的方式来触发,比如一些异步请求、定时任务等;

  4. 适应持续集成与交付:与流水线结合,当研发提交代码时,可以触发接口测试,作为交付质量的一个验证环节;

并不是所有的场景都适合做接口测试,如上图所罗列的 6 种场景,就不适合开展接口测试(不是做不了,而不是合适),强调下第二点,对于一些业务规则特别复杂的场景,接口测试是满足验证的,例如优惠券的选择使用,接口仅能验证券能使用,但是是否是最优组合,需要通过结合业务规则在前端验证,或者通过固化测试数据来做自动化验证(类似模型测试中的标注法,有机会另分享)

接口测试也不是什么银弹,很多团队认为引入自动化测试,就能够解决当下的问题,其实并不是这样的。重点澄清以下几点:

  1. 为了自动化而自动化:如上文提到的不适合接口测试的场景,就没必要强行为之,不要为了追求测试覆盖率而做自动化;

  2. 发现不了 BUG:接口测试本身是适用于回归测试,并不适用当前迭代的新内容,所以不要期望接口测试能发现大量 BUG,如果真出现这种情况,反而需要反思和检查;

  3. 能够快速提效:从短期(当个迭代周期)来看,接口测试反而是降效的。因为它需要更多的投入,但是从更多的时间维度来看,它才能提效。

接口测试用例也是需要经过设计的,而不是简单的接口堆砌,需要遵循基本的分类和设计原则,如上几图所示,比较清晰,不再赘述。

断言的设计是接口测试有效性的基本保障,没有断言、断言不合理的接口用例,写得越多,跑得越多,死得也就越快,希望大家能够重视。Http 状态码是替代不了断言的。

光有理论,没有案例是不行的,在分享的时候给出了 8 个常见错误案例和 1 个优秀案例。

由于篇幅原因,文末可下载完整 PPT 查看

所有的知识认知都会经历如上曲线。以接口测试为例,当我们刚接触的时候,可能会处于 A 点,感觉引入接口测试,就能解决大部分的问题,容易产生过高的期望值(特别是管理层,需要做好预期管理)。

团队在实践一段时间的接口测试时,由于落地方法不对、时间投入不足、维护成本高等问题,感觉接口测试也没什么用,进入低潮期。

经过实践,找到正确的方法,重新认知,又会走上正轨。毕竟这条路是行业大多数团队实践并取得成功过的,它一定能解决某些问题。

最后,组织和个人对于接口测试的诉求也是不一样的。越来越多的团队采用统一的测试平台来管理接口测试,因为团队希望得到标准化、可视化的数据沉淀。

而对个人来说,使用平台,可能会失去一个提升代码能力的机会(接口测试平台的实践是测试人员锻炼代码能力的重要路径),其实并不是,作为个人,应该抓住机会去了解平台的具体实现,甚至参与到平台的研发过程中,把别人的开发设计和解决问题的思路变成自己的心得体会。

关注并在公众号回复 “接口”,可获得本文完整的 PPT。因为做了脱敏处理,所以样式有点不好看,请见谅

共收到 13 条回复 时间 点赞
仅楼主可见
仅楼主可见

这个分享,解决了我计划分享的内容,可以偷个懒

tangoliver 接触接口自动化测试半年的感悟 中提及了此贴 04月27日 09:31
仅楼主可见

大佬厉害

9楼 已删除

谢谢大佬分享,对接口测试理解又深了一点

仅楼主可见

公众号多少,求关注

厉害了

仅楼主可见
仅楼主可见
CKL的思考 接口自动化不是救命稻草 中提及了此贴 11月15日 18:57
CKL的思考 接口自动化不是救命稻草 中提及了此贴 11月15日 18:57
CKL的思考 2023,悄然流逝,留下点什么 中提及了此贴 01月02日 09:52
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册