最近刚入职新公司，忙着适应公司的文化、工作流程的一些东西。因为部门要开发性能测试管理平台，今天邮件中我也对性能测试平台的设计提了一些自己的想法。

这篇博客，就说说我对性能测试管理平台设计的一些构思，仅供参考。。。

组织架构

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

思维导图

一、任务管理

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、容器

现在越来越多的企业开始将服务容器化（特别是在微服务的架构中，容器化是必要的一种手段），包括环境、脚本、服务都放在容器中。

那么对容器资源的监控，也是非常必须的。

4、服务器

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

5、DB

数据库层面，主要监控的内存、CPU等信息，当然也包括SQL语句执行耗费时间、锁等情况。

6、网络

网络是必不可少的一环，不稳定的网络环境对测试结果的影响很大，可能会带来一些隐藏的问题；网络监控一般关注这几个方面：稳定性、网关、CDN、防火墙等方面。

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

七、日志管理

在测试过程中，有时候不能从测试数据直观的看到隐藏的问题，就需要查看对应的日志，从详尽的日志中分析爆发问题的节点，然后进行针对性的分析。日志监控，大概分下面几个层级：

1、web

这里可以理解为用户层的日志，包括资源的本地加载、缓存等信息（由于某些情况下详尽的日志包较大，采用了日志写入用户层的操作）。

2、app

这里代指应用层，有时候出现性能问题的原因发生在应用层，那么对应用层的监控，日志分析也是很重要的。

3、service

后台服务层，日志包括处理了哪些操作，哪个请求甚至哪里调用等。

4、DB

数据库日志，同理，哪些操作耗费的时间长、资源多等，都是需要对应的监控和必要的日志分析，才能看出问题。

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

八、报表管理

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

1、实时结果

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

2、测试报告

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

3、性能基线

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

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

九、配置管理

1、挡板

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

①、HttpMock

HTTP是最常见的一种协议，而且随着微服务的流行，restful风格架构设计的运用，HttpMock的挡板服务，就变成一种常规需要。

②、SocketMock

TCP连接也是某些业务系统服务实现通信的方式，为了方便的进行性能测试而降低对其他某些服务的依赖，SocketMock挡板服务，也是必不可少的。

③、其他

包括dubbo接口等其他类型的接口调用，可以针对性的进行设计，将mock变为一种服务。

PS：从测试管理平台的角度来说，将Mock对象编程服务，通过界面进行增删改查的管理，更方便了管理和直观的理解。

2、容器

①、docker

容器化，是这几年越来越流行的一个趋势，对不同的测试环境的docker容器管理，也是必不可少的。

②、虚机

限于不同项目不同技术架构的情况，虚拟机管理这一项，可以根据具体的需要来进行设计，如果全部容器化，那么虚拟机管理，没有也罢。

十、系统管理

1、用户管理

包括使用这个系统的用户注册、新增、删除，状态管理等功能，以及可能需要的任务分配等操作。

2、权限管理

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

3、组管理

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

以上内容仅是我个人的一些构思和想法，还有很多不足之处和值得深入讨论的地方，如有更好的建议，请在评论区指出，谢谢。。。