性能测试---流程篇

一、制定目的

• 性能测试是一项严谨的、需要各团队协同配合的工作，其中包括产品、开发、运维、网络、DBA、测试等角色。从零开始实施性能测试，性能测试流程，是其中最重要的一步。
• 制定性能测试流程指南的目的：是从技术角度制定性能测试实施过程中的关键技术规范，更好的对系统进行性能测试，帮助性能测试人员更好地从技术上来规避系统上线后的风险、评估线上系统的真实能力，根据业务模型摸底线上能力以提前应对，尽可能减少系统上线后的性能风险带来的损失。

二、适用范围

• 对性能测试实施过程中非常重要和关键的相关技术进行分析，主要包括：系统环境、测试指标、业务模型、数据量级、测试模型、测试策略、测试脚本、被测场景、服务监控、瓶颈分析、优化验证。

三、测试流程

• 按照业内目前的最佳实践，性能测试的流程是很详细的，分为很多步骤。如下图：
  
• 但考虑到最开始实施的难度、公司所处的阶段、研发部门技术建设，建议对其进行一定的精简，原因有如下几点：
  • 接受程度：流程越精简，各团队成员的接受性越快；
  • 推动难度：精简的流程易于更快速的推动以及调整；
  • 快速产出：更快的产生反馈，性能测试产出更及时；
  • 心理落差：期待值越低，落地的结果越容易被接受。
• 根据个人的实施心得以及一些思考，精简后的性能测试流程以及对应阶段的岗位职责，如下图：
  

四、四大阶段

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

1、需求阶段

• 在需求阶段，我们需要明确以下几个点：
  • 明确倒底需不需要做性能测试？他的目的是什么？
  • 明确被测系统是什么？被测试系统的相关技术信息有哪些？
  • 明确被测系统的基本业务、关键业务和用户行为
  • 明确性能测试点是什么？都有哪些需要测试，为什么？哪些不需要测试，为什么？
  • 明确被测系统未来的业务拓展规划以及性能需求
  • 明确性能测试策略，即应该怎么测试？
  • 明确性能测试的指标，知道测试出来的结果怎么算通过？

①、提出需求

• 性能测试一定是先有需求，才可以决定要不要继续执行。而性能需求的提出方，可以是开发（觉得某个接口慢）、可以是运维（对某个系统的服务能力进行容量评估）；
  也可以是测试人员（从需求评审中分析出某个需求需要进行性能测试来规避风险）、更可以是产品（线上问题直接表现&用户反馈）。
• 而上图中项目负责人的角色不一定必须是岗位意义上的PM角色，而是需要这么一个角色来做好居中沟通、资源协调的工作。

②、需求调研

• 需求调研阶段主要是对后续性能测试实施的一些必要信息进行更细致的沟通和确认。
• 需求调研可以从以下几个方面入手：
  • 1、系统信息调研
    • 对被测试系统进行分析，需要对被测系统，有全面的了解和认识，这是做好性能测试的前置条件。
    • 并且在后续进行性能分析和调优时，将会有很大用处，如果连系统的架构、协议都不了解，我们如何进行准确的性能测试？如何进行性能分析与调优？
    • 注：pv访问量（Page View），即页面访问量，每打开一次页面，PV数+1，刷新页面也是。UV访问数（Unique Visitor）指独立访客访问数，一台电脑终端即为一个访客。
      
  • 2、业务信息调研
    • 指对被测试的业务进行分析，通过对业务的分析和了解，方便我们后续进行性能测试场景的确定以及性能测试指标的确定。
      
  • 3、性能需求评估
    • 在执行性能测试前，要对被测系统做对应的评估，主要目的为明确系统是否有必要做性能测试。
    • 如果确定要做，需要确定性能测试点和指标：明确该测什么？性能指标是多少？测试通过与否的标准？
    • 性能指标会根据情况评估，要求被测系统能满足将来一定时间段的业务压力。
    • 判断是否进行性能测试主要从下面两个方面进行思考：
      • 业务角度：系统是公司内部 or 对外？系统使用的人数的多少？
      • 系统角度：系统又可以从以下3个方面进行分析，a）系统架构；b）数据库要求；c）系统特殊要求。
  • 4、确定性能测试点
    • 在上面第3点中，我们简单分析了如何确定一个系统是否需要做性能测试。下面简单总结下如果一个系统确定要做性能测试，我们如何确定被测系统的性能测试点？
      • 我们可以从下面几个方面进行分析：
        • 关键业务：确定被测项目是否属于关键业务，具体有哪些主要业务逻辑点，重点关注与交易相关的功能点。如果项目不属于关键业务，则可转入下面。
        • 日请求量：确定被测项目中，各功能点的日请求量，如果日请求量较高，系统压力大，而且又是关键业务，则该项目需要做性能测试。而关键业务点，可以被确定为性能点。
        • 逻辑复杂度：判断项目各功能点的逻辑复杂程度。如果一个主要业务的日请求量不高，但逻辑很复杂，则也要通过性能测试。因为在分布式方式的调用中，当某一个环节响应较慢，就会影响到其它环节，造成雪崩效应。
        • 运营推广活动：根据运营的推广计划，来判断待测系统未来的压力。降低运营过程中的风险，是性能测试的主要目标。
      • 以上四个方面，相辅相成、环环相扣。在实际工作中应该具体问题具体分析。
  • 5、确定性能指标
    • 性能需求分析一个很重要的目标就是需要确定后期性能分析用的性能指标，性能指标有很多，可以根据具体项目选取和设定，而具体的指标值则需要根据业务特点进行设定。

③、需求评审

• 不经过评审的需求往往有很多坑！！！只有多方相关人员参与评审，从各自的角度给出意见，沟通达成一致，才能决定后续的要不要做？怎么做？以及谁来做什么事情！在职责、工时、排期、交付时间这几点上寻求平衡的可接受的点。

2、准备阶段

①、环境准备

• 无论是功能测试还是自动化测试或者性能测试，总是需要一个合适的环境来进行。对性能测试来说，无论是环境选择（生产or性能测试环境）还是申请对应的资源（虚拟机&云服务器&docker），一般都需要运维工程师来进行搭建配置，或者运维工程师和性能测试工程师配合搭建。
• 需准备的环境一般有以下两个：
  • 系统运行环境：
    • 这个通常就是我们的测试环境，有些时候需求比较多，做性能测试担心把环境搞跨了影响其它的功能测试，可能需要重新搭建一套专门用来做性能测试的环境。
  • 执行机环境：
    • 这个就是用来生成负载的执行机，通常需要在物理机上运行，而物理机又是稀缺资源，所以我们每次做性能测试都需要提前准备好执行机环境。

②、应用部署

• 性能测试的被测应用必须是稳定的，没有P2及以上缺陷或通过回归测试的版本包，根据每个公司的职责定位不同，应用部署一般是开发进行部署，或开发提供对应的代码路径，运维进行拉取部署。

③、数据准备

• 测试场景设计
  • 根据性能需求分析，设计符合用户习惯的场景，场景设计的好坏，直接影响到性能测试效果。
• 性能测试对数据的要求是很高的，无论是数据量级、精准度抑或是数据的多样性。一般分为如下几种数据类型：
  • 铺底数据：最常见的准备方式为从生产拖库最新的最完整的基础数据来作为性能测试所用；
  • 测试数据：比如性能测试场景需要读写大量的数据，而为了保证测试结果的准确性，一般通过从生产拉取同等量级或者至少未来一年的增长量级的脱敏数据；
  • 参数化数据：不同类型的数据处理逻辑有差异时，需要通过测试数据的多样化来提高性能测试代码的覆盖率，而参数化是最常见的方式。
• 性能工具准备
  • 负载工具：
    • 根据需求分析和系统特点选择合适的负载工具，比如LR、Jmeter等
  • 监控工具：
    • 准备性能测试时的服务器资源、JVM、数据库监控工具，比如nmon等，以便进行后续的性能测试分析与调优。

④、脚本开发

• 性能测试脚本需要针对业务模型转化后的测试模型以及采用的测试策略进行针对性的开发调试试运行。

3、实施阶段

• 完成准备阶段的工作，就开始开展性能压测了（有时候需要进行压测预热）

①、压测执行

• 性能测试执行阶段，是需要执行很多轮次，且测试脚本也需要不断地调整修改，根据测试结果不断改进的，这样才能得到更为准确的测试结果。

②、服务监控

• 这个阶段称之为APM（Application Performance Management：对应用程序性能和可用性的监控管理）更合适。
• 狭义上的APM单指应用程序的监控，如应用的各接口性能和错误监控，分布式调用链路跟踪，以及其他各类用于诊断(内存，线程等)的监控信息等。
• 广义上的APM, 除了应用层的监控意外，还包括App端监控、页面端监控、容器、服务器监控，以及其他平台组件如中间件容器、数据库等层面的监控。

③、瓶颈定位

• 进行性能测试的目的，就是为了探测系统是否存在影响提供正常服务的性能瓶颈以及为上线提供容量评估。
• 如果系统性能表现未到达预期指标，则需要对日志、监控数据进行分析，定位其性能瓶颈并针对性的进行优化才可以。

④、优化验证

• 发现性能瓶颈并修改优化后，需要再次执行压测，以验证问题是否得到解决以及性能的提升能力，衡量的标准是需求评审和调研阶段确定的业务性能指标。

4、结束阶段

• 性能测试结束的标志，一般包括如下如下几点：
  • 涉及的测试场景均已测试完毕；
  • 测试过程中发现的问题已全部修复验证；
  • 测试结果达到了预期的性能指标、满足上线要求。

①、测试报告

• 在满足上面4个条件后，最好是出具一份简洁但是明确的测试报告，性能测试报告中，需要对性能测试目标、性能测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能测试调优说明、性能测试过程中，遇到的问题和解决办法等进行说明，并给出测试结论。（测试报告的方式可以是文档、邮件、一个HTML页面等方式）

②、报告评审

• 最好是让参与本次性能测试各环节工作的各个角色都参与进行评审，大家对结果无异议，即可视为本次性能测试结束。
• 评审通过后，性能测试工程师，要将测试结果进行备案，并做为下次性能测试的基线标准。
  • 具体包括：性能测试结果数据、性能测试瓶颈和调优方案等。
  • 同时还需要将测试过程中，遇到的问题，包括：代码瓶颈、配置项问题、数据问题和沟通问题，以及相应的解决办法或方案，进行知识沉淀。