很多刚转测试的同学，接到的第一个任务叫「测一下这个接口」，做完又被问「它的并发扛不扛得住」，两件事听起来都在调接口，做法却完全不同。这篇不堆概念，而是从目标、用例设计、工具关注点、结果怎么看这条线拆开，帮你判断手上这个任务到底属于哪一类，以及先做哪个、各自做到什么程度算够。
很多刚转测试的同学，接到的第一个任务叫「测一下这个接口」，做完又被问「它的并发扛不扛得住」。两件事听起来都在调接口，工作方式却完全不同：前者盯的是逻辑对不对，后者盯的是压力下的表现。混着做，最容易出现的结果是——功能用例写得很全，压测脚本却拿同一套脏数据去跑；或者压测数字漂亮，但参数校验的漏洞一个都没发现。
这篇不堆概念，而是从目标、用例设计、工具关注点、结果怎么看这条线拆开讲，帮你在接到任务的前五分钟就能判断：这活属于哪一类，先做哪个，各自做到什么程度算交付。判断标准比工具名更重要，工具换了思路还在。
先看目标：一个问「对不对」，一个问「扛不扛得住」
接口测试验证的是单次调用的正确性。你关心状态码是不是符合约定、返回字段结构有没有变、边界值传进去会怎样、异常入参会不会把服务打挂、没带鉴权能不能访问到别人的数据。它的结论形式是「通过 / 不通过」，失败样本可以精确定位到某一条用例。
性能测试验证的是在给定压力下的表现。你关心响应时间的分布、每秒能处理多少请求、错误率从哪个并发量开始抬头、CPU 和内存在压力下有没有见顶。它的结论形式是「在什么条件下，表现是什么样」，不存在简单的通过或不通过，只有可接受还是不可接受。
| 对比维度 | 接口测试 | 性能测试 |
|---|---|---|
| 回答的问题 | 这个逻辑对不对 | 多大压力下扛得住 |
| 用例来源 | 输入组合与预期输出 | 业务场景与压力模型 |
| 数据要求 | 覆盖边界即可 | 需贴近真实规模 |
| 环境要求 | 测试环境够用 | 尽量贴近生产配置 |
| 产出形式 | 通过率、失败样本 | 延迟分位、吞吐、错误率 |
- 需求里出现「正确 / 失败 / 兼容 / 权限」——先做接口测试
- 需求里出现「多少并发 / 多快 / 稳定 / 不能超时」——要做性能测试
- 同一个接口两件事都要做，但结论不能互换：功能通过不代表能压，压测跑通也不证明逻辑对
- 最省事的判断法：把需求原话念一遍，看它问的是状态还是数字
用例怎么设计：单点覆盖 vs 场景与压力模型
接口测试用例围绕输入组合与预期输出展开。正向调用来一条，反向和异常来几条，边界值、空值、超长字段各来一条，幂等和重复提交单独设计。写的时候顺手问自己一句：如果这条挂了，用户会遇到什么。问不出来，说明这条用例可删。
性能测试用例围绕业务场景展开，动手前先把链路画清楚：谁在调这个接口、调用频率多高、请求里带的数据量多大、是纯读还是读写混合。很多人压测失败不是服务扛不住，而是压根没想清楚自己模拟的是哪个真实场景。
- 第 1 步：跑通正确性先确认接口在正常参数下能返回预期结果，这是后面所有工作的前提。
- 第 2 步：固定数据集为性能测试单独准备一份干净、规模可控的数据，别复用功能测试留下的脏数据。
- 第 3 步：固定调用方式把请求参数、鉴权、超时设置写死在脚本里，确保每次压的是同一件事。
- 第 4 步：量一条基线在低压力甚至单请求下先测一次，记下延迟和资源占用，作为后续对比的参照。
工具关注点不同：断言 vs 指标
接口测试工具的核心能力是断言和用例组织。你真正要看的输出是用例通过率、失败样本列表、以及出问题时的请求响应原文。选工具时先看团队已经在用什么，能接入现有平台就别新引一套，脚本的长期维护成本比工具本身贵得多。
性能测试工具的核心能力是稳定施压和指标采集。你要看的是并发数能不能稳定保持、延迟分位数据全不全、错误率统计准不准、有没有资源监控。压力发不上去或者数据采不全，后面的结论都是猜的。
- 断言
- 判断单次响应是否符合预期的条件，接口测试的核心产出点
- 分位延迟
- 把响应时间排序后取特定位置的数值，比平均值更能反映真实体验
- 吞吐
- 单位时间内系统成功处理的请求数量，需与错误率一起看
- 基线
- 空载或低压下的表现，没有它就无法判断后续数据是变好还是变差
结果怎么看：失败要复现，慢要有对照
接口测试失败先别急着提单。按这个顺序排查：断言是不是写错了、环境是不是不对、测试数据是不是被别人改了、最后才怀疑代码本身。拿请求和响应原文对齐，能复现再提，附上最小复现步骤。
性能测试结论不能只看平均值。平均值好看但慢请求占比高，用户照样骂。要看延迟分位、错误率随并发上升的变化趋势，以及资源占用有没有在某个点突然抬升——那个点往往就是系统的拐点。
- 没有基线就不要下「变慢了」的结论，先和单请求表现对比
- 错误率一旦抬头，先看是超时错误还是业务错误，两者排查方向完全不同
- 指标口径要写清是客户端测的还是服务端统计的，两者差异经常被当成 bug 吵
- 什么情况下不适用：一次性活动页、内部低频工具，做完整性能测试收益很低，抽查接口正确性就够
- 压测报告里必须带上复现命令，否则开发只能凭感觉改代码
上手顺序与交接清单
推荐顺序是固定的：先跑通接口正确性，再把数据集和调用方式固定下来，最后才逐步加压。跳过前两步直接压，压出来的问题往往分不清是代码问题还是数据问题，白折腾一轮。
交给开发的性能报告，至少包含这几项：场景说明、数据规模、并发梯度、延迟分位、错误样本、复现命令。少一项，开发就得反过来问你，一来一回半天没了。
| 交接项 | 写清什么 | 为什么重要 |
|---|---|---|
| 场景说明 | 模拟的是哪个真实调用链路 | 避免开发按错误场景优化 |
| 并发梯度 | 从低到高怎么加的压 | 能看出问题从哪个量级开始 |
| 错误样本 | 具体哪类请求失败了 | 定位方向依赖这个 |
| 复现命令 | 可直接跑起来的脚本或命令 | 开发能自查，不用反复找你 |
如果你需要对照当前主流模型接口的延迟表现，可以到站内 /tools/speed-test 和 /ai-status 看当时的实测数据，那里的数字比口头印象可靠。
下一步把你手上这个任务按目标分类，先确认它问的是「对不对」还是「扛不扛得住」，再决定用例怎么写、报告怎么交。对照站内 /tools/speed-test 的实测数据，可以帮你判断自己的压测结果在什么量级上算正常。→常见问题
刚入行只能学一个，先学哪个？
先学接口测试。它是所有测试的基础功，会看请求响应、会设计边界用例，转性能测试时脚本和数据准备都能直接复用；反过来先学压测工具，容易只会跑脚本看不懂失败原因。等接口能独立测明白，再往并发和容量方向走。
接口测试通过了，性能测试就一定能过吗？
不一定，两者互不推导。功能正确只说明单次逻辑对，并发下可能出现连接池耗尽、锁竞争、缓存击穿、下游限流等单次调用根本碰不到的问题。反过来，压测跑出漂亮数字，也不能证明边界入参和异常分支处理正确。
性能测试是不是一定要专业工具和独立环境？
不一定，取决于结论要用来干什么。只是想知道接口大致的响应量级，脚本循环加统计就能看个大概；要用来定容量、写进上线评审，则需要贴近生产的环境、独立数据集和明确的指标口径。环境差异太大时，结论只当参考，别当承诺。
