靓汤：性能测试策略实战解析

2017年3月7日周二晚8点30分，具有十余年自动化性能测试以及六年测试管理及测试过程优化的经验的产品测试架构师靓汤带来了主题为“图解性能测试之二：如何做性能测试”的交流。以下是主持人赫阳整理的实录，记录下了本场Chat的精彩片段。

问：订单交易类的如何做全链路压测？

答：这是一个大问题，有很多要聊的。首先解释一下全链路压测：全链路压力测试是2013年阿里提出来的。之前压力测试主要是：线下模拟单一集群测试；牛叉一点的团队会线上引流压测。但传统的压力测试暴露出的基本上是一些单点问题，最主要是测试情况与真实情况有偏差。

全链路压测特点：在生产环境压力，验证全流程，模拟用户交易全流程或模拟某产品大促或某个平台大促等，需要的大量技术支持和架构支持。

全链路压力测试一般是一些大公司在玩，最成熟的应该是阿里：主要特点是线上压测、影子数据库、全面容器化、全面监控、性能测试平台化、大量微服务化，所以一般的公司没有难做起来。那么对于小公司开展全链路压力测试，是比较困难的。

对于用能力有资源的团队来讲那么可以做些什么呢？

• 全面监控

• 性能测试平台化

• 推动公司开展微服务，进行服务治理

以上是前期可以开展的工作，特别是微服务，对于服务治理有很大帮助。以前接口调用情况是黑盒，现在可以变成白盒。

服务治理方面，可以建立统一平台、统一监控、统一调度，统一集成等。

中期可以做全面容器化，这主要是为了应对压力而要做的事情，微服务和全面容器化给灰度发布带来了机会，影子数据库则是实现线上压测的必经之路。

不同阶段可以用不同的方法实现。主要看公司的技术储备等。其实看有没有资源。

对于没有能力和资源的小团队：确定压力测试的目的最重要。我们做全流程的压力测试就是保证流程中没有瓶颈。我建议把事情简化，能才就拆，整个链路一定是有瓶颈的，找到瓶颈，找到最需要测试的地方是现在需要做的。

• 我们的目标是避免瓶颈。我们就分析哪些需要做压力测试，文章中描述需求和调研中有很多方法确认关键业务和关键场景。

• 找的瓶颈后就各个突破。

• 如果是多系统，建议先分段进行各系统的压力测试【此时可以有挡板】。

• 在整合所有资源做一次拉通的压力测试，如果系统多，就涉及协调沟通等问题。

以上是我的思路。

问：很多时候团队中没有如此优秀的人才负责性能测试，很多时候从设计时都没花心思考虑性能问题，这种怎么在实际工作中推进？

答：这是一个好问题很多团队是不重视性能测试的，分到的资源就特别少。性能测试是测试的一个分支，所有很多方法可以通用。

总结起来主要策略是：让干系人紧张、让流程顺畅、让设计可验收、让风险提前发现。

• 在需求评审时，引入非功能需求评审，问用户问业务要，用户量、要业务量。不行就自己参加调研，如果用户说不用考虑，就需要你去说服用户了，要么就做不了了。

• 在设计时团队使用验收测试驱动开发的办法，外部要求研发的设计需要测试验证。测试内部要求测试人员增加性能测试验收标准。

• 研发时，先测试前置，验收测试驱动开发，然后可以试试测试驱动开发，在测试里就设计高并发的压力测试，迫使研发人员对于高并发下的同步锁、响应时间等做错整改和设计。

• 在上线后，提出当前性能风险分析，如果做了微服务的就能看到服务的调用情况等。可以把用户的调用情况作为下个版本的输入，给到研发人员，产品架构师等。

• 另外要通知到你的运营和销售人员，有大促和活动时，通知到测试进行一些专项性能测试。

其实测试人员要明白，最关心系统性能的不是测试人员，应该是产品负责人；我们为何看到产品负责人一点不紧张，其实是因为他不了解。测试人员就要让相应人员了解情况，并督促验证相应问题。

问：同时在线用户数还是不太了解是要测什么？

答：用户数业务量是影响系统的主要因素，因此我们要细分用户。同时在线用户数主要用户组合场景的情况，比如12306有的用户在查询，有的用户在登录，有的用户在支付。我们掌握同时在线用户数主要是用来分为真实业务系统中，我们如何来进行虚拟用户的分配。主要考察固定时间段内用户的占比等。

另外对于同时在线用户数可以结合实际业务进行分析，看看有多少用户存在业务场景转换。比如一个大数据平台，A类用户可能一直关注商业人群的分析，但突然有一天这类用户可能突然转到分析商圈商业。有些业务之间存在引流的情况。这也是压力测试是设计人员需要考虑的。引流的用户比例大概是多少。

另外需要结合僵尸用户进行分析，看看有多少用户是短周期的僵尸用户。这些僵尸用户是在什么时候出现。比如以下场景：我们分析用户时拿了去年的双11的历史数据。而我们性能测试目的是系统能在一般大促中承受压力。那么大家可以在去年双11的用户中移除，全年就双十一有需求的用户。以此来保证系统不浪费资源又能承受压力。

用户不做操作，也要保证你数据库的连接数能满足用户的临时性请求。

问：2016年除夕夜支付宝收集福卡抢红包，对于这种即时性业务，支付宝测试团队如何去调研用户量，怎样最大限度去保证调研的用户量和当天实际的用户量相近，如果出现调研的用户量远远大于实际用户量，这样是不是浪费公司资源？

答：这个问题有提到两块，一是用户量，二是资源如何更合理。

首先我不知道他们怎么做的用户调研，但如果是我，我可能这样做：

第一，这样理解吧，除夕夜通常都是以最大业务量进行计算的，相信双十一也没有这样的高峰期。 对于支付宝系统，本身有他的优势：1）有历史数据可以参考；2）有用户增长比率可以参考。

当然最牛的就是用户预测。我们现在公司就在进行业务量的预测，当然这用了大数据建模。这个可能就需要专业人才了。我们现在的产品销量预测就能做到98%的准确。当然是指特定业务。如果对于普通公司第一次遇到大促的时候，有没有竞品和历史数据可以参考的时候，通常可以认为你的80%用户会参加活动。置于那个功能会有最大用户数和高峰用户数是多少，文中有详细介绍。

第二，对于我来讲保证业务的稳定性，此时高于用户的体验，架构上优化。另外我认为他们的红包永远不会出钱系统崩盘的情况。原因在于在真正服务器产生压力前，所有的压力都在队列里。发红包不同于秒杀，秒杀可能在前端就当掉了很多请求，然后在把请求放在队列，最后才会对服务器造成真正的压力。其实业内的同学都知道，很多公司的秒杀都是假的，很多用户都被提前挡在了外面，这也是提高体验的方法之一。

第三，使用云、微服务、使用容器保证，资源的收缩。好处在于实时可以看到资源的情况。有的公司也在产品包的目录下放置了监控包。用于全面的性能监控。根据监控情况实时调整资源。

调整的方法可以给大家说一下：使用动态服务注册，和动态服务通知的方法实现。当发现服务需要扩容的情况时。增加服务的容器，通知服务注册，然后消费方收到服务通知后就知道去访问相应的服务器，而减轻之前服务器的压力。

问：在性能测试时，模拟用户需要追求越真实越好吗？如果需要，有哪些模拟的方法，包括分析方法。如果不需要，如何来选择性能测试时的用户行为呢？性能测试一般需要持续多长时间？性能测试和稳定性测试还有压力测试的区别和联系？

答：第一个问题：当然越真实越好。分析主要两个方向，第一个是真实业务操作。主要看那些业务操作会对系统带来压力。

比如查询和查询条件的组合。另外就是要考虑用户群体，如果是不懂电脑的群体，如果出现卡顿，可能他会一直点下去。那么这就需要考虑是否前端就把这种无用请求给挡回去。用户有哪些关键行为，需要关联，我们性能需求分析中的关键业务分析。通过关键业务找到关键用户场景，去分析用户行为，准备相应数据和测试场景，测试步骤等。另外压力测试时间，一般业务15-30分钟就可以了。稳定性测试需要27小时以上，但如果已经性能问题了，可以随时中断。压力测试是稳定性测试的基础。压力都有问题就不要进行稳定性了。当然不是所有的压力测试都要做稳定性测试。原因要跟着性能测试目的来。以目的为出发点。

问：性能测试自动化怎么做？

答：有的同学可能觉得这是一个不怎么样的问题。但这是一个好问题，特别是使用不同工具进行性能测试的人来讲。所有需要一个平台，或一个串联的程序。这个时候一下CI程序就有用处了。我们可以使用粘盒机的python语言。也可以使用jenkins这样的工具，把不同的性能测试工具连起来。如果单一场景可能使用lr/jmeter/soapui等性能测试工具就可以实现自动化。自动化需要根据业务情况来看。

我之前在华为做一系统的测试时调度，就用的windows系统的定时任务来跑的。soapui是一个接口自动化、性能、安全测试的一个工具。所有根据实际情况来做。有资源就做平台。所有代码、调度、监控都让平台帮忙做。没有资源就用工具，工具多了就组合。

问：性能测试结束的准则是怎样的？系统性能不稳定了就可终止测试还是系统崩溃？一般系统的资源运行到极限的状态的参考值是多少呢？

答：工具之间可以毡合在一起跑。比如我调完lr在调SoapUI、在调自己写的代码。准则在测试策略里体现、具体结果以评审通过的性能指标为准则。具体指标在文章中有提到。压力测试压出问题就可以停下来了。因为优化后又要重新测试？一般系统的资源运行到极限的状态的参考值是多少呢？这篇文章里也有具体的数字，可以看看文章。

问：据我所知，很多导致性能地下的原因是交互没有分割好，比如有些放在数据库上的业务被放到了应用服务器上，这导致了数据库和应用服务器的反复交互，作者能够给出一个好的解决方案能够通过压力测试发现并合理的解决这种规划不当造成的设计缺陷么？

答：这有是要聊很久的话题。由于时间关系我题一下关键字，大家看看那些要展开我们就展开。首先我认为系统性能是设计出来的。如果真要谈到测试，那么就在研发设计的时候干预。通常我们性能设计会做这些事，大家看看自己项目可以选取什么。

一、动静分离

静态资源拿出来讲一下。所有静态资源放一个服务器。记得前面加一个网管。不然所有请求还是会通过动态服务器。

二、读写分离

第二个主要是对数据库的请求，进行读写分离。这些优化第4场细聊。

三、分工明确

是指代码的职责划分吗？是的，简单例子对于给别人掉的接口放到一个包，对于自己调别人的接口放另外一个包。

也可以根据业务功能来分，目前最好的架构状态就是微服务。

四、热数据无论大小都进缓存

五、慢SQL分析、索引

六、业务数据转历史

一般快到业务高峰期的时候可以对不参与业务高峰的数据进行转历史操作，减少表的数据量。当然有的公司进行了分表、分库出来，就更好操作了。当然业务高峰前还可以把系统里的慢SQL查询出来，进行SQL优化。慢SQL需要进行一些配置，所有要提前进行。慢SQL的具体如何优化，我们第4场CHAT会具体分析。

七、分区、分表、分库

目的通常就是减少基础数据量来的。后面我会找到相应的PPT补充这次回答的。大家可以在关注后面整理的文档，一下没有找到。一般按业务场景分、按hash值分。或者引入外部的中间件来分如mycat

问：进行性能测试的环境和数据，会对测试结果有影响，导致测试结论数据不准确，如何避免？

答：

• 一定要在每个事物进行数据断言。

• 使用生产数据（不脱敏最好、非要脱敏就越少越好）。

• 测试人员对业务场景和研发代码要深挖。

• 准备数据的存储过程、方法、策略要通过“干系人”评审。

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF9332500001E5F11B67770A1C28