1.1　性能测试的基础

性能可以理解为一个系统实现其功能的能力，从宏观上可以描述为系统能够稳定运行、高并发访问时系统不会出现宕机、系统处理完成用户请求需要的时间、系统能够同时支撑的并发访问量、系统每秒可以处理完成的事务数等；从微观上可以描述为处理每个事务的资源开销，资源的开销可以包括CPU、磁盘I/O、内存、网络传输带宽等，甚至可以体现为服务器连接数、线程数、JVM Heap等的使用情况，也可以表现为内存的分配回收是否及时、缓存规则的命中率等。

性能到底有多重要呢？我们可以举一个网站访问的例子来说明，一个网页的加载速度如果超过4～5秒，可能25%的人会选择放弃。百度的搜索结果响应时间慢0.4秒，一天的搜索量可能会减少千万次左右。所以一个系统、一个网站的性能决定了其能够支撑业务的能力。

不同的群体对性能的理解可能会存在很大的差异，普通的用户更加关心响应时间和稳定性。

·　访问页面响应还要让我等多久才能加载出来？

·　为什么有时候会访问失败？为什么会出现错误502？

架构师和工程师可能更加关心架构设计和代码编写的性能：

·　应用架构设计是否合理？

·　技术架构设计是否合理？

·　数据架构设计是否合理？

·　部署架构设计是否合理？

·　代码是否存在性能问题？

·　JVM中是否有不合理的内存分配和使用？

·　线程同步和线程锁是否合理？

·　代码的计算算法是否可以进一步优化以减少CPU的消耗时间？

运维工程师可能更加关心系统的监控以及稳定性情况：

·　服务器各项资源使用率在正常范围内吗？

·　数据库的链接数在正常范围内吗？

·　SQL执行时间正常吗，是否存在慢查询日志？

·　系统能够支撑7*24小时连续不间断的业务访问吗？

·　系统是高可用的吗，服务器节点宕机了会影响用户使用吗？

·　对节点扩容后，可以提高系统的性能吗？

1.1.1　性能测试的分类

性能测试的类型通常包括如下几种：

·　性能测试：寻求系统在正常负载下的各项性能指标，或者通过调整并发用户数，使系统资源的利用率处于正常水平时获取到系统的各项性能指标。

·　负载测试：系统在不同负载下的性能表现，通过该项测试可以寻求到系统在不同负载下的性能变化曲线，从而寻求到性能的拐点。例如负载测试时，在只不断递增并发用户数时，观察各项性能指标的变化规律，找到系统能到达的最大TPS，并且观察此时系统处理的平均响应时间、各项系统资源和硬件资源的消耗情况。

·　压力测试（在后文也简称为压测）：系统在高负载下的性能表现，该项测试主要为了寻求系统能够承受的最大负载以及此时系统的吞吐率，通过该测试也可以发现系统在超高负载下是否会出现崩溃而无法访问，以及在系统负载减小后，系统性能能否自动恢复。

·　基准测试：针对待测系统开发中的版本执行的测试，采集各项性能指标作为后期版本性能的对比。

·　稳定性测试：以正常负载或者略高于正常负载来对系统进行长时间的测试，检测系统是否可以长久稳定运行，以及系统的各项性能指标会不会随着时间发生明显变化。

·　扩展性测试：通常用于新上线的系统或者新搭建的系统环境，通过先测试单台服务器的处理能力，然后慢慢增加服务器的数量，测试集群环境下单台服务器的处理能力是否有损耗，集群环境的性能处理能力是否可以呈现稳定增加。

1.1.2　性能测试的场景

性能测试的场景类型通常包含如下几种：

·　业务场景：通常指的是系统的业务处理流程，描述具体的用户行为，通过对用户行为进行分析，以划分出不同的业务场景，是性能测试时测试场景设计的重要来源。

·　测试场景：测试场景是对业务场景的真实模拟，测试场景的设计应该尽可能贴近真实的业务场景，有时候由于测试条件的限制，可以适当做一些调整和特殊的设置等。

·　单场景：指的是只涉及单个业务流程的测试场景，目的是测试系统的单个业务处理能力是否达到预期，并且得到系统资源利用正常情况下的最大TPS、平均响应时间等性能指标。

·　混合场景：测试场景中涉及多个业务流程，并且每个业务流程在混合的业务流程中占的比重会不同，该比重一般根据实际的业务流程来设定，尽可能符合实际的业务需要。该测试场景的目的是为了测试系统的混合业务处理能力是否满足预期要求，并且评估系统的混合业务处理容量最大能达到多少。