软件性能测试平台的建设说明

软件性能测试平台的建设说明

一、组织架构

这里我按照每个不同系统归属的项目组为横向，性能测试团队作为职能部门为纵向的矩阵式组织架构为例，来介绍性能测试管理平台的构思。

二、思维导图

三、任务管理

1、任务申请

一般来说，性能测试需求的来源有2个方面：

①、项目组提需求

项目组主动提性能测试需求，需要一个统一的性能测试任务管理的模块，其中包括被测系统归属的项目条线、系统名称、系统架构图、网络拓扑图、相关设计文档及相关环境的配置信息，

以及项目经理、开发、运维、DB等联系方式，还有被测系统交付测试时间，deadline时间等信息。

这种情况又可以分为三种类型：

新系统发布：新的系统发布上线，需要对功能，性能，安全等各方面做一个完整的测试，评估是否达到业务、产品既定的上线要求。

老系统迭代：已有系统进行某些优化，新功能的增加或者新的业务渠道引入，可能带来更高的流量冲击，这时候项目经理或者开发经理会提出相关的性能需求，希望验证已有系统是否满足上线需要。

生产事故修复验证：系统在生产环境遇到性能问题带来了某些损失，经过调优或修复后需要进行一轮全面的性能测试来评估是否满足已有的实际业务需求。

②、性能组提需求

针对项目的迭代、新需求的引入带来的可能存在的性能瓶颈主动提出，然后经过评估，决定是否进行测试，来评估系统的稳定性可用性等。

2、任务审批

性能测试任务申请提交后，就需要项目组、性能组甚至其他相关人员根据现有情况，工作安排，工期等进行综合评估，来决定是否进行性能测试以及何时开始，资源分配的工作。其中需要涉及到多个团队多个人员的配合和参与，还有不能按期交付带来的风险预估等；关于性能测试需求评审，后续我会专门写篇博客来分析其中的一些细节。

3、任务排期

性能测试任务经过评估后决定进行，接下来就是根据具体的工作安排，资源调配，进行工作排期等进一步的工作。

四、用例管理

这里的用例，我指的是性能测试中包括基于任务类型，资源等各方面情况来建立的业务模型来抽象管理，具体可分为下面三种业务模型：

1、常规任务

常规任务，指的是系统迭代或者新系统发布提出的性能需求，其中包括项目条线、系统名称、架构、拓扑图、相关人员信息、业务模型等具体信息。

根据上述的情况进行具体的被测系统场景建模分析，然后制定具体的测试用例。

2、日常轮询

这一类型可以参考持续集成中的自动执行和条件触发等情况，设立定时任务对范围内的系统进行性能测试，测试类型主要包括并发、多节点等测试类型。

3、全链路压测

全链路压测，主要是生产环境进行的整体业务线的性能测试，具体内容，可以参考我之前的博客：聊聊全链路压测。

五、环境管理

性能测试开始的前提是有一个稳定可满足性能测试的环境，一般来说都是在下面两种环境进行：

1、UAT

UAT环境即我们俗称的用户验收测试环境，相对来说环境稳定，且配置各方面和生产相同或者可以进行等量代换，能满足常规的性能测试需要。

2、FAT

FAT环境可理解为生产验证测试环境，系统版本，配置、数据量等和生产保持一致，这样从可测试性和真实性上更符合实际的生产情况。

PS：还有全链路压测是在真实的生产环境进行，但是生产环境进行性能测试的风险太大，且对现有系统的改造工作较多，是否进行还需要经过详细的评估才能决定。

全链路压测的挑战在于这几点：

①、业务模型梳理

②、数据问题，包括数据的真实可用性、数据隔离和数据脱敏；

③、环境隔离，不能影响到实际的生产业务；

④、服务集群负载均衡，测试策略和服务间通信的问题；

⑤、容灾问题，包括某些服务宕机或者不可用时，不能对实际生产业务运行造成影响，系

统可用性等；

六、压测机管理

1、压测机调度

实际的流量冲击较高时，单个压力机可能无法支持，这时候就需要多个压力执行机来分布

式的进行压测。

在实际生产环境，流量的变化很有可能是随机的，如何做好压测执行机的增加和缩小，合

理利用资源，是需要考虑和解决的问题。

2、状态管理

这里主要包括压测机的状态变化，包括闲置、使用（甚至预测何时可释放出来供其他压测

任务使用等）、不可用（损坏或其他原因）等。

3、异常管理

当性能测试进行过程中，由于某些原因导致服务不可用，就需要及时的停止性能压测，一

般来说主要是下面几种手段：

①、手动停止：从管理界面的功能按钮来停止压测执行；

②、熔断措施：即通过监控报警措施，当系统不可用或超过某个阈值时，自动停止压测；

③、兜底手段：当手动停止或者自动熔断措施都不可用时，从外部的某些手段来停止压测

执行，这也算一种容灾措施；

相关资料可参考饿了么全链路压测平台的实现与原理。

七、数据管理

测试是需要数据来驱动的，那么在性能测试中，需要准备哪些数据呢？

1、基础数据

基础数据包括系统业务正常运行所必须的数据，比如：电商平台的SKU信息、库存数据等，还有银行的用户信息、某些业务的相关数据等，可以通过从生产备份等手段来解决。

2、预埋数据

预埋数据主要指的是DB层面，即性能测试需要模拟实际的环境，包括数据量等，从DB

层面来说，同一个库表，数据量不同在同样的业务模型下，其性能表现也是不同的。

预埋数据的准备，可以通过从生产备份，或者通过脚本、SQL语句来自定义准备一些可用的数据。

3、测试数据

测试脚本运行所必需的数据，通常可以通过参数化的方式来解决。

当然，从测试平台的角度，解决这个问题的方法可以通过统一的数据池来做管理，界面通

过不同的选择项，调用API来生成测试可用的数据。

八、监控管理

性能测试中，监控是必不可少的重要一环，通常来说，需要监控的包括以下几个方面：

1、前端性能

前端展示、资源渲染所花费的时间，哪些资源耗费了最多的时间和资源，都是需要通过监

控来得到相关信息。

2、中间件

①、Redis

有些系统架构利用Redis来做持久层或者缓冲区，那么对于缓存的可用性和缓存失效、缓存穿透等信息，也是必须要监控的。

②、MQ

MQ是一个异步的通信框架，类似的还有kafka等框架，对于消息队列的生产和消费速率，资源占用，可能的堵塞等情况进行监控，也是必不可少的。

③、其他

3、容器

现在越来越多的企业开始将服务容器化（特别是在微服务的架构中，容器化是必要的一种

手段），包括环境、脚本、服务都放在容器中。