十种常见的性能测试概述

Table of Contents

冒烟测试（Smoke Testing）

耐力测试（Endurance Testing）和浸泡测试（Soak Testing）

基准测试（Benchmark Testing）/ 性能回归测试（Performance Regression Testing）

负载测试（Load Testing）

断点测试（Breakpoint Testing）

尖峰测试（Spike Testing）

可扩展性测试（Scalability Testing）

容量测试（Capacity Testing）

瓶颈测试（Bottleneck Testing）

压力测试（Stress Testing）

总结

---

经常会提到的各种测试包括负载测试、容量测试、压力测试、断点测试、瓶颈测试、尖峰测试、耐力测试、基准测试、可扩展性测试和冒烟测试这 10 种。

 

冒烟测试（Smoke Testing）

冒烟测试是开发人员在开发环境里执行的简单测试，以确定新的程序代码不出故障。冒烟测试目的是确认系统和程序基本功能正常。冒烟测试的执行者往往就是开发人员，但有时也让运维人员参与。

耐力测试（Endurance Testing）和浸泡测试（Soak Testing）

耐力测试（或者耐久测试）有时也叫浸泡测试，是一种非功能性测试。耐力测试是长时间测试具有预期负载量的系统，以验证系统的行为是否正常。

举一个例子，假设系统设计工作时间是 3 小时；我们可以对这一系统进行超过 3 小时的测试，比如持续 6 小时的耐力测试，以检查系统的耐久性。执行耐力测试最常见的用例是暴露某些不易重现的问题，如内存问题、系统故障或其他随机问题。这里的偏重点是测试时间，因为有些程序和系统的问题只有在长期运行后才暴露出来。一个最明显的例子就是内存泄漏。一个程序或许短时间内运行正常，但是如果有内存泄漏，只要运行时间足够，就一定会暴露出这个问题。

 

基准测试（Benchmark Testing）/ 性能回归测试（Performance Regression Testing）

基准测试或者性能回归测试是着重“前后”对比的测试。这种测试往往是开发过程的一部分，一般不需要具体的性能要求。代码的演化过程中经常需要确保新的代码不会对整个模块或系统的性能产生任何不好的影响。

最简单的方法是对代码修改前后进行基准测试，并比较前后的性能结果。执行基准测试的重点是保证前后测试环境的一致，比如负载流量的特征和大小。

负载测试（Load Testing）

负载测试用于验证被测试系统或者程序是否可以处理预期的负载流量，并验证正常和峰值负载条件下的系统和程序行为。这里的负载可以是真正的客户请求，也可以是仿真的人工产生的负载。我认为负载测试的定义有时太广泛和模糊，很多其他测试都可以看作是负载测试的一种，比如马上就要讲到的容量测试，其实就是一种负载测试。

 

断点测试（Breakpoint Testing）

断点测试类似于压力测试或者容量测试。这种测试的过程是随着时间的推移而增大流量负载，同时监视系统的预定故障条件。断点测试也可以用来确定系统将达到其所需规范或服务水平协议的最大容量，并且自动采取措施来纠正或者缓解。比如云计算环境中，我们可以设置某种性能断点，用它们来驱动某种扩展和伸缩策略。比如一种性能断点可以是根据用户的访问延迟。如果延迟性能测量的结果是已经超过预定的阈值，就自动进行系统容量调整，比如增加云计算的服务器。反之，系统容量也可以根据断点的规则来减少，以节省成本。如下图所示。

 

 

尖峰测试（Spike Testing）

尖峰测试用于确定系统在负载（比如用户请求数）突然变化时的系统行为。这种测试是通过突然增加或减少由用户产生的负载来观察系统的行为。测试的目标是确定性能在这样的场景下是否会受损，系统是否会失败，或者是否能够处理负载的显著变化。尖峰测试的核心是负载变化的突然性，所以也算是一种压力测试。

可扩展性测试（Scalability Testing）

可扩展性（或者叫可伸缩性）测试用于确定一个程序和系统的非功能性特征能不能在变化的环境里合理扩展。这里的环境变化包括系统环境的变化、负载量的大小、请求的多样性、数据量的大小等。在系统环境变化时，同步的测量和观察各种性能指标，并进行数据的分析，从而确定在各种环境下被测试系统的可扩展性。如下图所示。这个测试的主要目的是了解系统在什么样的环境中，以及什么样的变化会导致系统不能扩展。发现这些环境后，可以进一步有针对性的分析和加强。

 

容量测试（Capacity Testing）

容量测试（或者叫体积测试，Volume Testing）是用于确定一个单位容量能够支持的最大负载。比如一个程序运行在某种服务器上，我们有时需要知道每台服务器能够支持的最大负载（例如客户数），从而决定需要部署多少台服务器才能满足预定的总负载要求。容量测试一般是会不断增大负载，并且不断地测量各种性能指标。在性能目标变得不可接受之前，系统和程序可以成功处理的负载大小，就是单位容量可以承担的负载。为了尽量让得到的结果匹配实际生产环境，采用的负载流量最好是真正的生产环境的请求和数据。正常生产环境中的流量和数据或许不够大到让一台服务器超载，因此我们需要解决这个问题。很多公司的解决方案是把其他服务器上的请求重定向到某一台被测试服务器，从而让这台服务器适度超载。这种机制我后面会用一讲专门讨论。容量测试是确保系统稳定的重要一环。只有进行彻底的容量测试，并有相对应问题的解决方案，才可以使我们能够避免将来出现潜在的超载问题，例如增加的用户数或增加的数据量。如下图所示，容量测试至少包含三个部分：可调节的流量负载、性能的测量、可以接受的性能指标。这三个部分一起就可以决定单位容量（比如一台服务器）的最大负载容量。这个数据可以帮助我们做各种决策，包括预估系统能负担的总负载；或者根据预期负载来决定部署多少台服务器。

 

 

 

 

瓶颈测试（Bottleneck Testing）

瓶颈测试其实可以看作一种特殊的压力测试。它的目的是找到被测试系统和程序的最制约的资源类型（比如 CPU 或者存储）。瓶颈测试并不局限于只找到最制约的一个瓶颈，它也可以同时找多个性能瓶颈。找多个性能瓶颈的的意义主要有两点：如果最制约的瓶颈资源解决了，那么其他制约资源类型就自动会成为下一个瓶颈，所以需要未雨绸缪。系统设计时可以考虑在几个资源之间做些平衡，比如用内存空间来换取 CPU 资源的使用。

压力测试（Stress Testing）

压力测试也是一种负载测试，不过它偏重的是在负载增加到超过系统设计预期后观察和验证系统的行为。当我们通过增加负载，对系统施压到超出设计期望的负载时，就能发现哪个模块或组件首先因超载而失败。这样我们就可以通过提升失败组件的性能来设计出更健壮、性能更优的系统。相对于容量测试，压力测试的目的是为了暴露系统的问题，因此采用的负载不一定是真正的生产数据和客户请求。

 

 

总结