在性能测试种最常见的问题

在软件性能测试期间，开发人员会寻找性能的症状和问题。速度问题——例如缓慢的响应和长时间的加载时间——经常会被观察和处理。但是还能看到有一些其他的性能问题：

瓶颈效应——发生在当数据流被中断或者停止的时候，因为没有足够的能力处理工作负载。

较差的可扩展性——如果软件无法处理所需数量的并发任务，结果可能导致延误，可能增加错误，或者发生其他无法预料的行为，这影响到：

○ 磁盘使用情况○ CPU使用情况○ 内存卸扣○ 操作系统受限○ 糟糕的网络配置

软件配置问题——通常设置不是设置在一个足够的级别上来处理工作负载。

硬件资源不足——性能测试可能暴露出物理内存限制或低效率的CPU。

性能测试7步

 Image credit Gateway TestLabs

同样也被曾作测试台，测试环境是设置软件、硬件和网络来执行性能测试的地方。为了使用性能测试测试环境，开发人员可以用下面七步：

确定测试环境

确定硬件、软件、网络配置和可用的工具，让测试团队设计测试和尽早确定性能测试挑战。性能测试环境选择包括：

○ 有少量低规格服务器的生产系统子集。

○ 有少量相同规范服务器的生产系统的子集。

○ 生产系统的复制品。

○ 实际生产系统。

确定性能标准

除了确定性能参数，例如响应时间，吞吐量和限制之外，确定性能测试的成功标准是什么。

计划和设计性能测试

确定性能测试方案，考虑账户用户的可变性、测试数据和目标参数。这将创建一到两个模型。

配置测试环境

准备测试环境的元素和监控资源所需的设备。

执行测试设计

开发测试。

执行测试

除了运行性能测试之外，监控和抓取生产数据。

分析，报告，再测试

分析数据，分享所发现的。使用同样的参数和不同的参数再次运行性能测试。

性能测试参数测量了什么

参数需要理解性能测试的质量和效果。除非有测量，否则无法提高。现在解释下2种定义：

测量——收集的数据，例如它响应一个请求所花的秒数。

参数——使用数据的计算结果，决定结果的质量，例如平均响应时间（总响应时间/请求）

有许多方法可以测量速度、可扩展性和稳定性，但是每轮性能测试无法使用全部方法。在性能测试中所用的参数，下面的是经常用到的：

响应时间：发送一个请求和获得一个响应的总时间。

等待时间 ：这也称为平均延迟，这告诉开发人员在发送请求后接收第一个字节需要多长时间。

平均加载时间：从用户的角度来看，交付每个请求所需的平均时间是质量的主要指标。

峰值响应时间：这是完成请求所需的最长时间的测量。峰值响应时间明显长于平均时间，这可能表明出现问题的异常情况。

错误率：这是一个与所有请求相比，计算产生错误的请求的百分比。这些错误通常发生在负载超过容量的时候。

并发用户：这是最常见的负载测量——在任意时刻有多少活跃用户，也称为负载大小。

每秒请求：多少请求被处理。

事务通过/失败：对成功或不成功请求的总数的测量。

吞吐量：以千字节每秒的速度度量，吞吐量显示测试期间使用的带宽量。

CPU利用率：CPU需要多少时间来处理请求。

内存利用率：需要多少内存来处理请求。

性能测试最佳实践

也许性能测试最重要的小建议就是早测试，常测试。一个单独的测试将无法告诉开发人员他们所需知道的全部。成功的性能测试是许多的反复测试和小测试组成的。

在开发中尽可能的早测试。当项目结束时，不要等待并急于进行性能测试。

性能测试不仅仅针对已完成的项目。测试单个单元或模块也是有价值的。

进行多项性能测试，以确保一致的发现和确定参数的平均值。

应用常常涉及多个系统，例如数据库、服务器和服务。单独测试各个单元，而且一起测试。

Image credit Varun Kapaganty

除了反复测试，通过一系列性能测试的最佳实践，性能测试将会更加成功。

让开发人员、IT人员和测试人员一起参与创建一个性能测试环境。

记住真正的用户将使用正在进行性能测试的这个软件。确定结果将如何影响用户，而不仅仅是测试环境服务器。

超越性能测试参数。通过计划一个测试环境来开发一个模型，这个测试环境尽可能多地考虑用户活动。

基线测量为确定成功或失败提供了一个起点。

性能测试最好在尽可能接近生产系统的测试环境中进行。

将性能测试环境与用于质量保证测试的环境隔离开来。

任何性能测试工具都不需要做任何事情。有限的资源可能会进一步限制选择。为了更适合研究性能测试工具。

尽可能保持测试环境的一致性。

计算出的平均值将提供可执行的参数。跟踪异常值也有价值。这些极端的测量可能暴露出可能的失败。

当准备报告分享性能测试结果时，请考虑听众。此外，还包括报告中的任何系统和软件更改。

5个性能测试常犯的错误

还有一些错误会导致性能测试时不太可靠的结果:

测试时间不足

不包括开发人员

不使用与生产系统类似的QA系统

优化软件不足

没有故障排除的计划

性能测试错误理论

性能测试的错误理论可能导致错误或遵循性能测试最佳实践的失败。根据Sofia

Palamarchuk的说法，这些理念在开发软件时可能会耗费大量金钱和资源：

性能测试是开发的最后一步

在前面性能测试最佳实践部分中提到过，预期和解决性能测试问题应该是软件开发的早期部分。尽早执行解决方案将比软件开发结束时的主要修复成本要低。

硬件越多就能解决性能问题

增加处理器、服务器或内存，简单的增加成本，不解决任何问题。更多有效的软件可以在硬件增加或改善时更好的运行和避免潜在的问题。

测试环境“非常接近”

在一个类似于生产环境的测试环境中进行性能测试，是一个性能测试的最佳实践。这些元素之间的差异可以显著地影响系统性能。在精确的生产环境中进行性能测试可能是不可能的，但是尝试匹配：

硬件组件

操作系统和设置

系统上使用的其他应用程序

数据库

现在什么有用，就全面的起作用

对于推算出的结果要小心。不要采用小的性能测试结果，并且假设当元素发生变化时，它们将是相同的。而且，它们是在对立面工作的。不要根据负载测试来推断最小的性能和需求。所有的假设都应该通过性能测试来验证。

一个性能测试方案就够了

不是每个性能问题都可以在一个性能测试方案中检测到。但是资源确实限制了可能发生的测试数量。在中间的是一系列性能测试，它们针对的是风险最高的情况，对性能会产生最大的影响。此外，问题可能出现在设计良好之外和设计良好的性能测试。监视生产环境也可以检测性能问题。

测试了每个部分等于测试了全部系统

虽然隔离功能用于性能测试是很重要的，但是单独的组件测试结果并不会添加到整个系统范围的评估中。但是，测试一个系统的所有功能可能是不可行的。一个完全可能的性能测试必须使用可用的资源来设计。但是要注意没有测试过的东西。

是什么对他们有用，对我们有用

如果一组用户确实遇到了复杂的问题或性能问题，那么不要认为这是对所有用户的性能测试。使用性能测试来确保平台和配置如预期的那样工作。

软件开发人员经验丰富，不需要性能测试

缺乏经验并不是造成性能问题的唯一原因。即使是过去开发过免费软件的开发人员也犯了错误。特别是当多个并发用户在系统中时，更多的变量开始发挥作用。

一个完整的加载测试说明了一切

在总负载中运行一个测试来发现所有性能问题是很吸引人的。除了这种测试，它往往会暴露出许多性能问题，以至于很难将注意力集中在单个解决方案上。从较低的负载开始，逐步向上扩展可能看起来是一个不必要的缓慢过程，但是它会产生更容易的结果，从而更有效地排除故障。

测试脚本是实际的用户

确保测试自动化正在以真实用户的方式使用该软件。当性能测试参数被更改时，这一点尤为重要。