为什么要做接口测试

Posted on Wed, 25 Dec 2024 10:36:19 +0800 by LiangMingJian

怎么理解接口

举个例子，假如我们在开发1个bug管理系统，该系统需要拿到公司的所有开发和测试人员的信息，这样开发和测试人员不用注册都可以登录进去了。那么这些人员的信息储存在哪里呢？一般存储在hr系统里。现在的需求更加明确了，我们要到hr系统中去拿到人员信息，获取hr系统中的人员资源。

怎么获取数据呢？直接把hr系统的数据库拷贝一份放到bug管理系统里的话，数据的同步会有点麻烦；直接连hr系统的数据库去查的话，我们就需要了解hr系统的数据存储结构和逻辑，一旦hr系统的数据字段发生改变，bug管理系统也要去改，以便同步，这样做同样麻烦。

比较好的做法是，hr系统暴露一些接口，通过这些接口去获取人员信息资源，这样bug系统就不需要关心hr系统的数据存储实现。

这些接口可能是这样的：

登录的接口，提供人员的用户名和密码，去hr系统中判断该人员是否存在，如果存在，验证用户名和密码，如果验证通过就返回1个token，该token就是这个人员的通行证，通过token可以登录到bug管理系统中去；
获取人员信息的接口，返回该人员的职位：测试还是开发，以及用户名，昵称等信息；

综上：接口是不同系统或模块之间资源交流的工具。

作为黑盒测试，基本的测试思路是通过输入和输出判断被测系统或者对象的逻辑。获取人员的信息，我需要把人员的用户名传给hr系统接口，这样hr系统的接口会返回给我用户的一些更加具体的信息。这里的输入是用户名，输出是用户的详细信息。

大部分系统和产品中，资源一般都是产品的核心，比如微信核心资源就是通讯录关系链和聊天记录等，因此资源是必测的。接口是不同系统或模块之间操作资源方式，所以接口测试是必要的。

另外接口中大部分的内容是数据，通过数据的对比我们能推测到系统和产品的逻辑，测接口就是测逻辑。

最后接口中的返回相对单纯，不像web页面，html代码中有太多UI的东西，UI最不稳定，变化太快，接口相对稳定一点点，但是里面的干扰信息更少，断言相对容易很多。

前端和后端往往节奏是不一致的。前端很多情况下需要等待后台的API开发完成后才能进行开发联调和测试，这种前后端不对称就造成了前后端团队节奏不一致，从而造成整个项目/产品交付/发布延期。

有一种解决方案的思路是前后端先约定好后端提供的API接口的细节，前端人员自行先模拟出这些后端的实现，当然这些实现是假的，不过前端可以去调用这些假的实现，而且能拿到返回，这样一来前端就不需要等待后端开发完成才开始工作了。

但是这样还是会有问题，前端实现的假的API没办法迅速反映出后端的变化。简单来说就是后端可能在约定好的API接口上进行了些许修改，而没有知会前端人员，这样前端的假的API实现并没有相应更新，在正式联调时就会出现问题。

像这种假的API实现，不管是前端实现的还是后端去实现的，我们可以称之为mock server

由于前后端往往有一些信息不对称，导致约定的API可能在前后端都会发生变化，所以保证前后端的一致性就成了一个挑战。这时候就有人提出了契约测试，大致思想是前后端共用一份契约，约定了API的细节，前后端的任何变化都需要先修改契约，然后通过契约去通知前后端团队，统一更新实现。这也是契约精神的表现。