一、什么是接口关联
在接口测试或接口自动化测试中，接口关联是指：
将前一个接口返回的数据，作为后一个接口的请求参数或请求头，从而保证业务流程能够正确连续执行。
如果不进行接口关联，后续接口往往会因为 缺少必要参数或鉴权信息 而访问失败。
二、常见的接口关联场景
注册与登录关联
在注册系统后，系统会生成 账号和密码 。
如果希望使用注册成功后的账号和密码进行登录，就需要：
从注册接口中获取账号、密码,将获取到的数据传递给登录接口
登录与用户信息访问关联（本例重点）
在未登录状态下，直接访问用户个人信息页面通常会失败，这是因为：
服务器需要通过 token 判断用户是否已登录,token 一般由登录接口返回
因此，需要：调用登录接口, 从登录接口响应体中 提取 token, 将 token 作为请求头参数（如 user_token_header）再访问用户个人信息或博客列表接口
验证码与注册接口关联
在一些系统中：
验证码接口和注册接口是 分开的,注册时必须提交验证码
此时就需要：从验证码接口中获取验证码,将验证码作为参数传递给注册接口完成注册
以「登录 token 关联用户信息接口」为例说明
(1)添加Json提取器
比如在博客登录请求中添加JSON提取器
通过names of created variables 创建变量user_token
可以看到这个就是登录接口的响应体内容
我们通过 $ 找到根节点,通过 .data找到data元素(具体提取规则可以看这个文章:
Python 使用 JsonPath 完成接口自动化测试中参数关联和数据验证 - 测试派
match No. (0 for random): 指定"提取第几个匹配结果
| Match No. 值 | 含义 |
|---|---|
1 |
取 第 1 个 匹配结果 |
2 |
取 第 2 个 匹配结果 |
3 |
取 第 3 个 匹配结果 |
0 |
随机取一个匹配结果 |
-1 |
取 所有匹配结果（数组形式） |
default value: 当没有匹配到任何结果时，使用的默认值
具体在博客列表请求中使用,因为没有成功登录返回的token作为,列表请求的user_token_header自定义请求头的值,就会出现401鉴权问题
(只有返回格式为JSON的时候才能使用JSON提取器)
三、断言
断言在接口测试中起着非常关键的作用，它的核心意义在于判断接口返回的结果是否符合预期。仅仅请求成功、返回了 200 状态码，并不能说明接口真正"可用"，因为业务逻辑可能仍然存在错误。断言正是用来弥补这一问题的，它通过对接口响应内容、状态码或性能指标进行校验，帮助测试人员准确判断接口是否执行成功。
在实际项目中，接口往往承担着具体的业务逻辑。例如登录接口，不仅要返回成功状态码，还需要返回正确的用户信息或 token；再比如下单接口，即使服务器返回了 200，如果订单并未真正创建成功，这次请求在业务层面依然是失败的。因此，断言的存在是为了从"业务正确性"的角度对接口进行验证，而不仅仅停留在"请求是否能通"。
在 JMeter 中，**每当取样器执行完成并收到服务器响应后，JMeter 会自动触发断言，对响应结果进行校验。如果断言条件不满足，该请求就会被标记为失败，并在监听器中以失败请求的形式展示出来。**这一机制使得测试人员能够快速定位问题接口，而不需要逐条人工检查返回结果。
最常见的断言方式是响应断言，它可以用来判断响应体中是否包含某些关键字段或关键字。
例如，在登录接口中，可以断言返回内容中是否包含 "token" 或 "success"；在查询接口中，可以断言返回结果是否包含正确的业务数据。这种断言方式简单直观，也是接口测试中使用频率最高的一种。
除了校验响应内容，断言还可以用于判断响应状态码。通过断言 HTTP 状态码是否为 200、201 或其他预期值，可以初步判断接口在协议层面是否执行成功。这类断言通常作为最基础的校验条件，与响应内容断言配合使用，能够同时保证接口在技术层面和业务层面都符合预期。
我们可以通过断言code的200来判断是否执行成功也可以通过断言msg的信息是否为OK来进行判断
在测试模式中分别添加OK和OK1来进行比对
可以看到断言是起效果的
如果仅通过"响应体包含 OK"进行断言，只要返回结果中任意字段包含 OK，断言就会通过，这种方式存在误判风险。更合理的做法是针对具体字段进行精确断言，确保关键业务字段的值符合预期。
(68 封私信 / 82 条消息) 如何设置自动化测试断言？ - 知乎
在一些对性能有要求的场景中，断言还可以用于校验响应时间。例如，可以设置断言要求接口响应时间必须小于 2 秒，一旦超过该阈值，就判定该请求为失败。通过这种方式，可以在功能验证的同时，对接口的性能表现进行约束，及时发现性能退化问题。
需要注意的是，断言并不是越多越好。断言的设计应当围绕核心业务逻辑展开，只验证关键字段和关键规则，避免对无关信息进行过度校验。过多或过于复杂的断言不仅会增加维护成本，还可能在接口返回结构发生轻微变化时导致大量用例失败，影响测试效率。