成功的性能测试方法的 3 个阶段

网站、Web 应用程序和 API 的成功性能测试需要规划。您可能想开始，选择一个负载测试工具并开始测试，但我们首先花一些时间来建立我们的方法。软件性能测试方法需要许多步骤。让我们将它们分为三个阶段：

第 1 阶段 - 规划、测试配置和验证
第 2 阶段 - 基线测试、扩展测试和复杂案例
第 3 阶段 - 持续的性能测试和自动化

重要的是要记住，性能测试应该是贯穿整个软件开发生命周期的持续测试过程的一部分。这意味着开发人员应该在开发周期的早期开始性能测试以及功能单元测试。他们可以将测试脚本交给 Q​​A 团队，以便在周期后期进行更大规模的测试。在第 3 阶段，正如我们将在下面讨论的，您将自动化负载测试，作为持续集成 (CI) 管道的一部分。所有这些都与将性能测试纳入您的 DevOps 方法一致（请参阅上一篇有关DXone 的文章）。

第 1 阶段 — 规划、测试配置和验证
规划
您正在测试的系统中最重要的部分是什么？关键组件如何影响性能并最终影响用户体验？也许少数 API 端点对系统性能最为关键。例如，应用程序登录过程可能会访问这些端点。在负载测试计划中重点关注这些 API 和端点。

一旦确定了关键组成部分，预期的结果是什么？是否有历史性能测试结果或事件可用于指定目标结果？继续登录示例，也许之前的版本经历了用户尝试新功能的大量流量，并且登录过程的响应时间降低了。您可以使用它来确定下一版本中站点或应用程序的此组件的负载测试的预期响应时间。 

您可能还应该考虑其他业务需求。企业是否实施了任何服务级别协议 (SLA) 或与性能相关的其他要求，例如某些响应时间、可用性等？

规划过程的另一个重要部分涉及目标环境的性质。它是生产环境还是暂存/测试区域？与生产相匹配的测试环境是最好的，但并不总是可用。测试您的生产环境需要额外的规划，以避免对您的业务造成干扰。

测试配置
接下来是性能测试配置。当您开始编写或记录（请参阅下面的浏览器记录）您的第一个性能测试脚本时，需要考虑以下事项：

与上述密切相关的是，用户最常采取的涉及您要测试的关键组件的操作是什么？登录往往是应用程序的重要组成部分之一。如果您正在测试用户旅程，请考虑应用程序用户通常遵循的逻辑顺序。不要试图在第一遍中测试所有内容；首先关注最重要的部分。因此，（暂时）跳过只有少数用户定期使用的功能。
确定应该在目标系统上施加多少负载。如果您正在测试单个组件（例如 API 端点），请考虑每秒请求数 (RPS)。如果通过网站或 Web 应用程序测试用户旅程，例如用户访问多个不同页面或执行多个操作，请考虑并发用户 - 我们将在性能期间使用“虚拟用户”(VU) 模拟这些并发用户测试。
接下来，考虑需要运行的性能测试类型。不同的测试会告诉你不同的事情。以下是在建立测试流程时适用于大多数组织的测试顺序：基线测试、压力测试、负载测试、尖峰测试（如果适用）。（请参阅上一篇文章以了解有关不同类型的性能测试的更多信息）。
根据您的测试场景，您可能需要提供一些数据。再次使用登录示例，一遍又一遍地测试同一用户登录通常只会测试您的系统缓存响应的能力。在这种情况下，您应该导入包含用户名和密码的参数化数据文件，以正确测试登录过程。
现在您已准备好开始手动编写测试脚本，或者使用浏览器记录器（Chrome 扩展）或HAR 文件转换器来创建测试脚本。浏览器记录器方法使您可以轻松创建现实的用户场景。

最好从小处开始，然后扩大测试覆盖范围。编写测试脚本就像为应用程序编写代码一样，将其分解为更小、更易于管理的部分。针对最重要组件的简单测试可以发现很多价值。

k6等负载测试工具支持用 JavaScript 编写的测试脚本的模块化。您编写的用于测试随机用户登录功能的脚本可以成为负载测试库中自己的模块。通过版本控制或其他方式与您的团队共享您的自定义库。

测试验证
当您编写脚本时，在更大规模地运行它们之前，运行验证（冒烟测试）以确保测试按预期工作非常重要。这些测试通常在非常短的时间内使用很少数量的虚拟用户运行。最快的方法是在本地运行它们并将输出输出到标准输出。k6支持本地执行模式。（请参阅此处如何下载和安装 k6。它是开源软件，可在 GitHub 上免费获得）。

第 2 阶段 — 基线测试、扩展测试和复杂案例
现在您已经完成了最困难的部分，即规划阶段，接下来的步骤就变得容易多了！

基线测试
您通常不希望以最大数量的虚拟用户全速运行第一次性能测试。始终进行比较思考至关重要——后续测试结果与这些初始测试相比如何？让您的第一次测试成为基线测试。这是在每秒“理想”并发用户数或请求数下进行的测试，并运行足够长的持续时间以产生明确的稳定结果。

你问什么是理想？一般来说，VU 数量相对较少，代表您的网站或应用程序上易于管理的正常负载水平。如果您不确定，请尝试 1-10 个虚拟用户。您的应用程序在任何给定时间通常有 500 个并发用户吗？您应该运行低于该数字的基线测试。

基线测试为您提供初始性能指标，供您与未来的测试运行进行比较。比较能力将有助于更快地突出性能问题。

扩展您的测试
基线测试完成后，就可以开始运行更大规模的测试来检测系统中的性能问题。利用压力测试通过不同级别的虚拟用户并发来扩展/逐步升级测试，以检测性能下降情况。当您发现这些性能下降并对代码和/或基础设施进行调整时，请多次迭代测试，直到达到令人满意的性能水平。

无论测试用例的复杂程度如何，您在此步骤中执行的测试都将提供最多的信息来提高性能。一旦完成此阶段的测试迭代并通过可接受的测试运行进行验证，您应该转向负载测试模式以验证被测系统是否可以在目标负载级别处理较长的持续时间。

更复杂的测试用例
如果您按照建议开始编写小型、简单的测试用例，那么现在是扩展它们的时候了。您可能需要重复第二阶段以查找更深层次的性能问题，例如，仅在多个组件处于负载状态时才会出现的问题。

如果到目前为止您已经对测试脚本进行了模块化，那么此步骤可能就像将它们组合成“主”测试用例一样简单。

第 3 阶段 — 持续的性能测试和自动化
我们方法的最后一步是长期的。到目前为止，您已经花费了大量的时间和精力来创建测试用例、执行测试、修复各种问题和提高性能。通过将性能测试纳入持续集成 (CI) 管道或仅通过定期手动运行测试，您可以继续获得时间投资的回报。

查看一段时间内和多次测试运行的性能趋势可以帮助您快速了解新版本何时导致性能下降。