# 性能测试场景，花5分钟了解一下?




小白学习性能测试的过程中，最普遍的一个问题就是没有办法弄清楚性能测试场景，这是因为，一般来说，小白收到的性能测试需求都是这样的

* 把某某系统的性能测一下
* 把这几个接口的性能测一下
* 我们要对这个项目做性能测试，你来搞一下

这些需求往往让人无所适从。当然小白们也不会坐以待毙，他们会去各种渠道求助，但是遇到这样的需求，恐怕大多数人都会表示爱莫能助。

今天我们就花5分钟的时间来了解一下性能测试的一种常见场景————重现线上问题。希望大家弄清楚了事情的始末之后能对性能测试场景有一定的感性认识。

事情的经过是这样的：通过日志发现，用户在夜间2点到2点30分的时候， 访问某些页面的时候特别的慢，可能是出现了性能问题，这时候需要小白同学来重现一下性能问题，以便让开发可以更加有目的性的进行问题排查。

小白同学大致可以这样做。

首先确定哪些页面的性能可能出现了问题；这是确定测试范围。

然后找相关人员，一般是运维或开发，了解一下在出现性能问题的段里，每个页面大概有多少用户进行了访问。这是确定压力负载。

接着申请一套跟线上一致的测试环境，如果没有办法做到一摸一样，那么我们可以适当的降低规格，但是软硬件架构和一些定时任务等都需要跟线上保持一致。这是搞定测试环境。

通过测试工具来实现性能测试脚本，来模拟发生性能测试的时间段内用户对系统的访问情况，并在测试环境上进行调试。这是完成测试脚本。

最后通过给予一定量的负载，并在对应的时间段(2点到2点30分)进行压力测试，重现线上问题。这是测试执行。

在本例中，系统2点到2点30分之间访问缓慢是因为线上定时任务在频繁的进行数据库操作，导致数据库读取缓慢，从而造成了性能问题，而小白在做测试执行时准确的重现了问题，开发经过排查，很顺利的定位到了问题根源，并解决了问题。

最后的最后，小白输出测试报告，记录测试过程，并对结果进行建议，比如晚上的定时任务建议采用读写分离来提升数据库性能之类的。

好了，这是出现问题并重现问题的过程，将这个任务的目的和过程调换一下位置，先自己想象一些测试场景，然后通过增加负载的方式去看看能不能发现问题，这是一般做先验性质的性能测试的过程。

综上，希望对你有所帮助，有问题欢迎留言讨论。                                      




原始封面

![课程图片](https://images.unsplash.com/photo-1506333438925-a6203045b492?w=300)