【服务端性能测试】性能测试实施流程！

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

我对性能测试的定义十分明确得描述了性能测试的方法和流程：

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。

我将其与自己的实践经验结合，重新整理了项目中通用的性能测试实施流程。

0. 前期准备

在正式开始性能测试之前，至少完成以下几个方面的准备工作

1. 系统基础功能验证

性能测试一般是软件系统已经基本完成开发或部署之后的测试活动，要求被测对象在功能上基本满足需求，且具有一定的稳定性。必须保证在性能测试之前至少进行一次系统的功能覆盖测试。

2. 预先的业务和架构分析

为了对系统性能建立直观上的认识和分析，应对系统较重要和常用的业务场景模块进行针对性的分析，以对接下来的测试计划设计进行准备。

3. 组建性能团队

根据需求组建性能测试团队，至少要报括性能测试设计和执行人员、开发和运维人员。

1. 性能需求分析

和做功能测试一样，我们需要花费一定的精力弄清楚性能需求到底是什么的。在这一步，我们需要与客户、项目经理、产品、开发等相关人员进行沟通，收集各种资料，对被测系统进行分析，确认性能测试目标，确定需要覆盖的性能场景，并最终将其转化为可衡量的性能指标和监控策略。

1.1 性能测试目的分析

我曾经负责过一个新系统上线前的性能测试工作，客户对这个系统的性能需求很明确：关键业务流程上的接口能达到100TPS，响应时间在200ms内，且在所有接口都达到100TPS的情况下能够稳定运行24小时。

显然，这一次的我是幸运的，但很难一直这么幸运。很多时候做出要做性能测试这个决定时，其目的通常并没有这么明确，需要我们持续追问并挖掘出性能测试要达到的目的。测试目的通常逃不出下面列举的范围：

1. 测试出系统的最大容量，上线后心里有底
2. 新版本和旧版本对比，性能不下降
3. 验证系统在一定的负载压力下能稳定运行
4. 系统性能调优到可接受范围内

也可以用应用领域来更为简洁得归纳总结性能测试目的：

• 能力验证：验证系统在给定环境中的性能能力，就是针对给定的指标，只做性能验证。
• 规划能力：测试出系统的最大容量，验证系统的性能扩展力，找出系统能力扩充的关键点，给出改善其性能扩展能力的建议。
• 性能调优：针对给定的系统，做全面的性能测试，同时提高系统的性能表现。

1.2 业务模型

在前期准备中，我们已经对系统所涉及的多种业务有了基本的了解。一般而言，性能测试不会针对系统所有功能来进行，选取重点的、具备足够代表性的业务功能，确定并建立起相应的业务模型是必不可少的。每种业务的逻辑、业务量、消耗的系统资源都存在差别，例如电商系统在不同的促销形式下，用户使用不同功能的配比是完全不一样的，系统承受的压力自然也不一样，因此业务模型直接影响着我们对系统的处理能力的判断。如果业务模型中业务和占比的选取跟生产差异非常大，将直接导致测试结果没有任何参考价值。

系统中的代表性业务如何选取呢？一般情况下遵循的规则是选取业务量高的、用户经常使用的、有风险的、未来有增长趋势的业务。已上线的系统可以通过系统日志分析出高峰时间段内的接口请求和所占比例，再结合系统业务逻辑梳理出业务种类和业务占比，以便更真实的模拟生产业务场景；不同时间段内的业务种类和业务占比存在较大差异时，需要选用多个代表性的业务模型。未上线的新系统则可以结合业务团队的判断和用户调研来确定业务种类和业务占比。

通用的业务模型如下，部分比例为0的业务未在表格中列出：

业务名	测试场景业务比例
业务1	2.56%
业务2	20.34%
业务5	40.25%
业务7	36.85%

1.3 性能目标

对于不同的性能测试应用领域，性能目标也会存在差异，下面是对各领域性能目标的类似描述：

• 能力验证领域：该应用能够以1秒的最大响应时间处理200个并发用户对用户A的访问；峰值时刻有400用户，允许响应时间延长为2秒；
• 规划能力领域：系统的A业务在未来的3个月内每天的业务吞吐量达到4000笔，找出系统的性能瓶颈并给出可支持这种业务量的建议；
• 性能调优领域：通过性能调优测试，本系统的A业务和B业务在200个并发用户的条件下，响应时间提高到1秒。

在这些性能目标描述中，对具体系统业务的响应时间、并发用户数、吞吐量等性能测试指标都进行了明确的定义，当然，还应该加上此时对系统资源的定义，如：该应用能够以1秒的最大响应时间处理200个并发用户对用户A的访问，此时服务器的CPU占用不超过70%，内存使用率不超过80%；峰值时刻有400用户，允许响应时间延长为2秒，此时此时服务器的CPU占用不超过85%，内存使用率不超过90%。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036【暗号：csdn999】

在 “性能测试指标”一文中，已经对性能测试中常用的业务指标和资源指标进行了详细的介绍，在实际确定性能测试目标时可从中选取恰当的指标，并根据业务需要确定各指标的具体取值，确定好后可以最终可以得出下表：

2. 性能测试设计和准备

2.1 性能测试环境

通常来讲，性能测试需要有独立的测试环境，其配置生产环境保持一致，但通常由于成本较高，会采用等比构建（1/2，1/4等）。但由于资源申请、预算、环境搭建步骤繁多的限制，可能没有办法拥有独立的测试环境，这个时候可以考虑使用的已有的测试环境或生产环境来进行测试，并提前识别出使用这些环境面临的风险。同时还需要考虑涉及到第三方服务的业务是否需要使用Mock来代替，如果不能则需要提前与第三方服务负责人沟通排期。

在我所参与过的一个性能测试项目中，我们最终采用了这样的环境策略：To C业务相关的服务采用独立、1/2等比构建的性能测试环境，To B业务则在功能测试环境中进行。这样做，虽然终于能够有环境来进行测试，但显然最后的测试结果参考意义降低了，而且由于功能测试环境还用于新功能的测试，我们的性能测试与功能测试在产生了严重的冲突，当压测开始之后，由于系统承受不住那么大量的请求，崩溃了，为了不影响功能测试的进度，性能测试的执行基本都要等到功能测试执行人员下班之后才能进行。

性能测试环境方案确定后就可以让运维同事开始部署性能环境了，性能环境部署完成后要先验证环境可用性。

2.2 性能场景设计

场景来源于英文scenario，本意是指：影视剧情中的人物在特定时间与空间内发生的行动。

对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

性能场景不会超出下面这几个分类：

在实际测试执行时，我们要对涉及的业务一个一个地做基准，找出每个业务在系统中的最大TPS和对应的响应时间；接下来是容量性能场景，根据性能目标中各业务的比例，不断增加压力，在加压过程中需要注意始终保持各业务的业务比例，最终得出混合业务的最大TPS及响应时间，当然，如果在你的项目中存在多个不同的业务比例的场景，也是需要都测试一遍的；然后是稳定性性能场景，这需要业务和运维部门联合给出一个指标：系统要稳定运行一周、支持2000万业务量，据此我们可以计算出稳定性性能场景中的时长：2000万 ➗根据容量性能场景中得到的容量TPS（所有业务TPS之和）；最后是异常性能场景，这时可以采用容量性能场景中最大 TPS 的 50%来做，然后对业务服务器、数据库服务器等做异常操作。

2.3 性能测试数据

在性能测试中，我们要关注的数据主要有基础铺底数据和参数化数据。

1. 基础铺底数据

在生产环境中，系统肯定不会一直是一个刚部署的空系统，会有一定量的数据已经存储在数据库、文件CDN、Redis缓存等中。因此在性能测试执行开始前，我们需要模拟出真实场景中业务操作的实际数据量。

2. 参数化数据

在性能场景运行过程中，我们会用到两类数据：唯一性数据和可重复使用的数据。参数化数据量取决于场景运行时间和TPS。

对于唯一性数据，比如删除操作所需要的数据，在被删除后是不可再次被使用的。所需的数据量计算方式很简单，比如一个运行20分钟的场景，TPS 如果是 100 的话，那就至少需要20min * 60s * 100 = 12 万条数据。

对于可重复使用的数据，比如查询单条记录，重复使用同一个参数（ID）进行查询显然是不符合真实场景的。这种场景下没有固定的条数限制，只能根据实际的业务进行判断。当然了，也可以先按唯一性数据的数据量计算方法计算，然后在实际执行中按需使用。

除了数据量要能满足性能场景的运行外，也要满足生产环境中的数据分布。比如记账应用中，用户每天记账的笔数通常会在5-20之间，上千甚至上万的数据量肯定是不合理的。

那么如何将设计好的参数化数据放到系统中呢？参数化数据可以分为两类：第一类是已存在后台数据库中，第二类是脚本执行成功后才会将数据Insert到数据库中；

对于第一类数据，以用户登录为例，登陆接口需要将其中的参数与后台数据库中的数据对比，这就要求数据库中要先存在这些数据，且压力工具也能够知道具体数据取值。实际项目中，通常会涉及多个数据库表，要先梳理清楚表之间的关联。

对于第二类数据，以记账应用的记一笔功能为例，只需要在压力工具中将相应数据参数化即可。

2.4 监控设计

在性能测试中，监控是非常重要的环节，监控是做性能分析的前提。

首先要分析系统的架构，在知道架构中使用的组件、服务之后，再有针对性的找对应的监控手段和方式。具体在设计时，可以使用从全局到定向的思路，列出要采用的计数器，形成可供分析证据链。

至于使用什么监控工具来获取这些计数器的值，推荐采用Prometheus + Exporter的思路。具体方案还是需要跟运维同事进一步确认，并由运维同事来实施监控工具的部署。

性能监控是一个很大的话题，真的要做好还是需要花费较大的精力去学习和实践，本文只能作为一个引子，还是需要大家自己去仔细钻研。

2.5 性能测试脚本

首先要确定性能测试的工具，比如Jmeter、Gatling、Locust等，这些工具的对比及具体使用教程在网上已经有很多有用的资料了，本文就不介绍具体工具的使用方法了。

选定工具之后就可以开始写对应的脚本并调试啦，这部分内容我会单独再出一篇文章做示例。

在这里还有一个步骤需要强调的是，性能脚本执行时是需要执行机的，具体需要几台需要大家根据自己的实际情况判断。而执行机通常也是需要提前申请的，配置高的为佳。

在性能测试设计完成后就可以开始编写《性能测试方案》的文档了。

3. 性能测试执行

有了前面的设计和准备工作，终于可以开始执行性能场景了。

这部分没有太多要说的内容，只需要关注下执行过程中的业务指标和监控的资源指标是否都记录上即可。

4. 性能测试结果分析及调优

每一个性能场景执行完后，要先从压力工具和监控工具中整理输出相应的结果，通常是表格和图表形式的。然后根据这些结果，判断测试是否通过。若性能不达标，需要针对性得进一步分析出影响性能的根本原因，但性能问题通常是相互关联相互影响的，表面上看到的现象很可能不是根本问题，而是另一处出现问题后引起的反应，这就要求监控收集数据时的证据链要完整，能帮助我们一步步得探寻到真相。

调优可能是一个漫长的过程，需要我们不断去尝试，要有耐心也要有信心。

影响性能的点及调优的方法如下，仅供参考：

1. 数据库：检查索引设置，检查SQL语句是否可以优化
2. 业务接口：流程是否有冗余；返回的数据是否有冗余；数据处理逻辑是否可以优化

5. 性能测试报告

最后就可以输出性能测试报告了，阐明性能测试目标、测试环境、数据构造规则、性能结果、风险等内容。

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。