O Que Os Auditores DORA Esperam Do Seu Teste De Carga

Sob a DORA, evidências de testes de carga e desempenho fazem parte da revisão de resiliência.

Para equipes de conformidade e engenharia em entidades financeiras da UE que precisam mostrar que seus sistemas resistem sob volume.

A Lei de Resiliência Operacional Digital da UE (DORA) tem se aplicado a entidades financeiras desde 17 de janeiro de 2025. Ela estabelece um único conjunto de regras para como bancos, seguradoras, firmas de investimento e seus provedores críticos de TIC mantêm os serviços digitais funcionando durante interrupções. O teste de resiliência operacional digital é um dos seus cinco pilares (juntamente com gestão de riscos de TIC, reporte de incidentes, risco de terceiros e compartilhamento de informações), e esse pilar abrange diretamente seus testes de carga e desempenho.

Primeiro, uma desambiguação, porque a sigla é usada para vários significados. Este artigo é sobre o regulamento da UE. Não é sobre os “métricos DORA” do DevOps (frequência de implantação, tempo de lead e demais). São DORA completamente diferentes.

O artigo 25 do regulamento lista os métodos de teste que um programa de resiliência deve utilizar. Testes de desempenho e testes ponta a ponta estão nessa lista, junto com avaliações de vulnerabilidades e testes de penetração. Portanto, quando um examinador revisa seus testes de resiliência, evidências de testes de carga e estresse são materiais válidos.

A maior parte da cobertura sobre DORA online foca em testes de penetração guiados por ameaças. Este texto cobre a obrigação mais silenciosa: mostrar que seus sistemas permanecem responsivos sob volume, produzindo as evidências que um auditor realmente pedirá para ver, e fazendo isso com uma ferramenta feita para a tarefa. LoadView é uma plataforma de teste de carga baseada na nuvem e em navegadores reais, e as seções abaixo mapeiam cada item da lista de verificação de um revisor de conformidade DORA para a capacidade do LoadView que o produz.

O Que Este Guia Cobre

1. Onde o Teste de Carga se Encaixa na DORA
2. As Evidências de Auditoria que um Examinador DORA Espera
3. Como o LoadView Apoia o Teste de Resiliência Operacional DORA
4. Por Que Números de Carga Só por Protocolo Não Se Sustentam em Auditoria
5. Como Produzir Evidências de Teste Preparadas para DORA
6. A Conclusão
7. Perguntas Frequentes

Onde o Teste de Carga se Encaixa na DORA

DORA é baseada em riscos, não prescritiva quanto às ferramentas. Não diz “execute um teste de carga de 500 usuários todo trimestre.” Diz para testar os sistemas de TIC que suportam funções críticas ou importantes, regularmente, e agir com base nos resultados.

Dois artigos carregam a maior parte do peso para o trabalho de desempenho:

• Artigo 24 estabelece os princípios gerais dos testes. Entidades financeiras testam os sistemas e aplicações de TIC que suportam funções críticas ou importantes ao menos uma vez por ano, usando uma abordagem baseada em riscos.
• Artigo 25 lista os métodos que o programa pode usar. Testes de desempenho e testes ponta a ponta são mencionados explicitamente.

Para uma plataforma de trading, uma API de pagamentos ou um portal de internet banking, “resistir a interrupções” inclui interrupções por carga: um pico na abertura do mercado, um aumento no dia de pagamento, uma promoção que triplica o tráfego de finalização de compra. Se o serviço desacelera ou cai sob volume, há uma falha em resiliência operacional. E DORA espera que você tenha buscado isso antes da produção, que é onde teste de carga para serviços financeiros ganha seu espaço no programa.

As consequências aqui são práticas, não só processuais. Supervisores podem exigir que uma entidade solucione falhas de resiliência que encontrarem, então uma revisão que descubra um sistema crítico não testado tende a gerar trabalho não planejado no cronograma do regulador e não no seu.

As Evidências de Auditoria que um Examinador DORA Espera

Examinadores trabalham com evidências, não intenções. Durante uma revisão dos seus testes de resiliência, espere que procurem artefatos como estes:

A primeira linha é onde as equipes perdem mais pontos. Sem SLAs de desempenho documentados, um teste de carga não tem linha de aprovação/reprovação, e o auditor vê um gráfico sem um padrão por trás. Escreva as metas primeiro: tempo de resposta P95 por transação crítica, limite máximo de taxa de erro e a carga máxima que cada sistema deve suportar.

As linhas dois e três são sobre tempo e severidade. Executar um teste de carga antes de cada lançamento em produção mostra que o volume é verificado antes dos clientes acessarem o código, e incorporar essa verificação no pipeline de lançamento mantém isso consistente. Testes de estresse vão além do teste de carga, ultrapassando picos previstos até algo falhar, para que o ponto de ruptura seja um número conhecido e não uma surpresa no dia de abertura do mercado.

A linha quatro é o artefato que os examinadores mais lidam. Um relatório com percentis de tempo de resposta, taxas de erro e o perfil de carga que os gerou é a principal evidência, e precisa ter data e versão para vincular a um lançamento específico.

A linha cinco conecta o teste a uma previsão. Documentação de planejamento de capacidade diz quanto de capacidade disponível o último teste mediu e quando o crescimento a consumirá. Linhas seis e sete distinguem um programa real de um apenas no papel. Quando um teste aponta um gargalo, o examinador quer saber o que foi feito depois, então os relatórios do LoadView que identificam gargalos de desempenho tornam a ação específica: qual camada estava lenta, o que mudou e o resultado do reteste.

Como o LoadView Apoia o Teste de Resiliência Operacional DORA

Cada linha da lista de evidências corresponde a algo que o LoadView faz diretamente. A tabela abaixo relaciona o artefato que um examinador pede com a capacidade do LoadView que o produz, assim o requisito de conformidade e a funcionalidade da ferramenta se alinham um a um.

Dois detalhes do LoadView fazem a maior parte do trabalho aqui. O primeiro é que os testes rodam em navegadores reais, então os números do seu relatório são os tempos que um cliente realmente veria, o que torna o relatório credível como evidência de resiliência. O segundo é que todo o fluxo é roteirizado como uma jornada do usuário em vez de um conjunto de requisições brutas, então um teste ponta a ponta sob o Artigo 25 da DORA cobre login, transação e confirmação da forma que uma sessão real faz. As duas próximas seções cobrem cada um desses em ordem.

Por Que Números de Carga Só por Protocolo Não Se Sustentam em Auditoria

Um teste de carga que dispara requisições HTTP brutas pode reportar números altos de throughput. Mas para um serviço financeiro voltado ao cliente, esses números descrevem o servidor, não a experiência do cliente. Eles ignoram o JavaScript, a checagem antifraude de terceiros, o redirecionamento SSO e a tela de confirmação renderizada.

Um examinador que pergunta se os clientes conseguem realizar transações sob carga quer evidências sobre a experiência do cliente, não só a taxa de requisições de origem. Testes de carga em navegador real rodam o teste por instâncias reais do Chromium, então os tempos de resposta do seu relatório são os que um cliente veria. Em termos simples, o teste carrega a página como o navegador do cliente faz — executando scripts, redirecionamentos e renderização — em vez de somente pingar o servidor.

Para um banco ou provedor de pagamentos, essa é a diferença entre “a API respondeu em 200ms” e “o fluxo do login até a confirmação demorou nove segundos porque a chamada de avaliação antifraude entrou em fila.” O segundo degrada o serviço. E é exatamente isso que uma revisão de resiliência procura, por isso testes de concorrência de transações sobre o fluxo real do usuário produzem evidências mais fortes do que um gráfico de throughput ao nível de protocolo.

Uma ferramenta que reporta “100.000 requisições por segundo” sem executar a página está medindo o throughput HTTP, não o que um cliente experimenta na tela de login. Um auditor que revisa a resiliência voltada ao cliente deseja o segundo número.

Testes ao nível de protocolo medem o servidor; testes em navegador real do LoadView medem o fluxo do login à confirmação que o cliente realiza.

Como Produzir Evidências de Teste Preparadas para DORA

Você não precisa de uma nova categoria de ferramenta para satisfazer este pilar. Precisa de testes que correspondam à lista de evidências e um registro que possa ser entregue a um auditor. Aqui está a sequência no LoadView:

1. Escreva os requisitos de desempenho para cada função crítica. Defina percentis de tempo de resposta e teto de taxa de erro por transação, faça a aprovação deles, e entre esses valores como limites de aprovação/reprovação do teste para que os resultados se avaliem automaticamente.
2. Registre o teste como um fluxo de usuário real. Use o gravador EveryStep para capturar a jornada real (login, transação, confirmação) clique a clique em um navegador real, depois execute-o sob carga com teste de carga de aplicação web ao invés de somente repetir chamadas HTTP brutas.
3. Teste até o pico esperado, e depois além dele. Configure tipos de curva de carga para manter usuários virtuais no pico previsto para o teste de carga, depois uma curva escalonada que ultrapasse este pico para o teste de estresse, para que tanto “podemos aguentar o dia?” quanto “onde quebramos?” tenham respostas documentadas.
4. Injete carga a partir das regiões que você serve. Se seus clientes estão espalhados pela UE, execute a partir de mais de 30 zonas de injeção geo-distribuída de carga para que o desempenho seja medido onde os usuários realmente estão, não só de um data center.
5. Guarde o relatório. Exporte os relatórios de teste de desempenho com percentis, taxas de erro, perfil de carga, waterfall e carimbo de data/hora, e arquive-os com o registro de lançamento. É esse arquivo que o examinador lê.
6. Reteste em cronograma e após alterações. Repita ao menos anualmente para funções críticas, após qualquer lançamento que afete o caminho crítico, e sempre que o crescimento se aproximar do limite de capacidade medido no último teste. Agendar a execução e integrá-la ao seu pipeline CI/CD mantém essa cadência automática em vez de depender de lembretes de calendário.

Feito assim, a evidência se constrói automaticamente como subproduto de testes que você já teria interesse em executar. Como o LoadView é totalmente hospedado na nuvem, não há infraestrutura de geração de carga para montar ou justificar a um auditor, e os artefatos correspondem exatamente ao que um revisor DORA solicita, na ordem que ele pede.

O escopo da DORA também alcança os provedores críticos de TIC terceiros em que você confia. Se um gateway de pagamento, serviço de identidade ou API de dados estiver em um caminho crítico, seu comportamento sob carga também faz parte da sua visão de resiliência, por isso teste de carga de API nessas interfaces mantém as mesmas evidências arquivadas para os serviços que você não gerencia diretamente.

Veja como o LoadView produz as evidências que um examinador DORA pede. Agende uma demonstração do LoadView para dimensionar um teste para seus volumes de pico e exportar os relatórios que seus auditores solicitarão.

A Conclusão

A DORA não entrega um checklist de testes de carga, mas seu pilar de testes de resiliência e os métodos do Artigo 25 tornam os testes de desempenho e carga parte do que um revisor pode inspecionar. Os sistemas que importam são os que suportam funções críticas ou importantes, e o padrão é se eles continuam atendendo clientes sob volume.

Produza os sete artefatos que um examinador espera, baseando-os em resultados de navegadores reais em vez de throughput só por protocolo, e reteste conforme os volumes crescem. O LoadView foi feito para gerar cada um desses artefatos a partir de um único teste roteirizado, então uma revisão de resiliência sobre seus testes de desempenho vira uma questão de entregar registros que você já mantém.

Perguntas Frequentes