《使用云计算和大数据进行性能测试》
今年的天猫双十一以912亿的交易量落下帷幕，在短短的24小时里，天猫创造了最高4500万人同时在线，系统交易创建峰值达到每秒钟14万笔，支付宝的支付峰值达到了每秒8.59万笔，全天支付笔数达7.1亿笔。如此天量的访问和交易，给天猫平台带来了前所未有的访问压力，天猫的IT运维人员是如何进行双十一IT性能保障的呢？
请看云智慧工程开发VP刘志达（Jason Liu）为您带来的云时代压力测试新方法。
Jason：大家下午好，我是云智慧的Jason Liu，主要负责公司技术部分工作。很高兴有机会和大家一起交流一下性能压力测试方面的话题。我要给大家介绍的是云智慧刚刚推出的压力测试产品叫压测宝。我们所说的压测和传统的压测有很大差别。
从案例看用户需求
我们压测产品主要从云的层面给系统做性能测试。先来看两个案例，大家多多少少订过火车票，12306刚上线的时候就出现过瘫痪问题，尤其是春运期间。双十一刚刚过去，阿里刚开始推双十一的时候支付环节也曾经瘫痪过。所有这些都指向一个问题，就是系统上线之后的性能问题怎么解决。这部分问题一旦发生，对整个业务影响是致命的，像阿里宕机一秒钟就可能会造成了百万级的损失。
同样作为电商网站，在双十一的时候，是否还敢去做促销？
我们看阿里巴巴是怎么做的，阿里现在除了国内还开始包括海外，双十一它对系统压力是巨大的，阿里是如何搞定这件事的？
在2013年阿里已经改变了对性能测试的方法，他们做到了一个全链路压测。全链路压测和传统压测完全不同，传统压测解决的是单点问题，看服务器负载能力可不可以，比如内部放三台负载机就去压一下，看能不能承受2000的并发或者十万用户访问。这是传统的压测。
但是一旦到线上，引流过来以后，带来的结果是什么？有可能系统挂掉了。这个原因是什么呢？就是因为我的测试环境和生产环境并不一样，我的测试压力制造都是在实验环境下做的。
阿里2013年做的全链路压测，做成具有真实环境的状态，让压测变成有确定性的评估，能确定上线后到底什么状态。他怎么做的呢？阿里的全链路压测覆盖了前端系统、网络、DB和基础架构等整个系统环境，在测试环境里把真实业务完全还原了。
要做这件事的不只是电商，前几个月我和建行的人聊的时候，他们的网银系统也要做这样的事，模拟生产环境一样的做测试环境，做真正的压力访问。他们要做交易链路上真实的限制，包括网络带宽、各级分级负载处理，甚至系统中间放了很多安全设备对性能影响有多大，都能通过全链路压测能发现，不仅仅发现性能问题和服务器本身的负载能力。
中国只有一个阿里巴巴，他们有五千个后台工程师负责整个系统后台维护，才能保障他们双十一活动的正常运转。现在阿里使用了全链路测试以后，只要有一千个后台工程师保障就够了。但大部分公司都不具备这样的实力，可能公司也才几百个人，虽然业务没有阿里庞大，更不可能放那多后台工程师去维护。
“云测试”的新方法
那么这种企业该如何解决性能问题？
云智慧提供了一个解决方案，通过云测试的方式帮企业彻底解决业务系统性能问题，那我们怎么做的呢？这里边有一个整体的结构图，在压力测试中，这边是业务系统，包括负载、服务器、网络，这是整个的真实测试环境。我们如何制造压力？云智慧在云端，比如阿里云、青云、Ucloud上，我们放了很多压力机，就是制造压力的服务器。 它通过云端制造压力访问系统，这个访问基本上跟实际生产环境的用户访问一致。因为这些服务器分布在不同的地区，而且它的访问量也很容易起来。通过这种分布式的方式，从云端来制造大量的压力，来模拟真实的用户访问，很容易测试系统上线之后是不是能够经受住预计五百万的用户访问和五千的用户并发。
接下来我们看这种测试如何做？比如说在某电商网站，我们做了三千并发用户，这是我们录入的测试脚本，录制好后，就模拟实际用户跑这个脚本。当压力增加到三千用户的时候，我们会发现在几个业务处理环节，响应时长和处理能力都变得比较差，这些业务是最关键的，从加入购物车到支付的环节，这里可以看出购物环节的性能是瓶颈。
这上面有几个数字，我稍微解释一下。一个是所花的时间，平均时间，最长时间和最短时间。我在做一段时间的并发压力测试下，系统性能最好、最差和平均数据都能拿到。但是有一个非常重要的数字就是90%，所谓90%什么意思呢？就是所有用户请求里90%用户的请求状态是多少？它代表了绝大部分用户。这个数字更具有参考意义。
在测试过程中我们也可以制订一些压力策略，比如说购物环节可能转化率非常高，80%的用户，甚至85%的用户都会走到这一步，就可以设置这部分请求数量我分配80%，也就是说我三千并发里有两千多并发在这部分，还有其他的几个非关键性业务还会占10%，按照这样的比例分配请求。这些都是动态可调的，我们做的过程中会按照这个策略分配访问用户来跑这个脚本。
在测试过程中除了看到速度还要看到一些出错的情况，并发从两千到三千这个过程中，我会产生多少失败的请求？失败请求数量有多少？随着压力上升，比如说我们在三千并发的时候，会有一些环节撑不住，就会有一些请求出错。偶尔有一两个出错对系统影响并不严重，属于可接受范围，但是像这种一个小时出现上千次请求失败的情况，就是一个非常严重的问题了。我们可以把严重的问题挑出来，针对性进行问题分析，到底是什么原因导致的。
我们可以分析不同的用户压力下，如并发用户一千、两千、三千时候的问题表现，我们在这次测试的时候，达到一千并发访问的时候，出现了502和504的错误。当我把压力加到两千的时候，我们看到购物车出现瓶颈了。出现瓶颈的原因我们从带宽上看，在一千用户的时候带宽消耗一百兆，按正常来说两千用户应该消耗两百兆带宽，但是没有消耗到这么多带宽，我们认为业务处理能力下降导致。
那么继续分析下降的原因是什么，这部分可能要联合开发和运维一起做测试。他会根据每个接口进行分析，比如刚才我们看到的这个接口，它是在商品购买的时候并发处理做得不好。每一个商品有一个可卖数，例如准备了五千个，下单的时候我们会在每一个用户下单购买这个商品的时候，把可卖数减1，直到卖完。开发在这一步骤的处理有问题，他用memcache来缓存，但是这个缓存并没有真正做到缓存的作用，仅仅做了一个中间数据库的过渡。他在每下一个单时都把可卖数取出来放到memcache，但是正常来说每次大家都应该来读memcache，一直到这可卖数为0。但实际情况是他每次都重新创建缓存，所以多线程并发的时候，尤其抢购的时候，导致了一个线程把缓存创建完，另外一个线程就把缓存干掉了，之前这个线程再去读的时候读不到数字，由此集中产生了大量的错误。
这种问题在功能测试阶段往往是发现不了的，只有在性能测试的时候，上了真实用户访问压力的时候才会曝露出来，然后我们才能有针对性的做分析。首先我们得知道到底哪个请求出了问题，否则对用户表现就是下单失败，但是为什么失败却没有人知道。
我们目前做过的客户有很多，像太平洋保险、中国海运、中国移动的咪咕、中国电信、苹果iCloud等。压力测试随着互联网发展越来越受重视，尤其是大家越来越关注用户体验的时候。
传统工具的缺陷
压力测试这项工作在很久之前大家就在做了，只要有测试团队的，压力测试一定会有。过去压力测试的做法实际上都是工具性的，所说的工具如JMeter和LoadRunner，我们称之为上一代产物，他们有一些缺点，一个是适应性比较差，需要对一次测试准备大量的环境，如要准备很多台压力机，然后录制脚本，做得好可以进行一些分发，但是这些机器终究要准备的。
尤其对业务量比较大的企业，比如我们要制造50万或者一百万用户访问的时候，一台物理机的并发模拟用户在500到1000的样子，就需要准备大量物理机，成本比较高、而且时间很长。像某些客户以前为了做性能测试，准备机器有时候就需要几个月的时间。
另外一个最大的问题是实验室环境，我们所说实验室基本在内网把环境搭好，而内网的网络条件都不会差，这时候用机器去压，有的时候并没有问题。但是真正上到生产环境，网络带宽和前端的负载机制，甚至前端加了安全措施都有可能对性能产生影响，导致服务响应慢或者宕掉。
压测宝的优势
压测宝有几个优势：1、速度，这个速度主要是部署，因为它整个测试是在云端发起的。利用了云的优势，在云端可以几分钟开出来一台压力机。我要模拟十万用户访问，开了五十台服务器，我想增加到十万，再开五十台就好了，不需要在每台机器上做准备工作。从过程来说，整个我们开压力机的时间基本上跟云主机的启动有关，大部分测试在半个小时内就能把压力测试环境准备好，而传统的工具基本上在一个多月。
2、分布式的环境，我在云端不同地区发起的用户访问，它不是在内网发起的，所有的架构、链路都会到，这是一个真实环境，因此可以大规模的，一百台、两百台甚至一千台都没有问题，而内部准备的时候还是受制于自己买的服务器、服务器的容量的限制。
3、性价比，我节省了人工，不需要那么多人准备压力环境、也不需要那么多人做压力测试，都由系统和云解决了。另外我可以在任何时间、任何地点来做，因为访问云是不受任何限制的，意味着发起压力的时候也不受限制。我们可以同时对多个系统做测试，都是在云端发起，只需要替换一下脚本就可以。
压测宝也在改变压力测试的标准。
一个是从研发到生产可以做高频度测试。因为在云端，想用就开，不想用就关，随时来做。第二可以从用户端真正做到全链路测试。
第三是实时统计分析，压测宝里的数据是实时统计的。用其他的测试方法，测试条件包括压力数量准备好之后，一般都会跑完，比如上五千并发，结果系统直接压死了。我们是可以随时调整压力的，随着压力逐步上升，系统的性能数据动态呈现。压力从一千加到五千，两千的时候就像我们刚才看到的数据，性能已经在下降了，大量出错，这个时候没有必要继续往下压。我们可以停掉，也可以把压力往下调，比如两千的时候出现严重问题了，那我调到一千五。根据系统目前状态，在保障业务正常运行的情况下看看能撑住多少用户访问，通过压力的上下调整找到这个点。也许我找到1300并发的时候，系统出错、性能都在容忍范围内。就说明系统现在承载能力在这个范围。
第四是配套的监控机制，压测宝能做到这一点依赖于一个监控机制，这个监控是可以接收即时数据，我们做了很多数据呈现的报表，这些报表也是随着压力变化呈现实时的曲线，所有数值都是在变化的，所以我们可以看到它的状态。
第五是测试周期的缩短。现在我们在给很多客户做的测试，其实花时间最多的是脚本录制。脚本录制完之后只需要几分钟、十几分钟压力测试准备好可以去测了。对脚本录制这部分，大家做的都是差不多的，比如压测宝，都是通过我们提供的录制工具，像实际访问一样，点浏览器一步一步操作，操作结束之后脚本录制完成。但这只是最初的脚本，真正要测试的脚本，有的时候要排除很多内容，比如CDN上的资源。很多时候压CDN是没有意义的，需要把CDN的资源替换掉，只留下服务器端发出的实际请求。另外有一些业务存在等待时间，中间也可以穿插等待时间。
压测宝的优势有哪些？
从使用层面上，我们不需要再做大量重新的学习，学习成本很低。录制脚本这块我们也会帮助来录。我们现在做的压力测试，对客户来说只需要把业务告诉我们，剩下的事情基本上不用管，所以做得很快。同时我们只要准备好一次之后，如果业务没有大的变化，以后每次直接跑脚本就可以了，完全不需要客户自己花太大的精力重新准备。原来的压测方式需要一个月测一次、两个月大的上线测一次，现在可以做到只要有版本更新迭代就可以去测。
我们在云端我们有很多合作厂商，几乎主流的云服务商我们都能在它上面测压力。测试规模可以从几万到几百万，主要取决于云主机开了多少，我们就能测试多少。这个压力量是没有一个上限的，这是传统压力测试在内网很难做到，因为硬件投入就很难。
报表是实时统计的，可以边做边看。
我们可以在测试过程中解决性能问题，解决问题不是单纯靠这个工具。本身云智慧是做性能方面的监控和分析的，压力测试能够帮助发现问题，我们的APM产品透视宝可以分析和定位问题。一般的话都是搭配来用，通过压测宝测性能、发现性能问题，通过透视宝分析和定位性能问题，而控宝能够做的一些是对基础服务的分析，这几种产品我们都有大量的实际案例。
今天把压测宝产品做了简单介绍，还是概念性的。因为在座的都是运维，跟测试部门不同，测试部门对这方面的需求比较多一些，一般来说做压力测试，尤其线上的压力测试有两种，一种是测试环境上线前做的，还有一种可以在上线后做。很多系统已经上线了，上线前没有做过压力测试，也不知道能撑多少的访问量，什么时候做系统升级，也没办法做预测。我们给不少用户做过这样的事情，用压测宝来做上线后的压测。
用压测宝做这件事最大的好处是压测宝能够逐渐调整压力范围，也就是说不会像常规压测，设5000，一下就爆了，我们可以找到系统性能的范围，第二能找到性能问题出现在哪里，所以这个场景下用的多一些。另外就是测试环境来做，但不论怎么用压测宝做压力测试，基本上需要运维部门来陪伴。
以上是我今天关于压测宝的分享，接下来是用户答疑环节，大家有什么问题可以提出来。
提问：您刚才提到压测宝监测功能比较强大，如果要看服务器压力，不知道压测宝怎么看？
Jason：压测宝重点不在这块，但会提供一套比较基础的监控，比如对服务器的监控，比如CPU内存、流量。我们一般搭配监控宝、透视宝，向中间件、数据库在压测过程中都有可能出现问题，配套的这些东西还是要做的。
提问：可以在内网监控吗？
Jason：可以在内网做，但是需要在测试的时候跟外网不同，和传统的方式类似，缺点是用户访问量不容易加上去，要做的话要加很多压力机。
提问：压力机都在云端？
Jason：对，其实我们还是推荐云端，如果放在内网跟真实环境还是有差异。当然像银行、政府机关因为有政策要求，说必须在内网环境，不能出公网，如果有条件的话，绝大部分环境都可以出公网，因为业务都在公网，这种访问最好在公网来做，自己省力，测试效果比较真实。
提问：压测宝和基调的测试一样吗？
Jason：其实并不一样，因为基调检测是模拟用户发一个单次请求来做监控。压力测试是把一个测试用例让大量用户，比如十万个用户持续访问，或是并发几千访问。
提问：一个是单个用户、一个是批量用户，他们之间产生的信息有差异性么。
Jason：这些信息都是类似的，每个请求都是一个HTTP请求，这肯定都是一样的。但是数据呈现的东西不一样。基调呈现的是从监控角度呈现，压力是看负载、错误的统计，做这方面的。
提问：如果用压测宝必须贵公司技术支持，还是我们本公司的测试也可以使用你们的环境？
Jason：你们可以使用这个环境，这个环境本来就是给大家来用的，但是这里面我们参与什么？一般会帮助做脚本录制，录下来还好办，更多的对一些变量的调整。压力测试的时候，我们准备最简单的测试实际用户，交给你之后，你可以拿出一万个用户，用户名、帐号密码这些信息肯定不能每个去做，通过一些规则、变量的方式去做，这种东西需要做脚本编写。压测宝提供了一些功能，但是是需要花一些时间研究和学习的。很多是我们帮着做的，做完以后照着这个就学会了。
提问：压测报表是通过什么做的？
Jason：其实都是图表呈现的插件，在创建压力测试任务的时候，我们提供了大概几十种数据呈现的选项，选择完之后就会把图形显示出来。
请看云智慧工程开发VP刘志达（Jason Liu）为您带来的云时代压力测试新方法。
Jason：大家下午好，我是云智慧的Jason Liu，主要负责公司技术部分工作。很高兴有机会和大家一起交流一下性能压力测试方面的话题。我要给大家介绍的是云智慧刚刚推出的压力测试产品叫压测宝。我们所说的压测和传统的压测有很大差别。
从案例看用户需求
我们压测产品主要从云的层面给系统做性能测试。先来看两个案例，大家多多少少订过火车票，12306刚上线的时候就出现过瘫痪问题，尤其是春运期间。双十一刚刚过去，阿里刚开始推双十一的时候支付环节也曾经瘫痪过。所有这些都指向一个问题，就是系统上线之后的性能问题怎么解决。这部分问题一旦发生，对整个业务影响是致命的，像阿里宕机一秒钟就可能会造成了百万级的损失。
同样作为电商网站，在双十一的时候，是否还敢去做促销？
我们看阿里巴巴是怎么做的，阿里现在除了国内还开始包括海外，双十一它对系统压力是巨大的，阿里是如何搞定这件事的？
在2013年阿里已经改变了对性能测试的方法，他们做到了一个全链路压测。全链路压测和传统压测完全不同，传统压测解决的是单点问题，看服务器负载能力可不可以，比如内部放三台负载机就去压一下，看能不能承受2000的并发或者十万用户访问。这是传统的压测。
但是一旦到线上，引流过来以后，带来的结果是什么？有可能系统挂掉了。这个原因是什么呢？就是因为我的测试环境和生产环境并不一样，我的测试压力制造都是在实验环境下做的。
阿里2013年做的全链路压测，做成具有真实环境的状态，让压测变成有确定性的评估，能确定上线后到底什么状态。他怎么做的呢？阿里的全链路压测覆盖了前端系统、网络、DB和基础架构等整个系统环境，在测试环境里把真实业务完全还原了。
要做这件事的不只是电商，前几个月我和建行的人聊的时候，他们的网银系统也要做这样的事，模拟生产环境一样的做测试环境，做真正的压力访问。他们要做交易链路上真实的限制，包括网络带宽、各级分级负载处理，甚至系统中间放了很多安全设备对性能影响有多大，都能通过全链路压测能发现，不仅仅发现性能问题和服务器本身的负载能力。
中国只有一个阿里巴巴，他们有五千个后台工程师负责整个系统后台维护，才能保障他们双十一活动的正常运转。现在阿里使用了全链路测试以后，只要有一千个后台工程师保障就够了。但大部分公司都不具备这样的实力，可能公司也才几百个人，虽然业务没有阿里庞大，更不可能放那多后台工程师去维护。
“云测试”的新方法
那么这种企业该如何解决性能问题？
云智慧提供了一个解决方案，通过云测试的方式帮企业彻底解决业务系统性能问题，那我们怎么做的呢？这里边有一个整体的结构图，在压力测试中，这边是业务系统，包括负载、服务器、网络，这是整个的真实测试环境。我们如何制造压力？云智慧在云端，比如阿里云、青云、Ucloud上，我们放了很多压力机，就是制造压力的服务器。 它通过云端制造压力访问系统，这个访问基本上跟实际生产环境的用户访问一致。因为这些服务器分布在不同的地区，而且它的访问量也很容易起来。通过这种分布式的方式，从云端来制造大量的压力，来模拟真实的用户访问，很容易测试系统上线之后是不是能够经受住预计五百万的用户访问和五千的用户并发。
接下来我们看这种测试如何做？比如说在某电商网站，我们做了三千并发用户，这是我们录入的测试脚本，录制好后，就模拟实际用户跑这个脚本。当压力增加到三千用户的时候，我们会发现在几个业务处理环节，响应时长和处理能力都变得比较差，这些业务是最关键的，从加入购物车到支付的环节，这里可以看出购物环节的性能是瓶颈。
这上面有几个数字，我稍微解释一下。一个是所花的时间，平均时间，最长时间和最短时间。我在做一段时间的并发压力测试下，系统性能最好、最差和平均数据都能拿到。但是有一个非常重要的数字就是90%，所谓90%什么意思呢？就是所有用户请求里90%用户的请求状态是多少？它代表了绝大部分用户。这个数字更具有参考意义。
在测试过程中我们也可以制订一些压力策略，比如说购物环节可能转化率非常高，80%的用户，甚至85%的用户都会走到这一步，就可以设置这部分请求数量我分配80%，也就是说我三千并发里有两千多并发在这部分，还有其他的几个非关键性业务还会占10%，按照这样的比例分配请求。这些都是动态可调的，我们做的过程中会按照这个策略分配访问用户来跑这个脚本。
在测试过程中除了看到速度还要看到一些出错的情况，并发从两千到三千这个过程中，我会产生多少失败的请求？失败请求数量有多少？随着压力上升，比如说我们在三千并发的时候，会有一些环节撑不住，就会有一些请求出错。偶尔有一两个出错对系统影响并不严重，属于可接受范围，但是像这种一个小时出现上千次请求失败的情况，就是一个非常严重的问题了。我们可以把严重的问题挑出来，针对性进行问题分析，到底是什么原因导致的。
我们可以分析不同的用户压力下，如并发用户一千、两千、三千时候的问题表现，我们在这次测试的时候，达到一千并发访问的时候，出现了502和504的错误。当我把压力加到两千的时候，我们看到购物车出现瓶颈了。出现瓶颈的原因我们从带宽上看，在一千用户的时候带宽消耗一百兆，按正常来说两千用户应该消耗两百兆带宽，但是没有消耗到这么多带宽，我们认为业务处理能力下降导致。
那么继续分析下降的原因是什么，这部分可能要联合开发和运维一起做测试。他会根据每个接口进行分析，比如刚才我们看到的这个接口，它是在商品购买的时候并发处理做得不好。每一个商品有一个可卖数，例如准备了五千个，下单的时候我们会在每一个用户下单购买这个商品的时候，把可卖数减1，直到卖完。开发在这一步骤的处理有问题，他用memcache来缓存，但是这个缓存并没有真正做到缓存的作用，仅仅做了一个中间数据库的过渡。他在每下一个单时都把可卖数取出来放到memcache，但是正常来说每次大家都应该来读memcache，一直到这可卖数为0。但实际情况是他每次都重新创建缓存，所以多线程并发的时候，尤其抢购的时候，导致了一个线程把缓存创建完，另外一个线程就把缓存干掉了，之前这个线程再去读的时候读不到数字，由此集中产生了大量的错误。
这种问题在功能测试阶段往往是发现不了的，只有在性能测试的时候，上了真实用户访问压力的时候才会曝露出来，然后我们才能有针对性的做分析。首先我们得知道到底哪个请求出了问题，否则对用户表现就是下单失败，但是为什么失败却没有人知道。
我们目前做过的客户有很多，像太平洋保险、中国海运、中国移动的咪咕、中国电信、苹果iCloud等。压力测试随着互联网发展越来越受重视，尤其是大家越来越关注用户体验的时候。
传统工具的缺陷
压力测试这项工作在很久之前大家就在做了，只要有测试团队的，压力测试一定会有。过去压力测试的做法实际上都是工具性的，所说的工具如JMeter和LoadRunner，我们称之为上一代产物，他们有一些缺点，一个是适应性比较差，需要对一次测试准备大量的环境，如要准备很多台压力机，然后录制脚本，做得好可以进行一些分发，但是这些机器终究要准备的。
尤其对业务量比较大的企业，比如我们要制造50万或者一百万用户访问的时候，一台物理机的并发模拟用户在500到1000的样子，就需要准备大量物理机，成本比较高、而且时间很长。像某些客户以前为了做性能测试，准备机器有时候就需要几个月的时间。
另外一个最大的问题是实验室环境，我们所说实验室基本在内网把环境搭好，而内网的网络条件都不会差，这时候用机器去压，有的时候并没有问题。但是真正上到生产环境，网络带宽和前端的负载机制，甚至前端加了安全措施都有可能对性能产生影响，导致服务响应慢或者宕掉。
压测宝的优势
压测宝有几个优势：1、速度，这个速度主要是部署，因为它整个测试是在云端发起的。利用了云的优势，在云端可以几分钟开出来一台压力机。我要模拟十万用户访问，开了五十台服务器，我想增加到十万，再开五十台就好了，不需要在每台机器上做准备工作。从过程来说，整个我们开压力机的时间基本上跟云主机的启动有关，大部分测试在半个小时内就能把压力测试环境准备好，而传统的工具基本上在一个多月。
2、分布式的环境，我在云端不同地区发起的用户访问，它不是在内网发起的，所有的架构、链路都会到，这是一个真实环境，因此可以大规模的，一百台、两百台甚至一千台都没有问题，而内部准备的时候还是受制于自己买的服务器、服务器的容量的限制。
3、性价比，我节省了人工，不需要那么多人准备压力环境、也不需要那么多人做压力测试，都由系统和云解决了。另外我可以在任何时间、任何地点来做，因为访问云是不受任何限制的，意味着发起压力的时候也不受限制。我们可以同时对多个系统做测试，都是在云端发起，只需要替换一下脚本就可以。
压测宝也在改变压力测试的标准。
一个是从研发到生产可以做高频度测试。因为在云端，想用就开，不想用就关，随时来做。第二可以从用户端真正做到全链路测试。
第三是实时统计分析，压测宝里的数据是实时统计的。用其他的测试方法，测试条件包括压力数量准备好之后，一般都会跑完，比如上五千并发，结果系统直接压死了。我们是可以随时调整压力的，随着压力逐步上升，系统的性能数据动态呈现。压力从一千加到五千，两千的时候就像我们刚才看到的数据，性能已经在下降了，大量出错，这个时候没有必要继续往下压。我们可以停掉，也可以把压力往下调，比如两千的时候出现严重问题了，那我调到一千五。根据系统目前状态，在保障业务正常运行的情况下看看能撑住多少用户访问，通过压力的上下调整找到这个点。也许我找到1300并发的时候，系统出错、性能都在容忍范围内。就说明系统现在承载能力在这个范围。
第四是配套的监控机制，压测宝能做到这一点依赖于一个监控机制，这个监控是可以接收即时数据，我们做了很多数据呈现的报表，这些报表也是随着压力变化呈现实时的曲线，所有数值都是在变化的，所以我们可以看到它的状态。
第五是测试周期的缩短。现在我们在给很多客户做的测试，其实花时间最多的是脚本录制。脚本录制完之后只需要几分钟、十几分钟压力测试准备好可以去测了。对脚本录制这部分，大家做的都是差不多的，比如压测宝，都是通过我们提供的录制工具，像实际访问一样，点浏览器一步一步操作，操作结束之后脚本录制完成。但这只是最初的脚本，真正要测试的脚本，有的时候要排除很多内容，比如CDN上的资源。很多时候压CDN是没有意义的，需要把CDN的资源替换掉，只留下服务器端发出的实际请求。另外有一些业务存在等待时间，中间也可以穿插等待时间。
压测宝的优势有哪些？
从使用层面上，我们不需要再做大量重新的学习，学习成本很低。录制脚本这块我们也会帮助来录。我们现在做的压力测试，对客户来说只需要把业务告诉我们，剩下的事情基本上不用管，所以做得很快。同时我们只要准备好一次之后，如果业务没有大的变化，以后每次直接跑脚本就可以了，完全不需要客户自己花太大的精力重新准备。原来的压测方式需要一个月测一次、两个月大的上线测一次，现在可以做到只要有版本更新迭代就可以去测。
我们在云端我们有很多合作厂商，几乎主流的云服务商我们都能在它上面测压力。测试规模可以从几万到几百万，主要取决于云主机开了多少，我们就能测试多少。这个压力量是没有一个上限的，这是传统压力测试在内网很难做到，因为硬件投入就很难。
报表是实时统计的，可以边做边看。
我们可以在测试过程中解决性能问题，解决问题不是单纯靠这个工具。本身云智慧是做性能方面的监控和分析的，压力测试能够帮助发现问题，我们的APM产品透视宝可以分析和定位问题。一般的话都是搭配来用，通过压测宝测性能、发现性能问题，通过透视宝分析和定位性能问题，而控宝能够做的一些是对基础服务的分析，这几种产品我们都有大量的实际案例。
今天把压测宝产品做了简单介绍，还是概念性的。因为在座的都是运维，跟测试部门不同，测试部门对这方面的需求比较多一些，一般来说做压力测试，尤其线上的压力测试有两种，一种是测试环境上线前做的，还有一种可以在上线后做。很多系统已经上线了，上线前没有做过压力测试，也不知道能撑多少的访问量，什么时候做系统升级，也没办法做预测。我们给不少用户做过这样的事情，用压测宝来做上线后的压测。
用压测宝做这件事最大的好处是压测宝能够逐渐调整压力范围，也就是说不会像常规压测，设5000，一下就爆了，我们可以找到系统性能的范围，第二能找到性能问题出现在哪里，所以这个场景下用的多一些。另外就是测试环境来做，但不论怎么用压测宝做压力测试，基本上需要运维部门来陪伴。
以上是我今天关于压测宝的分享，接下来是用户答疑环节，大家有什么问题可以提出来。
提问：您刚才提到压测宝监测功能比较强大，如果要看服务器压力，不知道压测宝怎么看？
Jason：压测宝重点不在这块，但会提供一套比较基础的监控，比如对服务器的监控，比如CPU内存、流量。我们一般搭配监控宝、透视宝，向中间件、数据库在压测过程中都有可能出现问题，配套的这些东西还是要做的。
提问：可以在内网监控吗？
Jason：可以在内网做，但是需要在测试的时候跟外网不同，和传统的方式类似，缺点是用户访问量不容易加上去，要做的话要加很多压力机。
提问：压力机都在云端？
Jason：对，其实我们还是推荐云端，如果放在内网跟真实环境还是有差异。当然像银行、政府机关因为有政策要求，说必须在内网环境，不能出公网，如果有条件的话，绝大部分环境都可以出公网，因为业务都在公网，这种访问最好在公网来做，自己省力，测试效果比较真实。
提问：压测宝和基调的测试一样吗？
Jason：其实并不一样，因为基调检测是模拟用户发一个单次请求来做监控。压力测试是把一个测试用例让大量用户，比如十万个用户持续访问，或是并发几千访问。
提问：一个是单个用户、一个是批量用户，他们之间产生的信息有差异性么。
Jason：这些信息都是类似的，每个请求都是一个HTTP请求，这肯定都是一样的。但是数据呈现的东西不一样。基调呈现的是从监控角度呈现，压力是看负载、错误的统计，做这方面的。
提问：如果用压测宝必须贵公司技术支持，还是我们本公司的测试也可以使用你们的环境？
Jason：你们可以使用这个环境，这个环境本来就是给大家来用的，但是这里面我们参与什么？一般会帮助做脚本录制，录下来还好办，更多的对一些变量的调整。压力测试的时候，我们准备最简单的测试实际用户，交给你之后，你可以拿出一万个用户，用户名、帐号密码这些信息肯定不能每个去做，通过一些规则、变量的方式去做，这种东西需要做脚本编写。压测宝提供了一些功能，但是是需要花一些时间研究和学习的。很多是我们帮着做的，做完以后照着这个就学会了。
提问：压测报表是通过什么做的？
Jason：其实都是图表呈现的插件，在创建压力测试任务的时候，我们提供了大概几十种数据呈现的选项，选择完之后就会把图形显示出来。