最近,小编身边有人提出一个问题:
背景
公司的接口自动化是从开发提测的时候开始用例设计开发的(因为我们公司没有接口文档,只能等开发完成后自己抓包),也就是接口自动化开发和功能测试是同时进行的,等功能测试快结束之后接口自动化开发才结束。这样的情况导致接口自动化只能用作回归,开发也不太认可自动化接口的测试结果。我们自动化部门也觉得耗费了半天时间但是没有太大的成果。
问题
接口自动化什么时间介入比较好?我看了好多文章,目前有接口规范的有在接口规范定好之后介入的,有在前后端联调的时候进行的(这种方式也是我们公司有可能实现的)
前期是先进行单接口测试然后再根据每个场景使用接口进行组装吗?目前我们公司直接进行的业务流测试,没有进行单接口测试。哪种方式比较合理?
能说下大家所在公司的接口自动化整个流程是什么样的吗?
观点一
接口文档,很重要,如果没有接口文档,前端是怎么对接的?
接口测试,不同公司,执行情况可能不同;
第一种,接口开发完,交给测试进行接口测试,后面,前端就可以直接使用接口,测试等功能稳定后,再进行接口自动化;后端开发完,会有接口出来,单接口,测完,会进行业务测试,就涉及到多接口。
第二种,接口开发完,后端自己测试,并通知前端,前端跟后端进行联调对接,直到接口符合前端需求,前端开发完功能后,测试人员进行功能测试,同时进行接口自动化;
你可能是属于第二种,在你项目的功能开发完,其实,接口已经对接完了,所以,接口自动化,只是起到一个冒烟测试的作用吧。
我们都是用 postman 或者 jmeter;
单接口:针对单个接口,进行测试,主要是参数校验,数据校核,比如,用户管理,单接口,就有,新增用户,删除用户,修改用户;
多接口:针对多个单接口,进行串联测试,比如:新增用户之后,修改这个用户,再删除这个用户,还可以给这个用户设置角色,设置职位,设置密码,,这些都是属于业务测试,也就是多接口测试,主要就是会对同一条业务数据,进行多接口串联测试;
使用 jmeter 或者 postman 就能够实现了,并且这两个工具,都可以做自动化。
观点二
我们是接口自动化由开发实现(在联调完毕后),实现测试左移,如果我们介入的话最少也要在提测之后才能介入时间会过晚。
针对第二点,很少会针对单一接口进行测试,都是先梳理好自动化测试场景评审完毕后,根据场景来组合接口测试。
观点三
1.什么时候介入,对于没有特别规范的接口文档输出的或者接口变更比较频繁的,实践出来比较好的时间点是在开发集成的后半段介入,在开发转内测前完成效果较佳。集成后半段基本该改的接口会改的差不多,变更不会那么大,接口文档可以通过工具类生成,因为有代码了。
2.单接口的测试建议可以工具化实现或者由开发实现,测试重点做场景化接口测试。
其他观点
1.接口自动化本身定位就偏向用于回归测试吧,功能测试过程中单接口测试才是重点,在开发环境通过接口自动化来验收本身就是一个成本不低的做法,个人看法。
2.第一次完整的接口测试有用,测试过的接口再做接口自动化没有意义,但是接口自动化升级改造为压力测试就有用了
3.在明确业务后进行;根据实际情况,我们就是先单接口,再流程;和功能测试一样,没啥特别流程。
4.自动化测试本来的定位就是偏向于回归和历史版本的验证。 跟随迭代进程,可以做接口测试 而不是接口自动化测试。 承对于不稳定功能的自动化落地成本太高了
5.怎么使用,主要取决于你们的使用,接口测试包含输入参数的测试、字段必填的测试、多接口等等,如果用来回归,那偏向多接口,如果是保证测试左移,那就要设计更多的用例。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取