关于性能测试平台的一些想法
最近刚入职新公司，忙着适应公司的文化、工做流程的一些东西。由于部门要开发性能测试管理平台，今天邮件中我也对性能测试平台的设计提了一些本身的想法。html
这篇博客，就说说我对性能测试管理平台设计的一些构思，仅供参考。。。前端
组织架构web
这里我按照每一个不一样系统归属的项目组为横向，性能测试团队做为职能部门为纵向的矩阵式组织架构为例，来介绍性能测试管理平台的构思。docker
思惟导图数据库
1、任务管理编程
一、任务申请缓存
通常来讲，性能测试需求的来源有2个方面：安全
①、项目组提需求服务器
项目组主动提性能测试需求，须要一个统一的性能测试任务管理的模块，其中包括被测系统归属的项目条线、系统名称、系统架构图、网络拓扑图、相关设计文档及相关环境的配置信息，restful
以及项目经理、开发、运维、DB等联系方式，还有被测系统交付测试时间，deadline时间等信息。
这种状况又能够分为三种类型：
新系统发布：新的系统发布上线，须要对功能，性能，安全等各方面作一个完整的测试，评估是否达到业务、产品既定的上线要求。
老系统迭代：已有系统进行某些优化，新功能的增长或者新的业务渠道引入，可能带来更高的流量冲击，这时候项目经理或者开发经理会提出相关的性能需求，但愿验证已有系统是否知足上线须要。
生产事故修复验证：系统在生产环境遇到性能问题带来了某些损失，通过调优或修复后须要进行一轮全面的性能测试来评估是否知足已有的实际业务需求。
②、性能组提需求
针对项目的迭代、新需求的引入带来的可能存在的性能瓶颈主动提出，而后通过评估，决定是否进行测试，来评估系统的稳定性可用性等。
二、任务审批
性能测试任务申请提交后，就须要项目组、性能组甚至其余相关人员根据现有状况，工做安排，工期等进行综合评估，来决定是否进行性能测试以及什么时候开始，资源分配的工做。
其中须要涉及到多个团队多我的员的配合和参与，还有不能定期交付带来的风险预估等；关于性能测试需求评审，后续我会专门写篇博客来分析其中的一些细节。
三、任务排期
性能测试任务通过评估后决定进行，接下来就是根据具体的工做安排，资源调配，进行工做排期等进一步的工做。
2、用例管理
这里的用例，我指的是性能测试中包括基于任务类型，资源等各方面状况来创建的业务模型来抽象管理，具体可分为下面三种业务模型：
一、常规任务
常规任务，指的是系统迭代或者新系统发布提出的性能需求，其中包括项目条线、系统名称、架构、拓扑图、相关人员信息、业务模型等具体信息。
根据上述的状况进行具体的被测系统场景建模分析，而后制定具体的测试用例。
二、平常轮询
这一类型能够参考持续集成中的自动执行和条件触发等状况，设立定时任务对范围内的系统进行性能测试，测试类型主要包括并发、多节点等测试类型。
三、全链路压测
全链路压测，主要是生产环境进行的总体业务线的性能测试，具体内容，能够参考我以前的博客：聊聊全链路压测。
3、环境管理
性能测试开始的前提是有一个稳定可知足性能测试的环境，通常来讲都是在下面两种环境进行：
一、UAT
UAT环境即咱们俗称的用户验收测试环境，相对来讲环境稳定，且配置各方面和生产相同或者能够进行等量代换，能知足常规的性能测试须要。
二、FAT
FAT环境可理解为生产验证测试环境，系统版本，配置、数据量等和生产保持一致，这样从可测试性和真实性上更符合实际的生产状况。
PS：还有全链路压测是在真实的生产环境进行，可是生产环境进行性能测试的风险太大，且对现有系统的改造工做较多，是否进行还须要通过详细的评估才能决定。
全链路压测的挑战在于这几点：
①、业务模型梳理
②、数据问题，包括数据的真实可用性、数据隔离和数据脱敏；
③、环境隔离，不能影响到实际的生产业务；
④、服务集群负载均衡，测试策略和服务间通讯的问题；
⑤、容灾问题，包括某些服务宕机或者不可用时，不能对实际生产业务运行形成影响，系统可用性等；
4、压测机管理
一、压测机调度
实际的流量冲击较高时，单个压力机可能没法支持，这时候就须要多个压力执行机来分布式的进行压测。
在实际生产环境，流量的变化颇有多是随机的，如何作好压测执行机的增长和缩小，合理利用资源，是须要考虑和解决的问题。
二、状态管理
这里主要包括压测机的状态变化，包括闲置、使用（甚至预测什么时候可释放出来供其余压测任务使用等）、不可用（损坏或其余缘由）等。
三、异常管理
当性能测试进行过程当中，因为某些缘由致使服务不可用，就须要及时的中止性能压测，通常来讲主要是下面几种手段：
①、手动中止：从管理界面的功能按钮来中止压测执行；
②、熔断措施：即经过监控报警措施，当系统不可用或超过某个阈值时，自动中止压测；
③、兜底手段：当手动中止或者自动熔断措施都不可用时，从外部的某些手段来中止压测执行，这也算一种容灾措施；
相关资料可参考饿了么全链路压测平台的实现与原理。
5、数据管理
测试是须要数据来驱动的，那么在性能测试中，须要准备哪些数据呢？
一、基础数据
基础数据包括系统业务正常运行所必须的数据，好比：电商平台的SKU信息、库存数据等，还有银行的用户信息、某些业务的相关数据等，能够经过从生产备份等手段来解决。
二、预埋数据
预埋数据主要指的是DB层面，即性能测试须要模拟实际的环境，包括数据量等，从DB层面来讲，同一个库表，数据量不一样在一样的业务模型下，其性能表现也是不一样的。
预埋数据的准备，能够经过从生产备份，或者经过脚本、SQL语句来自定义准备一些可用的数据。
三、测试数据
测试脚本运行所必需的数据，一般能够经过参数化的方式来解决。
固然，从测试平台的角度，解决这个问题的方法能够经过统一的数据池来作管理，界面经过不一样的选择项，调用API来生成测试可用的数据。
6、监控管理
性能测试中，监控是必不可少的重要一环，一般来讲，须要监控的包括如下几个方面：
一、前端性能
前端展现、资源渲染所花费的时间，哪些资源耗费了最多的时间和资源，都是须要经过监控来获得相关信息。
二、中间件
①、Redis
有些系统架构利用Redis来作持久层或者缓冲区，那么对于缓存的可用性和缓存失效、缓存穿透等信息，也是必需要监控的。
②、MQ
MQ是一个异步的通讯框架，相似的还有kafka等框架，对于消息队列的生产和消费速率，资源占用，可能的堵塞等状况进行监控，也是必不可少的。
③、其余
三、容器
如今愈来愈多的企业开始将服务容器化（特别是在微服务的架构中，容器化是必要的一种手段），包括环境、脚本、服务都放在容器中。
那么对容器资源的监控，也是很是必须的。
四、服务器
服务器的监控，主要是内存、CPU、IO等方面，包括占比、使用率、阈值和提醒等。
五、DB
数据库层面，主要监控的内存、CPU等信息，固然也包括SQL语句执行耗费时间、锁等状况。
六、网络
网络是必不可少的一环，不稳定的网络环境对测试结果的影响很大，可能会带来一些隐藏的问题；网络监控通常关注这几个方面：稳定性、网关、CDN、防火墙等方面。
PS：实际上从上面的几种监控来看，都是从用户层到最终的服务处理层，层层进行监控，作到一切用数听说话。
7、日志管理
在测试过程当中，有时候不能从测试数据直观的看到隐藏的问题，就须要查看对应的日志，从详尽的日志中分析爆发问题的节点，而后进行针对性的分析。日志监控，大概分下面几个层级：
一、web
这里能够理解为用户层的日志，包括资源的本地加载、缓存等信息（因为某些状况下详尽的日志包较大，采用了日志写入用户层的操做）。
二、app
这里代指应用层，有时候出现性能问题的缘由发生在应用层，那么对应用层的监控，日志分析也是很重要的。
三、service
后台服务层，日志包括处理了哪些操做，哪一个请求甚至哪里调用等。
四、DB
数据库日志，同理，哪些操做耗费的时间长、资源多等，都是须要对应的监控和必要的日志分析，才能看出问题。
PS：上述的几种日志管理，从性能测试平台角度来讲，都是但愿将日志更直观的进行展现、筛选，不然咱们须要经过命令或者其余工具的方式，到具体的层级去查找分析日志，这样无疑会浪费必定的时间。
8、报表管理
报表管理主要包括下面几个方面：
一、实时结果
将测试的实时监控结果存入数据库，而后经过grafana等工具展现在界面上，更直观的对测试结果进行管理。
二、测试报告
每轮测试结束，都须要对测试结果进行统计分析，以便于做为一个基点，对下一次测试提供参考和评估依据；测试报告界面能够经过自定义的样式来展示。
三、性能基线
这里的性能基线，指的是：将每次性能测试的最终结果做为一个性能参考基线，后续的每次迭代，以上次性能测试结果为评估点，而后持续更新性能基线，做为下一次的评估依据。
能够经过数据折线、树状图等多种方式来展示，目的是为长期的系统稳定性、可用性作一个监控，为系统调优或重构提供多种维度的参考依据。
9、配置管理
一、挡板
通常来讲，性能测试都是经过调用不一样的服务接口来进行模拟并发，进行测试，但有时候因为某些缘由，致使一部分服务暂时不可用，或者次数限制，这种状况急须要用到mock服务。
①、HttpMock
HTTP是最多见的一种协议，并且随着微服务的流行，restful风格架构设计的运用，HttpMock的挡板服务，就变成一种常规须要。
②、SocketMock
TCP链接也是某些业务系统服务实现通讯的方式，为了方便的进行性能测试而下降对其余某些服务的依赖，SocketMock挡板服务，也是必不可少的。
③、其余
包括dubbo接口等其余类型的接口调用，能够针对性的进行设计，将mock变为一种服务。
PS：从测试管理平台的角度来讲，将Mock对象编程服务，经过界面进行增删改查的管理，更方便了管理和直观的理解。
二、容器
①、docker
容器化，是这几年愈来愈流行的一个趋势，对不一样的测试环境的docker容器管理，也是必不可少的。
②、虚机
限于不一样项目不一样技术架构的状况，虚拟机管理这一项，能够根据具体的须要来进行设计，若是所有容器化，那么虚拟机管理，没有也罢。
10、系统管理
一、用户管理
包括使用这个系统的用户注册、新增、删除，状态管理等功能，以及可能须要的任务分配等操做。
二、权限管理
不一样的用户角色，分配不一样的系统使用权限，能够利用单点登陆的原理来设计这一模块。
三、组管理
这里的组管理，我我的理解为基于身份和角色不一样所划分的职能组，对其进行新增、权限职能分配、状态变动等功能的管理。
以上内容仅是我我的的一些构思和想法，还有不少不足之处和值得深刻讨论的地方，若有更好的建议，请在评论区指出，谢谢。。。