性能测试目的

1、性能调优

开发人员对系统调优后，需要测试人员配合去做性能测试，验证这次优化是否有效果。如果性能指标相比较之前的性能指标更好了，说明系统优化的有效果。反之说明调优不理想

2、新业务、新接口上线

系统从无到上线，验证新系统的能力是否能够满足某段时间系统使用要求，否则当高峰期来临，系统可能会崩溃。

3、验证系统稳定性

做性能测试经常跑一两个小时或者几十分钟就可以了，但系统的稳定性，系统能否长期稳定的工作，这个是不够的。系统出现的稳定性问题，一般有内存泄漏、连接数泄漏、死锁、游标不够用等，这些问题短时间内可能不会暴露出来。为了验证系统稳定性，一般用性能峰值并发数(即系统支持的最大并发数)7天24小时，系统的吞吐量，平均响应时间等各项性能指标均正常则认为系统稳定性是ok的。根据系统的重要程度，可以适当调整运行的时间，但至少要压测一个晚上的时间。

4、验证系统架构是否存在瓶颈

同一系统，架构师会提供不同的架构方案。那么不同的设计方案到底哪个好，我们可以通过性能测试验证不同方案的性能，其次了解系统大概达到什么量级的并发后系统就会出现问题，了解系统架构在达到性能峰值时哪块会出现瓶颈，帮助开发针对性地进行系统调优工作。

性能测试范围定义

一般考虑的点有如下几点：

• 系统中被频繁使用的功能、调用的接口等

• 系统中涉及大量数据库读、写的功能

• 大量读写系统缓存部分的功能，验证缓存是否生效

总得来说应该将用户访问量大的，频繁操作数据库的，系统核心功能这些地方考虑到性能测试范围内。

实例：对测试强度估算

基本概念：每个工作日80％的业务在20％的时间内完成。

例如：每天工作8个小时，那么每天80％的业务在8*20％＝1.6小时内完成。

例如：去年全年处理业务约100万笔，其中，15％的业务处理中，每笔业务需对应用服务器提交7次请求；70％的业务处理中，每笔业务需对应用服务器提交5次请求；其余15％的业务处理中，每笔业务对应用服务器提交3次请求。根据以往的统计结果，每年的业务增量为15％，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。

强度估算如下：

每年的总请求数为：

（100*15％7+10070％5+10015％*3）*2＝1000万次/年

每天的请求数为：

1000/160=6.25万/天<备注：每个月为20个工作日，所以1年为160天>

每秒请求数：（62500×80％）/（8*20％*3600）＝8.68次/秒

性能测试环境搭建

保证性能测试与真实生产环境的一致性，具体从以下三方面看：

1、硬件环境

如服务器的型号，是否与其它应用程序共享此服务器，是否在集群环境下，是否通过BIGIP进行负载均衡，客户使用的硬件配置情况，使用的交换机型号，网络传输速率。

2、软件环境

版本一致性

包括操作系统、数据库、中间件的版本，被测系统的版本。

配置一致性

系统（操作系统/数据库/中间件/被测试系统）参数的配置一致，这些系统参数的配置有可能对系统造成巨大的影响。所以，除了保证测试环境与真实环境所使用的软件版本一致，也要关注其参数的配置是否一致。

3、使用场景的一致性

基础数据的一致性

包括预测的业务数据量，以及数据类型的分配。很简单的一个列子，一个系统的数据库只有10条数据和一条数据库里几千万条数据，我们在对其进行性能测试时，得到的性能指标可能会有非常大的差别。

为了保证每次测试环境的更加一致性，磁盘的使用情况以及磁盘的碎片情况也会或多或少地影响的性能。

使用模式的一致性

尽量模拟真实场景下用户的使用情况，其实，我们在做性能测试前期的需求分析，其主要目的也就是为了更真实的模拟用户的使用情况。

最后感谢每一个认真阅读我文章的人，下面这个网盘链接也是我费了几天时间整理的非常全面的，希望也能帮助到有需要的你！

这些资料，对于想转行做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助……

如果你不想一个人野蛮生长，找不到系统的资料，问题得不到帮助，坚持几天便放弃的感受的话，可以点击下方小卡片加入我们群，大家可以一起讨论交流，里面会有各种软件测试资料和技术交流。

点击文末小卡片领取

敲字不易，如果此文章对你有帮助的话，点个赞收个藏来个关注，给作者一个鼓励。也方便你下次能够快速查找。

自学推荐B站视频：

零基础转行软件测试：自学完软件测试，拿到了字节的测试岗offer，堪称B站最好的视频！

自动化测试进阶：已上岸华为，涨薪20K，2022最适合自学的python自动化测试教程，自己花16800买的,无偿分享