项目背景：客户要上线新订单系统
上个月接手了一个电商后台系统的交付测试任务。客户是一家做生鲜配送的公司，原来的订单处理慢，高峰期经常卡住。新系统开发了三个月，现在要准备上线，我们负责最后的交付测试。
这时候的测试不是找bug那么简单了，而是要看整个系统能不能在真实环境下跑通，用户用起来顺不顺手，数据能不能对得上。
第一步：先理清楚交付测什么
很多人以为交付测试就是把功能点过一遍，其实没这么简单。我们列了四个重点：
- 核心流程能不能走通（比如下单、支付、发货）
- 和老系统的数据迁移有没有问题
- 性能能不能扛住早高峰的订单量
- 操作界面是不是符合业务人员的习惯
比如他们仓库人员文化程度不高，如果界面上一堆专业术语，就算功能没问题也用不起来。
第二步：模拟真实环境搭测试场景
我们借用了客户一台和生产环境配置一样的服务器，数据库也还原了上周的真实数据快照。网络延迟、带宽限制都按实际调低，就是为了复现他们门店连接总部时那种“卡一下”的感觉。
有个细节：他们很多员工用的是旧款安卓手机扫码入库，我们就专门找了两台同型号设备做兼容性测试。结果真发现问题——新版界面在低分辨率屏幕上按钮重叠，点不了确认。
第三步：让用户自己来操作
光我们测不够，得让真正的使用者参与。约了他们仓库主管老李过来，让他按日常习惯操作入库流程。他一边点一边念叨：‘这个该放上面’、‘我平时都是先扫再填数量’……
我们发现设计的流程和实际操作反着来，赶紧记下来调整。这种问题自动化脚本根本测不出来，只有真人上手才会暴露。
第四步：写可执行的验收清单
最后不是交一份厚厚的测试报告，而是给客户一张检查表。每一项都是具体动作，比如：
1. 登录订单管理页，搜索最近30分钟的订单，确认列表能正常显示
2. 点击导出Excel，检查文件是否生成且内容完整
3. 切换到移动端，在弱网环境下提交一笔新订单，观察响应时间这张表客户自己也能照着做，相当于教会他们怎么验证系统好坏。
上线前最后一轮压力测试
正式切换前一天晚上，我们用工具模拟了早8点的峰值流量。原计划撑500并发，结果到380就开始报错。查出来是库存接口没加缓存，紧急打了补丁。
第二天早上6点，团队全员在线盯着监控。看到第一波500多笔订单平稳处理完，客户老板发来消息：‘这次真不卡了’。那一刻才觉得这半个月没白熬。