性能测试基础

Posted 2021-02-17 liucheng0827

1、性能测试目的：

　　保证在现有软硬件和业务体系架构下，系统始终能够保持稳定运行。

　　对系统能力的评估、识别系统中弱点、调优等都是为了保证这最终目的过程方法，从而发现问题、评估能力、验证、保证稳定的维度进行测试工作的开展。

2、性能测试类型：

　　1）负载测试（Load Test）

　　　　指系统在高负荷的环境中运行，通过逐步加压来观察系统响应时间、吞吐量、系统所占资源（CPU、内存等），以发现系统可能存在的瓶颈（通常负载量以单项系统资源指标达到阀值为准）

　　　　tip：一方面负载测试若在长时间运行情况下，可认为是可靠性测试；

　　　　　　另一方面若系统经历了重要里程碑，需要重新制定阀值，可以用负载测试以响应时间为基准来对其他项进行阀值界定。

　　2）压力测试（Stress Test）

　　　　又称强度测试，是在强负载（大数据量、大量并发用户等）下的测试，主要用于验证系统在峰值使用情况下，系统是否具有良好的容错能力和可恢复能力。

　　　　压力测试分两种：1）长时间（通常24h以上）的稳定性压力测试（Extreme testing）

　　　　　　　　　　　　　　TPS/QPS在峰值的负载量下（至少两项系统指标达到阀值即系统资源稀缺的情况下）进行长时间的测试。

　　　　　　　　　　　　2）极限负载导致系统崩溃的破坏性压力测试（spike testing）：在极限负载情况下（短时间的）进行压力测试。

　　3）恢复性测试（Recovery Test）

　　　　恢复性测试通常和压力测试一起执行，在压力至系统崩溃后，进行撤压，观察撤压后系统恢复的情况（恢复的速 度、恢复的效率）以及验证重新初始化、检查点、数据恢复和重新启动等机制的正确性。对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受范围内。

　　4）容量测试（Volume Test）

　　　　容量测试的目的主要是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

　　5）配置测试（Configuration Test）

　　　　配置测试主要是通过对被测软件的软硬件配置的测试，找到系统各项资源的最优分配原则。配置测试能够充分利用有限的软硬件资源，发挥系统的最佳处理能力，同时可以将其与其它性能测试联合使用，为系统调优提供重要依据

　　6）并发测试（Concurrency Test）

　　　　并发测试是测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其它性能问题。狭义上的并发测试对时间要求比较苛刻，类似场景如：秒杀活动

　　7）失败测试（Failure Test）

　　　　对于有冗余备份和负载均衡的系统，通过失败测试来检验系统局部发生故障，用户能否继续使用系统，用户受到多大影响。如几台机器做负载均衡，一台或几台机器垮掉后系统能够承受的压力。

 

3、性能测试指标

　　详情请参考：https://www.cnblogs.com/chuaWeb/p/PerformanceMonitoring.html

　　1）前端--白屏时间（First Paint Time）

　　　　用户从打开页面开始到页面开始有东西呈现为止

　　　　计算方式：白屏时间=开始渲染时间(首字节时间+HTML下载完成时间)+头部资源加载时间

　　2）前端-首屏时间

　　　　用户浏览器首屏内所有内容都呈现出来所花费的时间（主要影响因素为图片加载，通常会要求前端工程师压缩至图片大小为200k之内，能缓存的尽量缓存，以便二次加载的速度提升）

　　3）前端--用户可操作时间（Dom Interactive）

　　　　用户可以进行正常的点击、输入等操作，默认可以统计domready时间，因为通常会在这时候绑定事件操作

　　4）前端--总下载时间

　　　　页面所有资源都加载完成并呈现出来所花的时间，即页面 onload 的时间

　　　　默认可以统计onload时间，这样可以统计同步加载的资源全部加载完的耗时。如果页面中存在很多异步渲染，可以将异步渲染全部完成的时间作为总下载时间。

　　　　ps：对于用到的统计脚本，需满足两个条件

　　　　1.避免对业务代码的入侵（独立的代码）

　　　　2.不影响被测量页面的性能（主文档加载完毕之后，再注入统计脚本收集数据，并且尽可能的合并数据请求，减少带宽消耗。）

　　5）后端--TPS（QPS）

　　　　每秒钟事物／request的数量（此项标准按照各业务的不同自行定义量化）如果是针对单独的查询服务器则用QPS。其它业务类型则用TPS

　　6）后端－事务响应时间（TRT）

　　　　通常我们的响应时间均代表的是事务响应时间，该指标是直接衡量系统性能的的参数（若事务直接影响客户直观响应感受，则可按照1/2/3原则）

　　　　注：响应时间我们取95%事务的平均响应时间，尽量不要用全数据的平均响应时间，因为可能存在噪点数据影响平均值

 　　7）请求响应时间

　　　　从客户端发起请求开始到收到服务端返回到响应结束，这个过程所消耗的时间。计算公式：网络响应时间＋应用程序响应时间（标准可参考2/5/8原则）

 　　8）后端－吞吐量（网络吞吐）

　　　　衡量系统承压能力，单位时间内系统处理的数据量总和就是吞吐率

　　　　网络吞吐是指在没有丢帧的情况下，设备能够接受的最大速率。通常以比特／秒或字节／秒为单位

 　　9）后端－Full GC

　　　　java垃圾回收机制，是对内存各区进行回收的过程，其中又以Full GC影响面最大，因此Full GC频率不宜过高，否则一方面可能会影响业务，第二方面对性能影响也较大，通常Full GC如果发生，服务卡顿几秒钟，就会让服务线程暂停导致队列堆积严重，特别是业务高峰期，因此，FGC频率由测试组按照实际情况给出标准。

 　　10）后端－资源利用率

 

　　11）后端－标准差

　　　　根据数理统计的概念得来，标准差越小，说明波动越小，系统越稳定；反之，代表不稳定。（考量对象：RT、TPS、load、CPU等等）    

　　　　计算公式：

 　　　　如：　T=（TPS标准差/TPS平均值）*100％一般说来小于10％

　　

4.性能指标对应图：

 　　负载测试：持续加压至b点（某项资源的阀值点）

　　压力测试：加压至c点（系统TPS峰值点）

　　恢复测试：加压至爆点，然后分段撤压至c、至b、至a观察