性能测试类型

1). 负载测试

测试应用程序在正常和峰值使用时的性能。检查应用程序对用户请求的响应，以及在不同用户负载下在可接受的容许范围内持续响应的能力。

主要的考虑因素有：

• 应用程序的最大负载是多少？
• 在应用程序开始出现意外前，应用程序能够承受的最大负载是多少？
• 在系统变慢或出现崩溃之前，数据库能够处理多少数据？
• 是否有任何网络相关的问题需要解决？

2). 压力测试

该测试还提供了系统可以承受的最大负荷范围。

压力测试采用渐进式方法，即逐渐增加负载。测试从应用程序已经测试过的负载开始。然后慢慢地增加更多的负载来给系统施加压力, 服务器对请求没有响应的点被认为是断点。

要解决以下问题。

• 系统在崩溃前能承受的最大负荷是多少？
• 系统是如何崩溃的？
• 系统一旦崩溃，是否能够恢复？
• 系统在处理意外负载时，有多少种方式会发生崩溃，哪些是薄弱节点？

3). 体积(Volume)测试

验证应用程序的性能是否受到应用程序所处理的数据量的影响。为了执行批量测试，需要将大量的数据输入到数据库中。该测试可以是增量测试或稳定测试。在增量测试中，数据量是逐渐增加的。

一般来说，随着应用的使用，数据库的规模会越来越大，这就需要对应用进行重度数据库的测试。

4). 容量测试

容量测试主要解决以下问题。

• 应用程序是否能够支持未来的负载？
• 环境是否能够承受即将增加的负载？
• 为了使环境有足够的能力，需要哪些额外的资源？

容量测试用于确定一个给定的网络应用程序能够支持多少用户和/或事务，并且仍然能够满足性能要求。在这个测试过程中，处理器容量、网络带宽、内存使用量、磁盘容量等资源都会被考虑并改变，以达到目标。

4). 可靠性/恢复性测试

可靠性测试或恢复测试--是验证应用程序在发生故障或异常行为后是否能够恢复到正常状态，以及需要多长时间才能恢复到正常状态（换句话说时间估算）。

如果一个在线交易网站发生了故障，用户在一天中的某个时间点(高峰期)无法买入/卖出股票，但在一两个小时后就能买入/卖出，我们就可以说这个应用是可靠的，或者说从异常行为中恢复过来了。

性能测试流程

1. 需求分析/收集

性能团队与客户互动，以确定和收集技术和业务需求。这包括获取应用程序的架构、技术、使用的数据库、目标用户、功能、应用程序用途、测试要求、硬件和软件要求等信息。

2. POC/工具选择

可用工具的列表取决于工具的成本、应用程序使用的协议、用于构建应用程序的技术、我们模拟测试的用户数量等。在POC期间，为确定的关键功能创建脚本，并与10-15个虚拟用户一起执行。

3. 性能测试计划和设计

进行测试规划和设计。

测试规划包括性能测试如何进行的信息--测试环境、工作负载、硬件等。

4. 性能测试开发

5. 性能测试建模

性能负载模型是为测试执行而创建的。这一步的主要目的是验证给定的性能指标(由客户提供)是否在测试中实现。创建负载模型有不同的方法。大多数情况下使用 "Little's Law"。

6. 测试执行

场景是根据Controller或Performance Center中的Load Model设计的，但初始测试并没有与Load Model中的最大用户一起执行。

测试执行是逐步进行的。例如，如果最大用户数是100个，则先以10个、25个、50个用户等场景运行，最终转为100个用户。

7. 测试结果分析

测试结果是性能测试人员最重要的成果。这是我们可以证明性能测试工作所能提供的投资回报率(ROI)和生产力的地方。

一些有助于结果分析过程的最佳实践。

• 给每个测试结果取一个独特而有意义的名字--这有助于理解测试的目的。
• 在测试结果摘要中包含以下信息
• 失败的原因
• 与上一次测试相比，应用程序性能的变化。
• 从应用构建或测试环境的角度出发，在测试中做出的改变。
• 在每次测试运行后做结果总结是很好的做法，这样就不会每次参考测试结果时都要编制分析结果。
• 一般需要多次测试运行才能得出正确的结论。
• 结果总结中最好有以下几点。 测试的目的 虚拟用户数 情景摘要 测试时间 吞吐量 图形 图表比较 响应时间 错误 建议

8. 报告

测试结果应该简化，使结论更清晰，不需要任何推导。开发团队需要更多关于分析、结果比较的信息，以及如何获得结果的细节。

测试报告如果能简明扼要、描述性强、切中要害，就可以认为是好报告。

性能测试的最佳实践

• 规划

尽量确定最常见的工作流程，即必须测试的业务场景。如果应用程序是现有的，那么检查服务器日志，了解最经常访问的场景。如果应用程序是新的，则与项目管理团队讨论以了解主要的业务流程。

计划负载测试的方式，你要覆盖广泛的工作流程，如轻度使用、中度使用和峰值负载。

你需要执行很多周期的Load Test，所以尽量创建一个框架，这样你就可以反复使用相同的脚本。另外，尝试对脚本进行备份。

尝试分析一个测试要运行多长时间，是1小时？8个小时？一天还是一周？通常情况下，长时间的测试会发现很多重大的缺陷，比如操作系统的bug、内存泄露等。

如果你的组织正在使用任何APM(应用程序监控工具)，那么你可以在测试运行期间加入它，这样你就可以很容易地发现性能问题，并更容易地找出根本原因。

• 开发

在开发脚本即录制的时候，尽量根据计划中提到的业务流名称，给出一个更有意义的事务名称。

不要录入任何第三方应用。

压力打到应用程序的后端，而不仅仅是缓存服务器。

• 执行

确保在类似生产的环境中运行测试，包括SSL、负载均衡器和防火墙等因素。这对于模拟系统的真实负载是必要的。

尽量创建一个非常现实的工作负载，如果是现有的应用程序，你可以通过检查服务器日志来获得，如果是新的应用程序，你需要从业务团队获得这些信息。

千万不要用生产规模一半的环境来运行测试来得出结论，总是建议在与生产环境相同的环境中进行测试。
在执行长期运行的测试时，尽量每隔一段时间就观察运行情况，以确保测试顺利进行。

• 分析
  试着分析应用程序，先增加几个重要的计数器，当发现瓶颈时，再试着增加与瓶颈有关的计数器。这样一来，将有助于更容易地找到问题所在。

一个应用程序失败的原因有很多，比如它可能无法响应请求、响应错误代码、你的验证逻辑失败或者响应速度太慢。所以，在得出结论之前，尽量研究一下所有这些问题。