性能测试基础（一）

前言‍‍

不论做什么事情，我们首先要有一个思路，那就是做这个事情的第一步做什么，第二步做什么.......第三步......，接着按照计划好的每一步开始实施，这样就形成了做一件事情的流程（方法论），那么测试项目的性能也一样，需要提前规划好测试这个项目性能应该怎么做，今天我就根据自己在公司做性能的一些经验以及大佬们的一些观点聊一聊性能测试流程以及流程中的关键节点需要的团队和需要做的事情。

性能测试流程‍

1.基础版流程

各阶段目标

1 获取性能指标

‍       性能指标包含业务指标和技术指标，业务指标包含时间指标和TPS指标，技术指标包含服务器的CPU，内存，IO，网络等，那什么样的性能指标才算是合理的呢？接下来从4种场景来看

‍‍1.1 基准场景

基准场景简单的说就是单接口的性能测试，为什么要测试单接口，直接测试容量场景不行嘛？我们知道容量场景是由多个接口组合而成的业务流，那么大家想一想，如果这个容量场景中的某一个接口出问题是不是会直接影响容量场景的性能结果？所以我们在进行容量场景测试之前首先要进行基准场景测试，保证单个接口的TPS能满足容量场景的需求且这个接口已经达到最大TPS，如何判断有没有达到最大TPS呢？服务器的任意一项资源打满就认为它已经达到最大TPS，后面会写一篇文章关于如何正确做基准场景测试的文章。基准场景的性能指标示例如下表(注意：这里只是示例，实际工作中根据需求修改)：

1.2 容量场景

容量场景上面也说过是由多个接口组成的业务流程，真实的生产环境中整个业务流程中的每一个接口所占的比例是不一样的，容量场景就是要模拟这种情况，所以容量场景中关注的是业务比例和总TPS，根据每个接口的比例计算单个接口的TPS，而每一个接口在容量场景中所占的比例怎么获取呢？可以找相关运营同事或者自己通过ELFK抓取，之后我们根据获取到的数据实现比例控制，Jmeter中可以通过吞吐量控制器控制各接口的比例，容量场景的性能指标又是什么样的呢，这里也给出如下示例(注意：这里只是示例，实际工作中根据需求修改)：

1.3 稳定性场景

 稳定性场景的目标是系统可以长时间稳定运行，无内存泄漏等现象出现， 这样就提取出稳定性场景中的关键点，场景要运行多长时间和用多少个线程来运行这个场景。这就会出现2个疑问，为什么要运行这么长时间以？为什么要用这个线程数来运行？大家都知道企业的技术团队在上线以及上线后的服务维护都需要运维团队的支持。线上环境每隔一段时间都会进行维护，我们只需要知道多长时间运维1次，维护时间内总请求量是多少？根据请求量及时间计算出稳定性场景的目标是多少TPS？从而计算出稳定性场景需要执行的时间。

用多少线程来运行呢？稳定性场景所执行的业务通常都是容量场景的业务，那么，在容量场景达到稳定TPS时所需要的线程数是否可以用这个数进行稳定性场景的测试呢？我认为是完全没问题的。当然前提是容量场景的TPS已经满足当前需求。稳定性场景性能指标示例(注意：这里只是示例，实际工作中根据需求修改)：

1.4 异常场景

异常场景的设计是否成功在于对系统架构了解的是否透彻，只有知道了系统架构，请求的走向，才有可能知道在哪一个节点会出现问题，出现问题后系统的表现是什么样的。所以异常场景的设计大概分这么几步：

第1步：分析系统架构中各组件‍‍‍‍‍‍‍‍

第2步：列出可能会出现问题的情况‍‍

第3步：根据可能会出问题的情况设计异常场景‍‍

异常场景性能指标示例(注意：这里只是示例，实际工作中根据需求修改)：

2.构建性能模型‍‍‍‍‍‍

各场景性能指标都已经设计完成后，我们要构建性能模型，性能模型包括监控模型和测试模型。‍‍‍‍‍

监控模型包括系统级监控(全局监控)和对出现问题的计数器进行监控（定向监控）。

测试模型除以上4类性能场景外还需要考虑各类场景的递增策略和递减策略，压力线程数的计算等等，这些具体的内容在下一篇文章中在写吧。

3.制定性能方案

以上都确定好之后要制定一份性能方案，在网上其实有很多这类的范文或模版，它是我们后续执行性能测试时候的指导，我们要按照制定的方案一步一步执行。既然它是后续性能工作的指导，可见性能方案是一个很重要的文档，所以性能方案室需要各团队参与对其进行评审的，评审后我们按照性能方案执行想你工作。具体性能方案内容我后面会写出一份模版，有需要的话可以私信我要一下就可以，这个就不在这里展现啦。

4.定位性能瓶颈‍‍‍‍

在我看来性能测试人员具有竞争力的能力除性能方案的制定外就是瓶颈定位以及给出优化建议的能力啦。那么如何定位性能瓶颈以及如何让相关技术人员认可你的结论呢？这就引出另一个话题，性能瓶颈定位过程及证据或者称之为证据链，这样不但可以让技术充分信任你的结论还能减少沟通和扯皮的时间成本，也提高了工作效率，还可以提高自己的价值。

废了这么多话，到底应该怎么做呢？今天就将方法教给大家，如果大家有更直观的方法也欢迎分享：

从场景监控结果中判断是否存在瓶颈，如果存在继续步骤2

根据该场景的请求路径拆分其响应时间

对响应时间长的节点组件进行监控并判断产生瓶颈的计数器

梳理这个计数器的底层逻辑

得出结论(调优建议)

以上步骤中1通过压力测试工具取到的数据进行判断，2根据链路监控数据可以判断，3根据监控平台可以查看，某些监控平台监控不全的指标可以根据命令查看，4需要自己的基础能力或者查看官方资料等，5有了前4步自然就出结论啦。

5.数据环比‍‍

与线上数据进行环比的目的是为了验证我们的性能测试场景是否正确，只有性能场景正确才能确定我们的性能测试以及结论是有意义的，具体怎么样做数据环比，简单的说就是通过命令或者工具获取日志中某一时刻峰值时的各接口请求占比，与我们性能测试场景中接口的占比进行对比，如果不一致，我们返回去修改我们的性能场景后再次执行，至于如何如果实现获取和获取步骤在下周的文章中分享。

6.性能测试结论

性能测试结论包括性能调优报告和性能测试报告，性能测试报告中最重要的就是结论啦，结论分别从不同场景进行总结，比如，经过基准测试，所有接口都满足TPS需求，经过容量场景测试可得出系统最大TPS为xxxx，系统可支持的最大在线用户数xxx，经过稳定性测试可得出系统可稳定运行xxx时间，最大业务累积量xxx，xxx服务器资源使用率稳定在xxx，无内存泄漏现象出现等等，异常场景场景结论可以这样写，在xx异常情况下TPS符合预期走势等等。

得出这些结论我们的性能才是有意义的，才是老版本想要看的结论，这些结论并不是你想咋写就咋写的，需要有数据支撑，也是需要经过计算得出的，具体如何计算，这块后面我会专门写一篇文章。性能报告中其他内容这里就不写啦，实际意义不是很大，有需要的可私信我要一下性能报告模版。

性能调优报告主要记录优化前和优化后各场景的性能变化，它能体现技术的工作成果和性能测试的价值，这个一定要有记录。