1. 接口自动化测试采用了具体哪些技术

:::info

  • python进行脚本编写
  • request库来发送请求
  • pytest进行脚本编写
  • allure输出测试报告
  • tomcat进行报告的展示

  • ddt测试数据 :::

    2. 接口自动化测试过程中碰到了哪些问题，如何解决

    :::info

  • 方法命名

    • 不同产品线，需要挑选模块进行执行，但是实际是有困难的，因为命名习惯不同，后面进行相关命名规范。
  • 动态数据
    • 刚开始做接口自动化时，一开始接口文件放在csv中，但是有些时候会出问题，如生成订单，需要获取当时数据；
    • 编码的唯一性。手机号码的反复插入，同样号码会报错，设计函数，如果为none时需要随机生成新的手机号

  • 接口依赖，接口请求不同，可能需要鉴权（token提取） :::

    3. 接口自动化测试是人工触发执行，还是自动执行的？

    :::info

  • 回归测试

  • Jenkins持续集成 :::

    4. 接口自动化在什么样的时间点进行接入，为什么要做接口的自动化测试/

    :::info

  • 新接口，postman或者jmeter进行测试，

  • 考虑回归的话，考虑工作量的话，已经通过的接口，编写自动化脚本， :::

    5. 接口自动化和ui自动化的区别

    :::info

  • ui自动化打开浏览器，模拟人的操作，基于ui界面

  • 接口，不关注前端界面
  • ui自动化测试适用于ui界面基本稳定，变动相对频率低

  • 接口主要从业务逻辑层进行调用， :::

    6.接口的鉴权机制是怎么样的，或者如何对请求方进行身份的验证

    :::info

  • 用户登录的时候是jwt的token机制，请求开发对token的时限进行更改

  • 工具

  • python :::

    7.你一般关注什么样的一些测试点

    :::info

  • 功能

  • 性能
  • 安全
  • 兼容
  • 易用性
  • 可靠性
  • 接口方面
    • 请求类型中不同的报文
      • 必填
      • 非必填
    • 请求正文
    • 请求参数
    • 测试结果
      • 响应报文是否正确
      • key值和key是否正确
      • 响应的正文的格式是否正确
      • 响应的正文数量
      • 响应的时间
      • 新老系统的兼容，业务逻辑的变动 :::

        8. 接口测试都关注哪些方面

        :::info 思路,不限于以下方式：
        可以从请求和响应两个方面进行回答
        请求方面：
        1. 要检查提测接口请求时，请求报文报文正确或者错误的情况，入参的必填与非必填的情况
        2. 根据等价类，边界值等方法对请求报文中的数据进行设计，构造不同场景的请求报文进行测试
        3. 从权限或者身份的合法非法角度进行请求
        响应方面：
        1. 检查返回的响应报文结构是否正确，key信息是否都正确
        2. 检查响应报文的value对应的值，格式2020/10/10，数据类型是否正确 100 ‘100’
        3. 检查响应报文的状态码，标准或者自定义的是否正确
        4. 检查响应报文返回的记录数是否正确
        5. 检查响应报文返回的信息是否有安全要求，是否加密处理等
        6. 检查响应报文返回的时间是否正常
        7. 考虑接口的幂等性
        8. 考虑接口的兼容性（业务的变更）
        …… :::

        9. get 和post接口的区别

        :::info
  1. get在url中进行参数传递，安全性较差；post一般在包体进行参数传递，当然也可以在url进行
    2. get传参有长度限制，但post在包体传参没有长度限制
    3. get在浏览器回退时是无害的，而post在浏览器回退时会再请求一次
    4. get请求只能支持url编码(application-x-www-form-urlencoded),post请求支持多种
    5. get请求，浏览器会把http header和data一起发送出去，服务器响应200，整个是一个TCP数据包
    而post请求，浏览器先发送的是header信息，服务器响应100 continue，浏览器再发送data，服务器响应200，整个过程是发送了两个TCP数据包
    6. 在Restful风格的接口设计中，get主要用来查询数据，post主要用来提交数据 put修改数据 delete 删除数据 :::

    10. 接口的请求头header中有哪些key

    :::info 列举请求头或者响应头中的几个key即可
    host cookie content-type ……

:::

11.接口的幂等性怎么理解

:::info 同一个接口，多次发出同一个请求，服务端必须保证该操作只执行一次
例：
用户针对某个订单进行支付操作的接口，就必须保证幂等性，不能出现同一个订单，多次扣款情况” :::

12. 接口对应的http标准状态码有哪些

:::info “标准状态码指
1 信息，服务器收到请求，需要请求者继续执行操作
2 成功，操作被成功接收并处理
3 重定向，需要进一步的操作以完成请求
4 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误
具体的如下的必须掌握：
200 请求被正常响应
400 Bad Request 客户端请求的语法错误，服务器无法理解
401 Unauthorized 请求要求用户的身份认证
403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求
404 Not Found url请求路径错误或者服务端资源不再存在
500 服务端错误” :::

13. 什么情况下要做关联，关联是怎么做的

:::info 当脚本的上下文有联系就用管理
对某件商品的购买 :::

14. 怎么进行接口测试？

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

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

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

　　异常测试：参数异常：关键字参数（应用其他的关键字替换进行测试）、参数为空、参数多少（通过添加参数增添个数），参数错误。数据异常：关键字数据（填入的数据用其他的数据语言的数据替用）、数据长度、数据为空、数据错误。
　　
　　由于我们项目前后端调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
　　–也可以用 接口自动化来实现，就是用代码实现，框架和UI自动化差不多，发送请求用断言来判断。 :::

15. 接口测试用例的设计思路

:::info 目的：测试接口的正确性和稳定性；
　　原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程；
　　重点：检查数据的交换，传递和控制管理过程，还包括处理的次数；
　　核心：持续集成是接口测试的核心；
　　优点：为高复杂性的平台带来高效的缺陷监测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显（提高测试效率，提升用户体验，降低研发成本）；
　　用例设计重点：通常情况下主要测试最外层的两类接口:数据进入系统接口（调用外部系统的参数为本系统使用）和数据流出系统接口（验证系统处理后的数据是否正常）；
　　PS：设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能，外部用户真正需要什么功能；

1 输入

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

　　a 必填项校验

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

　　b 参数长度校验

　　参考接口文档即可。

　　c 参数值的有效性校验

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

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

　　d 参数组合校验

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

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

　　f 参数值的默认值的校验

　　参考接口文档。

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

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

2 接口逻辑

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

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

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

　　以打款接口为例：

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

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

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

3 输出

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

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

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

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

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