前言

大汉堡工作第203天，本篇记录我第一次接触接口测试任务，最近有些懈怠啊~

接口文档

1. 首先就是接口地址，接口测试时用来访问接口。如果一个接口分为两个或多个不同的地址则需要分开进行测试，。
   
2. 接下来就是定义接口的请求方式，post方法是向指定资源提交数据，请求服务器进行处理。
   
   请求方式除了post外，还有Get、PUT、DELETE、HEAD、OPTIONS。
3. 入参示例和请求参数，作用是理解输入格式，构建请求体；设计测试用例。
   
   
4. 请求头（Request Headers）参数作用是定义客户端如何与服务器通信，对测试人员的作用主要有四点：①告诉服务器请求体中的数据格式②身份验证，确保只有经过授权的用户才能访问受保护的资源③提供用户代理信息：发起请求的客户端类型（如浏览器版本、操作系统等）④定制化请求行为：会话ID、语言偏好等
   
5. sign生成规则，放在接口的前置条件里，生成sign（签名），主要是为了确保请求的安全性和完整性。有效性一般不验证，都是3分钟或者用后即焚，目的是为了防止别人盗用。
   
6. 响应参数以及响应示例的作用是帮助测试人员了解API在不同情况下的预期输出，包括成功和错误场景；验证接口的正确性。可以根据这些信息来设计测试用例，确保所有可能的输出都被覆盖
   
   

单接口测试

环境配置

首先是配置测试环境，目的是为了确保测试能够在正确的上下文中运行。

通用配置是配置一些全局参数，本次我没有使用到。HTTP配置里配置根URL，请求头里的Authorization设置为${token}，代表了访问特定接口所需的认证令牌。

全局前置脚本的目的是为了在所有测试用例执行前统一处理一些公共逻辑，如登录获取token、初始化变量等，从而简化测试用例编写并提高测试效率。
下面的全局前置脚本的作用是执行一次登录操作以获取认证token，并将该token存储为全局变量供后续测试用例使用，使用beanshell语言，脚本执行顺序为步骤内前置脚本前。

梳理接口测试场景

使用xmind或者其他工具先简单梳理一下接口测试场景。一是因为一些接口的case执行需要他上游的接口先执行一次，比如积分解冻接口，需要先执行积分冻结接口，不然就可能报如下错误：

测试接口

1. 添加接口
   按照接口文档要求填写参数，请求头可以不写全不影响。因为接口文档里的请求头有的需要写在case里的前置操作里，值没有确定时不方便填写；若是确定值可以填写。通常建议至少包含Content-Type。
   
   如果之后的接口测试用例出现了以下报错 – Authorization: Basic Og==，需要将接口的认证方式改为No Auth：
   
2. 单接口测试（以一条正向用例举例）
   API保存完后点击CASE添加接口测试用例
   

请求头中的参数需要前置脚本生成时先编写前置脚本

正确填写请求头，这里需要填写完整。

正确填写请求体

最后添加断言规则，不会写正则表达式的可以使用JSONPath来进行判断。JSONPath需要先执行调试获取响应结果。

执行完成之后点击推荐JSONPath断言，在出来的窗口中选择需要断言的数据即可。

这样一条正向的接口测试用例就编辑好了。逆向的测试用例根据需要修改数据即可。

接口自动化

1. 点击接口自动化，全部场景里可添加子模块
   
   点击右下角指南针一样，一直在转圈的按钮可以导入之前写好的接口测试用例
   
   选择CASE，这里有复制和引用两个按钮

• 复制：点击 “复制” 按钮，会将选中的接口用例数据（如 “退回不正确的积分” 等用例）进行复制操作，生成一个与原用例完全相同的副本，该副本独立于原用例，后续对副本的修改不会影响原用例，反之亦然。比如复制了 “退回不正确的积分” 用例后，修改副本的 API 路径等信息，原用例的相关信息不会改变。
• 引用：点击 “引用” 按钮，是创建一个对选中接口用例的引用关系。被引用的用例与原用例指向同一份数据，若原用例发生变化（如修改了用例名称、API 路径等），通过引用使用该用例的地方也会同步变化。例如原 “退回不正确的积分” 用例的 API 路径被修改，那么引用该用例处显示的 API 路径也会随之改变。
  根据需要的场景进行选择，这里我都是选的复制。
  
  根据测试场景选择好对应的case，编排好case的顺序就可以执行自动化测试了
  

怎么写复用性高的自动化测试用例

比如在编写一个成功消费积分再退回的场景时，我的接口顺序如下：积分余额查询；组合支付积分冻结成功；组合支付积分扣减成功；积分余额查询；成功退回积分；积分余额查询
积分余额里的断言是写死的，等于固定值。
举个例子:执行了积分冻结和积分扣减接口操作后，剩余的积分还有760分，所以第二个积分余额接口的断言就直接用JSONPath拿取积分数据和760对比。
那这样只要我传入token的测试账号的积分发生变化，这个场景里的第二个积分余额查询断言就会发生错误，那该怎么处理这个问题呢？

解决办法之一就是使用全局变量，使用代码逻辑来进行判断。
全局变量可以在后置操作里提取，有两种方法

• 使用JSONPath提取变量：适用于不需要进行运算的变量
  eg：JSONPath表达式：$.data.point ；变量名：point_before_deduction
• 使用脚本编写变量：适用于需要进行运算的变量
  eg：def expectedPoint = point_before_deduction - deduction_point
  vars.put(“expectedPoint”, expectedPoint.toString())

定义完全局变量后就可以在断言里使用了。根据上面的例子，在第一个接口的后置操作里提取未进行扣减操作的积分。

第三个扣减积分的接口提取扣减的积分的值

第四个接口，积分余额查询接口JSONPath提取扣减完的积分的值，后置脚本计算期望的积分值并放入全局变量。

再在断言里添加脚本进行判断
PS:建议自己写脚本或者交给AI写，系统自己生成的代码总是出错

同样的操作再在最后一个积分查询接口执行一次，问题解决。这样不管传入token的测试账号的积分如何变化我都不需要维护脚本了。

总结

文章首先介绍了接口文档，如地址、请求方式等要素。接着阐述单接口测试流程，从环境配置到用例编写。最后介绍接口自动化，包括导入用例、编写高复用性用例及解决断言问题的办法 。