1. 接口测试怎么做的？
原来我们的接口测试，开发这边会给我们一个接口文档，我们根据接口文档编写测试用例，考虑接口正常场景跟异常场景。测试用例编写完成后，我们会用python request去执行，查看返回的结果是否跟用例的一致，不一致有bug。
需要注意的是参数之间是不是组合关系，如果是组合关系就需要同时考虑，如果不是组合关系就要单独考虑。
也需要考虑正常和异常的场景，多一个参数和少一个参数以及参数为空的情况。比如我们用python request做的一个前端注册接口，首先我们把每条用例定义成一个函数模块，再把需要组合的参数编写进用例里面。
比如用户名跟密码这是组合关系就要同时对这两个参数进行考虑。
- 当用户名与密码正确的情况下，返回的是一个正确的注册成功的信息。
- 当用户名为空和两个密码一至的情况下返回的提示应该是一个用户名不能为空的信息。
- 当用户名正确和两个密码不一至的情况下返回的提示应该是一个密码不一至的信息，
- 当用户名正确和两个密码都为空的情况下返回的提示应该是一个密码不能为空或密码过弱的信息。
- 当用户名重复，手机号码重复，
- 勾选了协议和没勾选了协议的情况，还有同时我们也需要用等价类边界值对参数的长度、特殊符号的输入和类型进行考虑。
最后加assert来断言判断返回的参数是否正确。
接口测试的主要好处：在后端测试接口，覆盖更加全面，测试时间可以提前。原来在接口测试过程中，发现问题最多的，来源于格式的校验这块。比方说，原来我们申请借款，利率设置成5000，也可以申请成功，功能测试，界面已经做了校验，只能在接口中才能测试出这个问题，还有原来我们申请借款时候，需要勾选，同意，协议，接口中不没有勾选，也表示成功。
2. 接口自动化测试怎么测？
原来我们也做了很多接口自动化。接口自动化这块，其实原来我们也是用jmeter请求去做的，这个时候，我们也用到一些工具，http代理，主要方便编写接口请求，通过录制就行了，我觉得接口自动化只是在接口测试中多加了一些参数化、关联、断言参数，主要是函数参数化，自定义变量参数化，文件参数化，主要文件类型csv跟txt，不过原来csv文件用的比较多，还有一些数据库的参数化，断言，主要响应代码断言，响应文档断言。
比方说，原来我们一个登录接口主要是正常场景，异常场景这块。
正常场景：主要是用户跟密码正确，采用数据参数化，把用户名用随机函数进行参数化，随机长度大一些，用户名不存在的情况，原来是通过文件参数化，设置参数值，密码不正确也是通过文件参数化，接口请求中host地址，目录地址，我们都进行数据化，自定义变量去操作，结果检查中，我们主要是用断言来检查，每个请求，设置了2个断言，一个响应代码断言，一般是200，响应文本断言，登录成功，返回码为1，状态提示成功，检查是否成功，
异常场景：都需要设置断言，去检查结果原来做的申请借款接口，需要登录接口cookie，我需要建立2个接口，一个登录接口，一个申请借款接口，通过正则表达式去提取 登录接口返回cookie，在申请借款请求接口，设置http cookie时，值为登录接口返回cookie，还有也要考虑原来我们项目，还有token值，登录返回token提取，当成申请借款的请求参数，当测试场景的脚本编写完成，执行接口测试用例，我们在察看结果树中，检查，主要是看颜色这块，红色检查哪些地方失败，绿色表示通过
3. 你们是怎么做接口自动化的？
原来我们接口 主要是用的python requests去运行的。
首先，开发会给我们一个接口文档，拿到接口文档后，我们就进行测试点的分析，考虑正确场景，条件的组合，异常场景，多一个参数，少一个参数，参数为空的情况，
比如原来我们做一个生成订单的接口，考虑正常场景，异常场景正常场景就是不同的订单类型，订单金额，能不能申请订单，每个参数的格式类型的校验，异常场景，多一个参数，少一个必填参数的时候，还有参数为空的情况，原来我们是用python request去做的接口。
首先，导入request包。建立一个 headers，保存请求头的信息，因为订单请求方式 是post类型，数据格式是 form表单格式，我们把数据保存到data的字典里面，这个时候我们还需要 登录的cookie值跟登录后产生的token值，我们会去通过动态关联去获取 登录的token跟cookies，cookies值的话，我们是直接调用登录返回的 cookies，token值的时候，我能是通过导入re模块，通过正则表达式去提取当参数，headers，cookies输入完成以后，我们就发送请求，打印返回结果，检查返回结果是否跟我们测试用例一致当运行其他测试用例时，我们去修改data里面的参数就行，在发送请求，有的请求时https协议的时候，我们发送请求的时候 还会verify=false 去忽略掉证书验证对应多个接口调用 cookies 我们会用到session去保存，接口发现比较多的问题，就是格式校验这块。比如说我们提交订单，订单数据没有显示，订单格式也没有显示，输入字母，汉字都可以订单类型 为空，也会生成订单成功，我觉得接口可以发现接口更多的bug，还可以提早进行测试，提高测试的质量。
4. 接口自动化
原来我们接口自动化是用 python request unittest执行。接口自动化其实主要就是接口测试的基础上添加了断言、参数化、动态关联，做接口自动化之前，我们也会划分模块：报告、公共的模块、测试数据、测试报告，主要的目的是为了方便后期的维护。
测试数据，一般原来我们就是用的接口测试用例；公共的模块主要是里面的一些公共的操作，比如说用例excel数据的读取，数据库的连接、还有我们封装的每个接口请求；断言的主要是 获取访问接口的值判断，用的是assert；参数化主要用的比较多是excel表格，就是测试用例数据；还有需要调用登录后的cookies跟token的时候，我们就会用到关联;
比如说原来我们写的一个 申请借款的接口吧。
首先我们会编写测试用例，把每个用例数据保存到excel中再建立一个 申请借款的模块，这个时候我们去调用申请借款的功能模块，里面的参数我们是保存在excel表格中，我们建立发送请求，通过参数化，去读写excel表格中的数据，获取到返回的数据，通过assert 去对应返回的数据跟用例中异常的数据，这个时候也会做数据库断言，去连接数据库去查询数据库中时候存在查询，如果是返回结果是json数据格式，我们还会转化下格式后，再去断言，这个申请借款模块，也会用到登录的cookie值token，我们先建立一个登录的请求，提取返回的cookie值token，excel表格多个用例，我们就用到循环去运行，读取excel中用例总的条数，去循环运行，这里要注意的是，就是excel表格数据时是str我们要eval转化成字典格式，把每个接口封装好以后，我们就会调用unittest框架去运行所有test文件的测试用例，如果只是执行部分用例，也可以通过unittest框架来指定接口自动化
我个人觉得，性价比是比较高的，实现起来简单、维护成本低，容易提高覆盖率等特点。接口是稳定的，最多是增加一个字段或者新增接口之类的低成本，有了相对的稳定性，不需要大量重新编写脚本，只需要基础维护包括用例的扩充就可以了，执行的快，反馈的速度快
5. 平常你是怎么测试接口的？
通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
接口安全：
1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
4、密码安全规则，密码的复杂程度校验
异常验证：
所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
性能测试
接口并发情况，如上面提到的：一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别。
6. 接口测试经常遇到的bug和问题，如下：
（1）传入参数处理不当，导致程序crash；
（2）类型溢出，导致数据读出和写入不一致；
（3）因对象权限未进行校验，可以访问其他用户敏感信息；
（4）状态处理不当，导致逻辑出现错乱；
（5）逻辑校验不完善，可利用漏洞获取非正当利益等。
7. 接口自动化测试中携带哪些参数
Url： http、https、tcp、ftp
Method： post、get、delete、put
Data： application/json、application/x-www-form-urlencoded、multipart/form-data、text/xml
Headers： content-type、user-agent、cookie、token、authorization
8. 当一个接口出现异常时候，你是如何分析异常的？
答：先抓包，用 fiddler（charles）工具抓包，或者浏览器上 F12 调试工具；APP 上的话，那就 用 Fiddler 做代理，通过手机设置代理去看请求和返回报文； 查看后端日志，如 Linux 系统通过 xhell 连上服务器，查看接口日志，查看是否有报错信息 （命令：tail -f 日志文件）；
9. 接口测试中，依赖登录状态的接口如何测试？
依赖登录状态的接口的本质上是在每次发送请求时需要带上 session 或者 cookie才能 发送成功，在构建 POST 请求时添加必要的 session 或者 cookie。
10. 平常用什么工具测接口的？
答：常用 http 协议接口测试工具，如：postman、fiddler、jmeter；webService接口用SoapUI、 jmeter 等。
11. 没有接口文档，如果做接口测试？
用抓包工具把接口抓取处理，然后针对性进行测试；接口中字段信息不清楚的，找时间集中寻求开发解答。（常用抓包工具 Fiddler、Charles 等）
12. 怎么设计接口测试用例？
通常，设计接口测试用例需要考虑以下几个方面：
①是否满足前提条件 :有些接口需要满足前提，才可成功获取数据。常见的，需要登录 Token。
逆向用例：针对是否满足前置条件（假设为 n 个条件），设计 0~n 条用例；
②是否携带默认值参数
正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值， 其他不填写，设计 1 条用例；
③业务规则、功能需求 这里根据时间情况，结合接口参数说明，可能需要设计 N 条正向用例和逆向用例；
④参数是否必填 逆向用例：针对每个必填参数，都设计 1 条参数值为空的逆向用例；
⑤参数之间是否存在关联 有些参数彼此之间存在相互制约的关系；
⑥参数数据类型限制 逆向用例：针对每个参数都设计 1 条参数值类型不符的逆向用例；
⑦参数数据类型自身的数据范围值限制 正向用例：针对所有参数，设计 1 条每个参数的参数值在数据范围内为最大值的正向用例；
13. 请问你们公司是如何做接口测试的？
①获取接口规范；
②设计接口测试功能用例（主要从用户角度出发看接口能否实现业务需求）；
③各种入参验证（正常情况，异常情况包括输入参数个数不对，类型不对，可选 / 必选，还有考虑参数有互斥或关联的情况）；
④接口返回值各种验证（符合接口文档需求）；
⑤了解接口实现逻辑，实现逻辑覆盖（语句 / 条件 / 分支 / 判定 /…）；
⑥接口能并发执行吗、安全吗，性能满足要求吗；
⑦采用工具或者自写代码来验证；
⑧发现问题跟功能测试一样，该报bug报bug，该跟踪状态的跟踪状态；
14. 测试接口，接口信息从哪里获取呢？
常用的有三种方式：
1 通过抓包工具比如fiddle，charles获取接口信息
2 通过浏览器开发者工具，networks查看接口请求信息
3 当然最直接和最靠谱的就是接口文档，这就是接口的需求文档。一个规范的接口文档最基本的应该包含了（接口请求地址，请求方法，请求头信息说明，接口入参说明(包括参数的类型、是否必填、长度范围等)，接口响应示例等）。
15. 什么是接口测试？
通过测试不同情况下的输入参数和与之对应的输出结果来判断接口是否符合或满足相应的功能性、安全性要求；接口测试就是代替前端或者第三方，来验证后端实现是否符合接口规范.；
16. 常见接口
webService接口：是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。可以使用的工具有SoapUI、jmeter、loadrunner等；
http api接口：是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json字符串格式，有get和post等方法，这也是最常用的两种请求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；
17. 接口测试的好处?(为什么要做接口测试)
测试接口的正确性和稳定性，能快速定位bug，提高测试效率.
能为项目平台带来高效的缺陷监测和质量监督能力；
平台越复杂，系统越庞大，接口测试的效果越明显（提高测试效率，提升用户体验，降低研发成本）
18. 接口测试原理
模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收响应数据后并进行判断。
请求： 是否正确, 默认请求成功是返回200, 假如请求错误返回400, 404, 500等状态码
检查：返回数据的正确性与完整性
安全性：接口一般不会暴露在网上任意被调用,需要做一些限制,比如必须登录或者请求次数、频率限制
19. 接口测试流程
定位服务器接口资源并提交测试数据，然后查看响应结果是否符合预期
定位接口资源(URL)
提交测试数据
检查响应结果
20. post请求体数据类型？
