大家好，我是CC，这是第104篇文章。
关于压测这块讲过很多次，我在viptest&七牛云、testerhome&得物等一起举办的企业级沙龙也讲过全链路压测相关，这次直播的主题是老张群里粉丝投票选出来的，可见大家在公司性能落地层面依然存在种种困惑，在直播前，小牛同学也跟我聊了线上压测落地的痛点，小牛目前在一线互联网公司，他给我的感觉是在一个成熟的公司，只要你不停的思考依然可以做很多改进。从我个人实践来看，现在无论是执行、监控、或者是定位配套方案都很多，但对于很多同学来说还是很迷茫，性能测试从执行层面我认为并不难，我觉得有以下几点原因导致不少人不能上手。
- 能够科学正规做性能的企业比较少，网上搜的不少内容本身不够准确，一般需要老师傅带。
- 个人层面性能测试很难达到一定规模的实践，自学只能到脚本层面。
- 需要诸多的知识点串联，学习能力一般的同学无从下手。
- 专业的压测服务商越来越多，全套的解决方案可以快速的解决问题，企业不一定需要花很长时间去培养相关领域人才。
下面是直播的实录，我本来是想讲一些落地和学习技巧，授人以鱼不如授人以渔，但有同学对鱼本身更有兴趣，CC认为比知识更重要的是如何获取这些知识，为了满足多方听众，关于知识体系本身我也引用了我专栏内的一部分内容，加上老张和ckl老师的观点。
一.性能测试包含的知识点
1.性能测试的基本认知很重要，说起来不以为然，但不少人理解都是有问题的。如何去衡量性能测试的指标，并发，tps、响应时间等，能够理解的比较透彻的人很少。比如说并发，有的测试理解为工具里的线程数，运维理解的是连接数，业务理解的是pv，这样的情况下，你觉得性能可以做好吗？会议上讨论的热火朝天，可能说的都不是一件事情，而这样的情况，很常见。
2.工具的使用，大佬的的观点是工具不重要，性能测试思想最重要；站在大佬的角度也没啥问题，但是在你没有成为大佬之前先把工具熟练了，如果你工具都不熟，没办法证明自身价值，不能熟练干活，难道专门让你去跟老板讲价值吗？熟练的标准是啥？以Jmeter为例，分布式配置，beanshell，插件开发你都得会。
3.监控工具的使用，硬件监控和一些组建监控如（mysql，jvm，redis等），都可以用exporter grafana promethues的方案，根据exporter类型的不同，可以针对不同组件的监控，对于链路监控可以有Skywaking，pinpoint等，先知道常见用法，再去深入了解使用特性、弊端等。
4.对编程语言、开发框架，中间件，sql运行机制等知识的熟悉，现成的工具可以帮助你分析定位问题，而为什么还会产生这样的问题，需要你去了解原理。
以上你都比较熟悉，应聘高级性能测试工程师没啥问题。
二.如何构建知识体系
- 性能测试的工具原理与使用。
- 性能测试目标与场景分析。
- 如何制定性能测试指标；参考数据有哪些，怎么获取；常见的性能测试场景有哪些，如何通过这些场景来提高性能测试的覆盖率，等等。这些都是性能测试方案的组成部分，只有制定了正确的性能测试方案才能做出有效的性能测试。
- 分层监控体系建设。重点是监控和问题定位，包括如何做硬件监控、系统链路监控，如何打造可视化的监控报表。监控是性能测试必要的步骤，是你发现性能问题的“眼睛”。
- 性能分析优化实践。如何从服务端、中间件、数据层三个角度了解如何定位和优化问题，如何结合自身工作场景进行性能调优。
在下文企业级压测体系中，上述几点会拓展下。
我认为相关的知识体系本身或多或少第一模块也都聊了，这部分核心词我认为是构建，说的直白点就是个人对性能知识如何能获取或者说掌握。
从一个学习角度上来说，性能和自动化或者其他方向最大的不同我认为自动化可以自学，但性能很难，对于自动化来说，只要你有笔记本去coding，只要你足够自驱，都可以比较快的成长；而性能你通过自己学习，可以掌握概念以及工具的用法，而真正达到企业级应用，必须要有相应规模的项目或者体系去锻炼，这一点无疑成本是很大的。而不经过企业级项目的锻炼，你的性能测试相关的技术和视野很难从量变引起质变。
那怎么办呢？如果你不会相关技术，企业一般也不会给你相应的机会，所以个人可以做一些低成本的实践，在个人服务器上部署单实例项目，去熟悉各种组件怎么用，你如elk，kafka等，让自己具备项目上手能力和相关的技术对话能力，一旦企业有机会，再去充分参与，通过这样的途径，形成质的飞跃才有可能；一些人的思维比较依赖于找一个企业能培养我，不是说完全不可能，你得证明你是值得被培养的，为什么不培养张三李四，只是纯粹等机会，劝你早放弃。
三.如何构建企业级的压测体系
问题：测试模型如何构建
这块核心在于历史访问数据，指的是什么类型的用户通过何种终端访问服务的接口次数。
怎么获取？Nginx，ELK都行，这种日志记录了用户的访问行为，可以基于相应的组件获取日志信息去做计算分析,下图是ELK。
有同学在直播间说了漏斗模型，我认为这是一个相对宏观的趋势模型，对于精确度比较高的场景并不适用。
以微服务为例，通过对原始数据的加工，你可以得到接口级别的测试访问模型，如下示意:
如何构建企业级压测体系？
- 需求管理
上面的问题给出了参考数据，我们就可以来看需求了，对需求接入和充分的分析能帮助你在测试之前获得更多的信息，也能制定出较为完善的性能测试方案。业务测试和性能测试都是从需求入手的，但业务测试会去了解相关的业务背景和产品方案；对于性能测试而言，则在需求来源、分析方面提出了更多的要求。
- 需求来源
需求来源其实就是你这次性能测试的目的，调研清楚这个问题能帮助你更有针对性地获取数据，从而制定更为准确的性能目标。例如，我们这次的性能测试是为了应对“618”的活动，那么就要考虑有没有以往的性能测试数据沉淀、以及当前有多少活跃用户数、网站交易数和活跃人数有没有相应的递增比例等和该活动有关的数据。
- 需求分析
弄清楚了性能测试的目的，我们就要来做需求分析和梳理了。
需求分析是在原始数据中提炼出有效的性能参考数据，通过这些数据构建性能测试的模型，再通过模型形成测试步骤。性能测试模型和性能测试执行步骤也是性能测试方案的核心内容，它决定了你做性能测试是否准确，是否更符合真实场景。
- 分析方案
在需求分析完成之后，就需要将你分析的内容提交一份性能测试方案了。性能测试方案的目的不仅仅在于让自己知道这次性能测试如何执行，也要让你的项目成员知道这次性能方案，它的执行周期、涉及的成员等，然后再一起评审这次方案中有没有不合理的地方。
- 性能测试环境
线上的全链路性能测试非常热门，但并不意味着就只做线上的性能测试了。关于性能测试环境，一般情况下我们会独立搭建一套，与业务测试环境相隔离，同时也能够在上线之前尽可能暴露一些代码中的问题。
我曾看到过这样一个观点：线下性能环境与生产环境机器配置相差甚大，我们直接在生产上做性能测试就可以了，没有必要在测试环境中做。
这个观点引起了一部分人的赞成，但我认为这个说法不够全面。环境的配置高低是决定性能结果的一个影响因素，但不是全部因素。能够提前测试、提前暴露 bug，修复 bug 的成本也就越低，所以在线下必须有专门的性能环境，它可以帮助你提前发现内存泄漏、死锁等问题。更何况，这些问题的发现和修复与服务器硬件配置并没有直接联系，如果能够在线下提早用更低的成本解决是一种更优的选择。
如果没有做线下性能测试的情况下直接在生产上测试，对性能中的异常测试、高可用测试可能无法充分执行；同时，修复性能 bug 也需要功能上的回归，这些都增加了过程管理的复杂度。
- 客户端数据监控
性能测试中说的客户端一般是指测试机，测试机输出的数据是观察性能好差的关键指标。我推荐 JMeter InfluxDB Grafana 的框架，它具备展现直观、数据实时的特点，可以全面地展示监控的数据。
- 命令行监控
通过命令的监控我们能够以最直接的方式获取服务器的实时状态。以 Linux 服务器举例，top、vmstat、iostat、iftop 等都是性能监控常用的命令。
- 可视化监控
可视化监控相对于命令行监控提供了更为丰富的图表展示，这样的话看起来更直观易懂，适合监控大屏的展示，能够将监控信息传递给项目组成员，但它需要提取数据之后计算，然后再展示，有一定的延迟，不如命令行监控直接。Zabbix、Prometheus Grafana 等都是可视化监控常用的手段，它们可以把数据持久化，能够调取过往时间轴的历史数据，一般在回溯、汇报、复盘时使用比较多。
不管采用何种方式，在进行硬件监控时，都应该涵盖测试过程中所有的服务器，包括压测机、应用服务器、中间件服务器数据库服务器等。
- 链路监控
链路监控是对代码本身的追踪，代码问题常常是问题产生的根因，所以关于代码的监控不可忽视。目前常用的代码链路追踪工具有 SkyWalking、PinPoint、Arthas，帮助你定位代码问题。
- 业务规则监控
业务逻辑报错和用户息息相关并且用户是可以直接感受到的，比如商品库存不足、用户余额不足，它们会直接影响用户的体验。线上出现问题并不少见，重要的是如何第一时间得知并且解决这些问题。所以当出现问题即时发送报警邮件或者短信也是十分必要的，对于业务的监控同样不能忽视。
拓展升级：企业级线上全链路压测的技术和流程
压测对于一个企业级的要求是需要具备开展全链路压测的能力。我主要说一些与线下压测的差异点和可能的踩坑项。线上的压测我们需要具备一定的系统改造能力，比如如何识别压测流量，如何做全套的影子库表、队列，缓存实例等等。而这一套要在生产上稳定运行，需要充分的实验，你可能会遇到下面的问题：
1.系统中跨协议影子流量如何标示
2.父子线程流量标示的传递
3.父子线程流程标示错乱
4.如何避免影子数据流量流入到真实库表中
5.如何进行过载保护
1-3的技术问题是相通的，可以仔细研究下threadlocal以及相应的增强类，第四点如果在前面没有技术缺陷的情况下，需要加入保护方案，因为一旦存在系统的变更，是有可能发生数据泄漏的，所以可以通过设置白名单，校验压测流量，如果开关没打开，则不能流入系统。第5个问题可以设置相关的阈值，如cpu、内存使用率，或者相关接口访问的报错率，达到阈值压测自动停止。
线上压测并不是说你脚本准备好就可以直接去压测的，压测技术保障试验流程：
- 线下的技术试验是必要的，线上试验的容错成本很少，包括试验数据流转验证，数据清理逻辑验证
- 线上的压测线读业务的验证，包括权限的验证，权限包括用户数据的业务权限和你压测机访问服务器的权限。在批量请求下会不会触发风控，会不会有拦截。批量请求下有没有限流机制，包括服务器层面（如防火墙，服务器连接设置）以及应用层面等。
- 线上写业务：按照线下环境进行梯度试验。
- 线上全链路：不少公司基于内网做全链路，外网做的少，如果需要全面一些，外网也是需要做的。
全流程压测的实施过程
全链路压测不应当理解为一个独立的流程，从业务部门开始就应当有所涉及，如果你连这次大促规则都不清楚，如何去匹配相应的测试模型？对于研发和测试来说，在前置环节要去解决基本的性能问题，可以执行单元级的性能测试或者接口级别的。而线上全链路压测更关注容量，部署的合理性，这个在线下环境测试往往不能发现；对于实际大促的监控，去发现可能存在的问题还有对数据进行研究，这些都是必要的。
四.性能测试体系如何在企业中落地
1.有没有必要落地。
性能测试是为了治理公司的性能方面的问题，是有成本的，尤其是线上全链路压测；如果大家普遍认为性能方面暂时没什么大问题，企业这方面不准备投入太多资源，那么没必要在公司聊各种性能测试体系，说的太多，反而觉得你有问题，除非你强有力的预见性打动老板，能够感受到价值。
2.你的想法能不能落地取决于你的专业性，你的专业性会让你具备公信力。
你的报告是否足够准确，能够对稳定性保障提供实际价值。比如你的测试模型与实际用户访问的一致性，并不能说会对未来的用户访问很贴近，但至少要跟你们的既定目标很接近。你的结果能不能匹配大促的实际情况，会不会出现压测处理能力很高，而大促还没达到阈值就各种不稳定，如果这些问题你的认知都不是很清晰，你的落地也就没什么意义。
3.学会复盘，很难一次成功，但不能犯同样的错误，从失败案例中汲取经验。
- 性能需求评估不准确
- 场景设计不合理
- 测试结果确认不到位
- 数据准备不足
如何让性能测试产生价值和个人公信力的提升，这部分能做到，落地我认为不是难事，就聊到这里，已经说了很多了。
CC简介：
测试实干派，目前在近70人测试团队担任质量委员会负责人，曾就职于一线互联网公司，在知名App上发布过测试专栏，付费订阅人数10000
