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

软件性能测试平台的建设说明一、组织架构这里我依据每个不同系统归属的工程组为横向，性能测试团队作为职能部门为纵向的矩阵式组织架构为例，来介绍性能测试治理平台的构思。二、思维导图三、任务治理1、任务申请一般来说，性能测试需求的来源有2个方面：①、工程组提需求工程组主动提性能测试需求，需要一个统一的性能测试任务治理的模块，其中包括被测系统归属的工程条线、系统名称、系统架构图、网络拓扑图、相关设计文档及相关环境的配置信息，以及工程经理、开发、运维、DB等联系方式，还有被测系统交付测试时间，deadline时间等信息。这种状况又可以分为三种类型：系统公布：的系统公布上线，需要对功能，性能，安全等各方面做一个完整的测试，评估是否到达业务、产品既定的上线要求。老系统迭代：已有系统进展某些优化，功能的增加或者的业务渠道引入，可能带来更高的流量冲击，这时候工程经理或者开发经理睬提出相关的性能需求，期望验证已有系统是否满足上线需要。生产事故修复验证：系统在生产环境遇到性能问题带来了某些损失，经过调优或修复后需要进展一轮全面的性能测试来评估是否满足已有的实际业务需求。②、性能组提需求针对工程的迭代、需求的引入带来的可能存在的性能瓶颈主动提出，然后经过评估，打算是否进展测试，来评估系统的稳定性可用性等。2、任务审批性能测试任务申请提交后，就需要工程组、性能组甚至其他相关人员依据现有状况，工作安排，工期等进展综合评估，来打算是否进展性能测试以及何时开头，资源安排的工作。其中需要涉及到多个团队多个人员的协作和参与，还有不能按期交付带来的风险预估等；关于性能测试需求评审，后续我会特地写篇博客来分析其中的一些细节。3、任务排期性能测试任务经过评估后打算进展，接下来就是依据具体的工作安排，资源调配，进展工作排期等进一步的工作。四、用例治理这里的用例，我指的是性能测试中包括基于任务类型，资源等各方面状况来建立的业务模型来抽象治理，具体可分为下面三种业务模型：1、常规任务常规任务，指的是系统迭代或者系统公布提出的性能需求，其中包括工程条线、系统名称、架构、拓扑图、相关人员信息、业务模型等具体信息。依据上述的状况进展具体的被测系统场景建模分析，然后制定具体的测试用例。2、日常轮询这一类型可以参考持续集成中的自动执行和条件触发等状况，设立定时任务对范围内的系统进展性能测试，测试类型主要包括并发、多节点等测试类型。3、全链路压测全链路压测，主要是生产环境进展的整体业务线的性能测试，具体内容，可以参考我之前的博客：聊聊全链路压测。五、环境治理性能测试开头的前提是有一个稳定可满足性能测试的环境，一般来说都是在下面两种环境进展：1、UATUAT环境即我们俗称的用户验收测试环境，相对来说环境稳定，且配置各方面和生产一样或者可以进展等量代换，能满足常规的性能测试需要。2、FATFAT环境可理解为生产验证测试环境，系统版本，配置、数据量等和生产保持全都，这样从可测试性和真实性上更符合实际的生产状况。PS：还有全链路压测是在真实的生产环境进展，但是生产环境进展性能测试的风险太大，且对现有系统的改造工作较多，是否进展还需要经过具体的评估才能打算。全链路压测的挑战在于这几点：①、业务模型梳理②、数据问题，包括数据的真实可用性、数据隔离和数据脱敏；③、环境隔离，不能影响到实际的生产业务；④、效劳集群负载均衡，测试策略和效劳间通信的问题；⑤、容灾问题，包括某些效劳宕机或者不行用时，不能对实际生产业务运行造成影响，系统可用性等；六、压测机治理1、压测机调度实际的流量冲击较高时，单个压力机可能无法支持，这时候就需要多个压力执行机来分布式的进展压测。在实际生产环境，流量的变化很有可能是随机的，如何做好压测执行机的增加和缩小，合理利用资源，是需要考虑和解决的问题。2、状态治理这里主要包括压测机的状态变化，包括闲置、使用〔甚至推测何时可释放出来供其他压测任务使用等〕、不行用〔损坏或其他缘由〕等。3、特别治理当性能测试进展过程中，由于某些缘由导致效劳不行用，就需要准时的停顿性能压测，一般来说主要是下面几种手段：①、手动停顿：从治理界面的功能按钮来停顿压测执行；②、熔断措施：即通过监控报警措施，当系统不行用或超过某个阈值时，自动停顿压测；③、兜底手段：当手动停顿或者自动熔断措施都不行用时，从外部的某些手段来停顿压测执行，这也算一种容灾措施；相关资料可参考饿了么全链路压测平台的实现与原理。七、数据治理测试是需要数据来驱动的，那么在性能测试中，需要预备哪些数据呢？1、根底数据根底数据包括系统业务正常运行所必需的数据，比方：电商平台的SKU信息、库存数据等，还有银行的用户信息、某些业务的相关数据等，可以通过从生产备份等手段来解决。2、预埋数据预埋数据主要指的是DB层面，即性能测试需要模拟实际的环境，包括数据量等，从DB层面来说，同一个库表，数据量不同在同样的业务模型下，其性能表现也是不同的。预埋数据的预备，可以通过从生产备份，或者通过脚本、SQL语句来自定义预备一些可用的数据。3、测试数据测试脚本运行所必需的数据，通常可以通过参数化的方式来解决。固然，从测试平台的角度，解决这个问题的方法可以通过统一的数据池来做治理，界面通API八、监控治理性能测试中，监控是必不行少的重要一环，通常来说，需要监控的包括以下几个方面：1、前端性能前端展现、资源渲染所花费的时间，哪些资源消耗了最多的时间和资源，都是需要通过监控来得到相关信息。2、中间件①、Redis有些系统架构利用Redis来做长久层或者缓冲区，那么对于缓存的可用性和缓存失效、缓存穿透等信息，也是必需要监控的。②、MQMQ是一个异步的通信框架，类似的还有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效劳。①、Mock是最常见的一种协议，而且随着微效劳的流行，restful风格架构设计的运用，Mock②、SocketMockTCP连接也是某些业务系统效劳实现通信的方式，为了便利的进展性能测试而降低对其他某些效劳的依靠，SocketMock③、其他包括dubbo接口等其他类型的接口调用，可以针对性的进展设计，将mock变为一种效劳。PS：从测试治理平台的角度来说，将Mock对象编程效劳，通过界面进展增删改查的治理，更便利了治理和直观的理解。2、容器①、docker容器化，是这几年越来越流行的一个趋势，对不同的测试环境的docker容器治理，也是必不行少的。②、虚机限于不同工程不同技术架构的状况，虚拟机治理这一项，可以依据具体的需要来进展设计，假设全部容器