在质量角度而言，针对一个被测的对象，不仅仅需要考虑它功能层面的完整性，也需要非功能场景下系统的健壮性和稳定性。一个系统最核心的是它的稳定性、完整性、以及弹性的能力。能够在不可预知以及突发的情况下系统能够平稳有效的平滑过去，而不对客户造成任何的影响。

在企业里面，都会接触到性能测试，往往很多的时候，有的同学不知道怎么下手，不知道到底需要关注什么指标，以及怎么判断它的合理性。比如在SAAS的架构下，集群资源怎么部署更加合理？容量规划如何能够有效的服务客户同时能够给公司节约计算成本。

从大的流程和分类上而言，凡是涉及技术角度的事宜，不是快速地干这件事，而是思考怎么干。抛开性能测试领域它的概念和各种工具中的术语，就单纯针对这件事而言，我们到底需要干什么，怎么干才是合理有效的，又如何判断这件事干的是否合理呢？如果非要使用步骤来梳理的话，那么第一步就是梳理性能测试方案，梳理性能测试方案结束后需要约相关的干系人进行性能测试方案的评审。这里阐述下评审的目的和评审方案需要解决的问题。针对方案部分可以汇总如下。

  • 需要阐述下干这件事的背景是什么，这样参与方案评审的干系人就清楚了上下文和这件事最终需要达到的目标。
  • 前置事宜，这部分主要列出做性能测试需要准备哪些事情，比如数据库是否需要采购、服务器是否需要采购、当前服务的资源是否需要弹升等等。同时在这项中需要清晰地列出每一个事宜的负责人并且当场进行确认，同时也需要写清楚每一个事项完成的时间节点。
  • 性能测试的目标。这部分是非常核心的部分，需要相关的干系人能够在目标上达成一致。之所以说目标是最核心的部分是因为最终有性能测试结果的时候，需要判断是否符合目标还是不符合目标，判断是否符合目标的前提是需要有一个判定的基准值，而它就是本次性能测试的目标。比如响应时间不能超过5秒，那么实际测试结果是超过了5秒，那么可以判定为不符合预期，当然这仅仅是一个维度，很多时候需要结合多个维度来进行判断。
  • 测试策略。这部分不可缺少的理由是参与方案评审的干系人需要清晰的知道你通过什么样的测试策略来执行和验证。比如验证一个系统是否具备弹性的能力，在资源伸缩的过程中是否可以平滑地无缝切换。那么既然验证这部分，验证它的策略到底是什么? 在进行资源伸缩过程中到底是手动模式还是自动模式，副本数是多少？这些都需要很清晰地列举出来
  • 除了测试策略外还需要测试场景。对一个系统而言有很多的场景，那么在进行性能测试的过程中，到底选择哪些场景来进行性能测试，为什么选择这些场景而不是其他的场景。这些信息都需要和参与方案评审的干系人沟通并且大家最终达成一致。

梳理性能测试方案除了上面列表的要素外，还需要核对的是资源的一致性，这些资源主要指的是服务资源配置(内存与CPU)、服务节点数、DB资源配置、MQ资源配置(分区数等)等其他组件的资源配置。一般而言肯定不能使用生产环境来进行性能测试，那么选择其他环境来进行性能测试的时候需要与生产环境的资源配置保持一致，这样测试的数据才有可参考的依据和标准。

在方案这些都完成的情况下进入到执行的环节，执行环节需要记录下每个场景中不同组件的资源信息，这些资源信息汇总如下。

  • 针对服务需要关注堆内存使用率、QPS、服务平均响应时间以及GC等资源
  • 针对MQ需要关注分区数、每个服务节点的MQ消费情况，和MQ未消费数据的变化趋势，如果可能也可以关注下MQ本身的资源信息
  • 针对DB需要关注的是CPU&MEM使用率、IOPS、读写吞吐量、QPS等资源，如果是多节点需要关注下节点资源使用情况。如假设四个节点只有2个节点资源是90%，另外2个节点资源不到3%，这很明显在DB层面资源使用非常的不均衡。
  • 针对被测的接口需要关注吞吐率、错误率、P99&P95&P90，和最大响应时间、最小响应时间、中位数以及平均响应时间
  • 针对被测的业务场景需要关注到的是任务执行的最大耗时、最小耗时、和中位数，以及任务执行总数、执行成功数，以及任务执行的成功率
  • 还需要关注性能测试过程中异常情况下它的日志信息，如错误关键字，日志链接地址等信息和其他相关信息。

最后就是梳理性能测试报告，进行各个不同维度的综合数据来进行判断是否符合期望的结果。比如从响应时间、吞吐率、资源使用率、任务执行结果、MQ消费等不同维度来进行判断。这需要看具体产品和业务特性。但是有一点需要清楚的是性能测试结果报告需要评审，评审参与的人也是最初参与方案的人需要参与进来，也许沟通性能测试结果还会有其他人参与进来。组织性能测试结果的沟通一个目的是针对性能测试进行阶段性的工作总结，第二是相关干系人也需要知道性能测试结果是否符合预期，如不符合后的ToDo和相关事宜有哪些，都需要沟通清楚。

有的性能测试目标是很清晰的，那么在方案清晰的基础上验证是否符合预期。但是有的性能测试目标是不清晰的。比如一个集群中到底可以部署多少租户？想了解下目前服务的吞吐率是多少以及它的响应时间是多少？这些其实就是不清晰的目标。针对不清晰的目标依然除了上述说的流程外。进行性能测试结果后，根据性能测试的结果再结合目前产品使用的客户数和客户情况，来反推当前系统(服务)是否满足业务诉求。其实这个过程也可以理解为探索性的一个测试。结合探索性测试的思想，进行验证，最后了解下当前系统的情况它能够承载多少任务，从而对系统的整体性掌握信息能够更加全面。