什么是可扩展性测试？通过示例学习
托马斯·汉密尔顿
什么是可扩展性测试？
可扩展性测试 可扩展性测试是一种非功能性测试方法，用于衡量系统或网络在用户请求数量增加或减少时的性能。可扩展性测试的目的是确保系统能够应对预期的用户流量、数据量和事务频率的增长。它测试系统满足不断增长的需求的能力。
可扩展性测试是以下类型的一个子类型： 性能测试因此，它主要关注应用程序部署到更大系统或在过载情况下运行的行为。 软件工程可扩展性测试衡量应用程序停止扩展的点，并找出其背后的原因。
为什么要进行可扩展性测试？
容量问题很少在功能测试期间出现。它们通常会在一年中最繁忙的交易日、营销活动上线时，或者当一个悄然增长了两年的数据集最终导致所有查询都变慢时才会显现出来。可扩展性测试首先在受控环境中暴露这些限制。具体来说，它可以帮助您：
- 确定应用程序如何随着工作负载的增加而扩展，以及该曲线何时趋于平缓。
- 在响应时间变得无法接受之前，确定 Web 应用程序的并发用户限制。
- 确定客户端性能下降情况以及负载下的最终用户体验，例如屏幕渲染缓慢。
- 确定服务器端的健壮性和性能下降情况，包括 CPU 饱和度、内存泄漏和连接池耗尽。
这种关系最容易用曲线来表示：吞吐量随着负载的增加而增加，直到资源饱和，之后额外的用户只会延长队列。
可扩展性测试的类型
可扩展性并非单一属性，因此测试计划通常涵盖多个维度。以下四种类型是大多数团队会衡量的，其中前两种决定了测试环境本身的架构。
| 类型 | 什么是规模化？ | 测试结果证明了什么？ |
|---|---|---|
| 垂直可扩展性 （扩大规模） | 向单个服务器添加 CPU、内存或存储空间 | 一台升级后的机器能承受多少额外负载，以及单节点负载上限在哪里？ |
| 水平可扩展性 （横向扩展） | 负载均衡器后面的其他服务器、容器或节点 | 吞吐量是与新增节点数量大致成正比增长，还是受共享资源限制？ |
| 功能可扩展性 | 新功能、模块或服务 | 新增功能能否在不降低现有交易质量的前提下被吸收 |
| 管理可扩展性 | 要管理的用户、租户、团队或环境 | 随着组织的发展，入职流程、权限管理和监控是否仍然有效 |
垂直扩展比较简单，因为架构很少变化，但单台机器的性能始终存在上限。水平扩展可以消除这种上限并提高容错能力，但代价是网络延迟、数据一致性和协调开销都会增加——所有这些都必须通过测试来测量，而不是假设。
可扩展性测试中需要测试什么
可扩展性取决于衡量指标，而非展示次数。在每个加载步骤中记录以下属性，以便观察趋势，而不仅仅是最终数值。
| 属性 | 它告诉你什么 |
|---|---|
| 响应时间 | 用户请求到系统响应之间的时间间隔；随着并发量的增加，该时间间隔应保持稳定。 |
| 屏幕转换 | 在负载情况下，一个页面或视图切换到下一个页面或视图的速度有多快？ |
| 生产能力 | 单位时间内处理的请求量；达到平台期即表示可扩展性极限。 |
| 时间测量 | 会话时间、重启时间、打印时间、事务处理时间和任务执行时间 |
| 用户数量表现 | 随着并发用户数的逐步增加，各项指标如何变化 |
| 请求费率 | 每秒请求数、每秒交易数和每秒点击数 |
| 网络使用 | 层级间带宽消耗和数据包延迟 |
| CPU 和内存使用情况 | 每次交易的资源成本；持续攀升的数字通常表明存在泄漏。 |
| Web服务器计数器 | 每秒请求和响应次数、队列深度和被拒绝的连接数 |
| 负载下的性能 | 所有指标在峰值时同时读取后的综合行为 |
可扩展性测试的测试策略
可扩展性测试的测试策略会根据被测应用程序的类型而有所不同。如果一个应用程序访问一个 数据库测试参数将包括数据库大小与用户数量的关系等等。
可扩展性测试的先决条件
- 负载分配能力 — 检查负载测试工具是否能够从多台机器产生负载，并从中央点进行控制。
- 运行系统 — 检查一下 操作系统 负载生成代理和负载测试主程序在以下环境下运行。
- 处理器 — 检查虚拟用户代理和负载测试主节点需要哪种类型的 CPU。
- 内存 — 检查虚拟用户代理和负载测试主程序需要多少内存。
- 测试环境 — 检查一下 测试环境 与生产过程的相似度足够高，结果可以转移。
如何进行可扩展性测试
- 定义一个可重复的流程，用于在整个应用程序生命周期中执行可扩展性测试。
- 确定可扩展性的标准
- 列出运行负载测试所需的软件工具
- 设置测试环境并配置执行可扩展性测试所需的硬件
- 规划测试场景以及可扩展性测试。
- 创建并验证虚拟用户脚本
- 创建并验证负载测试场景
- 执行测试
- 评估结果
- 生成所需报告
可扩展性测试计划
在实际编写测试用例之前，请先制定详细的测试计划。这是确保测试符合应用程序需求的重要步骤。
以下是创建明确定义的属性 测试计划 用于可扩展性测试。
- 脚本步骤测试脚本应包含详细的步骤，以确定用户将执行的确切操作。
- 运行时数据测试计划应确定与应用程序交互所需的任何运行时数据。
- 数据驱动测试如果脚本需要在运行时使用不同的数据，那么你需要了解所有需要这些数据的字段。
可扩展性测试示例
假设一家网店预计在季节性促销期间会有 2,000 名用户同时在线购物。团队首先制定了一个及格标准：95% 的用户必须在三秒内完成结账交易，且错误率低于 1%。
测试随后在 250、500、1,000、1,500 和 2,000 个虚拟用户下运行相同的浏览-搜索-购物车-结账脚本。在 1,000 个用户之前，响应时间保持在接近 2 秒的水平；在 1,500 个用户时，响应时间上升到 2.8 秒；在 2,000 个用户时，响应时间达到 9 秒，此时数据库 CPU 使用率高达 98%。因此，可扩展性极限约为 1,500 个用户，瓶颈在于数据库层，而不是团队计划添加的应用服务器。
可扩展性测试工具
可扩展性测试需要一款能够同时从多台机器生成负载并集中报告结果的工具。工具的选择通常取决于团队的主要编程语言和被测协议。
| 工具 | 脚本 | 最适合 |
|---|---|---|
| Apache JMeter | GUI 加 XML 测试计划， Java 基于 | 广泛的协议覆盖范围，包括 JDBC、JMS、LDAP 和 SOAP |
| Grafana k6 | Java脚本或 TypeScript | 将 API 和微服务测试集成到 CI/CD 流水线中 |
| 加特林 | JavaKotlin 或 Scala DSL | 每个注入器拥有大量虚拟用户，并提供详细的 HTML 报告。 |
| 刺槐 | 朴素 Python | Python 需要将客户端扩展到 HTTP 以外的团队 |
| 加载程序 | VuGen中记录的C类脚本 | 拥有传统应用程序和打包应用程序的大型企业环境 |
云端托管的运行器，例如 BlazeMeterLoadView 和 Gatling Enterprise 基于上述几种引擎构建，当测试需要数万虚拟用户或来自多个地理区域的流量时，值得考虑。有关该类别的更广泛调查，请参阅指南。 性能测试工具.
可扩展性测试中的挑战和最佳实践
最令人失望的可扩展性结果 trac回到测试环境而不是应用程序。这些问题总是反复出现，而养成良好的习惯可以避免这些问题。
共同的挑战
- 环境过小 — 测试平台只有生产环境一半的内存，却报告了一个在生产环境中不存在的瓶颈。
- 不切实际的工作负载模型 — 没有思考时间或数据变化的脚本会命中真实用户会错过的缓存。
- 结果嘈杂 — 自动扩展、垃圾回收和共享云硬件导致两次相同的运行出现差异。
- 薄可观测性 — 如果没有服务器端指标，速度慢只能说明某些地方出了问题，但无法确定具体是什么问题。
- Cost — 产生非常高的并发性需要自己的负载生成器集群，这很容易导致预算不足。
最佳实践
- 在第一次运行之前，商定通过标准，例如响应时间百分位数和错误率上限。
- 按计划逐步增加负载，并保持每个阶段足够长的时间，以使系统稳定下来。
- 对每个虚拟用户使用不同的测试数据，以避免缓存导致结果失真。
- 除了客户端数据外，还要收集应用程序、数据库和基础设施指标。
- 将测试脚本存储在版本控制系统中，并在每次构建时运行简短的可扩展性检查，然后在发布前进行完整运行。
- 应该比较不同版本之间的趋势，而不是孤立地评判单个报告。
可扩展性测试与负载测试
两者经常被混淆，因为它们都施加负载。区别在于它们各自回答的问题：可扩展性测试询问系统可以增长到什么程度，而 负载测试 询问它是否能够应对预期的负载。
| 基地 | 可扩展性测试 | 负载测试 |
|---|---|---|
| 专注 | 它关注的是，当系统规模或容量发生变化以满足不断增长的需求时，您的网站、软件、硬件和应用程序的性能。 | 负载测试侧重于在高负载下测试应用程序，以确定系统响应时间在何时出现故障。 |
| 负载模式 | 负载分阶段增加，并且可以在步骤之间添加资源。 | 负载在预期峰值水平保持固定持续时间 |
| 问题已解答 | 这个系统能发展到什么程度？又有哪些因素限制了它的发展？ | 该系统目前是否达到了既定目标？ |
| 典型输出 | 可扩展性限制、瓶颈和容量规划 | 响应时间和吞吐量目标是否合格 |
两者都位于下方 非功能性测试 旁边撑着伞 压力测试, 尖峰测试, 耐久性测试 和 容量测试成熟的性能策略通常会针对相同的脚本运行多个这样的测试。
