上周同事小张升级了公司内部的报表客户端，安装包双击下一步、下一步，最后点“完成”就去泡咖啡了。结果下午用户反馈：导出Excel卡顿严重，点击按钮要等3秒才响应。查了一圈发现，是新版本里加了个实时图表渲染逻辑，但没做性能压测——更关键的是，没人跑一遍老版本的性能基线对比。
性能回归不是“再跑一次脚本”
很多团队把“性能回归测试”理解成：每次发版前，把上次的JMeter脚本再执行一遍，看TPS掉没掉、错误率超没超。这顶多算“性能快照”，不是真正的回归。真正的回归，得明确“和谁比”——必须和上一个稳定版本在相同环境、相同数据量、相同操作路径下横向对比。
比如你测登录接口，不能只看当前版本耗时800ms是否合格；得拉出上个版本的记录：同样是100并发、500条测试账号数据，当时是620ms。这次涨到800ms，就得立刻查原因，而不是看一眼“没超2秒”就放行。
安装环节就是第一道性能关
“软件安装”栏目常被当成纯操作流程，其实它是客户端性能回归的起点。安装过程本身就有性能指标：静默安装耗时、首次启动时间、主界面渲染完成时间、基础功能（如打开本地文件、连接默认服务器）的响应延迟。这些数据一旦建立基线，后续每次安装新版，就能自动采集对比。
举个实际做法：用批处理+PowerShell记录时间戳。
echo %date% %time% > install_start.log
start /wait setup_client_v2.3.1.exe /S
echo %date% %time% > install_end.log再配合启动后自动执行一段轻量JS检测主窗口加载完成事件，把结果写入日志。这些数据攒够3个版本，就能画出趋势图——某次安装耗时突增40%，马上倒查是不是打包工具换了压缩算法，或者捆绑了新SDK。
别让“能用”掩盖性能退化
有次我们上线一个PDF预览插件更新，安装后所有功能按钮都点得动，测试报告写着“通过”。但用户实际用起来，翻页明显卡顿。后来回溯才发现：插件初始化阶段多调了一次全量字体扫描，而这个动作在旧版里是懒加载的。问题不在代码逻辑错，而在性能行为变了——回归测试只验功能通路，漏掉了资源加载时机的比对。
建议在安装完成后的“首次运行检查清单”里，硬性加入3项性能观测点：
• 主进程内存占用（启动后30秒内峰值）
• 首屏绘制时间（从双击图标到看到菜单栏）
• 本地缓存目录体积增长量（对比上一版安装后同时间点）
这些不用复杂工具，Windows自带资源监视器、macOS的活动监视器，配合几行shell命令就能抓到。关键是形成习惯：装完不点“关闭”，先盯10秒任务管理器。