这应该是一个老生常谈的话题了。

之前也分享过，在做性能测试之前，对大部分同学来说，最重要的问题就是搞清楚性能测试需求。

一般来说，需求大概是下面这样子的。

• 给我们的系统/产品做一下性能测试。这种需求太虚了，不细化的话基本上是没有可操作性的。
• 测一下我们的最大在线人数。这种需求基本上是做容量，看一下项目/产品的最大容量是多少。
• 线上有一个问题，但是我们找不到问题的原因，希望可以压测复现一下问题，以证实一些猜想。这种需求是重现线上问题，要求脚本能够尽可能准确的模拟真实业务。

关于如何做需求分析，之前应该有分析过，这里就不重复了。很多情况下，对于测试同学来说，搞清楚性能测试的目的和需求往往是非常困难的，除了经验之外，我们还需要跟开发同学有一些共同话题，了解开发同学是怎么想的，有哪些问题是需要注意的。不过这就需要我们对开发技术有一定的了解，不然很容易跟开发之间产生信息不对称，进而开发搞开发的，我们自己测自己的，没产生合力，最终的结果应该是很难让大部分人满意的。

其实，除了需求，环境因素也非常重要。

性能测试在哪个环境测，其实很有学问。

一般来说，我们建议在跟线上环境几乎一致的独立性能测试环境去测。为什么呢？很大程度上是架构的关系。不同的架构对于测试结果的影响是巨大的。大部分情况下，我们的测试环境跟正式环境的差异还是相当明显的。测试环境可能就是单机，生产环境可能是集群，我们在单机上压出来的问题可能在集群上不会出现，另外集群上出现的问题我们在单机上可能也难以重现。

最简单省事的做法就是在正式环境上压测，不过这要注意脏数据和错误恢复的问题。我们希望在正式环境上的压测不会影响真实用户的使用，不会修改真实用户的数据，并且压出问题之后系统可以迅速恢复。

当然，大部分情况下，在正式环境做压测是相当危险的。我们一般建议在跟生产环境几乎一致的环境上做性能测试。那么这个几乎一致是什么意思呢？

• 架构基本一致，但可以缩容。比如线上的反向代理之后的负载均衡机器有10台，我们可能用2台就够了。
• 数据量基本一致。线上有100万条数据，那么我们压测的时候也用100万条左右的数据量。
• 数据脱敏。不要暴露用户的敏感信息。
• 网络条件一致。线上的带宽是1G，那么压测的时候也用同样的带宽。

那么我们定义了独立的性能测试环境之后，这个环境谁来搭建和维护呢？

我是建议测试同学自己搭建和维护。那么问题就来了，搭建测试环境的话，除了一些基本的运维操作(安装软件，修改配置)之外,我们还需要什么知识呢？

我们需要理解系统的架构。

我在面试的时候喜欢让候选人简单画一下他所测系统的架构图，另外当你在某公司进行技术晋级的时候，无论哪个技术通道，都会问所在产品的架构，可见理解架构是相当重要的。

搭建测试环境可以让我们更好的去学习系统架构。我记得之前的公司新人来了之后都会给他几天的时间去搭建一套全新的开发或者测试环境，有时候是类生产环境，搭建环境的时候，比如我们需要安装redis，那么我们可以问开发同学，redis是做什么用的，用于什么业务场景或者用于解决什么业务问题。长此以往，我们的架构理解能力一定会有所提升。

另外很多情况下，架构的演进是为了解决一些已知问题，或者是为了能够服务更多的用户，这种架构更替中的讨论和技术选型也很有蕴藏着性能测试的需求，到后门一通百通，很多事情都会得心应手了吧。

最后，基础很重要，基础好的话一些概念理解起来可能会更加顺畅。比如链路层转发进行负载均衡的方式，如果你对链路层不理解，那么这个概念理解起来就会比较的困难了。

文章很长，总而言之，大家在做性能测试之前，可能需要

• 分析清楚性能需求
• 理解系统架构
• 搭建测试环境
• 努力补充基础知识

这些是我的一些不成熟的见解，希望对大家有所帮助。