接口测试 各位大佬,接口测试是否要尽量覆盖所有业务呢?

逗爸比 · 2021年02月07日 · 最后由 小狄子 回复于 2021年02月18日 · 933 次阅读

我们目前做的接口基本都是单接口测试,没有根据业务场景来做,因为如果那样接口测试就会变的复杂,维护成本也会变的很高。在很多公司做接口测试的基本就 1 个人,大批量的业务用例转换成接口用例显得有些吃力。但一直单接口的话也显得有些单薄。不知各位大佬平时都是怎么做接口测试的。希望可以指点一二。

目前有将近 100 个接口,我把接口和接口需要的数据(如:参数或 body)都写在 excel 里了,执行的时候依次读取执行,当然这 excel 中也有先后顺序之分并且后一条也会用到前一条返回的数据。

共收到 7 条回复 时间 点赞

我是写成自动化脚本

可以找一些 T0 级别的场景做一些冒烟 和 CI 挂钩,每次版本构建直接跑一次作为版本构建是否成功的标准

单接口测试说实话意义不大 1.无法覆盖真实业务 2.数据 hardcode,如果数据要动态,其实就是已经实现业务场景了

1、单接口测试,很难发现上下游关联问题,覆盖业务流程很有必要
2、重复性工作,考虑自动化,现在不掌握点接口自动化,很容易被汰换

换个角度,各种业务场景,还是由各种接口、异步消息、定时 worker 等组成的,最终还是会落到某个具体的方法上,那么你接口覆盖的情况足够多,场景还怕没覆盖完么~(当然异步消息你的自动化需要自己来生成这个消息来验证)

看哪种接口,原子化接口其实没啥业务可言。

可以通过集成测试来覆盖业务。

接口测试一般来说会有以下几个针对性的目的,要看题主的目的是什么了。
1.接口通,一般指的是 http 请求返回 200,可以代表系统已经正常运行了
2.接口的要求字段填写了正确/错误数据,返回了期望的结果,代表接口实现了预期的业务功能
3.接口的字段增加或缺失,程序正常响应了 (比如返回错误代码和错误信息,内容为 xxx 字段必填等),并且不影响下次请求,代表接口的数据检查&校验是生效的
等等
主要看测试的目的了,不同的目的有不同的测试策略和方法。
接口测试可以尝试一下 fit2cloud 的 metersphere https://www.fit2cloud.com/metersphere/index.html

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册