从压力测试说起
　　压力测试是确立系统稳定性的一种测试方法，通常在系统正常运作范围之外进行，以考察其功能极限和隐患。与功能测试不同，压测是以软件响应速度为测试目标的，尤其是针对在较短时间内大量并发用户的访问时，软件的抗压能力。
　　至于为什么产品或业务系统在通过功能测试后还需要进行压力测试，原因很简单，因为它重要，为什么重要？众所周知，响应速度是用户体验的核心指标之一。 SmartBear 数据表明，如果 Amazon 的加载时间延长1秒，那么一年会减少16亿美元的营收。用户与网站互动的过程中，如果加载时间超过3秒，57% 的用户会流失。可见，通过压测来优化产品体验和性能是多么的重要。

　　压测1.0 VS 压测2.0
　　传统的压测方法通常的做法需要准备大量的环境，如测试的压力机，安装测试工具，录制测试脚本，对服务器不断施加“压力”，通过这种方式来确定系统的瓶颈或者不能接收的性能点，来获得系统能提供的大服务级别的测试，这个阶段我们称之为压测1.0。
　　压测1.0时代的主流压测工具有 LoadRunner ， SilkPerformer ， Ratinal ， QA Load ， Jmeter 等等， LoadRunner 为传统压测1.0时代主要的代表产品。


　　
压测1.0 图1.传统的压测现状

　　传统的测试方法下很难去做到对整个系统去做一次大型的压力测试，这种情况下只能把每个系统独立开来，对他进行性能测试，然后对整个核心系统去做分析，确定系统的短板，对短板进行压力测试。
　　通常需要用预估的方式，业务部门估算今年的交易额，应用部门估算，网络部门估算，基础架构部门估算。后的结果是如果需要1000台服务器，那么准备1500台。如果需要5 G 的 CDN 带宽，那么准备7.5 G 。几乎所有资源都多准备50%。
　　压测1.0时代的压测缺点很明显。
　　· 测试过程缓慢，周期过长
　　· 并非聚焦于全球客户的体验
　　· 非常昂贵的授权费用及硬件投入
　　· 为实验室测试而设计，对生产或线上环境无能为力
　　· 不能针对当今复杂的应用及架构提供实时的反馈
　　基于云计算的全链路压力测试我们称之为云压测，这个阶段我们叫压测2.0。云压测通过遍布云端的压力模拟服务器，来制造“真实用户访问”，这个过程可以覆盖到真实交易系统的全链路，全业务测试系统，并且革命性的使用云资源这种轻属性资产，对几乎来自全世界互联网和移动互联网的压力进行测试。云压测模拟测试完全还原真实用户网络访问状况。


　
　压测1.0 图2.“云压测+ APM ”进入压测2.0时代

　　当产生压测需求时，我们布置在各主流云厂商（AWS、阿里云、Azure、青云、腾讯云、金山云、UCloud等等）的压测虚机自动下发压测脚本，进行云端托管式部署云端压测机启动，对用户系统进行压测。同步压测，同步产出压测数据。
　　利用云计算优势，当需要进行模拟大规模用户访问时，只要多开云主机能实现，需要模拟100万的用户访问，再开100台云主机。
　　云压测的准备时间基本上是由云主机启动时间来决定，这在压测1.0时代是根本不可能实现的。云压测是在云主机发起的，因此反映了真实的用户访问环境，而压测1.0时代的传统压测方式则必须在内网的模拟环境下进行。