第一、应用性能对用户体验至关重要
近年来，随着企业IT的快速发展，企业在业务快速变化的节奏中如何提供更便捷、更优质的服务从而提升客户体验成为了企业共同追求的目标。然而作为联系纽带的应用程序却越来越多的被性能问题所影响，以IT成熟度最高的电商行业为例，调查显示响应时间每延迟1秒，会导致页面访问量减少11%、客户转化减少7%、客户满意度降低16%。当一个网站出现中断后，9%的用户会永久放弃这个网站，48%的网站用户会转向竞争对手网站。因此，性能除了会造成用户体验不佳进而影响收入的损失，还会严重损害企业的品牌。
但是企业的业务应用复杂度不断提高，IT系统对性能的要求也随之增高，传统IT架构不再适应新业务增长的需求。随着移动互联网、虚拟化和云计算技术的不断发展，应用架构也变得更加离散和复杂，一个应用的成功交付不仅需要自身系统的稳健，同时也更加依赖网络、第三方服务的质量，而这些外部的“不确定”因素让架构变得更加“不可控”，要在这样一种“不可控”的复杂环境中评价高并发条件下的应用性能，对应用和业务进行容量规划，很显然会比以往更加困难。
第二、云时代的典型应用交付架构
随着计算资源的发展和使用，互联网技术的应用，业务规模扩张、全球化以及数据的爆发式等因素的推动和发展，IT技术架构经历了以数据计算为核心的C/S架构，到以聚焦业务功能及服务化构建应用的经典互联网架构，整合IT资源和按需使用云计算架构三个时代，如图1所示。
当面临新的IT挑战时，网络时代的企业应用架构产生了很大变革，由传统分离式基础架构开始向云计算、云数据中心基础架构转变，如图2所示典型的云计算环境的应用交付架构
当前基于云计算环境的应用交付架构具有如下特点：
1)用户终端变得更加多样：
从传统的PC到移动设备与智能电视终端，从原有Web页面到H5、App与微信小程序，在跨屏时代里用户的选择更多，但是影响用户体验的因素也变得更多、更复杂；
2)应用的架构变得更加复杂，关联性强：
一个成功的服务交付前所未有的依赖于外部的网络、CDN、第三方服务商，每个环节出现问题都会对用户体验产生巨大的影响；
3)企业的基础设施融合：
企业的数据中心也在向云端迁移，其基础设施正不断融合，特点是通过计算、存储和网络的硬件基础设施系统进行集成，实现基础硬件设施和虚拟化的整合，以及统一管理、统一维护的能力。
考虑到云计算的应用交付模式的复杂性，从性能测试的角度客观上要求服务企业必须关注每一个交付链条上的影响因素，从而才能够更全面准确地评估性能问题。
第三、压力测试发展的三个阶段
如图所示压力测试发展的阶段划分。
压测0：防火墙内部压力测试
这种是沿用了20多年的传统测试方法，其基本的实现原理是在防火墙内部产生压力来进行压测，即压测的环境（包括施压机以及被压测系统都在防火墙以内，见图2右半部分）。如果测试的目的仅是对内网的系统硬件资源以及服务、数据库在并发条件下的性能表现，这种模式依旧是一个合理的选择。压测1.0的代表性产品包括Jmeter和Loadrunner 12以前的版本。不过因为这种模式本身的一些弊端，随着应用的规模不断扩大以及云计算技术的成熟，大家提出一种很自然的解决方法，就是将压力发起的主机迁移到云端，利用云端的资源节省硬件消耗成本以及减少准备的周期，所以就衍生出压测2.0，即云端压测方法。
压测0：基于云计算的压力测试
基于云端压测模式将压测机迁移到云端，通过云资源在防火墙外部生成规模并发（见图2中右侧防火墙内和防火墙外的云端压测节点部分），一般来讲有三种方式进行“云端施压机”部署：
利用其它机房（自建、IDC数据中心）发起压力；
利用云服务商（如阿里云、AWS等）云主机发起压力；
利用在外部合作伙伴或者分支机构的计算机作为施压节点；
因为使用了基于防火墙外的云端资源使用方式，压测2.0相对上一代压测方法已经有了很大的进步，这种模式降低了压测的成本与准备周期，提高了效率。典型的产品有阿里云PTS、Blazemeter、Xmeter、Loadrunner 高级版本等。但严格意义讲，压测2.0仅仅是压测模式的“云化”转变，与压测3.0相比并不能说是划时代的压测方法。这是因为前两个阶段并没有从外部的真实用户和真实的应用交付架构全局视角来考虑压测问题，只是在当时的应用和技术条件下的解决方案，不能适应如今形式发展要求。
压测0：面向用户体验的外部压测
压测3.0是新一代应用性能压测的解决方案，这种解决方案真正从终端用户行为与体验的视角来审视应用性能问题，通过分布式压测点来从用户实际的所在地域来发起压力，让压力产生的更加真实；面向应用交付链的全技术栈的性能监控与诊断，能够从用户到网络、应用、第三方服务及基础设施进行“全覆盖”式的深度追踪，发现影响性能的问题瓶颈。相比前两代压测方法，压测3.0在真实性、全面性、深度和持续交付四个方面有着本质的不同。
压测0的“真实性”体现在如下两个方面：
真实用户业务场景与区域访问的分布情况的获取：
在压测方案实施前，究竟需要对哪些影响业务的场景进行压测？究竟需要关注哪些区域的用户？这些用户在不同区域的分布占比如何以及用户访问的潮汐流如何？传统方法只能根据以往经验进行判断，准确性很难保证。压测3.0提出了基于应用性能管理的数据采集方法，通过对移动端和浏览器端真实用户在应用中的行为流程确定压测的场景，同时基于对用户的地域分布及其比例、接入方式、使用终端及访问时段等信息进一步确定压测实施的任务配置信息。这种基于历史数据来确定业务场景及用户访问情况的方法确保了压测实施的真实性，能够保障影响关键用户体验的关键业务的正确与准确性。
从真实用户行为、区域视角分析性能问题：
对于评价应用性能的关键指标，如应用响应时间（比内网压测的响应时间更真实）、错误与失败情况、每秒钟的事务处理能力，不同区域用户的受影响程度等，从外部的用户视角来分析时能够全面地客观、考虑各个环节的最终综合影响情况，而不是单纯从防火墙内部考虑时的后端系统能够涵盖的指标因素，所以这种从用户外部视角的方法得到的压测结果会更真实。
压测0的“全面性”体现在如下三个方面：
确定应用交付链中网络对应用实际交付的影响：
网络问题如DNS路由问题、带宽问题、CDN配置问题、用户使用的移动网络问题等。在压测3.0方法中，通过对用户访问业务应用时的网络质量进行监控，使用监测数据评估用户真实的网络质量情况，对网络链路故障问题分析和定位。
明确第三方服务对实际用户使用的影响：
现代应用很多服务都是通过第三方服务接口来实现的，对这些“不可控”的服务接口压力测试，传统压测是无法解决的。利用压测3.0方法，能够对外部第三方接口的故障、响应时间以及接口返回结果的正确性指标进行压测验证，帮助用户准确感知整体业务的性能和质量状况。
发现应用架构的合理性问题：
如防火墙问题、Web服务器不平衡、负载平衡器的配置、系统之间的延迟问题等；
压测0的“深度”
压测的目的是考评系统在不同规模条件下的性能表现，进而排查和定位性能瓶颈。在压测3.0的方法体系中，压力测试与应用性能管理（APM）深度融合，在压测的同时通过端到端深入分析应用整体性能，实时定位代码级性能瓶颈，实现高并发条件下全数据采集的每条请求及其后端的代码级问题分析；
压测0的“持续交付”支持
从敏捷开发到持续交付，当今应用不仅每天会多次构建新的版本，频繁地发布且变更频率也很高。如果没有灵活的测试方法、正确的测试工具及合理的管理流程，那么带给产品的绝不是“灵活”，丧失了质量和性能的灵活性只会是一场“灾难”。压测3.0压力测试方案能够与敏捷开发和快速的变更频率保持同步，如下图所示。
通过“压测工具＋应用性能管理（APM ）＋已有测试管理工具”模式构建统一性能测试管控平台，是面向产品全生命周期的持续交付解决方案的一个重要构成部分。压力测试与性能分析平台能够自然融合在产品QA的环节中，压测产品本身能够提供丰富的API，能够通过提供扩展接口，支持与企业现有测试工具紧密集成，能够将测试任务以对外暴露的服务形式进行驱动执行，以实现更快更敏捷的交付与持续集成。
压测3.0的解决方案架构如下图所示：
压测0实施流程
压测3.0使用了戴明环PDCA方法将整个压测与优化过程化划分为：Plan(计划)、Do(执行)、Check(检查)和Action(纠正)，遵照执行顺序对应用的交付质量进行管理。更进一步，压测3.0根据其本身的特性对戴明环进行了优化，其实施流程如图所示。
图6：基于压测3.0方法的压测实施流程
压测方案准备阶段
对压测真正实施前需要对整体的方案进行制定，一般需要解决如下几个问题：
明确压测目的：
本次压测要解决那些问题，一般除探知业务容量的“天花板”外，还需要对影响关键业务的应用服务进行调优处理。
确定压测用户场景与目标：
本次压测要解决哪些关键业务场景的什么问题，这些场景本身的特性极其对用户体验及业务的影响会有多大？ 这是在方案策划解决需要重点考虑的内容，通过使用性能管理（APM）工具对移动端和浏览器端的历史数据进行统计分析，很容易替代传统压测的“经验式”解决方法，因为本质上应用性能管理是针对分布式用户的真实行为数据的采集与监测手段，这种“真实”对于压测方案更具客观性、准确性，能够帮助解决如下问题。
关键业务场景的确定，基于真实用户访问行为确定影响业务的关键点；
用户访问区域及分布占比；
用户访问模式及潮汐式施压曲线确定；
用户使用终端类型、接入方式和网络基本情况；
初步预判性能可能出现的故障点：
根据以往性能监控历史数据以及技术预判的性能薄弱环节，通过部署性能诊断平台，有针对性的进行重点监控，如针对关键节点的性能探针部署、监控任务与告警配置。
压测过程中的安全策略及测试数据准备：
如敏感数据的消隐处理、为虚拟用户创建模拟的测试数据、在最终支付环节的“挡板”程序准备以及安全验证码、短信验证码的处理等；
压测执行阶段
与传统戴明环显著的“阶段划分”不同，压测3.0实施流程将“DCA”环节更紧密地融合在一起。在压测的过程中，通过统一的“作战大屏”数据仪表盘，能够协同地让测试、研发、运维在一个平面对话，在流量不断上升的过程中，各方面人员对各个检查点（如数据库、网络、应用、CDN等）进行实时监控分析，当有问题出现时，可以随时调整压测策略或者暂停压测以进行局部调整，接下来又可以继续进行下一步压测……。一般来讲，在压测执行阶所要考虑的重点有：
系统吞吐处理能力（TPS，每秒事务数）：
理论上伴随压力上升过程的，系统处理能力应该保持在一个相对稳定的范围，但实际情况由于网络和后端系统支持的问题TPS会出现严重的波动，另外由于实施真实的外部用户压测，一般来讲在同样的并发条件下TPS会比在传统内部压测要小很多，这也符合真实的用户访问场景；
事务的平均响应时间：
可以通过结合percentile分析方法找到统计意义上的分布值，好的响应时间也不应该由于并发用户增多而持续攀升。
事务的错误和失败情况：
包括变化的趋势、不同类似错误与失败的分布等；值得说明是，错误和失败是两种不同的评价指标，失败是指HTTP或者网络连接时发生的问题，如返回400、502状态码等。而错误是指在事务的请求在调用过程中的断言验证出现问题的情况，一般对于自有或第三方服务接口的返回结果的正确性判断会很有帮助；
应用后端的性能问题：
通过缓慢和失败请求的深度关联分析，能够进一步定位到问题瓶颈，包括请求执行的链路、响应时间、错误请求快照、SQL脚本执行数据、后端堆栈跟踪、异常代码分析、JVM执行效果等；
后端支撑主机的性能表现：
运维人员能够实时对本次压测的服务器、数据库和各种支撑服务进行有效的实时监控，其中服务性能指标包括CPU使用率、负载、内存情况、网卡流量、硬盘、TCP链接情况等；
正是因为压测3.0的实时性、对各种监控的全面性以及对问题的深度诊断能力，使得“DCA”过程从以往的以周和天为单位变成以分钟为单位，执行、检查和纠正优化三个阶段变得更加紧密，从而提升了问题的快速发现和解决能力。
压测历史数据的积累与重用
因为压测过程，包括对应用性能的监控数据都已经保存在数据库中，每次压测的结果都可以积累作为下次压测计划中的历史基线，通过这种更大的测试闭环，形成了更为完善的压测实施体系。
云智慧压测宝及压测服务
压测宝是云智慧公司践行压测3.0方法体系的落地产品——面向真实用户行为与真实区域分布的全链路云端压力测试平台。压测宝通过云端服务器产生真实分布式用户访问压力，模拟来自各地域用户接入后台所带来的真实流量，从而跳出了“温室环境”的理想状态，无限接近生产环境所面临的各种复杂因素，测量真实的用户体验。通过集成云智慧应用性能管理和监控产品，帮助实现基于真实用户行为的压测方案定制、压测过程中实时定位各环节应用资源及代码瓶颈，现场纠错，分析应用性能肇因。
依托压测宝以及完善的产品线，云智慧为用户提供了一站式压测服务，面向云计算时代的复杂应用提供专业性能压测服务，帮助企业客观评估应用性能容量，发现全链路性能瓶颈，对应用架构的调优及架构容量规划提供专业咨询服务，从而保障产品交付满足企业灵活多变的业务需求。
来源:新一代面向用户体验的压力测试方法www.yacebao.com
转载成都seo_提供SEO优化和网站优化方案_解决成都网站建设与成都关键词优化问题-小丁分享【SEO网站优化技术博客】» 新一代面向用户体验的压力测试方法