DORA审计员对您的负载测试的期望

根据DORA，负载和性能测试证据是弹性审查的一部分。

对于需要证明其系统能在高负载下稳定运行的欧盟金融实体的合规和工程团队。

欧盟数字操作弹性法案（DORA）自2025年1月17日起适用于金融实体。它为银行、保险公司、投资公司及其关键ICT供应商设定了一套规则，以确保数字服务在中断时仍能持续运行。数字操作弹性测试是其五大支柱之一（同时包括ICT风险管理、事件报告、第三方风险以及信息共享），而该支柱直接涵盖了您的负载和性能测试。

首先需要澄清一点，因为这个缩写被赋予了多个含义。本文讨论的是欧盟的监管法规，而非DevOps中的“DORA指标”（部署频率、交付周期等）。两者完全不同。

该法规第25条列出了弹性计划应采用的测试方法。性能测试和端到端测试位列清单，与漏洞评估和渗透测试并列。因此，当审查员审查您的弹性测试时，负载和压力测试的证据是合理的考核内容。

线上对DORA的大多数报道聚焦于以威胁为导向的渗透测试。本文覆盖了较为低调的义务：证明您的系统在高负载下依旧响应迅速，生成审计员实际会查看的证据，并使用为此设计的工具。LoadView 是一款基于云、真实浏览器的负载测试平台，以下内容将每一项DORA合规审查员检查清单与LoadView的对应能力一一对应说明。

本指南内容

1. 负载测试在DORA中的位置
2. DORA审查员期待的审计证据
3. LoadView如何支持DORA操作弹性测试
4. 为何仅协议层负载数据在审计中站不住脚
5. 如何生成符合DORA的测试证据
6. 总结
7. 常见问题解答

负载测试在DORA中的位置

DORA基于风险，而非工具明确规定。它没有说“每季度运行一次500用户负载测试”，而是说要定期测试支持关键或重要功能的ICT系统，并根据结果采取行动。

两条条款对性能工作最为关键：

• 第24条设定了总体测试原则。金融实体应至少每年对支持关键或重要功能的ICT系统和应用进行基于风险的测试。
• 第25条列出了程序可采用的方法。性能测试和端到端测试被明确提及。

对于交易平台、支付API或在线银行门户，”抵御中断”包括因负载引起的中断：市场开盘激增、发薪日峰值、一场促销将结账流量提高三倍等。如果服务在高负载下变慢或崩溃，就是操作弹性存在缺口。DORA期望您在上线前发现这些问题，这就是金融服务负载测试在此计划中重要性的体现。

这里的关切既是实务层面的，也是程序层面的。监管机构可以要求实体修复发现的弹性缺口，因此审查中发现未测试的关键系统往往会造成监管方按照其时间表进行的临时工作，而非您的计划内工作。

DORA审查员期待的审计证据

审查员依据证据而非意图行事。在审查您的弹性测试时，预计他们会查验以下证据：[等]

第一条是团队最容易失分的地方。没有已记录的性能SLA，负载测试就没有通过/失败标准，审计员看到的只是没有标准的图表。首先写下目标：每个关键事务的P95响应时间、错误率上限，以及每个系统必须处理的峰值负载。

第二条和第三条关注时机和重要性。每次生产发布前进行负载测试，表明在客户使用之前进行了流量检查，将该检查纳入发布管道可保持一致性。压力测试比负载测试更进一层，推动负载超过预计峰值直到系统崩溃，这样您知道系统的极限，而不会在市场开盘日遭遇意外。

第四条是审查员最常处理的凭证。包含响应时间百分位、错误率和产生它们的负载曲线的报告是核心证据，且需标注日期和版本，以对应具体发布版本。

第五条将测试结果与预测连接。容量规划文档说明了上次测试测得的余量及增长何时会用完。第六和第七条将实际项目与纸面项目区分开。测试发现瓶颈时，审查员希望看到后续行动，因此LoadView报告中定位性能瓶颈的功能让行动具体：哪一层变慢了？做了什么改变？复测结果如何？

LoadView如何支持DORA操作弹性测试

上述证据清单的每一行都直接对应LoadView的某项功能。下表将审查员所需的证据与LoadView产生该证据的功能配对，使合规要求与工具功能一一对应。

LoadView在这其中完成大部分工作的两项细节：首先测试在真实浏览器中运行，使报告中的数据是真实客户会观察到的响应时间，这保证了报告作为弹性证据的可信度。其次，整个流程通过用户旅程脚本化而不是裸请求集合，因此DORA第25条的端到端测试覆盖登录、交易和确认，仿真真实会话。接下来两节将分别介绍这两点。

为何仅协议层负载数据在审计中站不住脚

仅发起原始HTTP请求的负载测试或许能报告较大吞吐量，但这表示的是服务器的处理能力，而非客户的体验。它跳过了JavaScript执行、第三方欺诈检查、单点登录重定向及渲染确认屏幕等步骤。

审查员关注客户在负载下能否完成交易，需证据展现客户体验，而非仅源服务器请求速率。真实浏览器负载测试使用Chromium实例运行测试，因此报告中的响应时间即客户实际见到的时间。通俗来说，测试加载页面的方式与客户浏览器相同——执行脚本、重定向和渲染，而非简单请求服务器。

对于银行或支付服务商，这就是“API响应200毫秒”与“登录到确认流程耗时9秒因欺诈评分调用排队”之间的差异。后者会降低服务质量，也是弹性审查关注的内容，这也是为何针对真实用户流程的交易并发测试比协议层吞吐量图更有说服力的原因。

没有执行页面的工具报告“每秒100,000请求”是在测量HTTP吞吐量，而非客户在登录界面上的体验。审计客户面对的弹性，需要看到后者。

协议层测试测量的是服务器；LoadView的真实浏览器测试测量客户完成的登录到确认流程。

如何生成符合DORA的测试证据

您不需要新类别的工具来满足DORA这一支柱。您需要的测试对应证据清单，并生成可交给审计员的记录。LoadView的操作步骤如下：

1. 为每个关键功能编写性能需求。为每笔交易设置响应时间百分位和错误率上限，获得批准，将其录入测试的通过/失败阈值，让结果自动评判。
2. 以真实用户流程记录测试。用EveryStep录制器捕获实际旅程（登录、交易、确认），点击录制在真实浏览器中，然后用Web应用负载测试重放，而非只是重放裸HTTP调用。
3. 测试到预期峰值，再超过峰值。配置负载曲线类型保持虚拟用户在预测峰值，随后使用渐进曲线推动超过峰值进行压力测试，从而得到“能否承载当天流量”和“系统哪儿崩溃”的答案。
4. 从您服务的区域注入负载。如果客户分布于欧盟，使用30多个地理分布负载注入区进行测试，确保性能测量真实反映用户所在地，而非仅在某个数据中心。
5. 保存报告。导出性能测试报告，包含百分位、错误率、负载曲线、瀑布图及时间戳，并归档入发布记录中。审查员阅读的正是该文件。
6. 定期及变更后复测。至少每年对关键功能测试一次，每次发布触及关键路径后测试一次，当交易量增长接近上次测试测得的容量上限时亦测试。安排测试并接入CI/CD管道实现自动化，而非依靠日历提醒。

采取这套流程，证据自然产生，作为您本就想执行测试的副产品。LoadView是完全云托管，无需搭建负载生成基础设施或对审计员进行辩护，且生成的证据完全符合DORA审查员的要求，且顺序吻合。

DORA的范围还涵盖您依赖的关键ICT第三方供应商。若支付网关、身份服务或数据API位于关键路径，它们的负载表现也是您弹性考量的一部分，因此针对这些端点的API负载测试能保持相同的证据记录，覆盖您未直接控制的服务。

查看LoadView如何产出DORA审查员要求的证据。预约LoadView演示，为您的峰值流量设计测试，并导出审计员所需的报告。

总结

DORA并没有给您直接的负载测试清单，但其弹性测试支柱和第25条方法使性能和负载测试成为审查员可检查的内容。关键系统是指支持关键或重要功能的系统，标准是它们在高负载下能否持续为客户提供服务。

提供审查员期待的七项证据，基于真实浏览器的结果而非协议层吞吐量，并随着流量增长周期性复测。LoadView设计用于从单一脚本测试生成所有证据，使性能测试弹性审查转变为仅仅交付您已保存的记录。

常见问题解答