性能测试线下体系压测​测试平台工具优化之路

随着市场经济的快速发展，人们的风险管理意识逐渐增强，证券行业快速发展。尤其是近年来随着互联网大数据技术的应用，证券行业发展势头突飞猛进。在此背景下证券企业承接的业务量迅速增加，这对企业业务系统的稳定性带来了更大的挑战，多数证券企业对性能测试实施质量的要求和投入也水涨船高。

B企业作为证券行业的头部企业，其IT测试部门从2010年开始持续投入较高的成本来搭建并不断扩充性能测试团队。经过多年的团队建设，该性能测试团队在项目实施规范和性能测试体系的落地工作中取得了一定的成效。

在2020年，B企业全面启动转型2.0，重在丰富业务模式，优化业务结构和转换发展方向。B企业转型规划中包含大量的业务推广工作，后续业务规模必将随之迅速增长，线上的核心业务系统必将迎来更大的性能挑战。在此背景下，性能测试团队将面临更多需要迅速响应的版本迭代和更高的性能保障要求。团队原有的测试实施模式和测试人员能力可能难以支撑，企业需要重新建设更全面、高效、专业的性能测试团队，搭配更加完善的性能测试体系来提升对性能测试需求的交付效率和对测试质量的把控能力，助力企业在全面转型后能保持系统稳定。

现有的团队是需求驱动式的，其规模及项目实施能力仅能满足企业转型1.0阶段的测试需求。但面对企业转型2.0阶段业务量快速增长带来的更多的性能测试需求及更高的快速回归要求，一味增加测试人员的数量并不是最优方案，如不改变整个测试体系，就不足以支撑系统的良好运转。

更高的人效、更高的测试质量要求、更完善的性能测试体系成了整个团队的目标，然而调整一定不能盲目，单点调整起不了决定性的作用，反而可能打破原来的平衡。

基于以上背景，内部各层管理人员通过与实施人员进行持续沟通和调研，对自有团队及下属的3个供应商的性能测试项目的实施现状、主要痛点、愿景规划进行分析后，决定对团队的性能测试体系做全面的优化。

测试平台工具优化之路

通常在企业内部性能测试需求不大及测试人员不多的时候，性能测试项目的实施可以通过单点工具来完成。但随着业务发展，需要多人协同、版本管理、资产复用、项目跟踪、全链路压测分析的时候，就需要一个自动化的测试平台来完成此类工作，帮助测试实施人员提升测试效率与质量，帮助管理人员做好任务发布、项目进度跟踪、阶段性统计等工作。

(1)测试平台工具现状调研

目前性能测试团队仍使用LoadRunner、JMeter作为性能测试的发压工具，使用nmon作为基础的服务器资源监控手段，管理人员缺乏管理测试项目的平台，不能及时跟踪项目的进度和掌握人员情况，日常获取项目信息基本靠邮件、内部聊天工具、会议。

当前测试实施人员主要面临如下困境

缺乏平台化、数字化规范管理资产的手段，测试资产的整理、汇总、交接均采用人工的模式，很容易造成资产的缺失。

需要进行大量重复性劳动，如脚本编写、脚本调试、监控部署、数据采集、问题分析、Excel数据导入、图表制作等，对测试人员自身能力的提升有限。

大型压测活动较多，通常需要几万及数十万级的并发压测能力，传统的LoadRunner、JMeler压测工具的压力机部署及调试效率极低，难以实现快速发压，而长时间的稳定性测试经常会因工具本身出现性能问题而无法回收测试结果。

测试环境的检查、日志清理、数据回滚等均需大量人力完成，缺乏自动化的手段。

不同类型的服务端监控部署方法各异，监控部署、数据采集需要消耗大量的人力资源。

业务流程经过多个系统流转，数据链路复杂，监控成本高，缺乏全链路监控及分析的功能与手段，造成测试人员对性能问题进行追踪定位困难，性能调优基本靠开发人员定位。

分析手段缺失，LoadRunner、JMeter工具以执行性能测试为主，缺少全链路压测平台的链路监控及根因分析的能力。而APM类的分析工具受限于内部较长的申请流程，无法快速部署。同时，行业的安全制度较严，测试人员无法在测试环境内安装开源分析工具。

此时，性能测试团队管理者的痛点如下。

测试需求及并行项目多，管理者无法即时获悉项目的进展、状态并进行过程把控。通过传统的邮件及电话的沟通方式来跟踪项目进度会消耗管理者较大的精力，很容易出现信息不同步、信息价差等情况。

因并行项目较多，项目的实施质量检查采用人工抽检的方式，无法全覆盖所有的项目验证。对测试结果数据进行准确性验证的成本高，例如测试人员提交的测试结果是否在真实有效的测试场景下执行得出，以及测试数据的统计是否出现偏差等都需要人工核验。同时，测试人员编写的脚本及场景、详细测试结果等内容在实施过程中均存于电脑本地，待项目结束后统一归档在团队的资产库中。管理人员无法在测试实施阶段进行实时的检查，提前规避项目中的风险项。

各业务系统的测试工作分配给不同的性能测试人员，若有核心系统的紧急发布需求，需要验证的周边相关系统通常有几十个，需要调动对应的数十个测试人员发起验证，在人员较少时使用传统的压测工具无法快速完成全量回归及定时回归。

多个系统间相互调用关系复杂，由于版本选代周期较短经常出现相关系统同时进行测试的情况，很难靠人力去避免系统问题，同时调用造成的测试结果失真的问题。通常管理人员会在团队间约束测试发压的时间，但在团队人数较多、发布周期短的情况下仍不能完全避免此问题。

性能测试负责人与测试经理对团队的资产、人员产出、实施的项目数量、解决的性能问题等数据均依赖人工记录，因数据较多，经常出现漏记、错记等情况，手动汇总数据的能力较弱，年度汇总及汇报的时候需要花费大量的人力去整理相关数据，多数数据需要跟实施人员核对，重复性的工作较多。

性能测试团队60多人，按照一个测试人员配备两台LoadRunner负载发生器，结合测试小组内自行调剂的情况，性能测试团队共有近120台负载发生器。负载发生器的管理和维护均在个人及小组中进行，用率较低，仅靠小范围借调资源，无法形成资源池供整个大团队使用，负载发生器的资源消耗及维护成本较高

(2)工具平台优化方案

工欲善其事必先利其器。通过对测试团队的现状进行调研及分析，企业决定通过持续打造一套全链路压测平台取代原来使用LoadRunner、JMeter工具的压测方式。在平台版本选代过程中，要持续增强平台能力来实现快速发起项目信息登记、脚本调试、场景执行、全面实时监控、链路追踪、根因定位分析、基线跟踪等压测流程。

测试人员依托平台建立规范化的项目实施流程，打造敏捷全量回归、全链路压测快速发起、链路跟踪、根因定位分析的能力，彻底实现对应用系统在快速迭代下的性能评估能力。管理者通过平台能快速查看各组度统计(资产统计、问题统计、团队统计、应用统计、业务统计)的数据，了解项目的实施进展及详细内容，做好团队的把控。如此，测试人员和管理人员在日常工作中都能够更加高效、高质量地完成工作。

(3)平台优化建设效果

1)快速适应组织架构变化。

如下图所示，原测试团队组织架构是:性能测试负责人管理测试经理共6人，测试经理对接供应商的测试组长，各供应商的测试组长管理组内10名左右不同级别的测试人员。性能测试团队负责集团总公司及其余各子公司的所有性能测试需求。

业务架构的变化带来IT部门架构快速进行拆分的需求，由于测试平台资产统一化的优势，历史的项目资产均按照规范对资产所属子公司、业务部门、测试团队进行了标签标识。所以平台能根据组织架构的变化在线上迅速进行资产拆分，省去组织架构变化后大量的资产交接、人员沟通成本。原有标准的性能测试体系快速地在各个分公司继续实行，保障了整个企业组织架构变化后性能测试团队仍能高质量地保障系统稳定性。

在业务调整的背景下，原集团总公司拆分成3个业务子公司，原性能测试团队跟随业务子公司的拆分分别形成3个独立的测试团队。拆分后测试团队的组织架构如下图所示。

2)压测快速发起及定时回归能力。

通过工具化压测的方式通常无法快速发起大量系统压测，一个大型的核心系统至少需要一名测试人员负责定时回归，在这种模式下要围盖更多系统的测试实就需要增加更多的测试人员。

平台化的优势在于整个团队所有的系统及其不同选代版本的测试脚本、测试场景等均在平台上实现，测试实施人员只需在平台上根据需求进行点选操作，就能随时、快速地发起多个系统或项目的压测。平台自动化的监控及结果回收也解放了人力，人人均能胜任的压测项目会成倍增加。同时，平台也具有定时回归能力，根据版本迭代的周期来设置场景自动运行的时间，减少人员重复性工作，真正实现一次设置多次复用，

并且，平台支持通过Shell及其他类型脚本进行环境检查、日志清理、数据准备等工作，有效提高整体效率。

3)权限隔离能力。

平台支持精细化权限管理，可对小组或个人进行各类资产的权限控制，也可按照项目、场景、脚本等维度进行创建、编辑、删除等权限分配。通过合理的权限分配让测试实施人员只可见自己有权限的项目，项目与项目之间相互隔离，所有项目、脚本、压测记录等资产相互不可见。

4)全链路跟踪及问题根因定位能力。

证券行业的核心业务流程较长，一个业务流程可能会经过将近10个系统的流转，而且数据链路复杂，监控成本较高，性能问题追踪定位较为困难，性能调优以开发人员为主，多数情况下开发团队的能力决定了性能调优的定位效率与效果。

全链路压测平台具备链路耗时分析能力、链路拓扑生成能力、链路资源消耗分析能力。同时具有内存透视、CPU定位、线程概览、代码子调用耗时分析等功能，将复杂能力平台化，改善性能分析深度及效率。测试人员可通过图形化的调用链路快速定位到耗时长的方法及源码，同时在面对被测服务端CPU占用高、内存OOM、频繁FuGC、线程锁等问题时能通过分析平台快速定位问题。平台图形化的展示及功能按键触发(非手动敲命令)方式降低了测试人员进行性能分析的门槛，使初中级性能测试人员也能参与到性能定位当中。

这项能力打破了过去性能测试人员只要找到性能瓶颈的问题方向便反馈给开发人员的工作模式，改变了普通性能测试人员无法在性能瓶颈定位中发挥主导作用的限制，让测试人员在整个性能测试过程中有了更多的价值体现。

5)对系统同时调用的提前告警能力。

该能力能解决多个测试人员发起各自系统的压测时，核心系统被同时调用造成的测试结果失真的问题。平台能在场景发起前进行告警，提示测试人员进入智能排队模式，管理人员无须为此投入大量的时间精力。

6)测试结果与预期指标验证能力。

通常管理者在检查项目的测试结果时需要查看大量的测试指标数据，如TPS、响应时间以及服务器各资源的测试数据等，判断它们是否均在正常范围内。而通过在平台设置测试目标的结果数值，对不符合要求的结果做标红处理，可真实展现测试结果是否满足预期。因此可以灵活配置事务成功率、TPS、响应时间、被测服务器CPU、内存、网络等各项指标的检查项。

7)项目跟踪能力。

平台上各个项目的查询支持按照项目名、项目状态、创建用户、标签过滤等各种推度来进行，该能力彻底解决了性能测试负责人及测试经理对每个项目状态跟踪困难的痛点。测试经理可在平台上快速跟踪每个项目处于哪个阶段(如未开始、进行中、已解决、已延期)，项目整个生命周期中的成本涉及哪些业务交易，测试场景覆盖情况，测试结果记录，基线跟踪，测试目标的评估指标，项目测试过程中解决的性能问题记录，以及生成的项目报告等。

8)数据汇总展示能力。

平台具有统计各维度数据的能力，例如资产统计、问题统计、团队统计、应用统计等，形成统计大盘。资产统计覆盖脚本库数量、场景库数量、压测场次、实施项目数等，管理人员能时查看测试团队阶段性和整体汇总的实施情况。问题统计能直观地呈现测试团队的整体价值产出，如发现了多少性能问题，解决了多少性能问题，正在挂起的问题数量等。团队统计可以查看各小组或者不同供应商团队的综合工作量，该数据可作为团队绩效考核的参考。应用统计可以查看目前监控覆盖的系统有多少个，以及测试环境的服务器数、节点数量，为调整测试环境的资产提供参考依据。

对内，管理人员可以阶段性地对各维度数据做分析和机理，寻找优化点；对外，可以拿各项数据来展现测试团队的工作成果和价值。

9)负载发生器管理能力。

平台针对负载发生器提供智能分配及排队机制，能在多人多项目并行的情况下，按照项目需求自动调度空闲的负载发生器完成任务，降低负载发生器的闲置率。同时，当负载发生器资源不足时，测试人员通过平台获得提示及自动排队，降低沟通协调成本。总之，平台能提升大量性能测试任务的资源利用率，减少硬件成本投入，目前企业负载发生器已从之前的近120台减少至40台以内。

10)统一监控部署能力。

平台通过探针能对部署在Windows、Unux等不同的操作系统及不同内核版本号上的被测服务器进行监控。在实现基础的CPU、内存、网络、磁盘监控的同时，可以采集到调用链路、对JVM的堆内存监控及其Dump、线程状态及其Dump，还具备CPU热点分析、源码反编译等功能。

探针的设计能实现一次部署、日常使用，减轻测试人员重复部署及维护监控服务的工作量，采集的监控数据随着测试场景的执行被实时展现在平台上，无须测试人员手动连接被测服务器，通过命令发采集。测试结果与监控数据一体化展现，便于测试人员对测试结果进行分析。

阅读后若有收获，不吝关注，分享，留言等操作！！！