谈谈性能测试那点事

原文连接：https://bbs.aliyun.com/read/256964.html?spm=5176.bbsl243.0.0.ooaefv

现在的系统几乎都要做性能测试的，虽然每个系统做性能测试的目标不同，但总体来说，需要的都是测试结果对生产系统要有参考价值的，

那么如果保证 呢 ？对于没有相关经验和性能理论不深的测试人员来说，或多或少的会进入如下误区：

a.测试 环境 随意搭建，早期性能测试开始萌芽的时候，将所有的应用都部署在一台机器上，随便压一下就行了，这种理论在如今的性能测试
人员基本不存在了，大家都知道， 测试环境 系统架构和生产环境要相同， 操作 系统、中间件、应用版本、参数 配置 都近可能与生产环境相同。

b.随便挑选两笔主要业务压一下，由于时间、人力、经费等限制，做一下简单的压测，这种想法目前在不重视产品质量的公司都存在，都是
先保证功能、性能做不做无所谓，要知道功能决定现在，性能决定未来，业务发展下去了，后续还会做性能测试的，并且花费的代价非常昂贵。
因此正确的做好是通过生产上历史 数据 来统计高峰时候的业务量（老系统）或者业务调研（新系统），至少要挑选60%以上占比较高的业务或者
业务量排在前10名的业务。

c.脚本设计上，有很多性能测试人员根本不重视，以为录制一下就OK了，但实际上业务是否做成功了，根本不清楚，如果业务都没有真正做成功
那么压测又有什么意思呢？任何 工具 都无法 自 动判断业务是否成功了，因此需要测试人员在脚本脚本里面添加检查点进行验证，有时还需要关联
和参数化。根据我经验来说，录制的脚本，很多性能测试人员根本不添加检查点进行验证。

d.业务 场景 设计，不同系统 服务 的客户不一样，业务场景也有很多差异，多种典型场景需要综合考虑，很多性能测试人员都知道单业务场景
但忽略了混合业务、业务突变、稳定性、可靠性、批量、批量对联机交易影响场景。

e.并发用户数来衡量系统的性能，很多性能测试觉得系统性能是靠并发用户数来衡量的，一上来就来1万甚至10万个用户并发，最后测试结果
响应时间都要几十分钟、 错误 一大堆、曲线图根本没法看。实际上衡量系统处理能力的性能是靠TPS（笔/秒）来衡量的,范围是一定的，不会
随着并发用户数的增加变动很大，增加并发用户数，响应时间就会增加很多，如果真要用并发用户数来衡量系统性能，建议增加响应时间限制这个
条件。

f.跑出来的业务量和占比跟生产上一致么？很多性能测试人员认为业务占比就是用户占比，这种观念是错误的，如果你那样做，那么你跑出来的
业务占比可能跟生产上大相径庭，生产上A业务占比90，B业务占比10%，而你压测出来的结果正好相反，这样的测试结果有参考价值么？

g.分析及调优，这个是性能测试的一个难点，很多测试人员认为这都是开发的事情，其实不然，一个优秀的性能测试人员需要学会如何分析及调优，
这里面需要一个漫长的过程，不仅需要扎实的功底、还要有动手的经历以及分析的经验，需要不断地积累