性能测试从零开始实施指南——流程篇
很久没更博客了，最近忙着调整状态、适应新环境各方面，学习方面大多都是零散的笔记，感受再不更新下，就真的要断更了。有点理解写做者的苦衷了，催更啊。。。。。。html
因为新公司业务快速发展带来的流量突增以及技术负债各方面，性能的问题就开始急速冒头，这点不少创业阶段的中小型公司都存在该问题，表如今以下几个方面：docker
一、技术负债累积过大数据库
二、流程规范定义不清服务器
三、岗位职责划分模糊网络
四、QA建设几乎为零并发
快速发展的业务须要更好的技术支撑（这点在以前的博客：当咱们讨论性能测试时，咱们在说什么？已经讨论过这个问题），然而现实倒是技术永远慢业务需求一拍甚至好几拍。运维
这篇博客，就最近我在新公司开始性能测试实施工做的总结以及我的的一些思考，来聊聊从零开始实施性能测试，要注意哪些方面。。。分布式
1、制定目的高并发
性能测试是一项严谨的须要各团队协同配合的工做，其中包括产品、开发、运维、网络、DBA、测试等角色。从零开始实施性能测试，而性能测试流程，是最重要的一步。性能
制定性能测试流程指南的目的，是从技术角度制定性能测试实施过程当中关键技术规范，更好的对系统进行性能测试，帮助性能测试人员更好地从技术上来规避系统上线后的风险、
评估线上系统的真实能力，根据业务模型摸底线上能力以提早应对，尽量减小系统上线后的性能风险带来的损失。
2、适用范围
对性能测试实施过程当中很是重要和关键的相关技术进行分析，主要包括：
系统环境、测试指标、业务模型、数据量级、测试模型、测试策略、测试脚本、被测场景、服务监控、瓶颈分析、优化验证。
3、测试流程
按照业内目前的最佳实践，性能测试的流程是很详细的，分为不少步骤。以下图：
但考虑到从零开始实施的难度、公司所处的阶段、研发部门技术建设以及上面提到的4点问题，在最开始时候，建议对其进行必定的精简，缘由有以下几点：
一、接受程度：流程越精简，各团队成员的接受性越快；
二、推进难度：精简的流程易于更快速的推进以及调整；
三、快速产出：更快的产生反馈，性能测试产出更及时；
四、心理落差：期待值越低，落地的结果越容易被接受；
根据我的最近的实施心得以及一些思考，精简后的性能测试流程以及对应阶段的岗位职责，以下图：
4、四大阶段
大致来讲，性能测试的流程可分为如上四个阶段，分别是需求阶段、准备阶段、实施阶段以及结束。
一、需求阶段
①、提出需求
性能测试必定是先有需求，才能够决定要不要继续执行。而性能需求的提出方，能够是开发（以为某个接口慢）、能够是运维（对某个系统的服务能力进行容量评估）；
也能够是测试人员（从需求评审中分析出某个需求须要进行性能测试来规避风险）、更能够是产品（线上问题直接表现&用户反馈）。
而上图中项目负责人的角色不必定必须是岗位title意义上的PM角色，而是须要这么一个角色来作好居中沟通、资源协调的工做。
②、需求评审
不通过评审的需求每每有不少坑！！！只有多方相关人员参与评审，从各自的角度给出意见，沟通达成一致，才能决定后续的要不要作？怎么作？以及谁来作什么事情！
③、需求调研
需求调研阶段主要是对后续性能测试实施的一些必要信息进行更细致的沟通和确认，以及在职责、工时、排期、交付时间这几点上寻求平衡的可接受的点。
二、准备阶段
①、环境准备
不管是功能测试仍是自动化或者性能测试，老是须要一个合适的环境来进行。
对性能测试来讲，不管是环境选择（生产or性能测试环境）仍是申请对应的资源（虚拟机&云服务器&docker），通常都须要运维工程师来进行搭建配置。
②、应用部署
性能测试的被测应用必须是稳定的，没有P2及以上缺陷或经过回归测试的版本包，根据每一个公司的职责定位不一样，应用部署通常是开发进行部署，或开发提供对应的代码路径，运维进行拉取部署。
③、数据准备
性能测试对数据的要求是很高的，不管是数据量级、精准度抑或是数据的多样性。通常分为以下几种数据类型：
铺底数据：最多见的准备方式为从生产拖库最新的最完整的基础数据来做为性能测试所用；
测试数据：好比性能测试场景须要读写大量的数据，而为了保证测试结果的准确性，通常经过从生产拉取同等量级或者至少将来一年的增加量级的脱敏数据；
参数化数据：不一样类型的数据处理逻辑有差别时，须要经过测试数据的多样化来提升性能测试代码的覆盖率，而参数化是最多见的方式；
④、脚本开发
性能测试脚本须要针对业务模型转化后的测试模型以及采用的测试策略进行针对性的开发调试试运行。
三、实施阶段
完成准备阶段的工做，就开始开展性能压测了（有时候须要进行压测预热），这也是不少对性能测试不太了解的同窗对性能测试的认知（录制脚本→无脑高并发）。
①、压测执行
性能测试执行阶段，是须要执行不少轮次，且测试脚本也须要不断地调整修改，根据测试结果不断改进的，这样才能获得更为准确的测试结果。
②、服务监控
这个阶段称之为APM（Application Performance Management：对应用程序性能和可用性的监控管理）更合适。
狭义上的APM单指应用程序的监控，如应用的各接口性能和错误监控，分布式调用链路跟踪，以及其余各种用于诊断(内存，线程等)的监控信息等。
广义上的APM, 除了应用层的监控意外，还包括App端监控、页面端监控、容器、服务器监控，以及其余平台组件如中间件容器、数据库等层面的监控。
③、瓶颈定位
进行性能测试的目的，就是为了探测系统是否存在影响提供正常服务的性能瓶颈以及为上线提供容量评估。
若是系统性能表现未到达预期指标，则须要对日志、监控数据进行分析，定位其性能瓶颈并针对性的进行优化才能够。
④、优化验证
发现性能瓶颈并修改优化后，须要再次执行压测，以验证问题是否获得解决以及性能的提高能力，衡量的标准是需求评审和调研阶段肯定的业务性能指标。
四、结束阶段
性能测试结束的标志，通常包括以下以下几点：
涉及的测试场景均已测试完毕、测试过程当中发现的问题已所有修复验证、测试结果达到了预期的性能指标、知足上线要求。
①、测试报告
在知足上面4个条件后，最好是出具一份简洁可是明确的测试报告，说明本次性能测试的目的、范围、环境信息、测试结果、问题，并给出测试结论。
测试报告的方式能够是文档、邮件、一个HTML页面等方式，但这个环节必定不能省略！！！
②、报告评审
最好是让参与本次性能测试各环节工做的各个角色都参与进行评审，你们对结果无异议，便可视为本次性能测试结束。
以上即为性能测试从零开始实施的我的总结，若有更好的建议，请及时指出，内容仅供参考。。。