功能测试、性能测试、兼容性测试区别

刚接手测试的人最常卡在一句话上：都是跑用例、都出报告，为什么还要分成功能、性能、兼容性三拨？分不清就会把接口连通性当性能验证，把换浏览器当兼容性全测，报告写出来没人认。这篇只讲一件事：三类测试各自在回答什么问题、用什么手法回答、什么时候不适用，最后给一份可以照着排的执行顺序。

刚接手测试的人最常卡在一句话上：同样是跑用例、同样出报告，为什么还要分成功能、性能、兼容性三拨人来做？分不清的直接后果是，把接口能连通当成性能验证过了，把多换两个浏览器当成兼容性全测完了，报告交上去没人认。这篇就讲一件事：这三类测试各自在回答什么问题、用什么手法回答、什么时候压根不该做，最后给一份能照着排的执行顺序。

先把一个前提说清楚：三者既不互斥也不互相替代。功能过了不代表扛得住压，扛得住压不代表换台机器就不崩，换台机器不崩更不代表功能做对了。任何一类的结果都不能拿来给另一类交差，这是入门阶段最容易踩的坑。

三类测试分别回答什么问题

把它们想成三个人问三个不同的问题，判断标准就清楚了。功能问「做没做对」，性能问「扛不扛得住」，兼容性问「换个环境还成不成立」。一个问题回答完，另外两个还是空白。

功能测试

输入符合预期时输出是否正确、异常输入是否有合理提示；核心是可预期、可复现，换个人跑结果应该一样

性能测试

给定负载下的响应时间、吞吐量和资源占用；它不判断对错，只看快慢和稳定性，同一个功能可以既正确又慢到不能用

兼容性测试

换浏览器、系统、机型、依赖版本之后行为是否一致；重点是「一致性」，不是「有没有功能」

注意最后一条常被忽略：兼容性测试比对的是同一功能在不同环境下的表现差异，所以要先把功能在一个基准环境跑通，再去比。基准都没跑通就去铺环境，测的是自己的 bug 还是环境问题，说不清。

手法差异：从用例设计到结果判定

性能测试特别要说一句：判定看的是分位值，不是平均值。平均值好看但尾部很差，用户体验照样崩，所以要多轮取样、看分布，而不是跑一次截个图就下结论。

还有个共同前提容易被跳过：接口连通和鉴权得先正常。连都连不通的时候，先到 /tools/verify 做一次在线实测，确认是网络或鉴权问题，别把这类问题当缺陷提上去，白耗一轮沟通。

什么情况下这三类测试不适用或代价过高

• 功能测试不适合用来自证性能：小数据量下跑再多次也压不出瓶颈，硬套只会得到「好像挺快」的安慰性结论。
• 性能测试不适合在功能还没收敛时做：需求还在改，压出来的数据下个版本就作废，等于白跑一轮，还占着环境。
• 兼容性测试不适合无边界铺开：环境组合会指数级增长，没有用户分布依据时，先覆盖占比高的少数几档就够。
• 一次性的脚本、临时活动页、内部小工具，通常做到功能验证加关键路径冒烟即可，不必三类齐上。

判断依据可以归结成两条：这东西会不会长期跑在真实用户面前？改动频率高不高？两个都是「是」，三类都得排；有一个是「否」，就果断砍掉对应那类，把时间留给更值得的地方。

落地时按什么顺序排，每步做完交什么

1. 定目标与验收线功能聚焦回归范围，性能先写下响应时间和错误率的上限口径，兼容性先列环境矩阵。写完确认一遍：这条线是谁认的、按什么口径量。
2. 功能打底核心链路先跑通。验证方式是关键路径全部通过，且异常输入有合理提示；这一步没过就别往下走，否则后面两类测的都是坏系统。
3. 性能设基线先量一次当前延迟当基线，可到 /tools/speed-test 记录，再逐步加压看拐点出现在哪。验证方式是至少两轮取样结果接近，抖动大就加量再测。
4. 兼容性抽样按用户占比挑前几档环境，剩下记录进待覆盖清单。验证方式是每档环境的输出与基准环境逐条比对，差异项单独归档。
5. 留可复盘证据每步都留输入、环境、观察到的现象与判定依据。缺一样，结论就站不住，别人也没法替你复现。这一步最容易被省，也最容易被追问。

顺序上有个朴素的道理：功能没通就压性能，是在给一个坏系统测速度；性能没基线就铺兼容，环境差异和性能差异会混在一起，最后谁也说不清问题出在哪。按上面的顺序排，每一步的产出都能当下一步的输入。

另外提醒一句：具体工具的报价、各家方案的实时表现这类会变的信息，别凭印象写进报告。需要引用时，到 /price-watch 看当时的数字，到 /rankings 看当前排序，口径统一了报告才立得住。