什么是接口?
想要了解这个概念,我们先从日常生活中常见的事物说起。举个例子:汽车加油。加油员在控制面板上输入要加多少钱的油,然后用加油枪向油箱续油,当加满时,油枪拨片回弹,不再加油,加油完成。其中加油枪枪口与油箱口是不是接口呢?传输中的汽油是不是某种意义上的“数据”呢?控制面板输入的金额是不是所谓的“输入参数”呢?油枪拨片回弹,不再加油,是不是返回的“状态”呢?加油完成是不是最后返回的结果呢?
输入、输出、反馈
又举个例子:每天我们都会使用插座,给手机充电或者插座上接插座等。插座有2孔的,也有3孔的,3孔插头就不能插2孔插座,2孔插头可以插3孔插座。其中的限制是不是对规则的校验呢?
规则校验
再举个例子:A拨打电话给B,A等待B接通,B拿起电话,电话接通,A开始说话。有来有往,像极了TCP协议(三次握手)。这又是不是可以诠释接口的协议呢?
协议标准
我们再聊聊编程语言中接口:interface
Interface中文名为接口,该接口在Java编程语言中是指一个抽象类型,是抽象方法的集合。通常以Interface来声明,一个类通过继承接口的方式,从而来继承接口的抽象方法。接口不是类,虽然编写接口的方式和类很相似,但是它们属于不同的概念。类描述对象的属性和方法。接口则包含类要实现的方法。接口无法被实例化,但是可以被实现。一个实现接口的类,必须实现接口内所描述的所有方法,否则就必须声明为抽象类。
所以接口其实就是处理数据的载体,会有入参、出参、状态、规则检验、逻辑处理以及标准协议。API接口是一种传输或操作数据的方式,广泛应用与APP、服务器、WEB等,适用于数据的获取、更新、删除以及其他操作。
接口的分类?
1、系统与系统之间的接口
既可以是公司内部不同系统之间调用的接口,也可以是不同公司不同系统之间调用的接口
2、下层服务对上层服务的接口
应用层->service->DB
3、服务与服务之间的接口
Service->Service->Service
接口测试所处的层次?
测试金字塔的概念基本观点是:我们应该有更多低级别的单元测试,而不仅仅是通过用户界面运行高层端对端的测试。意思就是说我们应该更多在代码层面进行最小规模的单元测试,并不是一味地只是通过用户界面去做手工测试或UI自动化测试。
从这个图可以看出,单元测试在金字塔最底层,其次是接口测试,金字塔最上层的是UI测试或称手工测试。测试过程中单元测试所占的比例应该大于接口测试,接口测试应该大于手工测试。而在如今大部分公司做不到这点,依然把手工测试放到首位,甚至将接口测试或单元测试,直接抛开,全面执行手工的UI测试。
这样的行为就如蛋筒冰淇淋的一样,上层是居多的奶油就是手工测试,看着特别好吃,吃多了也就腻了,其下层是自动化UI测试、接口测试、单元测试。这种冰淇淋的模式,目的想全面覆盖UI,遂动用UI自动化,慢慢地自动化的程度要求越高,于是造成团队规模膨胀,经济成本支出更多,维护成本也越来越高。
从适用性角度来说,并不是所有项目都适用于这种传统的自动化模式:UI自动化。如“短”、“平”、“快”的项目就不适用于UI自动化,所以就演变成了另一个模式:橄榄球模式。
以接口形式为主,更多地去执行接口测试,其次是单元和UI。从接口处于的位置就容易看出,接口测试比UI测试更接近业务逻辑代码,又比单元测试更接近用户操作,在其中调和,正是中国人所讲的“中庸”吧。那接口测试的意义是什么呢?
无非总结出有这么几点:
1、更早的发现问题,在执行接口测试后做UI测试能减少问题的出现率,剩下的只是一些与业务逻辑不太相关的页面问题、易用性问题;
2、缩短研发周期,正是更早的发现问题,那么不会因为最后发现问题再去补坑导致浪费的时间;
3、发现更底层的问题,因为接口测试比较接近业务逻辑代码,所以能比UI测试更发现底层的问题。
那接口自动化测试的意义又是什么呢?
1、可以完成重复度较高的任务,减少重复工作量;
2、效率较高,需要更少的时间快速执行。可常用流程接口自动化,并定时构建自动执行;
3、及时发现后台API更新后的问题,保障主流程。
讲了这么多接口测试的东西,但并没有说什么是接口测试。
接口测试?
接口测试是测试系统组件间接口的一种测试,接口测试主要用于检测外部系统与系统之间以及内部各子系统之间的交互点。
接口测试的重点是什么呢?
异常校验:对入参的字段进行异常校验、对不同状态触发的流程进行检查、文档中要求的限制条件是否严格执行等等。
状态检查:请求状态是否正确,所谓的接口有没有调通,调通后,检查返回数据的状态,文档中定义好的。
返回数据检查:对照接口文档检查返回数据的正确性,字段是否拼写错误、字段对应的值是否正确、是否存在与文档未定义的字段返回等等。
业务逻辑检查:对照接口文档所描述的业务逻辑,对其反应出的数据库、日志进行检查等。