性能测试前我们要做些什么

---

前言

当接到一个项目需要压测，进行性能测试时，该怎么入手，该怎么准备。我想这是我们作为测试来说，首先需要考虑的事情，不能上来就压，就测吧。不能像功能测试一样，上来就测吧，需求，用例不清楚的状态下，就直接测吧。以下，是我在测试过程中，学习和实践中 对于性能测试前的准备总结，欢迎一起探讨学习。

一、内容概览

废话不多说，先上图，一图胜千言。

二、测试前准备

1. 梳理业务逻辑，大致给出不同接口的业务比例

大家都知道，一个项目，各个业务在实际访问过程中肯定是不一样的，比如登录接口和账户修改密码接口。他们直接的访问比例肯定是不一样的，我想没人每天都去修改下自己的密码吧，，但登录就不一样，如果实现token过期机制，一段时间不登录就会要求你重新登录。所以在这个背景下，就要根据业务实际的需求，制定出不同的业务比例。这样做的目的一方面性能压测一定要符合实际，不能上来随笔分配500个线程跑全部接口，另一方面就是在之后的写脚本的过程中，根据不同的业务比例，从而制定不同的压力级别。如果还未上线的项目，这事可能就需要产品和业务方共同拟定。

2.性能场景和对应指标的确立

这个很好理解，就像我们写case一样，知道需要覆盖那些场景，测到什么程度，所以我们测试前，需要根据需求先写出对应的case。性能测试也一样，知道我们这次测试过程中，需要测到那些场景，测试的目标是什么，都不知我们要测什么，那还怎么玩呢，对吧。

常见的场景你比如说： 基准场景，容量场景，稳定性场景，异常场景。基准场景我们就要压出系统最大容量，是否符合容量场景要求，是否存在瓶颈等。容量场景根据上一步的业务比例，跑出总的tps是否符合业务目标。等等。场景和指标的确立这是需要结合业务需要和实际进行评估和制定的。

3.造数据

这个就不多说了，巧妇难为无米之炊。你不能让jemter 空着跑吧。造的数据一定要符合实际业务，那些可以重复循环使用，那些不能使用。这些基底的数据，我想，是我们测试之前需要和开发讨论清楚地，这些数据的量是否符合线上使用的量，这个数据循环使用，是否对性能压测过程的偏差等等。

4. 编写脚本

有了业务比例，有了数据，下面我们就可以着手编写测试脚本了，根据不同的场景需求，编写不同的业务脚本，和执行策略。这里需要重点强调一点是，线程执行的策略一定是递增连续的设计。比如每隔30秒增加一个线程，持续300秒等。

5. 搭建性能监控

做这一步之前，我们需要跟项目组首先确认的是整个项目的部署架构是什么，根据对应的架构，列出那些组件需要监控，从而做出全局监控部署的搭建。

有了上一步，先对全局监控都有了一定的部署了解，有助于在压测过程中，快速的定位到问题所在，有着先全局在局部的观念。然后针对局部所在的问题，我们利用对应的定向分析工具分析找出问题所在。这不是此篇文章讨论重点，之后进一步阐述。

总结

以上5步走大致阐述了性能测试之前，需要我们要准备的材料和目标。从而有了一个大致的目标，知道路该怎么走，这样就不会上来比较蒙，不知对应的切入点是什么。体现出测试人的专业性。对于每一步具体的准备和注意事项，将会放在下一讲具体阐述，欢迎大家一起讨论学习，点个关注。