近期公司为了节省成本搞了一波机房迁移，整合了一些南美部署架构。有一些上google云和有些下阿里云等大的调整。 在做机房迁移项目当中就需要思考如何进行性能测试，这种大的机房迁移SRE（运维）会针对组件会做一些单组件的性能测试，但是整个迁移之后性能上面会不会整体上达到与迁移之前一致，并不能讲的很清楚。 鉴于此作为QA就要针对性的对迁移之前的性能质量做整体评估。 以下是关于性能测试的一些指南。
1.概述
性能测试是一种软件测试形式，它关注运行系统的系统在特定负载下的性能。这与查找软件错误或缺陷无关。不同的性能测试类型根据基准和标准进行测量。性能测试为开发人员提供了消除瓶颈所需的诊断信息。
在本文中，您将了解：
性能测试类型
如何运行性能测试的步骤
性能测试指标
以及软件测试最佳实践
2.软件性能测试类型
首先，了解软件在用户系统上的表现非常重要。在软件测试期间可以应用不同类型的性能测试。这是一种非功能测试，旨在确定系统的就绪性。（功能测试侧重于软件的各个功能。）
测试类型
负载测试
负载测试会随着工作负载的增加而衡量系统性能。这种工作负载可能意味着并发的用户或事务。随着工作负载的增加，系统会受到监控，以测量响应时间和系统的持续能力。该工作量在正常工作条件的参数范围内。
压力测试
与负载测试不同，应力测试（也称为疲劳测试）旨在测量正常工作条件参数之外的系统性能。该软件提供了更多可以处理的用户或事务。压力测试的目标是测量软件的稳定性。软件在什么时候发生故障，软件如何从故障中恢复？
尖峰测试（pike testing）
尖峰测试是一种压力测试，当工作负载快速且重复地大幅增加时，它会评估软件性能。短时间内工作量超出正常预期。
耐久性试验（Endurance testing）
耐久性测试（也称为浸泡测试）是对软件如何在长时间内以正常工作负载执行的评估。耐久性测试的目标是检查系统问题，如内存泄漏。（当系统无法释放丢弃的内存时，就会发生内存泄漏。内存泄漏可能会影响系统性能或导致系统失败。）
可扩展性测试（Scalability testing）
可扩展性测试用于确定软件是否有效地处理不断增加的工作负载。这可以通过在监视系统性能的同时逐渐增加用户负载或数据量来确定。此外，当CPU和内存等资源发生变化时，工作负载可能保持在相同的水平。
体积测试（Volume testing）
批量测试确定了软件对大量预测数据的执行效率。它也被称为洪水测试，因为测试用数据淹没了系统。
性能测试中观察到的最常见问题
在软件性能测试期间，开发人员正在寻找性能症状和问题。
速度问题——例如响应慢和加载时间长——经常被观察到并解决。
可以观察到其他性能问题：
瓶颈-当数据流中断或停止时，因为没有足够的容量来处理工作负载，就会出现瓶颈。
可扩展性差-如果软件无法处理所需数量的并发任务，结果可能会延迟，错误可能会增加，或者可能会发生其他影响：
磁盘使用情况
CPU使用率
内存泄漏
操作系统限制
网络配置不良
软件配置问题—通常设置的级别不足以处理工作负载。
硬件资源不足-性能测试可能显示物理内存限制或CPU性能低下。
3.七个性能测试步骤
也称为测试台，测试环境是建立软件、硬件和网络以执行性能测试的环境。要使用测试环境进行性能测试，开发人员可以使用以下七个步骤：
1.确定测试环境。
通过识别可用的硬件、软件、网络配置和工具，测试团队可以尽早设计测试并识别性能测试挑战。性能测试环境选项包括：
生产系统子集，具有较少的低规格服务器
具有较少相同规格服务器的生产系统子集
生产系统副本
实际生产系统
2.确定绩效指标。
除了确定响应时间、吞吐量和约束等指标外，还要确定性能测试的成功标准。
3.计划和设计性能测试。
确定考虑用户可变性、测试数据和目标度量的性能测试场景。这将创建一个或两个模型。
4.配置测试环境。
准备测试环境的要素和监控资源所需的仪器。
5.实施测试设计。
开发测试。
6.执行测试。
除了运行性能测试之外，还要监视和捕获生成的数据。
7.分析、报告、重新测试。
分析数据并分享结果。使用相同的参数和不同的参数再次运行性能测试。
衡量哪些性能测试指标
需要度量来理解性能测试的质量和有效性。除非进行测量，否则无法进行改进。需要解释的两个定义：
测量值
-正在收集的数据，例如响应请求所需的秒数。
度量
-使用度量来定义结果质量的计算，例如平均响应时间（总响应时间/请求）。
衡量速度、可伸缩性和稳定性的方法很多，但不能期望每一轮性能测试都使用所有这些方法。在性能测试中使用的指标中，通常使用以下指标：
响应时间
发送请求和获得响应的总时间。
等待时间
也称为平均延迟，它告诉告诉在发送请求后接收第一个字节需要多长时间。
平均加载时间
从用户的角度来看，交付每个请求所需的平均时间是质量的主要指标。
峰值响应时间
这是对完成请求所需的最长时间的度量。显著长于平均值的峰值响应时间可能表明会产生问题的异常。
错误率软件测试
此计算是与所有请求相比导致错误的请求的百分比。这些错误通常发生在负载超过容量时。
并发用户
这是最常见的负载衡量标准，即任何时候有多少活跃用户。也称为负载大小。
每秒请求数
处理了多少请求。
事务通过/失败
成功或不成功请求总数的度量。
吞吐量
以每秒千字节为单位衡量，吞吐量显示测试期间使用的带宽量。
CPU利用率
CPU处理请求所需的时间。
内存利用率
处理请求需要多少内存。
4. 性能测试最佳实践
也许性能测试最重要的提示是尽早测试，经常测试。单个测试不会告诉开发人员他们需要知道的所有信息。成功的性能测试是一系列重复和较小的测试：
在开发过程中尽早测试。不要在项目结束时等待并匆忙进行性能测试。
性能测试不仅仅针对已完成的项目。测试单个单元或模块是有价值的。
进行多项性能测试，以确保一致的结果并确定指标平均值。
应用程序通常涉及多个系统，如数据库、服务器和服务。单独以及一起测试各个单元。
除了重复测试之外，通过遵循一系列性能测试最佳实践，性能测试将更加成功：
让开发人员、IT人员和测试人员参与创建性能测试环境。
记住，真正的人将使用正在进行性能测试的软件。确定结果将如何影响用户，而不仅仅是测试环境服务器。
超越性能测试参数。通过规划尽可能多地考虑用户活动的测试环境来开发模型。
基线测量为确定成功或失败提供了一个起点。
性能测试最好在尽可能接近生产系统的测试环境中进行。
将性能测试环境与用于质量保证测试的环境隔离开来。
没有任何性能测试工具可以完成所需的一切。有限的资源可能会进一步限制选择。研究合适的性能测试工具。
保持测试环境尽可能一致。
计算平均值将提供可操作的指标。跟踪异常值也有价值。这些极端测量可能会揭示出可能的故障。
在准备共享性能测试结果的报告时，请考虑受众。此外，在报告中包括任何系统和软件更改。
五种常见的性能测试错误
性能测试时，某些错误可能导致不可靠的结果：
没有足够的时间进行测试。
不涉及开发人员。
没有使用类似于生产系统的QA系统。
未充分调整软件。
没有故障排除计划。
性能测试谬论
性能测试错误可能导致错误或未能遵循性能测试最佳实践。根据Sofia Palamarchuk的说法，在开发软件时，这些信念可能会耗费大量资金和资源：
性能测试是开发的最后一步。
如性能测试最佳实践一节所述，预测和解决性能问题应该是软件开发的早期部分。早期实施解决方案的成本将低于软件开发结束时的主要修复。
更多的硬件可以解决性能问题。
添加处理器、服务器或内存只会增加成本，而不会解决任何问题。更高效的软件将更好地运行，并避免即使在硬件增加或升级时也可能出现的潜在问题。
测试环境足够接近。
在与生产环境类似的测试环境中进行性能测试是一种性能测试最佳实践，这是有原因的。元件之间的差异会显著影响系统性能。可能不可能在精确的生产环境中进行性能测试，但请尝试匹配：软件开发生命周期
硬件组件
操作系统和设置
系统上使用的其他应用程序
数据库
现在起作用的，是全面起作用的。
小心推断结果。不要接受一小组性能测试结果，并假设当元素发生变化时，它们将是相同的。而且，它的工作方向相反。不要根据负载测试推断最低性能和要求。所有假设都应通过性能测试进行验证。
一个性能测试场景就足够了。
并非每个性能问题都可以在一个性能测试场景中检测到。但资源确实限制了可能发生的测试数量。中间是一系列性能测试，针对风险最大的情况，对性能影响最大。此外，在计划良好和设计良好的性能测试之外，可能会出现问题。监视生产环境还可以检测性能问题。
测试每个部分等于测试整个系统。
虽然隔离功能以进行性能测试很重要，但单个组件测试结果并不构成系统范围的评估。但测试系统的所有功能可能不可行。必须使用可用资源设计尽可能完整的性能测试。但要注意哪些东西没有经过测试。
对他们有用的东西对我们有用。
如果给定的一组用户确实遇到了复杂性或性能问题，不要将其视为所有用户的性能测试。使用性能测试确保平台和配置按预期工作。
软件开发人员经验丰富，不需要性能测试。
缺乏经验并不是绩效问题背后的唯一原因。即使是过去创建过免费软件的开发人员也会犯错误。更多的变量发挥作用，特别是当系统中有多个并发用户时。
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
