交付前只测功能够吗？功能、兼容、压力测试到底测什么

软件项目验收时，最常见的场景是：开发方现场演示一遍功能流程，甲方点头签字。可上线不到一个月，投诉来了——老款手机打不开页面、促销高峰系统卡死、换了台电脑数据导不出来。这些问题在验收时全都不在「功能演示」的射程之内。原因很简单：软件测试远不止「功能能不能用」一种。

功能测试：验收的起点，不是全部

功能测试验证的是「正常操作下结果对不对」：下单流程走不走得通、金额计算准不准、审核流转发给谁。这块大多数团队都会做，但容易被忽略的是异常路径——填了错误格式的手机号会不会有提示？断网时提交订单会怎样？重复点击提交按钮会不会生成两笔订单？功能测试做得好不好，一半取决于异常场景覆盖得全不全。

兼容性测试：不同设备、浏览器上还是不是同一个软件

你的用户不会都用同一款手机。兼容性测试关注的是软件在不同环境下的表现：设备维度（不同品牌、屏幕尺寸、新旧机型）、系统维度（iOS与安卓各版本、Windows与macOS）、浏览器维度（Chrome、Safari、微信内置浏览器）。企业里最常见的坑是只在开发者自己那台新手机上测试，结果中老年用户占比高的产品在老款机型上白屏。验收前要求开发方提供主流机型和浏览器的测试记录，比事后补救便宜得多。

压力测试：平时好用，人多的时候还好用吗

功能测试通常是一个人操作，可上线后是成百上千人同时用。压力测试通过模拟大量并发用户，回答三个问题：系统最多扛多少人（容量上限）、扛不住时表现如何（是排队变慢还是直接崩溃）、高峰过去能不能自动恢复。做活动、发优惠券、整点抢购这类场景，压测是上线前的必答题。企业验收时可以问开发方两个具体问题：预估峰值并发是多少？压测做到多少？数字对不上，就是隐患。

给企业的验收建议

• 测试项写进合同：把功能、兼容、压力三类测试的范围和标准写进验收条款，别只写「功能验收合格」。
• 要测试报告不要口头保证：规范的团队会输出测试用例清单和执行记录，报告本身就是交付物的一部分。
• 组织真实用户试用：正式上线前安排小范围灰度试用，收集不同设备、不同网络的反馈，比内部测试更能暴露问题。

软件交付的质量，从来不是签验收单那一刻决定的，而是测试做没做足决定的。多问一句「兼容和压测测过吗」，可能帮你避开上线后最大的几次事故。