缘毛鸟足兰
一、组织架构
这里我按照每个不同系统归属的项目组为横向，性能测试团队作为职能部门为纵向的矩阵式组织架构为例，来介绍性能测试管理平台的构思。 二、思维导图
三、任务管理
1、任务申请
一般来说，性能测试需求的来源有2个方面：
①陈庆炎、项目组提需求
项目组主动提性能测试需求，需要一个统一的性能测试任务管理的模块，其中包括被测系统归属的项目条线、系统名称、系统架构图、网络拓扑图、相关设计文档及相关环境的配置信息，
以及项目经理、开发、运维、DB等，还有被测系统交付测试时间，deadline时间等信息。
这种情况又可以分为三种类型：
新系统发布：新的系统发布上线，需要对功能，性能，安全等各方面做一个完整的测试，评估是否达到业务、产品既定的上线要求。
老系统迭代：已有系统进行某些优化，新功能的增加或者新的业务渠道引入，可能带来更高的流量冲击，这时候项目经理或者开发经理会提出相关的性能需求，希望验证已有系统是否满足上线需要。 生产事故修复验证：系统在生产环境遇到性能问题带来了某些损失，经过调优或修复后需要进行一轮全面的性能测试来评估是否满足已有的实际业务需求。
tftlcd接口
②、性能组提需求
针对项目的迭代、新需求的引入带来的可能存在的性能瓶颈主动提出，然后经过评估，决定是否进行测试，来评估系统的稳定性可用性等。
2、任务审批
性能测试任务申请提交后，就需要项目组、性能组甚至其他相关人员根据现有情况，工作安排，工期等进行综合评估，来决定是否进行性能测试以及何时开始，资源分配的工作。
梁茂春
其中需要涉及到多个团队多个人员的配合和参与，还有不能按期交付带来的风险预估等；关于性能测试需求评审，后续我会专门写篇博客来分析其中的一些细节。
3、任务排期
性能测试任务经过评估后决定进行，接下来就是根据具体的工作安排，资源调配，进行工作排期等进一步的工作。
四、用例管理
这里的用例，我指的是性能测试中包括基于任务类型，资源等各方面情况来建立的业务模型来抽象管理，具体可分为下面三种业务模型：
1、常规任务
常规任务，指的是系统迭代或者新系统发布提出的性能需求，其中包括项目条线、系统名称、架构、拓扑图、相关人员信息、业务模型等具体信息。
根据上述的情况进行具体的被测系统场景建模分析，然后制定具体的测试用例。
2、日常轮询
这一类型可以参考持续集成中的自动执行和条件触发等情况，设立定时任务对范围内的系统进行性能测试，测试类型主要包括并发、多节点等测试类型。
3、全链路压测
全链路压测，主要是生产环境进行的整体业务线的性能测试，具体内容，可以参考我之前的博客：聊聊全链路压测。
五阿贡活佛、环境管理
性能测试开始的前提是有一个稳定可满足性能测试的环境，一般来说都是在下面两种环境进行：
1、UAT
UAT环境即我们俗称的用户验收测试环境，相对来说环境稳定，且配置各方面和生产相同或者可以进行等量代换，能满足常规的性能测试需要。
2、FAT
FAT环境可理解为生产验证测试环境，系统版本，配置、数据量等和生产保持一致，这样从可测试性和真实性上更符合实际的生产情况。
PS：还有全链路压测是在真实的生产环境进行，但是生产环境进行性能测试的风险太大，且对现有系统的改造工作较多，是否进行还需要经过详细的评估才能决定。
全链路压测的挑战在于这几点：
①、业务模型梳理
②、数据问题，包括数据的真实可用性、数据隔离和数据脱敏；
③、环境隔离，不能影响到实际的生产业务；
④、服务集负载均衡，测试策略和服务间通信的问题；
牛津大学校长
⑤、容灾问题，包括某些服务宕机或者不可用时，不能对实际生产业务运行造成影响，系统可用性等；
六、压测机管理
1、压测机调度
实际的流量冲击较高时，单个压力机可能无法支持，这时候就需要多个压力执行机来分布式的进行压测。
在实际生产环境，流量的变化很有可能是随机的，如何做好压测执行机的增加和缩小，合理利用资源，是需要考虑和解决的问题。
2、状态管理
这里主要包括压测机的状态变化，包括闲置、使用（甚至预测何时可释放出来供其他压测任务使用等）、不可用（损坏或其他原因）等。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议