题记

今年是我个人从事软件测试工作的第六个年头，职业生涯至今经历了功能-接口-自动化-性能测试岗位的变迁。

18年下半年开始以团队owner的角色进行工作开展，不过当时团队技术体系建设已经步入正轨，对我个人而言，并没有太多沉淀。

19年跳槽后，有幸从零开始主导我司的性能测试体系建设工作，个人之前的很多想法得以落地实现。

这也许是除了薪资之外，对我个人而言获得的最大成就感。。。

导图

演进

基础建设

1、文档建设

前段时间知乎回答了一个问题：做技术人是不是都反感写文字类的东西，比如需求文档，需求分析等等？之前的博客也写过类似的内容：性能测试从零开始实施指南——文档建设篇。

我个人认为无论是作为个人学习笔记抑或一个Team的累积沉淀，文档建设的工作必不可少，而且是重中之重。原因如下：

1）降低“口头说明”带来的风险；

2）文档是很重要的记录和交流介质；

3）便于事前、事中、事后快速回溯追踪；

4）降低工作交接、沟通的成本，提高效率；

5）文档是一次梳理思路，review的方式；

6）文档是很重要的工作产出，自我价值诉求的重要手段（KPI）；

当然，现在有很多在线协同文档工具，如confluence、语雀（参考-工具汇总）。我司性能团队文档类目如下：

2、资源管理

这里的资源主要指压测资源，包含如下几项：

1）压测机

2）压测场景

3）压测脚本

4）压测数据

无论是平台化还是基础的命令执行，其中要考虑的因素还是很多的，比如：

脚本命名规则：以接口名命名，见名知意；

文件命名规则：以参数类型、字段名命名；

权限管理：性能测试同学可以赋予root/s-user权限；开发&业务测试同学可以赋予ops/onlyread权限；

路径管理：按照服务器的访问权限&路径命名，比如：

    　　 压测脚本路径：ops/perftest/script/transcation/order/ordercreate.jmx

    　　 压测数据路径：ops/perftest/data/transcation/order/productId.csv

PS：如上命名规则和权限路径，以jmeter命令行启动场景为准，平台化可通过配置文件统一自定义。

3、环境建设

我个人强烈建议有一套独立的压测环境，这样既能做到和业务测试互不干扰，压测的结果相对来说也更贴近真实的场景。

考虑到成本和维护等因素，压测环境建议按照具体情况来配置，主要遵循如下几条原则：

1）机器配置和生产保持一致；

2）机器数量和生产进行等比缩容（可以同配置最小化，即1台机器1个服务）；

3）网关和注册中心&配置中心可以集群部署（按照流量大小）；

4）支持自动扩容、监控告警等功能（需要基础技术建设到一定程度，比如：发布&监控平台支持）

PS：上述原则，基于微服务架构！

4、技术选型

技术选型主要考虑如下几个方面：

1）压测工具：接入成本、学习成本，重点是快速产出有效直观的价值！

2）监控工具：监控工具要考虑到性能损耗、接入难度、全面性、易用性；

3）数据工具：包括造数工具、数据存储、解析等方面；

4）分析工具：主要指的是问题分析工具，比如JDK自带的JVM Profiler；

规范制定

技术体系建设中，规范的重要性不言而喻。在性能测试中，比较重要的有如下几条规范：

1、需求发起

性能是一种需求！需求从何而来，如何发起，准入准出条件，必须优先界定好。思维导图：

2、需求评估

在性能需求评估中，主要考虑如下几点：

1）可行性（必要性）分析；

2）收益率评估（投入/产出-ROI）；

3）约定关键时间节点，如提测、deadline；

4）统一重要指标口径，明确预期指标（业务&技术）；

3、资源排期

这里的资源主要指人力资源、时间窗口以及机器资源，对于一个team来说，资源排期很重要！

4、指标度量

这里的指标并非压测数据指标，而是从部门/Team角度长期来看，需要考虑的指标，主要参考如下几点：

1）成本：测试前后，机器成本降低了多少；

2）数据：每迭代/版本，服务/链路性能提升占比；

3）效率：每个阶段，准备/部署/测试耗时降低了多少；

4）输出：团队/部门内部技术分享、性能宣讲、质量意识提升比；

5）质量：每统计区间，线上服务可用性/稳定性提升比、故障率下降比；

6）赋能：每月/季度，业务测试团队性能测试工时/需求接入/技能提升占比；

5、测试方案

测试方案的规范，可以视公司研发文化、team大小、具体情况来制定。当然，制定一个规范模板还是很有必要的，这样不仅能对工作给出一定的指导方向，还便于其他干系人能快速了解。

参考：简易性能测试方案模板

性能测试方案模板.docx

6、测试报告

同测试方案一样，测试报告的规范模板也是很有必要的，同样可以对工作给出指导方向。

参考：简易性能测试报告模板

性能测试报告模板.docx

需求周期

1、调研评估

接触了很多做性能测试的同学，聊下来，发现部分同学对性能需求的可行性评估，依然不太明白为什么这么做。如上文所说，在性能需求调研评估过程中，要注意的几点分别如下：

1）可行性分析：即业务场景、该场景的技术实现方案、用户特征等，是否有必要开展性能测试；

推荐阅读：认清性能问题（Thinking Clearly about Performance）

2）收益率评估（ROI）:开展性能测试的成本，包括时间、人力、机器环境成本，以及技术改造成本；

3）约定关键时间节点，如提测、deadline：这样做的好处是能根据测试时间窗口更好的评估测试工作的安排，知道什么时间做什么，区分优先级很重要。

4）统一指标口径，明确预期指标：比如双11大促，技术指标包括：日常线上峰值流量、机器负载、预估流量递增比率、扩容速率、consumer group、告警阈值等；

   而业务指标包括：预计GVM、活动场次时间、优惠券类型数量、订单量等指标。明确这些数据后，才能更好的评估需求，进行压测方案设计。

2、需求排期

需求排期的重要性不言而喻。如何在有限的资源下尽可能提高需求的吞吐量，除了个人工作效率、团队协同能力之外，良好的资源评估和任务分配是很重要的影响因素。

3、准入准出

无论是过早还是过晚的考虑性能问题，都会是一场灾难！

过早考虑不确定性较多，太晚的话，优化成本及风险又太高，因此，选择合适的时机开始，是很重要的。

性能测试切入时机，是个玄学，需要考虑需求类型、具体场景、资源、时间、优先级等很多因素。但一般来说，还是有适合大多数场景的参考原则，列举几项供参考：

1）普适性原则-功能测试提测阶段切入；

2）特殊性原则-电商双11，最少提前2个月准备；

3）迭代性原则-二轮测试开始时切入；

4）新服务原则-prd&技术review阶段切入；

数据管理

数据管理是性能测试中很重要的一环，无论是数据量级、分布方式、是否缓存、缓存大小还是热点数据，都是需要考虑的地方。

还有一点经常被忽略的，是数据多样性引起的覆盖率问题。性能测试中，主要有如下几种类型：

1、基础数据

对于性能测试来说，基础数据一般指的是支撑业务流程正常运行所必备的数据，需要考虑如下几个方面：

1）数据量级：根据环境具体配置信息，保证数据量级和生产环境等比例，是很有必要的事情；

2）数据脱敏：从经验来说，基础数据的量级一般较大，常见的准备方式都是copy生产数据并进行脱敏；

2、测试数据

测试数据是为了满足被测业务场景的链路而所需的数据，在具体的压测准备阶段，需要根据被测链路，针对性的准备测试数据，保证场景的正常执行；

3、唯一性数据

某些比较特殊的被测场景，所需的数据是具有唯一属性的，或者一次性使用的特性。

从经验来说，这类数据，建议通过走正常的业务逻辑去生成，可以根据所需数据量大小来准备。

4、参数化数据

这类数据一般是具有可复用性的，比如productId/userId…，建议提前了解整体的业务和技术类型，准备一批量级较大的数据，避免重复工作。

问题追踪

1、问题记录

针对压测过程中发现的问题进行分类记录汇总，是很重要的一件事。优点如下：

1）问题追溯

2）工作产出

3）输出规范手册

PS：性能缺陷分类参考

2、生命周期

性能问题的生命周期，和功能BUG一样，这点技术同学应该都懂。

3、方法输出

影响性能的因素有很多，但绝大多数的性能问题都是由于配置、参数、代码逻辑的问题导致。

通过对性能问题的分类记录汇总追溯，可以总结出一些比较通用的参考规范，类似《阿里巴巴java开发手册》。

常见影响性能的因素及优化建议如下：

1）日志打印：降低日志输出level，减少IO消耗；

   　　　　 日志打印建议移除json序列化操作；

   　　　　 关闭状态机内相关日志，添加开关，大促时关闭；

   　　　　 出参过多情况下，封装处理，只打印需要的核心参数；

   　　　　 避免统一日志处理的apo拦截，建议移除所有主动拦截，需要的地方添加注解；

2）缓存使用：针对不易发生变动/变动影响较小的调用添加缓存/数据快照；

3）调用方式：对于一些聚合类的接口调用，建议串行改并行/异步调用；

4）线程配置：隔离各接口使用的线程池，防止长短尾拖垮线程池；

   　　　　 为了防止网络抖动，建议线程数按照（CPU可用核心数/(1-阻塞系数)*2）配置。

   　　　　 worker-threads、maxConnections、ConnectTimeout、ReadTimeout等参数无需过高；

5）重复调用：微服务间的调用存在方法调用冗余情况，应尽量避免；

6）等待队列：根据等待队列长度算法来说，建议队列长度根据可接受的最长时间来配置，比如：

　　　　 　　接受最长时间500ms，超过500ms还不能处理丢弃。已知正常rt25，每个线程500ms可以处理20个等待队列内的请求，

　　　　　　 假若有16个线程，所以等待队列长度设置为320。队列过长无意义，无法新增非核心线程，且持续恶化处理速度。

监控体系

监控体系的构建，是一个长期迭代的过程，很考验基础技术建设的能力和程度。

除了压测本身所需的指标监控，还需要对被测服务的资源耗用（基础监控）、链路调用关系（链路监控）以及各种中间件进行监控。

1、压测监控

基于jmeter+influxdb+grafana搭建的压测监控大盘：

2、基础监控

基于Prometheus技术体系搭建的基础指标监控大盘：

3、链路监控

目前业界内链路监控工具还是蛮多的，而且开源的也不少，足以满足日常所需。比如Cat、Jaeger、Zipkin、Pinpoint、Skywalking等。

下图为Jaeger的链路追踪界面：

4、中间件监控

中间件监控，涉及的组件较多，比如redis/MQ/Kafka/DB等，上面提到的链路监控工具，实际上对中间件的监控支持还算不错，当然，各有优劣。

需要哪些指标，告警阈值如何设置，还是按需所配吧。

报表输出

报表对于一个team来说是很重要的工作量化产出！

1、轮次小结

一般来说，性能测试要执行多轮的测试验证，针对每轮结果进行直观的比较验证，无论从效率还是信息同步方面，都是很有帮助的。

2、数据归档

这里的数据归档，包含需求吞吐量、完成质量、遗留问题、压测结果等很多数据。

我们目前的做法及规划如下：

1）需求/问题归档：写入mysql，通过定时job扫描，并定期拉取数据进行不同维度的聚合计算，CC干系人。

2）压测数据归档：写入Influxdb，并提供查询API给到度量平台来聚合数据，做其他维度的报表展现。

3、性能基线

性能基线的建立，有以下几点需要注意：

1）定义基准：包括术语、维度、范围、指标等信息的统一说明；

2）基准数值：个人建议可接受降幅原则上≤5%；

3）跟踪方式：性能变化的跟踪方式，和上述的衡量维度类似，分短期和长期，时间区间可自定义；

4）实施说明：包含执行的时间、范围、具体方式、准入准出条件，该任务最好具体到人；

5）前置条件：核心链路梳理、初始版本基准数值确认、环境/压测机/权限分配/路径/脚本/数据；

PS：如何追踪、如何统计并聚合计算，根据team情况和具体情形自行确定！

4、容量规划

容量规划是一个长期建设的过程，目前我司也是规划中，具体如何开展，什么时候开展，有哪些方法论，业内目前并没有一个普适性的方法论。

可以参考我之前的一篇博客：浅谈容量测试与容量规划

赋能开源

我个人认为，性能是一个团队所必需具备的能力和特质，并不是少数专职性能测试同学才能做得事情。

在基础的技术建设和性能测试成熟度到一定程度时，可将部分压测相关工作&权限赋予业务测试和业务研发团队，这样不仅有助于工作上互相了解，

更能提高整个团队的能力，性能测试同学也可以抽出更多时间在稳定性保障工作上，而不是写个脚本压测下，就完事的重复工作。

更多阅读：当我们讨论性能测试时，我们在说什么？

团队沉淀

要想不断提高团队的技术、沟通协同、解决问题能力，团队升级是需要时刻考虑的。

只有不断提升团队整体的能力，个人的能力才会更快的提升。一般来说，常见的方式有如下几种：

1）技术累积：前面说的文档建设就是个很好的方式，还可以输出技术白皮书等内容；

2）内部培训：建议定期开展，一般每个月固定开展一次，包括技术、业务、经验和教训；

3）团队分享：指的是包含整个研发部门甚至整个公司的跨团队分享，还是建议积极参与；

4）公开沙龙：当团队规模，技术累积等到了一定程度，可以对外举行技术沙龙，进一步提升技术影响力的同时，也是一个很好的锻炼个人能力的方式。有输入有输出，才能有所得；

5）技术大会：每年都有很多的业内技术大会，可以挑选具有一定影响力和知名的行业大会，在团队里挑选部分优秀的同事参加，然后分享，这也是一个促进团队凝聚力的方式。