聊聊影响性能测试成熟度的内容项

性能需求型模式是指在性能测试实施过程中，一般因为项目上线需要或者业务活动需要，项目开发团队或业务团队作为需求方来提出性能测试的实施需求的模式。在这种模式下一般是从开发或者业务的角度来选择需要测试的功能，工作人员往往在内部没有任何流程的情况下就开始实施性能测试，只是为了系统能够上线或者避免活动时出现生产故障。同时在企业内部也缺乏专业的性能测试工程师，性能测试工作会由开发工程师或者功能测试工程师来完成，很少由全职的性能测试工程师来完成。

在性能需求型模式下，性能测试执行的启动基本没有规划，可以总结为“提出性能需求，实施性能测试，整理测试结果”三大步骤，主要依靠人来驱动，实施过程中各环节的设置相对粗糙，缺少标准的流程和规范。这样的测试资产基本无法得到复用或者为后续工作提供参考，性能测试结果无法得到持续总结和沉淀。

性能需求型模式下的性能测试在流程规范上还不够完善，导致测试的内容不全。虽然能发现性能问题但是其测试结果仅能作为上线前的参考，不具备准确的性能容量指导意义。随着性能测试需求的不断增加，需要开展性能测试的系统越来越多，而由于没有标准的流程规范，为了满足项目组申请的大量性能测试需求，测试团队常以人员扩张的方式应对，即通过人海战术完成性能测试需求。这就带来了一定程度上无效的成本投入和更多的团队管理问题。另外，由于测试工程师的技术能力的不足，在这种模式下测试完成的系统在生产环境或活动期间依然可能出现性能故障，使整个测试团队或者质量团队被质疑。

1.2、性能常态化模式下的流程规范

性能常态化模式是指在性能测试实施过程中，企业内部的不同部门，包括业务团队、开发团队、测试团队和运维团队等多方共同制定并执行内部达成一致的性能测试实施流程规范的模式。该模式下的性能测试通过流程规范形成了人员执行的准入准出条件，能有效并有序地实现各项目的性能测试，过程中通过人工评审来保障流程规范的顺利执行。

该模式下的企业大部分也经历过性能需求型模式的阶段。由于在需求型模式下，人员扩张带来了一定成本，并最终无法实际保障生产环境的稳定性，因此性能测试团队开始寻求变化。性能常态化模式不仅可以提升测试团队价值，还可以提升生产环境的稳定性。在这样的性能测试团队中，性能测试体系建设主要包括如下两大方面工作。

1)阶段性规划，主要明确性能测试执行的6个阶段，以及每个阶段需要完成的工作任务，同时依照标准进行操作，并形成指定的过程产物作为下一阶段的准入材料。通过这样的方式，可以确保从测试需求到测试结束全流程的规范性和准确性。测试执行的6个阶段包括测试规划阶段、测试准备阶段、调试与确认阶段、测试执行阶段、报告编写阶段、项目总结阶段。

2)测试模型规划，主要明确在性能测试执行过程中需要提前考虑或规划的内容，主要目的是解决性能测试团队中人员技能成熟度不一的问题。在测试执行阶段，不同的脚本、用例、配置均会影响最终的测试结果，而测试工程师对与这些内容的把控则至关重要，因此需要在团队内部明确并执行统一的性能测试模型，确保每位测试执行者均按照相同的规范进行性能测试，以确保性能测试的全面性、准确性和有效性。性能测试模型主要包括业务模型、数据模型、监控模型、策略模型、风险模型、执行模型。各个模型中的实际内容不在本章中展开，感兴趣的读者可以详细查看第5章内容。

1.3、性能平台化模式下的规范流程

该模式下的企业的IT建设成熟度较高，并且大部分已落地持续集成和持续交付(CI/CD)的流水线平台，IT团队偏向敏捷化。在这样的情况下，传统的靠人驱动的性能测试规范已经无法支撑持续交付和高质量交付的要求，因此急需使性能测试的部分流程实现平台化。

平台化的优势如下。

1)平台化的实现能减少人工的投入，针对一些重复的执行操作，由平台代替人工，以达到提升测试效率的目的。常见的可复用操作包括:测试规划阶段的类似测试计划复用;测试准备阶段的测试资产分类管理;调试与确认阶段的日志汇总;测试执行阶段的环境自动检查、压力机智能调度、测试数据自动切分；报告编写阶段的数据自动汇总;项目总结阶段的资产存档等。

2)平台化的实现在减少重复性工作的同时能释放性能测试工程师更多的时间及精力，使其专注于新业务的调研、测试脚本的书写、测试场景的覆盖，逐渐对业务项目实施全系统、全工程、全接口的全量覆盖。并且，平台化的实现能针对已有业务定期开展性能巡检，强化性能评估频率，建立基线库。

3)平台化的实现使测试团队在具备一定的对接能力后，可以与现有的CI/CD流程平台进行系统级对接，补足在持续集成、持续发布过程中需要的持续测试能力，基于流水线能力快速进行性能回归测试，性能测试结果基于基线的判断也可作为后续流程的准入触发条件，形成一体化的流程体系。

二、性能测试环境

性能测试环境是性能测试开展的基础，基于调研的数据，通过分析整合，笔者对性能测试环境总结出如下几类情况。

2.1、无性能测试环境

完全无性能测试环境的企业，根据不同的业务属性可以分为如下两类。

1)开发自测型。企业不够重视性能测试质量，系统的性能测试均由系统的开发工程师自行完成，开发

工程师仅进行单接口的自测，自测结束后发布上线，测试结果对生产环境下的真实用户场景缺乏参考意义。在项目紧急发布时，不进行性能测试就发布上线，将性能问题暴露在生产环境中，很可能给企业及用户带来一定的损失。

2)多供应商自测型。无性能团队或无IT团队的企业，对系统的开发及测试在很大程度上依赖于外包工程师，企业内部团队仅负责业务运营，其中大量的性能测试由外包工程师在开发环境下自研自测，外包工程师在测试完成后交付测试报告给企业内部团队进行验收。部分企业的验收团队也会在系统上线前基于发布环境进行性能测试，验证其性能结果及报告是否与外包团队提供的测试报告一致。此类现象主要集中在外企。

以上两种情况均导致系统在生产环境处于“裸奔”"状态，在日常运行或活动期间容易发生性能故障，因此业务中断。由于企业内部的IT团队只能对生产环境中出现的性能故障进行单点优化，无法模拟用户的使用场景进行测试，因此优化后的效果无法得到有效评估，只能通过生产环境下的真实用户使用反馈来判断优化效果，这可能造成业务系统进入无解的性能故障“死循环”。

2.2、性能测试与功能测试共用测试环境

多数企业属于这类情况。此时企业会综合考虑投入的IT成本，在准备硬件资源时优先满足生产环境所需的配置。企业针对内部测试环境的搭建以满足功能测试的需求为主，一般通过最小配置的资源投入来完成测试环境的准备。

在企业没有独立的性能团队负责性能测试时，一般由几位功能测试工程师兼顾性能测试的工作职能，因此性能测试的执行只能覆盖重要系统的核心业务接口，测试执行很难形成规范，并且在性能测试执行过程中可能存在与功能测试共用测试环境的情况，导致测试结果容易出现偏差，测试数据混乱。为了确保性能测试

结果的正确性，一方面需要确保测试环境没有被并行使用，另一方面需要通过重复执行性能测试进行验证。

由于功能测试环境普遍使用的是应用单节点部署模式，因此测试结果仅能反映应用在单节点的性能表现，针对高可用、分布式多节点部署模式下的生产环境，该性能测试结果只能作为一定参考，无法真实评估系统生产环境的性能情况。

共用测试环境导致性能测试结果的不全面，所以系统在生产环境发布后，依然容易出现性能故障。如果生产环境频繁出现性能故障，整个性能测试团队就会遭受质疑，性测试工程师也会被”为什么做了性能测试还有这么多生产性能故障?"等类似问题拷问。由于看不到投入后的产出，部分企业甚至会降低测试的投入，团队因此面临“巧妇难为无米之炊”的局面。

2.3、有独立的性能测试环境

有独立的性能测试环境的企业基本上都具备相对成熟的标准流程和规范，并且测试团队具备专职的性能测试工程师。在企业内部一般分为两种情况:第一种情况是资源池模式，即按项目需求以实际生产环境的配置进行资源的申请，通过资源池进行分配，待项目结束后资源释放回收；第二种情况是常态模式，比如针对核心业务系统有独立、稳定的性能测试环境。业务系统在测试环境的部署架构参考生产环境，一般从同架构、等比例两个维度表现。

1)同架构：指测试环境的搭建与生产环境完全一致，比如生产环境是高可用的，测试环境搭建也必须高可用。

2)等比例：指测试环境的搭建基于生产环境的配置情况进行等比例压缩，如某个业务系统在生产环境中，A服务部署8个应用节点，B服务部署4个应用节点，那么性能测试环境搭建时可按照A服务部署4个应用

节点、B服务部署2个应用节点这种二分之一的配置方式进行，另外针对数据库等可以采用生产环境配置二分之一进行准备。

基于独立的性能测试环境，性能测试团队能够开展更多类型的性能测试，从而发现更多的性能问题，不仅限于单节点的性能验证，还可以探索或实践全链路的性能测试，获取基于业务视角和用户视角的整体系统性能表现的数据，从而形成业务场景的性能基线。常态化的性能测试产生的基线数据可以为系统在生产上的日常运行及重大活动提供参考和容量规划等方面的建议。

三、工具及平台

对当前行业和企业使用的性能测试工具进行调研后，笔者对常见工具及平台进行分类、汇总，主要概括为如下几类。

3.1、性能测试压测工具

企业内部的性能测试团队主要使用开源(或商用)的压测工具，常见开源工具包括JMeter、GatlingLoadRunner等，这些工具普遍应用于各行各业，其中以项目制测试组织为多。这些企业的性能测试团队关注点在于性能测试的执行层面，受限于测试工具，在人员的技能培训、测试流程的规范性、测试过程的沉淀、性能问题的发现、测试资产的复用等方面相对薄弱。

在性能测试的执行中，由于工具仅能执行发压，因此测试前的规划、准备，以及测试后的数据总结全依赖人力完成，在时间上存在大量的消耗，在执行质量上受性能测试工程师的经验限制，这可能导致测试数据出现偏差，使测试结果不具备实际的参考价值。

3.2、性能测试压测平台

企业客户的性能测试团队已经开始基于常见压测工具进行二次开发，结合企业内部的测试流程，整合出一体化的线上性能压测平台。随着业务的发展，传统性能测试工具已经成为提升效率的瓶颈，大量人工的统计和操作制约了性能团队的提速，因此平台化的二次改造则变得至关重要。通过调研发现，目前企业内部主要进行二次开发的功能分为3类:管理类功能、统计类功能、执行跟踪类功能。

1)管理类功能：主要包括人员权限管理、资产关联管理等。在多项目、多人员的测试团队中，平台按照业务线或系统类型，将不同脚本、场景、报告、测试记录归类至对应的业务或系统下，确保资产之间不出现混用、乱用的情况。同时，将资产与人员建立关联关系，只有对应的执行人员能完成测试流程的发起和护行，不同项目组的人员无法对权限之外的资产进行查看或操作。这样的规范可以提升测试工程师专注度，提升测试资产的有效复用，同时可以提升数据安全性。

2)统计类功能：核心在于将过程资产沉淀、操作执行等实现线上化。传统的C/S架构工具受限于本地客户端，过程资产仅能独立存储，无法快速共享。而构建基于B/S架构的性能测试平台，一方面可以提升测试执行的便捷度，有网络、有权限即可通过浏览器快速发起性能测试执行;另一方面可以将测试执行过程中涉及的资产均进行线上化管理及统计，包括脚本、场景、压力机、缺陷、性能指标等维度，对资产进行一站式收集和可视化统计。

3)执行跟踪类功能：主要以平台化方式跟踪从启动到收尾阶段的性能测试过程。一方面将规范化的测试执行步骤在平台功能中体现，落地为功能，确保所有测试人员能按照统一的规范和流程开展性能测试工作，同时减少无效的人力投入。另一方面可以通过过程跟踪了解不同类型项目在各个阶段的耗时情况，提前

预知可能的逾期风险，同时方便进行效能统计，用过程数据支撑未来规划。常见跟踪维度包括:测试需求的建立;测试目标的细化、明确;测试资产的构建、绑定;测试指标的评估;测试的执行记录;缺陷的新增、流转、关闭;测试报告的生成;测试计划的关闭等。

3.3、全链路压测平台

部分企业客户已建设了全链路压测平台，不仅实现了管理、统计、执行跟踪类的功能，还在核心技术上进行了突破，在提升性能测试效率的同时提升了性能测试的质量。平台不仅能够自动化实施性能测试，还能不断提高性能测试工作的专业化水平，扩大性能测试覆盖面的广度和深度。全链路压测平台的核心能力包括如下几个。

1)分布式压测能力。平台通过调度算法将负载发生器(为被测系统生成负载的工具，企业内部也称为压力机)整合为统一资源池，在日常测试过程中，能基于多用户的压力策略自动调度所需的负载发生器，进行负载生成操作。压测结束后负载发生器自动将配置初始化，并释放到资源池中用于下一次项目调用，可大大提升负载发生器的复用率，减少后期由于测试项目过多而带来的硬件资源投入。在活动性能测试中，平台也可通过调度算法实现上百台压力机同步调度，实现海量并发，以模拟活动期间的压力。其中涉及的测试数据也可根据压力机数量自动切分及上传，代替原有的人工操作。

2)全链路跟踪分析能力。平台可以从压测流量入口开始进行性能跟踪，通过绑定压测发起的流量，实时采集被测场景中涉及的应用、中间件、数据库，形成全链路调用拓扑，针对出现瓶颈的实例进行代码级分析，建立全面的性能追踪与分析体系。调研发现，目前大量企业内部采用流量染色及字节码增强技术实现此能力。流量染色技术主要确保所分析的数据来源于实际执行的性能压测流量，与本次压测无关的数据不会被

采集统计，减少异常数据带来的分析困扰。字节码技术主要实现代码级数据的采集，通过指定的规则进行代码级分析及告警，可实时分析压测链路或单个应用实例中的代码耗时、日志报错、程序异常等数据，帮助性能测试工程师与相关开发工程师快速发现测试过程中的性能瓶颈，定位代码根源。更多链路分析的内容会在后文展开描述。

3)根因分析能力。平台可以从进程到线程到代码实现对根因的精准定位分析。性能测试工程师在测试过程中可以实时了解线程全貌，并按需实时采集运行时的内存数据，定位更深层次的性能问题。部分企业还建立了自动体检能力，将企业历史中出现的性能问题归纳总结为可复用的知识库，实现压测过程中的实时性能体检，自动捕捉系统异动点，快速定位并基于历史解决方案提出基础优化方向和建议，进一步降低测试工程师进行调优工作的门槛。

3.4、生产全链路压测平台

有些企业已开始建设基于生产压测能力的拓展平台。此类企业常见于连锁快消行业，大量的线上活动使得性能测试团队需要更关注容量级别的评估和验证，而大部分情况下，测试环境无法一比一复现生产的比例和架构。因此为保证测试的真实性，部分企业开始在生产环境，也就是最真实的环境中进行容量瓶颈测试。在这样的情况下，如何确保压测数据不污染业务数据是至关重要的。

部分企业在初涉生产压测时，对于更新类数据库的压测方案是压测完删数据，这种方案为了保障数据纯净，对于人员要求较高，且存在对生产数据库误操作的风险。而较好的方式则是通过平台实现数据的隔离和流量的熔断，通过技术手段识别压测流量与真实用户流量，在数据持久层构建影子库或影子集群，将压力流量的增删查改均分配至影子库，从而确保生产业务数据的独立性。此时涉及染色、透传、影子构建、流量熔

断等技术能力，测试流程也与线下性能测试有较大区别

四、性能测试团队

每一块业务的提升都离不了人员，性能测试的业务也是如此。一般性能测试团队的建设和成长都会经历以下几个阶段。

4.1、开发或功能测试工程师

这种情况一般发生在业务量小或者IT建设成熟度相对较低的企业，由于企业内部对于质量不够重视或者没有足够的资源完成性能测试，一般都是由开发人员自测或者让功能测试工程师来完成性能测试的工作。此处的开发自测并非是说企业有独立性能测试团队来赋能开发团队完成单元及单个应用服务等方面的性能测试活动。

2.2、全职的性能测试工程师

随着企业IT建设成熟度的提升以及业务的发展需要，企业内部对于质量逐步重视并且开始把性能测试作为系统上线的质量红线。在这样的情况下，企业开始招聘性能测试工程师，团队的工作职责主要以性能测试工作为主。随着项目的不断实践，企业开始逐步完善性能测试能力，从使用性能测试工具到掌握性能测试流程，再到指导建设性能测试体系，对测试团队进行多方面的持续建设和提升。

4.3、具备性能调优能力的工程师

性能测试团队的核心工作还是通过性能测试获取系统的性能情况，以及提升性能测试工作的专业度等。最早关于性能调优的内容一般都由开发工程师来完成，性能测试团队只负责测试结果的反馈以及配合开发人员完成调优后的复测工作。随着性能测试的发展，企业也要求性能测试工程师具备性能调优能力，能够直接定位并且解决性能问题。

五、性能测试价值度量

随着企业内部IT建设的不断完善，企业从单个项目实施流程的标准化到性能测试实施的体系化，再到性能测试的工程化，在性能测试方面能力也在不断成熟。与之对应，企业在不同的阶段对如何度量性能测试的

价值有不同的表现，一般会经历以下几个不同的阶段。

5.1、无度量

无度量的企业，一般性能测试团队的人员较少，测试执行不频繁，无特定规律，测试产出均是一次性产物，无法形成有效的度量数据。由于频次低、需求弱，所以针对整个性能测试没有任何工程化层面的建设和规划，也不会体现性能测试的价值。

5.2、测试过程度量

开展测试过程度量的企业，一般性能测试团队具备一定的人员规模，能通过项目制方式完成性能测试的执行，在这过程中希望通过数据分析产出可量化的价值，同时分析出可优化的方向。

目前此类企业主要以一些通用的工具，例如Excel，实现基本数据统计及常见项目维度的统计。在项目制压测过程中，各个性能测试执行人员针对现有测试业务进行统计，主要统计和分析各个项目在测试执行过程中产生的缺陷和测试结果。

这类企业通常会存在如下问题。

1)各个项目的执行规范及内容不统一。有的项目只是简单的压测，因此其过程产物非常简单，人员的参与度较低。有的项目需要进行重点测试，但是测试环境不稳定或无标准规范，导致大量重复的测试操作和人力投入。

2)进行统计的人员的能力及视角不同，导致统计的数据不在一个维度。例如，部分人员以执行者视角进行统计，又有部分人员以管理视角进行统计。

3)统计的数据通常以文件方式存储，无法快速共享，也无法统一维护。

以上问题导致此类企业无法对团队效能进行有效统计，也无法从效率方面对团队进行更多的优化。

5.3、全方面多维度度量

全方面进行度量的企业往往内部有相对成熟的性能测试平台。企业通过对内部的实际情况进行建设和规划，将测试过程及规范在平台中体现。因此，平台能在测试过程中实时进行数据的沉淀，在总结时进行一键式自动分析。管理人员可以基于平台从各维度按需进行数据收集和整理，并且使用报表自动生成功能，除了可以做阶段性汇报外，也可以将过程数据投放至大屏中展示。以下总结了几个常见的展示维度。

1)对测试计划执行进度进行展示。根据每个测试计划的执行情况，分析是否出现计划逾期或计划提前完成的情况，进一步分析计划逾期的原因是不是执行期间的并行项目较多且测试执行人员较少。

2)对测试过程中各个阶段产出物数量进行展示。包括脚本书写数量、场景构建数量、测试执行次数、缺陷产出数等，再结合测试计划的进度数据进一步分析。如果测试计划出现逾期，并且各阶段的产出物数量也很多，那么可以初步判断是由于人员不足导致的测试计划逾期，测试负责人可根据现有团队的人员情况结

合下一阶段的测试需求，合理进行测试人员规模的扩大。

3)对压力机水位的度量进行展示。并且可以通过对水位情况的分析，确认是否需提前准备更多的测试资产，以支撑更多项目的性能测试。

除了以上几个展示维度外，还可从缺陷、报告、业务性能趋势，结合时间进行多维度的对比分析，为下一阶阶段的性能测试的整体发展规划提供有效的数据支持。

标签：聊聊,成熟度,性能,平台,压测,测试,团队,测试环境
From： https://blog.csdn.net/qd_lifeng/article/details/142750354