Testes de desempenho SAP: carga, concorrência e ferramentas

Os testes de desempenho SAP provam, antes do go-live, que as transações críticas, os jobs em background e as interfaces atendem aos tempos de resposta acordados quando muitos usuários e jobs rodam ao mesmo tempo. Na minha experiência, os testes de concorrência são os que importam, executados com dados mascarados no volume da produção e com base em critérios de aprovação e reprovação que o negócio acordou antes da primeira execução.

Este guia é para CIOs, diretores de programa e líderes de teste em programas S/4HANA, incluindo o RISE with SAP. Ele cobre o que testar, os dados de que você precisa, como escrever critérios de aceitação, quais ferramentas fazem o trabalho e quem responde pelo quê. Para ver onde o desempenho fica entre os outros tipos de teste, comece pela minha visão geral de testes SAP explicados.

Problemas de desempenho em programas SAP raramente são uma surpresa.

Os tiles do Fiori estouram o tempo limite quando centenas de usuários entram no início de um turno. Um relatório customizado trava porque alguém executou uma seleção sem limite de exercício fiscal sobre uma tabela muito grande. Os jobs em background se sobrepõem no fechamento do mês e a execução de lançamentos é abortada.

Isso é previsível. A única questão é se o programa testou esses cenários, ou se o negócio vai descobri-los com pedidos reais rodando.

Testes de desempenho ao longo do SAP Activate

1. 01

   Explore

   Identificar os riscos de desempenho no desenho. A arquitetura e o formato dos relatórios decidem os resultados antes de o código ser escrito.

2. 02

   Realize

   Executar testes de volume e de carga à medida que a configuração se estabiliza. Uma configuração parcial produz resultados enganosos.

3. 03

   Pré-UAT

   Concluir o ciclo completo de desempenho antes do UAT, e não como parte dele.

4. 04

   Cutover

   Aprovar o cutover com base nos critérios de aceitação acordados antes, e não em opiniões.

5. 05

   Hypercare

   Acompanhar os KPIs em produção por 30 a 60 dias. A maioria das regressões aparece no primeiro ciclo de fechamento.

Em um sistema ECC sobre um banco de dados tradicional, testar desempenho significava fazer teste de carga no servidor de aplicação e no banco de dados: tempo de execução ABAP, desempenho de SQL e agendamento de jobs. O front end era o SAP GUI, que raramente surpreendia alguém.

No S/4HANA, com front ends Fiori, extensões no SAP BTP e integração pelo SAP Cloud Integration, o desempenho depende de várias camadas ao mesmo tempo. Um tile do Fiori lento pode ser uma chamada ABAP longa, um timeout do gateway, um serviço OData que não foi desenhado para requisições simultâneas ou a latência de rede em uma configuração híbrida. Testar só o back end não vai encontrar o problema.

1. 01Abertura do tilePicos de login no início do turno
2. 02Chamada ODataTimeouts do gateway, serviços não construídos para concorrência
3. 03Processamento ABAPChamadas ABAP de longa duração
4. 04Leitura no banco de dadosSeleções sem limite em tabelas grandes
5. 05RenderizaçãoMais a latência de rede para unidades distantes

Um único tempo de resposta, medido de ponta a ponta

Os testes de desempenho do SAP HANA têm uma particularidade em uma conversão. Um código ECC estável se comporta de forma diferente em um banco de dados em memória. Muitos programas ficam bem mais rápidos, enquanto alguns produzem perfis inesperados com determinados padrões de dados, então a regressão específica da conversão para o código customizado pesado não é opcional.

Os fluxos de integração trazem o seu próprio risco. Fluxos que funcionavam no desenvolvimento com mensagens de teste isoladas podem acumular filas ou falhar em silêncio com volumes de produção. Os sintomas parecem outra coisa: falhas intermitentes em pedidos, divergências em faturas, dados presentes em um sistema e ausentes em outro.

O teste de desempenho precisa acontecer antes do go-live. Os testes que trato como os importantes são os de concorrência: muitos usuários e jobs acessando as mesmas transações, tabelas e serviços ao mesmo tempo.

Um único usuário criando uma ordem de venda em dois segundos não prova quase nada. A mesma ordem com 150 pessoas digitando pedidos, uma execução de remessas em background e uma interface lançando mensagens de entrada é o teste que prevê o primeiro dia.

Esta tabela mostra o que cada tipo de teste prova e quando executá-lo:

Teste	O que prova	Quando executar	O que costuma encontrar
Concorrência	Muitos usuários e jobs conseguem trabalhar nos mesmos objetos ao mesmo tempo	Realize, quando a configuração estiver estável, e de novo antes do UAT	Esperas por bloqueio, picos de login, gargalos no gateway
Carga	O sistema atende aos tempos de resposta no volume de pico esperado	Realize, depois que os scripts de concorrência funcionarem	Serviços OData lentos, relatórios customizados pesados
Estresse	Onde o sistema quebra acima dos limites do desenho	Antes do UAT, se houver crescimento esperado	Lacunas de dimensionamento, limites de fila
Resistência (soak)	O sistema sustenta uma carga constante por horas	Antes do UAT, de preferência ao longo de um fechamento simulado	Crescimento do uso de memória, disputa entre cadeias de jobs em execuções repetidas
Ponta a ponta	O caminho completo que o usuário espera atende à meta	Junto com os testes de carga	Problemas invisíveis quando cada camada é testada sozinha

A palavra-chave no teste de carga é esperado. Você precisa de volumes reais de transações, quantidades de usuários e padrões de sessão. Um teste de carga construído sobre estimativas de volume que todos já sabiam que eram otimistas dá uma aprovação que não significa nada.

O teste de resistência é o mais pulado. Os testes de volume em geral são o atalho que os programas mais tomam quando o cronograma aperta, e do qual mais se arrependem.

Roteirize estes primeiro. Eles cobrem a maior parte das falhas que chegam à produção.

1. Troca de turno e pico de login. Quando algumas centenas de usuários abrem o launchpad do Fiori ao mesmo tempo, a autenticação e a renderização do launchpad disparam. Um sistema que vai bem fora do pico pode ficar inutilizável nessa janela se os logins simultâneos nunca foram testados.
2. Fechamento mensal e anual. Lançamentos em grande volume, cadeias de jobs com sequência rígida e uma equipe financeira correndo contra um prazo fixo. Execute as cadeias de jobs do fechamento de ponta a ponta com os volumes do período de fechamento, e não com as médias diárias.
3. Jobs em background sobrepostos. Os jobs em lote costumam ser testados um de cada vez, o que não reflete a realidade. Um job mal otimizado pode bloquear vários outros, e o fechamento passa da sua janela.
4. Relatórios customizados sem limite de seleção. Um relatório que responde na hora com dados de teste pode levar minutos com um exercício fiscal completo. Teste seleções típicas e de pior caso, e bloqueie as que não têm limite.
5. Usuários em várias regiões. A latência de rede afeta todas as transações. O RISE leva a hospedagem para a SAP, mas a latência ainda depende da região que você escolhe e do roteamento até os seus usuários, então teste a partir das unidades mais distantes.

O meu guia de migração de ECC para S/4HANA mostra onde os testes de conversão se encaixam no plano mais amplo.

Dados de teste em nível de produção

Os dados decidem se algo disso significa alguma coisa. Eu insisto em dados mascarados em nível de produção: volume e realismo de produção, com os campos pessoais e sensíveis mascarados.

Um cliente com 200.000 linhas de pedido em aberto se comporta de forma diferente de um com 5.000. Filtros que respondem na hora em um mandante de teste escasso estouram o tempo limite em produção. Gere volume para as áreas de alto risco, use uma combinação representativa de transações e faça chamadas reais de interface sempre que puder.

Como obter esses dados com segurança, por meio de cópias, ferramentas de dados de teste seletivos e mascaramento, está no meu guia de gestão de dados de teste SAP. Planeje a atualização antes do primeiro ciclo de desempenho, porque ela leva mais tempo do que a maioria dos planos de teste supõe.

Acorde os critérios com o negócio na fase Prepare, antes de qualquer teste rodar. Cada um nomeia a transação ou o job, a carga e o limite.

Estes exemplos mostram o formato. Defina os seus próprios números a partir das necessidades operacionais:

Item	Condição de carga	Limite de aprovação	Responsável
Criação de ordem de venda (VA01 ou app Fiori)	150 usuários simultâneos de entrada de pedidos	Menos de 3 segundos para 95% das transações	Dono do processo order to cash
Primeiro carregamento do launchpad do Fiori no início do turno	Pico de logins simultâneos do maior turno	Menos de 5 segundos para 95% dos usuários	Líder de operações de TI
Cadeia de jobs do fechamento mensal	Volumes do período de fechamento, sequência completa	Termina dentro da janela de fechamento acordada, sem abortos	Controller financeiro
Interface de entrada de pedidos	Volume de mensagens na hora de pico	Nenhuma fila acumulada com mais de 15 minutos	Líder de integração
Relatório customizado de alto volume	Volume completo de dados de produção, seleção típica	Menos de 60 segundos; seleções sem limite bloqueadas	Dono do relatório

“O sistema deve ser rápido o bastante para as operações do negócio” não pode ser testado nem aceito. Mudar os critérios depois que os resultados chegam anula o propósito de tê-los.

Se o sistema foi aprovado porque os usuários do UAT disseram que parecia rápido, você tem uma opinião, e não um critério de aceitação. Faça dos resultados um gate formal antes do cutover, como descreve o meu guia de quality gates no SAP. O plano geral dos ciclos, com critérios de entrada e saída para cada fase de teste, pertence à sua estratégia de testes do S/4HANA.

Ferramentas de teste de desempenho SAP

Um teste de desempenho precisa de três coisas: um gerador de carga capaz de operar os protocolos SAP, monitoramento do lado SAP e um lugar para gerenciar os casos de teste e os resultados. O LoadRunner é a ferramenta de carga que as minhas equipes usaram em programas SAP. Nomeie a ferramenta no plano de testes cedo, porque licenças, geradores de carga e competências de scripting levam tempo para serem providenciados.

As principais opções em 2026:

Ferramenta	Papel	O que saber
OpenText Professional Performance Engineering	Geração de carga	O produto antes chamado LoadRunner Professional. Os seus pacotes de protocolos cobrem SAP, SAP GUI e SAP Web
Tricentis NeoLoad	Geração de carga	A Tricentis lista suporte a SAP GUI, Fiori, RFC e IDoc, e ele pode reutilizar ativos do Tricentis Tosca
Apache JMeter	Geração de carga	Código aberto. Gera tráfego HTTP, como chamadas Fiori e OData
SAP Cloud ALM	Gestão de testes	Prepara e executa casos de teste manuais e automatizados e acompanha os defeitos. Não gera carga por conta própria
SAP Solution Manager	Gestão de testes	A manutenção padrão termina em 31 de dezembro de 2027, então planeje o trabalho novo no Cloud ALM

Para uma visão mais ampla das ferramentas funcionais e de automação, veja a minha comparação de ferramentas de teste e validação SAP. A ferramenta importa menos do que os scripts, os dados e os critérios.

O RISE with SAP divide a responsabilidade

No RISE with SAP, a SAP é responsável pela infraestrutura: dimensionamento, região do hyperscaler, rede e disponibilidade da plataforma. O cliente e o parceiro são responsáveis pela camada de aplicação.

O documento de papéis e responsabilidades do RISE da SAP é claro sobre isso. A execução dos testes de carga e o ajuste de instruções SQL custosas são SAP Cloud Application Services, cobrados à parte. Se você não os contratar, o trabalho fica com o cliente.

Uma falha comum em programas RISE é supor que a SAP vai pegar os problemas de desempenho porque opera a infraestrutura. Ela vai pegar problemas de infraestrutura. Escreva a divisão no termo de abertura e no plano de testes:

1. SAP: disponibilidade da infraestrutura e resposta no nível da plataforma
2. Parceiro: desempenho da aplicação sob a carga definida, incluindo extensões e fluxos de integração
3. Cliente: resultados no nível do processo, como o tempo de execução do fechamento e o volume de pedidos processados, e a decisão de aceitação

A nuvem pública reduz o escopo

Na public edition do ERP em nuvem da SAP, o sistema roda em uma plataforma compartilhada, operada pela SAP. Antes de planejar qualquer teste de carga contra um tenant, pergunte à SAP por escrito se isso é permitido e com quanta antecedência ela precisa ser avisada.

Os seus testes então se concentram no que é seu: integrações customizadas, extensões, relatórios de alto volume, a sequência do fechamento e o caminho de rede a partir das suas unidades. Problemas de desempenho da plataforma vão para o suporte da SAP.

Erros comuns

1. Tratar o teste funcional como teste de desempenho. Os testes funcionais provam que uma transação dá o resultado certo. Eles não dizem nada sobre 150 pessoas executando-a ao mesmo tempo.
2. Deixar o desempenho com a equipe Basis. A Basis é responsável pelo dimensionamento e pelo agendamento de jobs. Ela não é responsável pelo desenho dos relatórios, pela arquitetura dos serviços OData nem pelo desenho dos fluxos de integração, e são eles que determinam o desempenho da aplicação.
3. Dar a responsabilidade só ao QA. O QA executa os testes e relata os resultados, mas as decisões que causam problemas de desempenho são tomadas no desenho. Um líder de testes ou arquiteto no nível do programa precisa de autoridade para questioná-las cedo, e a matriz RACI deve dizer quem pode bloquear o go-live por motivos de desempenho.
4. Aceitar lacunas como problemas conhecidos. A maioria dos programas com problemas de desempenho em produção não deixou de testar. Eles testaram sem critérios acordados, ou testaram e depois aceitaram as falhas sob pressão do cronograma.

Escreva os cinco ou seis critérios de aceitação para as suas transações e jobs de maior risco, com um responsável nomeado para cada um. Se você não consegue preencher a tabela acima, você não está pronto para testar, e acabou de encontrar a primeira lacuna.

Depois verifique duas coisas: se uma atualização de dados mascarados no volume da produção está no plano, e se o ciclo de concorrência termina antes de o UAT começar.

Se você quer uma visão independente sobre um plano de testes de desempenho ou uma decisão de go-live, eu ajudo organizações com isso. Você pode entrar em contato comigo aqui.

O que são testes de desempenho SAP?

Eles verificam como o SAP se comporta sob uma carga realista: tempos de resposta das transações dos usuários, tempos de execução dos jobs em background, vazão das interfaces e uso de recursos quando muitas pessoas trabalham ao mesmo tempo. Eles precisam ser feitos antes do go-live.

Correção funcional e desempenho são propriedades diferentes. Uma transação que está correta para um usuário pode estourar o tempo limite para 200.

Quando os testes de desempenho devem começar em um programa SAP?

A identificação de riscos começa no Explore, porque as escolhas de arquitetura definem os resultados de desempenho. Os testes ativos começam no Realize, quando a configuração estiver estável o bastante para que os resultados signifiquem algo.

Termine o último ciclo antes do UAT, e não durante. Defeitos de desempenho encontrados no UAT comprimem o cronograma e criam pressão para aceitá-los como problemas conhecidos.

Qual é a diferença entre teste de carga e teste de concorrência no SAP?

O teste de carga verifica os tempos de resposta no volume de pico esperado. O teste de concorrência verifica o que acontece quando muitos usuários e jobs trabalham nas mesmas transações, tabelas e serviços no mesmo momento. É aí que aparecem as esperas por bloqueio, os picos de login e os gargalos no gateway.

Na minha experiência, os testes de concorrência são os importantes. Execute-os primeiro e depois construa o teste de carga completo sobre eles.

Que dados de teste os testes de desempenho SAP devem usar?

Dados mascarados em nível de produção. Isso significa volume e realismo de produção, com os campos pessoais e sensíveis mascarados. Dados de teste escassos escondem os filtros lentos, os relatórios pesados e os longos tempos de execução de jobs que aparecem no primeiro dia.

Quais ferramentas são usadas para testes de desempenho SAP?

Geradores de carga como o OpenText Professional Performance Engineering (antes LoadRunner Professional), o Tricentis NeoLoad e o Apache JMeter geram a carga. O SAP Cloud ALM ou o SAP Solution Manager gerenciam os casos de teste e os resultados, e o monitoramento do lado SAP mostra o que o sistema fez sob carga.

Quem é responsável pelos testes de desempenho no RISE with SAP?

A SAP é responsável pela infraestrutura: dimensionamento, região, rede e disponibilidade da plataforma. O documento de papéis e responsabilidades do RISE da SAP deixa a execução dos testes de carga e o ajuste de SQL custoso com o cliente, a menos que os SAP Cloud Application Services sejam contratados à parte.

O cliente e o parceiro são responsáveis pelo desempenho da aplicação e pela decisão de aceitação. Escreva a divisão nos critérios de aceitação, para que cada limite tenha um responsável.