---

前言

性能测试成熟度级别

救火（Firefighting）：应用程序发布前很少或从来没有进行过性能测试的情况。所有性能缺陷（100%）都在生产环境上发现并解决。

性能验证（Performance Validation）：公司为性能测试单独安排了一段时间，而不是在产品的后期才开始进行性能测试。因此，在研发过程中，仍然有相当多的性能缺陷被发现（ 30% ）。这是当前绝大多数公司的做法。

性能驱动（Performance Driven）：在应用程序生命周期中的每一阶段都考虑了性能。因此，当系统上线后，出现的性能缺陷就不会太多（5%）。性能驱动（Performance Driven）级别是所有企业应该追寻的目标。

糟糕性能的原因

系统设计阶段缺少性能方面的考虑（考虑整体系统集成后的性能）;
直到最后一刻才进行性能测试（性能测试越早越好）;
对系统的容量或规模没有足够的考虑（最终用户的规模和分布）;
对性能峰值预期偏低（12306）;
性能测试还不规范，没有有效的方案参考或实施;
没有使用性能测试自动化工具。

新公司业务快速发展带来的流量突增以及技术负债等各方面，性能的问题就开始急速冒头，这点很多创业阶段的中小型公司都存在该问题。

表现在如下几个方面：
1、技术负债累积过大
2、流程规范定义不清
3、岗位职责划分模糊
4、QA建设几乎为零

快速发展的业务需要更好的技术支撑（这点在之前的博客：当我们讨论性能测试时，我们在说什么？已经讨论过这个问题），然而现实却是技术永远慢业务需求一拍甚至好几拍。

我们来聊聊从零开始实施性能测试，要注意哪些方面

一、制定目的

性能测试是一项严谨的需要各团队协同配合的工作，其中包括产品、开发、运维、网络、DBA、测试等角色。从零开始实施性能测试，而性能测试流程，是最重要的一步。

制定性能测试流程指南的目的，是从技术角度制定性能测试实施过程中关键技术规范，更好的对系统进行性能测试，帮助性能测试人员更好地从技术上来规避系统上线后的风险、评估线上系统的真实能力。

根据业务模型摸底线上能力以提前应对，尽可能减少系统上线后的性能风险带来的损失。

二、适用范围

对性能测试实施过程中非常重要和关键的相关技术进行分析。

主要包括：
系统环境、测试指标、业务模型、数据量级、测试模型、测试策略、测试脚本、被测场景、服务监控、瓶颈分析、优化验证。

三、测试流程

按照业内目前的最佳实践，性能测试的流程是很详细的，分为很多步骤。
如下图：

从零开始实施的难度、公司所处的阶段、研发部门技术建设等等，在最开始时候，建议对其进行一定的精简。

原因有如下几点：
1、接受程度：流程越精简，各团队成员的接受性越快；
2、推动难度：精简的流程易于更快速的推动以及调整；
3、快速产出：更快的产生反馈，性能测试产出更及时；
4、心理落差：期待值越低，落地的结果越容易被接受；

精简后的性能测试流程以及对应阶段的岗位职责，如下图：

四、四大阶段

大体来说，性能测试的流程可分为如上四个阶段，分别是需求阶段、准备阶段、实施阶段以及结束。

1、需求阶段
①、提出需求
性能测试一定是先有需求，才可以决定要不要继续执行。而性能需求的提出方，可以是开发（觉得某个接口慢）、可以是运维（对某个系统的服务能力进行容量评估）；
也可以是测试人员（从需求评审中分析出某个需求需要进行性能测试来规避风险）、更可以是产品（线上问题直接表现&用户反馈）。
而上图中项目负责人的角色不一定必须是岗位title意义上的PM角色，而是需要这么一个角色来做好居中沟通、资源协调的工作。
②、需求评审
不经过评审的需求往往有很多坑！！！只有多方相关人员参与评审，从各自的角度给出意见，沟通达成一致，才能决定后续的要不要做？怎么做？以及谁来做什么事情！
③、需求调研
需求调研阶段主要是对后续性能测试实施的一些必要信息进行更细致的沟通和确认，以及在职责、工时、排期、交付时间这几点上寻求平衡的可接受的点。

2、准备阶段
①、环境准备
无论是功能测试还是自动化或者性能测试，总是需要一个合适的环境来进行。
对性能测试来说，无论是环境选择（生产or性能测试环境）还是申请对应的资源（虚拟机&云服务器&docker），一般都需要运维工程师来进行搭建配置。
②、应用部署
性能测试的被测应用必须是稳定的，没有P2及以上缺陷或通过回归测试的版本包，根据每个公司的职责定位不同，应用部署一般是开发进行部署，或开发提供对应的代码路径，运维进行拉取部署。
③、数据准备
性能测试对数据的要求是很高的，无论是数据量级、精准度抑或是数据的多样性。一般分为如下几种数据类型：
铺底数据：最常见的准备方式为从生产拖库最新的最完整的基础数据来作为性能测试所用；
测试数据：比如性能测试场景需要读写大量的数据，而为了保证测试结果的准确性，一般通过从生产拉取同等量级或者至少未来一年的增长量级的脱敏数据；
参数化数据：不同类型的数据处理逻辑有差异时，需要通过测试数据的多样化来提高性能测试代码的覆盖率，而参数化是最常见的方式；
④、脚本开发
性能测试脚本需要针对业务模型转化后的测试模型以及采用的测试策略进行针对性的开发调试试运行。

3、实施阶段
完成准备阶段的工作，就开始开展性能压测了（有时候需要进行压测预热），这也是很多对性能测试不太了解的同学对性能测试的认知（录制脚本→无脑高并发）。
①、压测执行
性能测试执行阶段，是需要执行很多轮次，且测试脚本也需要不断地调整修改，根据测试结果不断改进的，这样才能得到更为准确的测试结果。
②、服务监控
这个阶段称之为APM（Application Performance Management：对应用程序性能和可用性的监控管理）更合适。
狭义上的APM单指应用程序的监控，如应用的各接口性能和错误监控，分布式调用链路跟踪，以及其他各类用于诊断(内存，线程等)的监控信息等。
广义上的APM, 除了应用层的监控意外，还包括App端监控、页面端监控、容器、服务器监控，以及其他平台组件如中间件容器、数据库等层面的监控。
③、瓶颈定位
进行性能测试的目的，就是为了探测系统是否存在影响提供正常服务的性能瓶颈以及为上线提供容量评估。
如果系统性能表现未到达预期指标，则需要对日志、监控数据进行分析，定位其性能瓶颈并针对性的进行优化才可以。
④、优化验证
发现性能瓶颈并修改优化后，需要再次执行压测，以验证问题是否得到解决以及性能的提升能力，衡量的标准是需求评审和调研阶段确定的业务性能指标。

4、结束阶段
性能测试结束的标志，一般包括如下如下几点：
涉及的测试场景均已测试完毕、测试过程中发现的问题已全部修复验证、测试结果达到了预期的性能指标、满足上线要求。
①、测试报告
在满足上面4个条件后，最好是出具一份简洁但是明确的测试报告，说明本次性能测试的目的、范围、环境信息、测试结果、问题，并给出测试结论。
测试报告的方式可以是文档、邮件、一个HTML页面等方式，但这个环节一定不能省略！！！
②、报告评审
最好是让参与本次性能测试各环节工作的各个角色都参与进行评审，大家对结果无异议，即可视为本次性能测试结束。

五、总结

目标的坚定是性格中最必要的力量源泉之一，也是成功的利器之一。没有它，天才也会在矛盾无定的迷径中徒劳无功。

生活不能等待别人来安排，要靠自己去争取和奋斗，努力的人，就像盛开的花，越努力越美。

不是每件事都注定会成功，但是每件事都值得一试。如果你决定要旅行，那就别怕风雨兼程。