性能测试是软件测试的一种形式，集中于系统如何在特定的负载下运行系统执行。这不是关于发现软件bug或者缺陷。性能测试是根据基准和标准来应对。性能测试需要给开发人员提供诊断信息，以便他们清除问题。
软件系统测试的各种类型
为了理解软件如何将在用户系统运行，有几种不同类型的性能测试在软件测试期间可以应用。这是非功能测试，目的在于确定系统的准备情况。（功能测试集中于软件的个别功能。）
负载测试
负载测试检测系统随着工作负载增加时的性能。工作负载可能意味着并发用户或事务。当工作负载增加，监控系统来检测它的响应时间和系统的持久能力。该工作负载在正常工作条件的参数范围内。
压力测试
不像负载测试，压力测试——也叫做疲劳测试——意味着检测系统在正常工作条件参数范围外的性能。可以给这个软件更多的用户或事务处理。压力测试的目标是检测软件的稳定性。软件会在何种程度故障，还有软件如何从失败中恢复。
尖峰冲击测试
尖峰冲击测试是压力测试的一种，它评估软件负载在快速和反复大幅度增长时的性能。在短时间内，工作负载超出了正常的预期。
耐力测试
耐力测试——也叫做浸泡测试——是评估软件性能如何在长时间执行正常工作的。耐力测试的目标是检查系统问题，例如内存泄露。（内存泄露发生在系统无法释放被丢弃的内存的时候。内存泄漏会损害系统性能，或者导致系统失败。）
可扩展性测试
可扩展性测试是用来确定软件是否有效的处理日渐增长的工作负载。这可以通过当监控系统性能时，增加的用户负载或数据量来确定。并且当CPU和内存等资源变更的时候，工作负载可能保持在相同的水平。
容量测试
容量测试确定软件在大量、预期数据量下的执行效率。它也被称为洪水测试，因为这个测试用数据淹没了系统。
在性能测试种最常见的问题
在软件性能测试期间，开发人员会寻找性能的症状和问题。速度问题——例如缓慢的响应和长时间的加载时间——经常会被观察和处理。但是还能看到有一些其他的性能问题：
- 瓶颈效应——发生在当数据流被中断或者停止的时候，因为没有足够的能力处理工作负载。
- 较差的可扩展性——如果软件无法处理所需数量的并发任务，结果可能导致延误，可能增加错误，或者发生其他无法预料的行为，这影响到：
○ 磁盘使用情况
○ CPU使用情况
○ 内存卸扣
○ 操作系统受限
○ 糟糕的网络配置
- 软件配置问题——通常设置不是设置在一个足够的级别上来处理工作负载。
- 硬件资源不足——性能测试可能暴露出物理内存限制或低效率的CPU。
性能测试7步
同样也被曾作测试台，测试环境是设置软件、硬件和网络来执行性能测试的地方。为了使用性能测试测试环境，开发人员可以用下面七步：
- 确定测试环境
确定硬件、软件、网络配置和可用的工具，让测试团队设计测试和尽早确定性能测试挑战。性能测试环境选择包括：
○ 有少量低规格服务器的生产系统子集。
○ 有少量相同规范服务器的生产系统的子集。
○ 生产系统的复制品。
○ 实际生产系统。
- 确定性能标准
除了确定性能参数，例如响应时间，吞吐量和限制之外，确定性能测试的成功标准是什么。
- 计划和设计性能测试
确定性能测试方案，考虑账户用户的可变性、测试数据和目标参数。这将创建一到两个模型。
- 配置测试环境
准备测试环境的元素和监控资源所需的设备。
- 执行测试设计
开发测试。
- 执行测试
除了运行性能测试之外，监控和抓取生产数据。
- 分析，报告，再测试
分析数据，分享所发现的。使用同样的参数和不同的参数再次运行性能测试。
性能测试参数测量了什么
参数需要理解性能测试的质量和效果。除非有测量，否则无法提高。现在解释下2种定义：
- 测量——收集的数据，例如它响应一个请求所花的秒数。
- 参数——使用数据的计算结果，决定结果的质量，例如平均响应时间（总响应时间/请求）
有许多方法可以测量速度、可扩展性和稳定性，但是每轮性能测试无法使用全部方法。在性能测试中所用的参数，下面的是经常用到的：
响应时间
发送一个请求和获得一个响应的总时间。
等待时间
这也称为平均延迟，这告诉开发人员在发送请求后接收第一个字节需要多长时间。
平均加载时间
从用户的角度来看，交付每个请求所需的平均时间是质量的主要指标。
峰值响应时间
这是完成请求所需的最长时间的测量。峰值响应时间明显长于平均时间，这可能表明出现问题的异常情况。
错误率
这是一个与所有请求相比，计算产生错误的请求的百分比。这些错误通常发生在负载超过容量的时候。
并发用户
这是最常见的负载测量——在任意时刻有多少活跃用户，也称为负载大小。
每秒请求
多少请求被处理。
事务通过/失败
对成功或不成功请求的总数的测量。
吞吐量
以千字节每秒的速度度量，吞吐量显示测试期间使用的带宽量。
CPU利用率
CPU需要多少时间来处理请求。
内存利用率
需要多少内存来处理请求。
性能测试最佳实践
也许性能测试最重要的小建议就是早测试，常测试。一个单独的测试将无法告诉开发人员他们所需知道的全部。成功的性能测试是许多的反复测试和小测试组成的。
- 在开发中尽可能的早测试。当项目结束时，不要等待并急于进行性能测试。
- 性能测试不仅仅针对已完成的项目。测试单个单元或模块也是有价值的。
- 进行多项性能测试，以确保一致的发现和确定参数的平均值。
- 应用常常涉及多个系统，例如数据库、服务器和服务。单独测试各个单元，而且一起测试。
除了反复测试，通过一系列性能测试的最佳实践，性能测试将会更加成功。
- 让开发人员、IT人员和测试人员一起参与创建一个性能测试环境。
- 记住真正的用户将使用正在进行性能测试的这个软件。确定结果将如何影响用户，而不仅仅是测试环境服务器。
- 超越性能测试参数。通过计划一个测试环境来开发一个模型，这个测试环境尽可能多地考虑用户活动。
- 基线测量为确定成功或失败提供了一个起点。
- 性能测试最好在尽可能接近生产系统的测试环境中进行。
- 将性能测试环境与用于质量保证测试的环境隔离开来。
- 任何性能测试工具都不需要做任何事情。有限的资源可能会进一步限制选择。为了更适合研究性能测试工具。
- 尽可能保持测试环境的一致性。
- 计算出的平均值将提供可执行的参数。跟踪异常值也有价值。这些极端的测量可能暴露出可能的失败。
- 当准备报告分享性能测试结果时，请考虑听众。此外，还包括报告中的任何系统和软件更改。
|
