测试开发之路——关于API接口测试现状分析
目前API测试行业需求现状
? 在目前招聘测试的趋势中，API的测试技术基本是必备的技术，也是必须要求掌握的，这在过去说的很透彻，接口测试技术将会成为基础测试技术，当时也有人很多留言说，那么什么是高级测试技术了？抛开技术的角度，在一个组织中要的是成本和效率，使用有限的资源有限的成本达成最初计划的目标，那么推动这个过程中的，就是结果，这就对软实力要求非常高，推动解决这些问题的过程中，仅仅具备技术的不够的，还得懂技术，得会沟通，得推动别人解决问题，也就是说通过别人来完成自己的工作。那么什么是高级技术了，我个人理解的就是推动完成目标的能力，测试架构的技术能力，性能测试技术的能力和质量风险把控能力以及产品驾驭能力和测试开发的技术能力以及商业思维能力（发现自己这方面差距很多啊）。但是今天还是继续谈谈API的测试。
关于接口测试的浅理解
? 接口测试的核心并不在于使用常见的测试工具（Postman,JMeter等），也不在于代码的实现，这些只是实现结果的一个手段，就像物理学上说的，通过一个简单的公式，依次推理得到一个结论，这个推理的过程它是间接的证明了这个公式是否正确于否，接口测试的核心首先是要理解它的原理，比如HTTP的请求过程，常用的请求方法的差异，常用的状态码有什么特点，以及cookie,session,token的请求过程，和常用的认证方式，客户端请求服务端过程中请求头的信息和响应头的信息，这些需要清楚。清楚了这些，无非就是使用工具来完成这个过程，和工具的整合。如postman+newman+jenkins能够整合到一起,JMeter+ant+Jenkins也是能够整合到一起,当然JMeter性能测试工具还可以和influxdb,grafana工具能够整合到一起（后期我会更新Grafana的数据整合）。代码层面整合的也是很多的，比如单元测试框架，面向对象，设计模式，数据驱动，测试框架等等，到最后基本是按框架的方式来编写测试用例。好，那就接着谈接口测试的维度。
? 从形态上说，接口测试可以分为单接口的测试和基于业务的接口测试，单接口的很好理解，就是每个接口测试之间没有任何的依赖关系，客户端请求服务端，服务端返回响应数据然后断言，我个人觉得它的测试是有必要的，但是意义不大，毕竟从产品形态上来说，怎么可能没关联了，事物之间充满了太多的依赖性。那么使用最广泛的也是基于业务场景的API的测试，通过接口测试的技术实现业务场景的测试，这样它的难点在于业务之间的关联性，以及接口和接口之间的依赖关系，处理最复杂也是最普遍的是参数的上下关联性，如A接口返回的参数，给下个接口B调用，使用的方式当然也是很多的，如postman里面使用定义变量方式解决，JMeter里面可以使用后置处理器来解决，代码层面可以使用函数的返回值来解决，其实思路都是一样的，只不过一个是工具，另外一个是代码。当然针对单纯的一个接口来测试，就存在几个维度，如一个接口中，它的请求参数是否为空验证，类型验证，边界值验证和安全性的验证。
另外一点是在接口测试中，使用工具了为什么还要使用代码了？这很好回答，工具人人都会，代码是一种能力，不一定人人都会（当然也是人人都可以会的）。
最后谈谈API的分层测试，API的网关经常会被使用到，网关封装了所有连接外部服务的逻辑，同时它也是处理了底层的通信协议，对另一个领域下的对象进行了序列化与反序列化。只所以谈分层，是因为在一个接口的测试中，我们很多时候调用的是上层的接口，但是上层的接口又是另外一个被封装的接口被提供的，这中间是多层的处理思路，如果基础架构平台出问题，基本就是瘫痪，影响的全局产品，但是如果是最上层出问题，只是影响了一个应用程序或者一个产品而已，所以API的测试也需要分层来考虑，这就需要对公司的架构得非常熟悉，了解各个之间的调用链的关系。
? 建议尽量做API的自动化测试，一方面做API的测试比较简单，第二是执行效率高，在维护成本上需要看具体设计的框架，但是比起UI的框架维护成本还是比较低的。接口测试从大的维度来说，分为两类，一个是单接口的测试，另外一个是多接口的测试（基于业务场景的测试），单接口的在微服务和开放平台测试中比较常见，比如提供了一个接口给合作伙伴，但是需要测试来测试下这个接口的功能和它的稳定性，那么只需要在如下几个维度来具体测试：
1、接口的请求参数它的数据类型后台是否做了校验
2、接口的请求参数必填的参数后台是否做了处理
3、接口的请求参数长度是否做了处理
4、提供的接口是否实现了对应的业务场景和业务功能
在这里还是重点来看前面几点，关于后面的在多接口的测试来逐步的总结。
做单个接口测试是很有必要的，而且是必须的，但是我一般建议做单个接口测试的维度，只需要校验下接口是否可以正常的请求，以及请求后响应数据是否正确，至于请求参数这一层，依据情况来做，怎么说了，很多公司给测试接口的API文档都不提供，更别说去修改这些本应该判断的问题了，也从某些维度说，不是所有的事都是必须做的，依据情况进取舍.
多接口的测试，也就是基于业务场景的测试，这部分测试起来难度还是大的，但是这也是接口测试必须要做的部分，如果单纯的验证一个接口是否请求OK是没有多大意义的，更多的应该站在业务场景来设计接口测试用例，那么也就意味着中间需要处理很多的业务场景，动态参数的处理和业务逻辑的处理.比如一个XX管理模块，使用接口自动化测试实现它的添加，查询，修改，删除，中间第一个需要处理的是添加成功后用户的ID需要获取到，并传给下一个接口，这中间就会使用到函数的返回值的知识体系，以及动态参数的处理思路，另外一个业务逻辑是当添加用户的时候，实际XX用户已经存在（不能重复添加），那么也就需要在对象层对添加用户的接口进行判断，当添加用户存在的时候，怎么处理，不存在当然是继续添加和走业务场景，这中间也许有人反驳说我执行添加前看一下，如果存在手动删除，这样不智能，另外一个观点是每次执行后都会删除，这是必须的，但是我们无法保证每次测试用例执行创建的用户就删除，比如某次执行的时候，删除的接口出了问题，导致没删除，在这中间，程序不能有太多的假设，用例必须考虑到各个业务场景和逻辑，然后在对象层进行处理。
|