1：什么是接口测试？
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
2:接口的本质及其工作原理是什么？
接口简单的理解他就是URL，工作原理就会说URL通过get或者post请求像服务器发送一些东西，然后得到一些相应的返回值，本质就是数据的传输与接收。
用例设计重点：通常情况下主要测试最外层的两类接口:数据进入系统接口（调用外部系统的参数为本系统使用）和数据流出系统接口（验证系统处理后的数据是否正常）
3:接口的分类？
3.1：webService接口是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。
3.2：http api接口是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。
json是一种通用的数据类型，所有的语言都认识它。（json的本质是字符串，他与其他语言无关，只是可以经过稍稍加工可以转换成其他语言的数据类型，比如可以转换成Python中的字典，key-value的形式，可以转换成JavaScript中的原生对象，可以转换成java中的类对象等。）
4:接口测试常用工具？
4.1：jmeter、postman等
5：如何进行接口测试分析
拿到接口我们要怎么进行接口测试分析呢？
对于任何功能或者应用要怎么做测试分析，首先先要明确需求，先定性在定量。
即有哪些显性需求，哪些隐形需求？需求文档是否清晰明确，性能是否需要，可靠性安全性是否有要求？明确后在定量，功能测试，有哪些功能，每个功能点是什么，入口有哪些，出口有哪些？在确定功能点测试范围后，第一步可以先把业务流程图画出来；然后依据路程图中的分支分别设计，不同分支不同的场景，这里就要把异常的场景考虑进去；如接口超时，接口异常，接口请求成功或失败，成功后怎么处理，失败后流程是否继续执行，失败后的数据怎么处理等
6：接口测试测试点
以下是工作中的一些总结和思考，如果有不对，请指正。
接口功能常用的方法：等价类、边界值、因果法、情景分析、正交表、错误推断法
关于业务功能测试：主要分为正常场景测试和异常场景测试
接口不与外部服务交互
从流程上功能一般的测试顺序校验点
5.1：请求参数校验：必输项校验、字段长度校验、字符合法性校验、字段默认值校验、非必填项字段为空、非必填项字段值为空、字段枚举值校验、条件必填项校验
5.2：业务逻辑校验；（一般设计方法分支覆盖—>路径覆盖—>场景覆盖,同样也是要结合实际业务场景，根本不发生的业务场景就是无效的测试用例。）
5.3：数据入库是否正确（是否存在长度超长自动截取、枚举值是否转换正确、交易处理状态是否正确、敏感信息是否加密存储（用户密码、银行卡加密622821XXXX111）等）
5.4：输出参数校验：是否给出正确响应（主要依据接口文档，返回参数的值是否与数据库一致、返回的结果是否服务预期业务场景）
5.5：内部服务处理异常场景、内部服务模块处理超时等异常场景返回结果是否正确
接口与外部服务交互
1:还需考虑调用外部服务异常处理是否正确、调用外部服务超时是否处理正确、外部服务给出正常应答是否处理正确
关于异常：
1、关注异常场景处理是否合理
2.1、内部模块处理超时是否合理
2.2、事务测试（考虑事务处理异常是否回滚；考虑商户有请求中有多笔批量明细）
2.3、单线程测试（考虑单线程执行某个任务有多条记录，一条任务执行错误，是否会影响后面任务的执行）
2.4、redis（如果有用到redis考虑redis值是否与数据库值一致，测试过程中发现有些控台做的update操作（某商户某一类型交易每笔收费金额由0.01更新道0.02，且控台数据是从数据库获取查看是更新成功），数据库更新正确redis值未更新，导致发送交易获取该商户收费金额仍然为0.01，从而与实际业务不符）
2.5、集群测试（考虑集群交易流水号生成是否重复、集群用户是否满足不能同时登陆、考虑集群信息的同步等）
2.6、批量数据测试
2.7、分布式测试（mq：考虑消息队列消费异常是否有重试机制、加大负载mq处理是否及时是否会阻塞）
2、考虑异常场景出现后程序是否有对应的补偿机制
2.1|、eg：对接三方支付接口，如果客户的订单很多都是处理中，那么客户是需要查证去明确交易状态，此时我们系统内部就可以设置一个定时任务去定时处理处理中订单发起查证；或者在一些情况下我们需要有一些重试机制，
2.2、系统每天都会先去获取三方支付公司对账文件，然后系统内部对账、最后生成商户的对账文件，如果获取三方支付公司对账文件没有成功，则程序应该会重复触发执行，否则一次获取不到则不进行对账，那么很容易就出现商户得不到对账文件，从而来投诉；这种情况就是程序的重试机制，那么如果程序重试一直获取不到第三方支付公司的对账文件呢？那我们自然也生成不了商户对账文件，那么客户也会投诉，怎么办？这种依赖获取第三方支付公司对账文件然后处理后给商户对账文件，我们可以打印相应的日志让运维做监控，以便能及时处理
关于安全
1、web
1、前后端敏感信息的传递是否加密，比如：密码、身份证、银行卡、cvv2、有效期等
2、登陆：
2.1、考虑xss攻击、越权（一般是公司安全测试部门测试），
2.2、功能测试可以考虑：是否单点登陆、密码的复杂度设置、密码错误的重试次数（超过一定次数失败是否锁定）等
2、openapi
2.1：openapi接口一般接口会对请求进行验签，对于返回出去的响应进行加签，一般的加密方式有RSA和MD5
2.2、对于接口中有银行卡敏感信息要怎么处理：dgtl_envlp数字信封、acc_info账户信息，首先账户信息肯定是需要加密的，一般采用对称密钥要加密（使用数字信封指定的方式和密钥加密），那么如何解密账户信息呢？即如何安全的知晓对称加密的密钥呢？因为只有知道知道这个密钥我们才能对加密的acc_info账户信息进行解密，那么我们就会这个对称密钥再次进行加密（平台的公钥加密），作为平台收到商户的请求首先先用平台的私钥把dgtl_envlp数字信封解密获取到对称密钥，然后在用对称密钥解密acc_info账户信息
3、数据库存储：敏感信息是否脱敏存储（银行卡前6后4、身份证脱敏）、非必要存储信息如信用卡CVV2 有效期不允许存储
4、日志打印：敏感信息脱敏打印，或者不打印
关于性能：
1、关注tps、用户数、平均响应时间；服务器：cpu使用率、内存使用率、io、网络
7、面对没有接口文档的接口需要测试，怎么办？
大家肯定有遇到过产品组因为没有出具体需求文档接口文档，然后提测，然后就是一对理由比如时间紧等等，后面在补充文档这种情况，需要先测试。这种情况要怎么做呢？你会左右为难吗？不测又被逼迫，做又如鲠在喉。遇到这种情况就是拒绝，没有需求文档的东西，客户如何对接？别人怎么使用我们的服务？测试如何测试？如何知道预期结果，如何保证产品质量？