一.说说你们公司做接口测试的流程？（接口测试怎么测）

1.获取接口文档，分析接口需求和业务逻辑

了解接口业务逻辑，请求类型，请求地址，请求数据，响应数据，依赖接口

2.设计接口测试用例，内部评审用例

根据参数类型，是否必填，约束条件，参数之间的关联，参数组合，状态码等结合实际
组内评审用例，完善用例

3.编写测试脚本，调试脚本

Jemeter、postman,编写脚本，或者用代码来写

4.校验响应数据，分析结果，输出报告

校验HTTP状态码，错误提示，响应数据、输出测试报告

5.持续集成

可以结合Jenkins,构建自动化测试，达到持续集成的效果，还能发报告到组内成员的邮箱

二、做接口测试遇到的最大的问题是什么？怎么解决的？

问题：

没有接口文档
接口文档不齐全
接口文档已将过时

解决方案：

第一步：工具辅助

通过抓包工具（Fiddler,Charles）抓取需要进行测试的接口

第二步：分析问题

抓取到需要接口之后，深入分析接口的组成（Request、Response）
从请求体中可以获取到：请求方法、请求地址、请求头、Cookies
从响应体一般就是拿到响应数据和它的数据结构，方便后续作为其他接口的入参数据

第三步：询问解惑

请求头（Headers）和Cookies一定是重中之重
因为包含的参数，你可能并不知道它有什么用，是不是必传，要怎么传值
而响应数据的参数含义也可能会比较复杂，不一定都了解
此时可以找接口对应的开发，直接问他这些参数是啥意思

此题考察目的

参数的含义和来源
参数的作用域
响应数据的含义

三、接口测试出现错误怎么分析？

首先需要分析错误的类型
如果返回的是4**状态码那就是接口写的有问题
如果是400：一般还会提示Bad Request,代表请求体写错了，可能请求方法错了（本是POST方法但是用了GET请求）、请求数据类型错了（没有传Json格式的数据）、请求参数漏传
如果是401：认证问题，认证信息还未得到服务器的认证通过，可能是Header少传了Authorization参数
如果是403：权限问题，用户认证通过了，但是没有权限访问请求地址，可能是用了HTTP协议，但实际要求的是HTTPS,SSL问题
如果返回的是正常响应体，只不过内容不符合预期结果，那很可能是传参的问题，这里可能参数不全，参数值类型，参数值不正确的问题

四、一个合格的接口文档应该包含什么？

接口功能
请求方法（post、get）
请求地址
请求头（body）
响应数据
返回的状态码解析（包含请求成功、请求失败的状态码）

五、一个完整的接口测试应该包含哪些类容

单接口测试

保证接口的正确性和健壮性
也就是说，既要保证这个接口可以按照需求，正确处理传入的参数，给出正确的返回，也可以按照需求，正确拒绝传入非正确的参数，给出正确的拒绝性返回
总结：需要有足够的用例保证接口正确处理各种正常情况和异常情况

业务流程的接口测试（多接口测试）

主要是保障通过多个接口的串联操作可以完成需求中提出的业务逻辑
比如：下订单的完整流程：浏览商品-添加商品到购物车-下单-支付订单-查看订单，这样就是一个完整的业务流程
总结：重点在于业务流程是否能跑通（场景测试）

接口测试中的签名问题你是如何解决的？

了解开发的签名方式
如果只是一个Token,则拿到登录接口返回的Token即可
如果签名还涉及算法加密，需要找到开发拿加密算法代码，然后将参数值加密后再传递

接口测试效率为什么会比UI自动化效率高？

从以下几个维度来说

学习成本

接口测试可以用工具，比如postman、Jmeter等待，界面友好而且学习成本低，当然也可以用写代码的方式
UI自动化测试能完全使用工具代替写代码的方式比较少，学习成本可能比较高，不仅要了解前端基础知识，还需要了解代码框架

时间成本

接口测试用工具的话时间成本会很低
UI自动化从0开始搭建的话，整个生命周期会很长

稳定性

接口稳定性肯定会比UI界面友好很多，特别是在敏捷开发模式下，需求变动很快的同时，界面可能也会随之变动的非常快，但是接口可能并不需要频繁的变动

后期维护成本

因为接口稳定性好，所以后期的维护成本肯定会大大减少，而UI自动化测试的维护成本则会增加

投入产出比

接口测试不仅可以从用户角度关注界面层的业务逻辑，也可以从代码角度关注底层的业务逻辑，可测范围更广，发现的问题层次更深，问题的影响范围也会更广
UI自动化只能针对主流程主功能的一些页面做回归测试，更多是避免在迭代过程中引发新的错误，保证主功能流的可用性
所以接口测试的投入产出比肯定是高于UI自动化测试的

Postman如何做接口自动化测试？

  • 拿到接口文档，先分析接口的业务逻辑，确认接口的关键信息
  • 在postman先把接口脚本写出来，调试一遍，看看是否能跑通
  • 若跑不通，确认是脚本写的有问题还是接口文档没有更新，及时跟开发进行沟通，确保接口文档是最新的
  • 根据接口文档编写接口自动化测试用例
  • 首先会从业务逻辑方面来考虑，设计正常场景和异常场景
  • 然后从参数边界值考虑，比如参数是否必填、参数类型、参数长度、参数取值范围、参数有限制
  • 再就是响应结果，比如状态码、响应信息、数据校验等

  • 自动化测跑通后，会结合Jenkisn，完成持续集成的流程

    Jmeter操作接口的方式

    问：post请求，把接口请求体进行加密，将加密之后的请求体放回请求中，Jmeter怎么做？

  • Jmeter有提供md5加密函数，也有自定义加密函数，可以直接在请求体中对需要加密的数据调用函数

  • 如果有特殊加密方法，可以找开发拿到加密方法，在前置BeanShell里面调佣
  • 加密方法来对请求数据加密，然后将加密后的数据put进变量池，最后请求体拿到加密后的变量

接口自动化测试用例是怎么管理的？

  • 首先，我会分成三个部分进行管理：测试用例集、测试用例、测试步骤
  • 测试用例集是一个文件夹，包含多个测试用例
  • 测试用例是一个yaml文件，包含多个测试步骤
  • 测试步骤在yaml文件对应的是一个test键
  • 对于单个测试用例来说，会包含一个全局配置项config和若干个测试步骤test
  • config为全局配置项，作用域为整个测试用例，test对应单个测试步骤，作用域仅限于本身
  • config可以包含测试用例名称，全局变量，全局参数，公共host、公共headers
  • test可以包含测试步骤名称，请求URL,预期结果等
  • 还有一个关键字文件，主要是封装一些经常需要复用的接口

依赖于第三方数据的接口如何进行测试？

  • 首先得知道第三方接口的返回 数据有哪几种可能
  • 然后可以使用SoapUI等工具直接调用第三方数据接口的WebService，通过返回值来查看第三方数据的接口是否调用正常

  • 也可以利用MOCK工具来模拟第三方返回的数据

    接口的外部调用，自动化中是怎么处理的？

    分两种情况

    调用的是项目中的其它接口（依赖接口）

  • postman：依赖接口通过后置脚本保存响应数据到环境变量中，然后接口通过前置脚本拿到这个环境变量去传参即可

  • Jmeter：依赖接口通过后置处理器里的Json提取器或者正则提取器把响应数据保存到变量中，然后接口可以直接调用该变量去传参

  • Python Requests:使用yaml文件管理依赖接口和测试接口

    第三方提供的接口，比如微信支付等待

  • 一般会用mock的方式，模拟第三方接口的响应内容

  • 最简单的可以用Fiddler、Charles抓包工具来mock

  • 也可以用moco,他是一个mock-server，基于JAVA开发的框架，可以模拟Http、Socket等协议的接口

    做接口自动化遇到最困难的一件事是？

    如何解决依赖接口过多的场景

    怎么解决困难的？

    解决依赖接口过多的重点是测试用例的设计思路

  • 首先，我会分成是三个部分进行测试用例管理：测试用例集、测试用例、测试步骤

  • 测试用例集是一个文件夹，包含多个测试用例
  • 测试用例是一个yaml文件，好汉多个测试步骤
  • 测试步骤在yaml 文件对应的是一个test键
  • 对于单个测试用例来说，会包含一个全局顶配项config和若干个测试步骤test

  • 还有一个关键字文件，主要是封装一些经常需要复用的接口

    举个栗子

  • 假设一个D接口需要依赖A、B、C三个接口和一个关键字，那么yaml文件就有四个测试步骤

  • 前三测试步骤分别是A、B、C接口的请求信息，包含请求地址、请求头、请求数据，还需要保存响应数据

  • 第四个测试步骤就是待测接口D，它可以调用前面测试步骤保存下来的响应数据，也可以直接调用关键字，然后作为请求数据的一部分

    多接口依赖你是怎么写的？

    将复用性高的接口封装成一个关键字，整个项目公用一个关键字文件，当接口需要用到直接调用即可

    那如果同事依赖的接口改动了，维护成本不是很大吗？

    直接修改关键字就行，不需要修改待测接口或者测试用例，维护成本还是挺小的

    用excel跟yaml文件有什么区别？

  • excel易用性更好，因为就是表格，平时工作写用例也会用到，可以复制粘贴

  • yaml文件有自己的格式需要去遵守，yaml文件的数据可以更快速的转化为其它类型的数据，而且分层结构清晰，扩展性更好

    做接口自动化的框架、环境都是你这边搭建的？

  • 是的，框架是用到了Python requests库 + Pytest +Allure

  • 直接在公司服务器上，先搭建Docker环境
  • 然后通过Docker 搭建Jenkins、git两个容器

  • 最后将项目部署到git上，结合Jenkin完成持续集成

    为什么选择Pytest+ALLure

  • 首先Pytest是单元测试框架，Allure是测试报告框架

  • Pytest相对于unittest来说，他编写用例格式简单，可以直接使用Python断言，提供了10种前置后置处理方式，自带参数化装饰器，扩展性高可以安装多种插件，能集成Allure

  • Allure报告里面数据非常全面，界面也很友好，可以直接集成到Jenkins里面发送测试报告

    接口覆盖率如何？

    覆盖了总接口数的50%-60%，每一个接口一般都会有10条左右的测试用例

    你是只校验状态码吗？具体响应内容不校验吗？

    一般分为两种情况

  • 如果接口是增删改类型的，会校验响应状态码和响应信息，严谨点的话会去数据库校验数据是否正确

  • 如果是接口查询，不仅会校验响应状态码和响应信息，还会校验查询结果集的Json结构和预期Json结构是否一致，这里会用到python的jsondiff库 (Json断言 要学习下)

    最终，在实现持续集成的过程中发现什么问题吗？发现问题的占比大概是怎么样的？

    通过率大概有95%
    有发现一些问题，主要是一些在界面不会发现，但在接口层来说可能会出现问题
    比如：

  • 越权问题，比如横向越权，纵向越权，不同学校的人可以删除、创建、查询其他学校的班级

  • 同一条数据可以重复删除，取消
  • 请求参数传非指定数据类型的数据，比如参数类型是整型，但传了个字符串，导致服务端报代码级别的原生错误
  • 页码、页数传入负数可以正常响应