应先用pm.response.json()解析响应，再通过可选链或逻辑兜底获取total（如res.total || res.data?.total）和列表（如res.list || res.items），最后用Array.isArray(list) ? list.length : 0取长度并断言total >= list.length。
如何用 pm.response.json() 提取分页总数和当前列表长度
分页接口通常返回类似 {"total": 127, "list": [...]} 或 {"data": {"total": 127, "items": [...]}} 的结构。校验一致性，第一步是准确取值——不能靠肉眼数数组长度，也不能把嵌套字段写错。
常见错误：直接写 pm.response.json().list.length，但实际字段名可能是 items、records、data，甚至带下划线如 page_data；或者 total 在根层级，也可能藏在 meta 里。
- 先用
console.log(pm.response.json())看清真实响应结构 - 用可选链（如果 Postman 运行环境支持 ES2020+）：比如
pm.response.json()?.data?.total，避免因字段缺失报Cannot read property 'total' of undefined - 稳妥写法用逻辑判断兜底：
const res = pm.response.json(); const total = res.total || res.data?.total || res.meta?.total || 0; - 列表长度建议统一用
Array.isArray(list) ? list.length : 0，防止后端偶尔返回null或字符串
用 pm.test() 写断言：total 是否 ≥ 当前页数据量
分页总数 total 必须大于等于当前页返回的条目数，否则说明后端计算逻辑出错（比如漏统计、缓存未刷新），或前端误把 total_pages 当成了 total。
注意：不要断言 total === list.length，那是只有第一页且 page_size > total 时才成立的特殊情况；常规校验是“上限关系”，不是“相等关系”。
- 正确断言示例：
pm.test("total >= current page size", () => { const res = pm.response.json(); const list = res.list || res.items || []; const total = res.total || 0; pm.expect(total).to.be.at.least(list.length); }); - 如果接口还返回
page_no和page_size，可以进一步校验：pm.expect(list.length).to.be.at.most(res.page_size) - 避免在 Tests 里重复解析 JSON：一个请求只调一次
pm.response.json()，赋给变量复用
为什么不能只校验 total，还要比对数据库 count？
Postman 断言只能验证接口返回自洽，但无法确认 total 值本身是否真实。比如缓存未更新、SQL 漏写 COUNT(*)、或分库分表聚合出错，都可能导致 total 固定返回 100。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
真实测试中，你得额外发一个查总数的请求（如 GET /api/users/count），再用 Pre-request Script 或 Tests 把两个响应关联起来比对。
- 在 Pre-request Script 中设置变量：
pm.variables.set("expected_total", 0); - 在 count 请求的 Tests 中写：
pm.variables.set("expected_total", pm.response.json().count); - 在分页请求的 Tests 中读取并比对：
pm.expect(res.total).to.equal(pm.variables.get("expected_total")); - 关键点：两个请求必须在同一个 Collection Runner 批量执行，且顺序不能颠倒；否则变量跨请求不生效
page_no=1 时 list 长度为 0，但 total > 0 怎么办？
这通常不是 bug，而是业务逻辑允许空列表（比如按时间筛选，第一页没匹配到数据）。但需要明确这是预期行为，而不是后端漏查条件或 SQL 写错。
此时光靠接口响应无法判断对错，必须结合查询条件反推：
- 检查请求参数：比如
start_time=2099，那list=[]就合理；但如果传的是status=active却返回空，而数据库明明有 active 数据，就得怀疑 SQL 的 WHERE 条件或索引问题 - 建议在 Tests 里加日志：
console.log(`page_no=${pm.variables.get("page_no")}, page_size=${pm.variables.get("page_size")}, total=${total}, list_length=${list.length}`);，方便批量跑时快速定位哪页异常 - 如果发现某页
list.length 且page_no * page_size ，说明不是最后一页却提前截断——大概率是分页参数被后端忽略或类型转换失败（比如字符串 "10" 被转成 0）
分页断言真正难的不是写几行代码，而是搞清业务语义：total 是精确总数还是估算值？空列表是否允许？page_no 从 0 还是 1 开始？这些细节一旦和后端理解不一致，再严密的 Postman 脚本也拦不住线上问题。
