接口测试简介

1.什么是接口

      接口就是内部模块对模块，外部系统对其他服务提供的一种可调用或者连接的能力的标准，就好比usb接口，他是系统向外接提供的一种用于物理数据传输的一个接口，当然仅仅是一个接口是不能进行传输的，我们还的对这个接口怎么进行传输进行进行一些设置和定义。开发所谓的接口是模块模块之间的一种连接，而测试眼中的接口是一种协议（对接口的功能的一种定义）

2.接口的种类和分类

外部接口，内部接口：上层服务于下层服务，同级服务。常见的接口分类http：get，post，delete，put

3.各个接口之间的区别

    通常我们测试的接口分为get接口和post接口，get的提交方式是明文提交，把提交的参数跟在url后面发送给服务器，所以不安全，而且get提交的参数是有字符限制的且可以被当做书签保存，但是post的提交方式跟get完全不一样，post提交的参数是放在表单里的，所以不会存在字符限制，而且因为参数是放在表单里，不容易被看到，所以会比get更安全。

4.什么是接口测试

     简单的来说接口测试对于测试来说其实是对接口协议的一种测试，这个协议指的是为了让这个接口实现某种需要的功能还设计的一种要求。

5.为什么要进行接口测试

       因为不同端（前段，后端）的工作进度不一样，所以我们要针对最开始出来的接口，以及需要调用其他公司的（银行，支付宝，微信，qq等）一些接口进行接口测试及验证数据，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易），需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

6.接口测试流程

     需求讨论，需求评审，场景设计，编写用列，准备数据，执行测试

7.怎么进行接口测试

    通过工具模拟客户端向服务端发送请求并接受服务器返回的数据来对接口的功能，逻辑业务，异常，安全进行测试

     功能测试：测试这个接口的功能是否实现，并且测试这个接口是否按照接口文档来进行开发的（比如说接口文档规定了一些关键字，而开大的时候把关键字改成了其他的关键字，因为在整个项目周期，并不只有一个开发而是有多个，所以可能因为在开发过程中因为关键字不一样导致某些开发的功能异常，还有自动化脚本也会发生异常）

　　逻辑业务，主要指的是一些逻辑业务依赖关系（比如支付宝提交订单的时候要保证你是在登录的情况下，如果你没有登录而提交成功了，这就是异常，可以修改请求的cookie来测试）

　　异常测试：参数异常：关键字参数（应用其他的关键字替换进行测试）、参数为空、参数多少（通过添加参数增添个数），参数错误。数据异常：关键字数据（填入的数据用其他的数据语言的数据替用）、数据长度、数据为空、数据错误

8.接口测试需要用到的工具

　   接口测试常用的工具，fiddler抓取请求，postman模拟客户端通过对fiddler抓取的请求修改并发送到服务端并接收服务器返回的数据及异常来进行验证接口。工具不是固定的，需要根据项目来进行选择。

接口测试用例设计思路

1 输入

　　输入参数主要从以下几各方面设计：

　　a 必填项校验

　　接口文档中有是否必填的说明。参考接口文档即可。

　　b 参数长度校验

　　参考接口文档即可。

　　c 参数值的有效性校验

　　如：身份证号的校验 ，设计的数据虽然符合身份证号的规则，但是并不是真实有效的身份证号；这种情况就要看身份证号的校验规则是什么样了，一般都是用的现成的身份证号校验器，但是有些是自己写的校验算法，这个本人就遇到过这种问题---校验算法写的不正确；

　　所以参数有效性的校验就需要结合实际业务场景，判断哪些数据是真实有效的数据，一定要确保所有真实有效的数据是可以验证通过的。

　　d 参数组合校验

　　不同的参数组合可能会存在不同的业务场景；

　　e 如果参数是枚举值，一定要各种枚举值都要测试，因为可能不同的枚举走的不同的业务流程；

　　f 参数值的默认值的校验

　　参考接口文档。

　　g 某些参数具有特定的生成规则，要单独针对生成规则设计用例，一定要保证真实有效的数据是可以验证通过的。

　　如身份证号中间几位 ******19860701****，本人就遇到过输入******19861001****这种值校验不正确；

2 接口逻辑

　　接口逻辑我用的设计方法是分支覆盖--->路径覆盖--->场景覆盖,同样也是要结合实际业务场景，根本不发生的业务场景就是无效的测试用例。

　　a 第一步先把业务流程图画出来；

　　b 依据路程图中的分支分别设计，不同分支不同的场景，这里就要把异常的场景考虑进去；如接口超时，接口异常，接口请求成功或失败，成功后怎么处理，失败后流程是否继续执行，失败后的数据怎么处理；

　　以打款接口为例：

　　打款结果有打款成功或打款失败，成功后怎么处理，需要回写打款成功状态，失败后怎么处理，也需要回写失败状态，失败后的数据可以操作退回，也可以操作重新出款等等；

       c 测试逻辑设计完成后要想一想不同的业务场景怎么去测试，需要哪些人员协助，

        如接口超时怎么去测试，请求重复怎么去测试，请求并发怎么去测试

3 输出

输入结果：正常输出和异常输出，常用的方法有错误推断法（列举出程序中可能存在的错误或者异常，根据他们选择测试用例）

4 以上都完成后，要结合实际的业务场景去掉冗余的用例（即实际业务场景不存在的流程或者输入数据）；

5 如果业务流程涉及到状态转换，要单独设计用户---方法：状态转换图；

6 涉及到多个不同金额或者手续费的计算，可能还会用到正交实验法去设计用例；

7 另外，用例设计中还应当包含异常流程中产生的异常数据的处理流程；---通常所说的补偿机制，这块流程能大大的减轻人工运营的工作量，当然，这需要在做系统设计的时候就需要把这部分考虑进去。