功能测试性能测试接口测试的发布标准

每次上线前最怕的不是测不完，而是不知道该不该放行：功能用例跑过了、压测数字看着还行、接口返回也正常，但真出事往往就出在没人定过准入线。这篇按功能、接口、性能三类测试，各给一份「必须过」的判据和一张放行前清单，让你在评审会上能直接照着说。

上线前最怕的不是测不完，而是不知道该不该放行。功能用例跑过了、压测数字看着还行、接口返回也正常，但真出事往往就出在没人提前定过准入线。放行那一刻是拍脑袋还是照单子勾，事后差别很大。

这篇按功能、接口、性能三类测试，各给一份「必须过」的判据和一张放行前清单，让你在评审会上能直接照着说。数字类的东西一律不写死，需要对比就去站内对应页面核对当时的口径。

先定义「准入线」：三类测试各管什么，别互相替代

三类测试不是可以互相顶替的。接口全绿不代表用户点得通，压测跑得欢不代表契约没被悄悄改坏。先把各自管什么说清楚，后面判放行才不会互相甩锅。

功能测试

管「对不对」：核心路径、边界输入、异常分支是否都有明确结果，接口和性能都替代不了它

接口测试

管「契约稳不稳」：状态码、字段结构、错误码语义、鉴权失败路径是否与文档一致，重点在回归而不是覆盖数量

性能测试

管「扛不扛得住」：峰值并发、可接受延迟和错误率上限要先写下来，没定目标的压测等于白跑

三类测试的通过标准要写进同一张发布检查表，避免出现「功能过了但没人看性能报告」这种漏项。谁签哪一栏提前定好，评审时逐条念。

功能准入：哪些必须过，哪些可以带伤上线

功能准入最容易扯皮，因为「bug 不大」是个主观判断。解决办法是把阻断级和可放行级提前分类，分类之后再讨论具体某条缺陷归哪一类。

• 回归范围按改动影响面圈定：动了公共组件跑全量核心用例，只改文案可只跑冒烟
• 每种「可放行」都要有人签字确认影响面，不能靠口头说问题不大
• 缺陷登记要写清触发条件和兜底表现，方便发布后对照观测
• 回滚方案在放行前就要写好，不要等出事再现场想

接口准入：契约、错误路径与兼容性怎么判

接口测试的常见误区是只测成功返回。真正会炸的往往在鉴权失败、参数缺失、超限和超时这些路径上，尤其是中途换过网关或鉴权中间件的版本。

1. 列放行清单成功响应结构、鉴权失败、参数缺失、超限返回、超时返回五类场景各留一条实测记录
2. 核对错误码语义状态码和错误码含义是否与文档一致，别出现文档说客户端错误、实际返回服务端错误
3. 看字段兼容性新增字段是否可选、删改字段有没有下游依赖，重命名类改动一律按破坏性变更处理
4. 实测鉴权与限流不只看文档，换过网关或代理配置的改动，接口测试要整轮重跑
5. 验长连接行为流式或长连接接口单独验一遍中断与超时表现，不能只测短请求

接口契约的判定标准可以参考站内的资料库页面，把当时记录的字段约定和鉴权要求拉出来对照，避免只凭记忆判断。

性能准入：用你自己定的阈值判，不用别人的数字

性能准入的前提是先有自己的基线和阈值。公开榜单只能当参考，不能当放行依据，因为业务模型、数据量级和调用链完全不同。

接口延迟和吞吐的基线可以到 接口测速：先量出你的延迟基线（/tools/speed-test） 实测一轮，把结果记进检查表。有了自己的数字，判断就变成对照而不是猜测。

• 压测要在接近生产的配置下跑，小规格测试机的结论不能作为放行依据
• 性能不达标先分清是容量不够还是代码有问题，盲目加机器会掩盖慢查询和串行调用
• 数据量级要与生产接近，用空库压出来的漂亮数字没有参考价值
• 性能报告要有结论和责任人，不能只丢一堆图表进群

放行前最后一遍：清单、责任人与回滚条件

走到这一步，前面三类的结论应该已经能勾选。最后一遍不是重新测，而是确认每条判定都有状态和负责人，没有人默认通过。

回滚条件要提前定：错误率、延迟、核心功能失败率超过哪条线就回滚，而不是等出事再开会讨论。发布后头一段时间看日志、错误码分布和接口耗时是否与测试期一致。

把这次的口径和踩坑记下来放进站内指南里，下次直接复用，不用重新吵一遍标准。中转站相关的接口口径和可信度信息可以顺手到 站内中转站目录（/sites） 核对，避免拿旧信息判断。