接口测试需要怎么做？

关注【郑大钱呀】[公][众][号]，回复 交流群，进群，我们一起交流，一起学习。

什么是接口测试？

在了解接口测试之前，我们需要先了解一下，什么是接口？接口从分类上来说一般分为两种：一种为程序内部的接口即方法与方法、模块与模块之间的交互，程序内部的接口，如购买基金，想要购买基金就必须要登录，不登录就不能购买基金，所以这里我们发现，购买基金和账户登陆，两者是有调用关系的，所以会提供两个接口供内部系统调用；另一种就是系统对外的接口：即从别人的网站或服务器上获取资源或信息，对方不会提供数据库共享，但会提供接口供外部使用，如获取天气接口，当你需要使用时，直接调用第三方提供的接口即可获取天气的数据。

对于接口我们可以大致简单地理解成一个方法、一个函数又或者是一个对象，接口测试主要验证的就是数据之间的交互是否正常。我们先看一下软件开发的大致生命周期，我们这里以瀑布模型为例，一个需求大致的开发流程如下：

从软件开发整个周期上来说，接口测试介入的时间点位于整个测试阶段的早期，比功能测试早一个阶段，更早地介入测试，就能提前发现问题，降低项目风险，减少项目研发成本。接口测试相比较与功能测试来说，接口没有了前端UI的限制，在场景设计上，有了更多的可能，前端无法传入的参数，无法模拟的场景，都可以进行接口测试，通过直接给接口传参，来看接口的表现。

接口测试到底测什么？

接口测试验证，我们分为两种，一种是接口的功能性验证，另一种是非功能性验证，我们先来看一下功能性验证的测试点，如下：

通过性验证：所谓通过性验证就是验证，这个接口是满足需求的，正常的传入参数，可以返回正确的结果，也就是我们所说的正向验证，接口测试的时候，应该首先对通过性进行验证。

参数必填性校验：即参数是否必填，必填的参数，如果不填会这么样，是否有正常的返回报错，填了返回结果是否与预期一致。非必填的参数，不填功能是否正常，填了返回结果是否与预期一致。

参数的边界值验证：有很多的接口，传入的参数都会限定在一个范围，如券商的基金定投接口中定投的金额的限制范围，此时就需要对边界值做相关的验证，举个例子：假设定投的接口定投金额限制在闭区间[1,10000],那我们至少要验证如下几个值：1、10000、中间值、小于0的一个值、大于10000的一个值。

参数非法性校验：即参数我如果传入一个非法的值，接口是否正常，会不会返回异常，能否正常的返回报错信息，参数的非法性校验主要验证如下几种：

1. 参数的数据类型：如果一个参数的传入类型要求是数值，那么我传入字符串、特殊符号会怎么样，接口能否正常处理，传入一个类型为字符串的数值，接口是否会做强制转换。如果是一个整型数值类型的参数，那么我传入小数、负数、很大的数值，接口又会如何处理。对于一些金融相关的接口，如银行、券商相关的接口，对数值都有精度的要求，此时我们如果传入一个超精度的数值，接口又如何处理，是截断还是四舍五入，还是会返回报错信息等等。
2. 参数的长度：一般情况下，接口的数据都会有长度的限制，数据库中的表也会对字段进行长度的限制，所以此时我们需要验证，如果数据超过了长度，接口能否正常的处理，是否有报错的返回，是否会产生异常。
   组合参数校验：在接口中，我们常常遇到，参数之间会有相关的限制，举个例子：如果定投的周期为每日，那么定投的扣款日期就为当日，如果你在定投周期为每日的情况下，将扣款日期传入其他参数，就会报错，由此可见，组合传参的重要性，要尽可能覆盖各种组合场景，覆盖到代码的每个分支，对代码各个分支做到100%覆盖。

说完了接口的功能性验证，我们再说一下非功能性验证，非功能性验证的测试点如下：
接口安全验证：接口的安全验证主要是对信息的加密验证，对于核心的接口，一般都会要求对核心信息进行加密处理，如券商、银行的交易、鉴权、认证等相关接口，都要求对接口中的信息进行加密处理，防止有人通过抓包工具获取非法的信息，进行违法操作，避免不必要的损失。

接口性能验证：接口的性能测试不是一个强制性的要求，主要是针对存在高并发场景的接口，如商城的秒杀活动、券商的交易等，主要验证接口在高并发情况下的表现，看是否满足用需求，响应时间用户是否可以接受，还需要找出接口压力瓶颈，为开发优化接口，提供数据支持。一般接口性能测试工具有HP的Loadrunner、Apache的JMeter(开源、免费)。

接口网络验证：即验证接口在弱网、断网、超时情况下的表现，会不会出现软件崩溃等其它的异常情况。
如何进行接口测试

如何进行接口测试？

我们在了解了什么是接口，以及接口测试的测试点后，那我们如果进行接口测试呢？我们这里主要讨论Web接口测试，由于某些第三方的接口测试需要特定的发包工具，不具有普遍性。在说Web接口测试前，一般情况下，一个规范的完整的接口测试流程是这样的：开发提供接口文档，测试人员通过接口测试文档编写测试案例和测试脚本，接口开发完成后提测，测试人员开始进行接口测试。

但是有些时候，由于种种原因，并没有较完整的接口文档，有些老接口，甚至就没有接口文档，这个时候，我们会遇到两个问题，第一个问题：我们怎么拿到接口，这个接口到底有那些入参数；第二个问题：没有接口文档，我们这么判断出入准则，比如这个字段到底能不能为空；对于第一个问题，我们可以通过抓包工具来解决，比如使用Fiddler、wireshark、httpwatch、HttpCanary(一款安卓抓包工具)等，通过抓包我们可以知道接口的URL、入参、出参、服务器地址和端口、请求头等信息。对于第2个问题，这个一般只能根据测试的情况和开发进行友好的沟通，我们在项目中还是尽量的保证有完整的接口文档，这样方便测试去确定出入准则，减少不必要的沟通成本。

Web的接口测试工具有很多，比较常用的有：postman、postwoman、soapUI、JMeter、Charles，还有一些基于开发语言的接口测试框架，如Java 的TestNG、Python的request 等等。每个工具都有自己的特点，重要的是要选择符合自己需求的，简单的接口测试，可以选择Postman,对于有性能要求的接口，可以选择JMeter,Soap 协议的接口选择soapUI。

SSL-Pinning的问题及解决方案

我们在APP上进行抓包的过程中，会发现只要一抓包，APP的页面就报超时或打不开，这可能是使用了一种叫ssl-pinning的技术来防止中间人攻击，当我们使用抓包工具抓包时，抓包工具在拦截了服务端返回的内容并重新发给客户端的时候，使用的证书不是服务器端原来的证书，而是抓包工具自己的，抓包工具原来的证书并不是APP开发者设定的服务端原本的证书，于是就构成了中间人攻击，触发SSL-Pinning机制导致连接中断，所以我们无法直接抓到包。在网上有很多解决方案，比如：使用VirtualXposed+justtrustme绕过SSL-Pinning、通过Frida 将脚本注入到APP中(不得将以上技术用于非法用途)，从而达到修改APP的目的，当然这两种方法并不能绕过所有APP的ssl-pinning机制 ，对于安全机制很高的APP，如券商、银行的APP，这些方法并不一定有效。

接口测试自动化回归测试

我们在完成迭代需求的接口测试后，不能测试完成了，程序上线了，就不管了，我们可以将已经测试过的接口，进行优化调试，通过不断的积累形成一个可用的接口回归测试案例库，在每次新需求引入的时候，我们可以对所有接口进行一遍回归测试，以防止新需求的变动影响到现有的接口,又或者后端人员将数据库的某个字段的长度、类型修改后，由于某些原因没有及时通知前端工程师就上线了，而此时前端获取的这个字段的类型、长度是以前的，那么就可能引发线上事故。由此可见接口的回归测试是尤为重要的，也是对产品的质量保障也多一分信心。进行接口自动化回归测试，要考虑很多事情，大致如下：

测试数据与测试脚本维护：一般接口自动化回归测试，随着需求慢慢迭代，会形成一个数量庞大的接口案例库，对于测试脚本和数据的维护就显得尤为重要，我们建议将测试数据和测试脚本相分离，这样当接口有变动时，我们只需修改测试数据，或者对脚本进行少量的修改即可，大大降低了项目的维护成本。关于测试数据和测试脚本的分离，我们这里用JMeter举个简单的例子：我们将测试数据保存到CSV文件中，即一行数据一条案例，在JMeter中通过CSV数据配置元件，将CSV的数据加载进来，之后我们添加采样器，编写接口并将接口的参数进行参数化，添加循环逻辑控制器或者修改线程组迭代次数，即可完成所有案例测试。

数据参数化：所谓数据参数化问题，简单地说就是，接口的有些值不能写成定值，比如定投接口中的token值，token是有时效的，是动态的，如果我们写成定值，当token失效时，那我们这个定投的接口案例就会失败，所以一定要对token这个入参进行参数化，即写成一个变量，每次执行的时候，我们先调用登录接口，然后将登录接口返回的token，传入定投的接口中，这样就不会出现上面的问题。

一次性接口问题：所谓一次性接口问题，我们举个例子：以券商的开通创业板业务为例，我们以接口的形式去开通创业板，开通成功后，就无法再次开通了，此时可能就需要一些特殊的操作，比如每次在开通创业板前，先从数据库中查询一下，是否已经开通创业板，如果已经开通创业板，则在数据库中，将相关表的记录删除，然后再进行测试，这样就可以解决一次性接口的问题。在工作中，这类一次性接口还是有不小的占比的。上面的方法，能解决一部分的问题，如果某些接口的数据直接保存在本地，上面的方式还是不可行的。
断言出入准则：所谓断言就是接口返回的真实结果是否与我们的预期的结果是否一致，断言出入准则就是我们断言的出入准则应该是什么样的，是否要对返回的数据进行精确校验，还是只是只验证返回码和返回信息，不同的接口的出入准则是有差别的，比如交易的核心接口是要对返回的所有数据进行精确校验。

案例批量执行和测试报告：接口自动化测试，肯定不能手动的一个接口一个接口的进行测试，必须要支持案例批量的执行，执行完成后，要能生成反应整体测试情况的测试报告。

接口自动化回归测试方案

下面我们再说如何进行接口自动化回归测试，一般情况下会有如下几种解决方案：

购买第三方接口自动化测试平台：有很多测试公司，都开发了接口测试平台，然后向目标客户投标，由于不同的客户，需求有差异，为了满足客户的需求，他们一般也会根据客户的需求进行一些定制化的开发，往往一套接口自动化平台的售价从几十万到上百万不等，有很多券商、银行会通过竞标的形式，向市场进行招标，多家对比，选择合适自己的测试平台。

自己定制开发接口测试平台：第三方的接口测试平台，价格昂贵，对于很多项目来说，成本太高,不划算,此时可以通过现有的框架进行开发,量身打造,举个例子:使用Python + request + unittest 可以定制开发出接口测试框架，如果考虑到易用性，可以在以上框架的基础上，再使用PyQt5开发接口测试平台的界面。

使用开源工具框架：以上两种方式，一个昂贵(当然贵有贵的道理啊)、一个费时费力，需要投入时间、人力成本。这个时候我们在开源社区中选择合适我们的、成熟的测试工具来组合成一套完整的测试框架，举个例子：我们可以使用下面的一套测试工具组成一个持续集成的接口自动化测试框架 ，即：SVN+JMeter+Ant+Jenkins，我们使用SVN来进行测试数据和测试脚本的维护，JMeter用来编写调试测试案例，使用Ant批量执行JMeter脚本，并生成测试报告，再加上Jenkins，可组合一套支持持续集成的接口测试框架。这里我们稍微说一下，为什么要选择JMeter,首先JMeter开源，没有使用成本，JMeter能够很好地实现测试数据和测试脚本的解耦，其拥有丰富的配置元件和断言，以及可以调用自己开发的jar包，足以支持多样化的测试场景。当然肯定有其它的框架，这里仅做一个参考。

接口测试的更多可能

我想很多测试人，都不太喜欢测试案例，对于功能测试来说，要先分析需求，再结合设计稿，对于不熟悉的点，还要和产品经理沟通，最终形成一份测试案例，手动案例存在很多的不确定性，无法自动编写，但是接口测试案例的测试点有很大一部是固定的呀，无非是从如下测试点：正常情况、参数为空、参数非法、参数组合、参数数据类型等方面进行校验呀，所以我们是不是可以通过开发一款工具，我们填入参数，点击一下按钮，就根据上面的测试点，自动生成测试案例呢，并返回每条案例的测试结果，这岂不是极大地提高了工作效率。

测试只是手段，质量保证才是目的，祝大家产品上线都没Bug，文章如有不足之处，希望大家多多指教，本期就到这里了，大家生活愉快，疫情期间戴好口罩，我们下期见。

参考文献

1. SSL pinning部分
2. 自动化部分