这样的好处就是可以让server人员能够腾出更多的精力去关注服务端数据交互,包括服务端性能
而前端人员将会把更多的时间节省在对前端展示的关注上。
并且随着前后端分离的流行,越来越多的接口相关问题也就随之产生,比如:学生就遇到这样一个问题,面试的过程中问到你们当时的接口有多少?

那么这道问题,该怎么回答呢?
有人会说几十个?几百个?

其实这些回答都不会抓住面试官的心。
这道问题一般可以按照这样一个思路进行拆解。
回答方式一:针对这些做过接口自动化的人群
答案借鉴,我具体也记不清楚我们当时有多少接口了,但是我记得我做的接口自动化里面大概写了几百个case。
回答策略其实是侧面的让面试官通过我曾经做过接口自动化的工作量来对我测试的接口工作量有一个大致的认知。
回答方式二:必须对接口测试流程必须很熟悉的人群。
我们当时的接口大概有100多个,具体记得不是很清楚。
因为项目是敏捷迭代开发的。
所以,有的时候迭代新功能会有新增的一些接口(少的时候,可可能就3-4个,多一点10几个,甚至也是有的),包括有的时候还要对变动的老接口进行修改,所以具体的数字记得不清楚了。
一般情况下我们都知道整个团队的流程一般是需求评审,评审完成之后,开发编写开发计划,同时测试编写测试计划,开发编写完开发计划之后,进行数据库的设计包括接口的设计和文档输出,所以有的时候其实接口的数目跟业务的大小有一定的关系,拿订单的业务来说:
一个订单模块的业务,至少要包含:
新增订单------新增订单接口
修改订单------修改订单接口
删除订单------删除订单接口
订单列表------查询订单接口
这不就一个模块的增删改查接口4个出来了。
以此类推,跟面试官解释下你这块数据的依据,这样才会有数据,并且对数据的多少有一些支撑性的说明。