关于性能测试平台的一些想法

这是一篇三年半前写在博客园的文章，昨晚无意看到。

很相似的项目背景，只是时间过了这么久，唏嘘不已。

三年半前刚入职新公司，负责性能测试平台的测试工作。

现在在新公司，同样负责全链路压测平台的项目管理、产品设计、质量保障和落地交付工作。

这篇文章，对原文略作修改，谈谈我现在的一些想法和实践经验。

组织架构

每个公司的组织架构都不一样，可以按照事业线的BU来做横向，也可以按照每个不同系统归属的项目组为横向，测试团队作为职能部门为纵向的矩阵式组织架构为例，来介绍性能测试管理平台的构思。

思维导图

一、任务管理

1、任务申请

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

①、项目组提需求

项目组主动提性能测试需求，需要一个统一的性能测试任务管理的模块，其中包括被测系统归属的项目条线、系统名称及相关环境的配置信息，以及开发、运维、DB名称，还有提测时间，deadline时间等信息。这种情况又可以分为三种类型：

• 新系统发布：新的系统发布上线，需要对功能，性能，安全等各方面做一个完整的测试，评估是否达到业务、产品既定的上线要求；
• 老系统迭代：已有系统进行某些优化，新功能的增加或者新的业务渠道引入，可能带来更高的流量冲击，这时候项目经理或者开发经理会提出相关的性能需求，希望验证已有系统是否满足上线需要；
• 生产事故修复验证：系统在生产环境遇到性能问题带来了某些损失，经过调优或修复后需要进行一轮全面的性能测试来评估是否满足已有的实际业务需求；

②、测试组提需求

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

2、任务审批

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

3、任务排期

根据具体的工作安排，资源调配，进行工作排期等进一步的工作。

二、用例管理

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

1、常规任务

常规任务，指的是系统迭代或者新系统发布提出的性能需求，其中包括项目条线、系统名称、相关人员信息、业务模型等具体信息。根据上述的情况进行具体的被测系统场景建模分析，然后制定具体的测试用例。

2、日常轮询

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

3、全链路压测

全链路压测，主要是生产环境进行以及日常的线上日常性能巡检工作。

三、环境管理

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

1、UAT

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

2、PAT

PAT环境可理解为独立性能测试环境，其他和生产保持一致，应用数量保持等比最小化配比，主要是满足日常的迭代压测和性能基线以及问题优化验证使用。

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

四、压测机管理

1、压测机调度

实际的流量冲击较高时，单个压力机可能无法支持，这时候就需要多个压力执行机来分布式的进行压测。在实际生产环境，流量的变化很有可能是随机的，如何做好压测执行机的增加和缩小，合理利用资源，是需要考虑和解决的问题。

2、状态管理

这里主要包括压测机的状态变化，包括闲置、使用（甚至预测何时可释放出来供其他压测任务使用等）、不可用（损坏或其他原因）等。

3、异常管理

当性能测试进行过程中，由于某些原因导致服务不可用，就需要及时的停止压测，一般来说主要是下面几种手段：

• 手动停止：从管理界面的功能按钮来停止压测执行；
• 熔断措施：即通过监控报警措施，当系统不可用或超过某个阈值时，自动停止压测；
• 兜底手段：当手动停止或者自动熔断措施都不可用时，从外部的某些手段来停止压测执行，这也算一种容灾措施；

五、数据管理

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

1、基础数据

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

2、预埋数据

预埋数据主要指的是DB层面，即性能测试需要模拟实际的环境，包括数据量等，从DB层面来说，同一个库表，数据量不同在同样的业务模型下，其性能表现也是不同的。预埋数据的准备，可以通过从生产备份，或者通过脚本、SQL语句来自定义准备一些可用的数据。

3、测试数据

测试脚本运行所必需的数据，通常可以通过参数化的方式来解决。当然，从测试平台的角度，解决这个问题的方法可以通过统一的数据池来做管理，界面通过不同的选择项，调用API来生成测试可用的数据。

六、监控管理

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

网络：网络监控一般关注这几个方面：稳定性、网关、CDN、防火墙等方面。

前端：前端展示、资源渲染所花费的时间，哪些资源耗费了最多的时间和资源，都是需要通过监控来得到相关信息。

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

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

服务器：服务器的监控，主要是内存、CPU、IO等方面，包括占比、使用率、阈值和提醒等。

DB：数据库主要监控的内存、CPU等信息，也包括SQL执行时间、连接数等。

PS：实际上从上面的几种监控来看，都是从用户层到最终的服务处理层，层层进行监控，做到一切用数据说话。

七、日志管理

在测试过程中，有时候不能从测试数据直观看到隐藏的问题，就需要查看对应的日志，从详尽的日志中分析问题的节点，然后进行针对性的分析。

从性能测试平台角度来说，希望将日志更直观进行展示、筛选，否则我们需要通过命令或者其他工具的方式，到具体的层级去查找分析日志，这样无疑会浪费一定的时间。

八、报表管理

报表管理主要包括下面几个方面：

1、实时结果

将测试的实时监控结果存入数据库，然后通过grafana等工具展示在界面上，更直观的对测试结果进行管理。

2、测试报告

每轮测试结束，都需要对测试结果进行统计分析，以便于作为一个基点，对下一次测试提供参考和评估依据，测试报告界面可以通过自定义的样式来展现。

3、性能基线

性能基线指的是将每次性能测试的最终结果作为一个性能参考基线，后续的每次迭代，以上次性能测试结果为评估点，然后持续更新性能基线，作为下一次的评估依据。

可以通过数据折线、树状图等多种方式来展现，目的是为长期的系统稳定性、可用性做一个监控，为系统调优或重构提供多种维度的参考依据。

九、Mock管理

一般来说，性能测试都是通过调用不同的服务接口来进行模拟并发，进行测试，但有时候由于某些原因，导致一部分服务暂时不可用，或者次数限制，这种情况急需用到mock服务。

mock服务一般需要满足如下几个特性：

• 高性能；
• 支持多协议(http、rpc、webscoket)；
• 自定义函数以及个性化的一些配置如强制等待、随机返回等；

从平台的角度来说，将Mock配置可视化进行增删改查的管理，更方便管理和配置。

十、系统管理

1、用户管理

包括使用这个系统的用户注册、新增、删除，状态管理等功能。

2、权限管理

不同的用户角色，分配不同的系统使用权限，利用单点登录的原理来设计这一模块。

3、分组管理

这里的组管理可以理解为基于身份和角色不同所划分的职能组，对其进行新增、权限职能分配、状态变更等功能的管理。

上述内容综合了我目前正在做的全链路压测平台的一些想法和实践，具体的一些实现细节如Mock平台、压测集群调度、造数工具、监控集成、压测日志采样、数据报表等功能，后续我会写一个平台设计系列的文章，来详细介绍。