性能测试报告和性能调优报告有什么区别？为什么调优前必须找第三方做一次基线测试？

经常有客户打电话来问：“你们做不做性能调优？”我们一般先反问一句：“你要的是证明，还是结果？”

这两个东西不是一回事，搞混了，钱花了，最后验收还是过不去。一个是“体检单”，一个是“治疗方案”

性能测试与性能调优

一、两者的区别

1.性能测试报告是结论性的

它回答一个很窄的问题：在约定的条件下，系统达没达到约定的指标。依据通常是 GB/T 25000.51-2016，测并发用户数、响应时间（一般会标P90/P95）、吞吐量、资源占用率、稳定性长压。结尾那句话基本长这样：“经测试，系统在500并发下订单提交成功率≥99.9%，平均响应时间1.8秒，符合需求规格说明。”

它不负责告诉你为什么慢，也不负责改。慢就是慢，写进报告里，那就是客观事实。

2.性能调优则是一连串的动作

定位瓶颈、改配置、改SQL、加缓存、调整线程池、再压、再定位。交付物一般是方案、变更记录和回归对比数据，属于技术服务，不属于“可检项”。严格说，“性能调优报告”这个标题本身就不规范，机构能盖章的是《性能效率测试报告》，调优是服务过程记录。

所以别指望一份报告既当验收凭证又当优化手册。真要两样都要，就得拆成两份东西：一份带章的测试报告交上去验收，一份不带章的调优记录留给运维接着用。

二、为什么调优之前，非得先做一次基线测试

说实话，这不是我们的流程洁癖，而是不做的话，后面谁都说不清。

第一，没有基线，优化效果没法证明。

客户常说“明显快了”，但评审会不看“明显”。他们要看的是同一批场景、同一套数据、同一个环境配置下，P95从4.2秒降到1.6秒，CPU峰值从92%掉到58%。这组对照数据只能来自调优前的那一次正式压测。事后补不出来，环境变了、数据量变了，数字就对不上了。

第二，责任要划清楚。

系统慢的原因很多：代码问题、SQL没走索引、中间件配置、网络带宽、数据库参数，甚至底层虚机的资源争抢。如果一上来就直接动手调，调好了是你的功劳，调不好就是原来的底子烂，两边都容易背锅。先出一份基线报告，把瓶颈落在哪一层写明白，后面改什么、谁改、改完怎么验证，就有据可依了。

第三，避免瞎调。

这是最贵的一种坑。我们见过太多次：团队凭经验把连接池从200加到800，压测发现更慢了，因为线程切换和锁竞争上来了；或者给某个接口加了缓存，QPS是好看了，但数据一致性出了问题，上线后被审计打回。基线的作用是先告诉你瓶颈在哪，而不是让你把所有能动的地方都动一遍。定位对了，可能只改一条索引；定位错了，折腾三周回到原点。

有个真实的例子：某政务系统上线前压测，基线显示订单查询接口在300并发时P95已经到7秒。开发团队第一反应是加服务器。但基线报告里的资源数据很怪，CPU只到40%，数据库等待时间却占了大半。顺着查下去，是一个关联查询没走复合索引。加了索引，没加机器，P95掉到1.4秒。要是当时直接扩容，钱花了，问题还在。

三、几点实在建议

性能测试注意点

1.基线一定要“可复现”。场景脚本、数据量级、环境配置、监控口径，全部留档。不然调完之后回归对不上数，等于白测。

2.别让开发和调优的人自己出基线。不是信不过，而是独立第三方的数据在验收会上才站得住。自己人出的数字，专家问一句“你这环境和生产一致吗”，很容易卡住。

3.指标一次定死，别把愿景写进去，“希望越快越好”这种话进不了报告，也只会让报价变贵。写清楚几个场景、多少并发、成功率阈值、要不要长压，剩下的交给数据。

4.调优和复测最好分开计价、分开交付。混在一起最容易出现的结局是：钱按调优收了，验收时对方说缺一份正式的测试报告，还得再来一轮。

如果你那边正准备做性能这块，可以把系统的架构、用户规模预估、验收文件里对性能的要求发我看看。我们帮你判断是该先做基线还是直接上专项，顺便给一份能拿去比价的测试范围说明，指标写清楚了，报价才可比，返工才少。

标签：性能调优、性能测试