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