Testes de desempenho SAP: o que os líderes de TI precisam saber

O teste de desempenho SAP comprova, antes do go-live, que as transações críticas, os jobs em segundo plano e as interfaces cumprem os tempos de resposta acordados sob os volumes de produção. Comece no desenho, execute os testes de volume e de carga na fase Realize, quando a configuração estiver estável, termine o ciclo antes dos testes de aceitação do usuário (UAT) e faça dos resultados um critério de aprovação do cutover. 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, quem é o dono, como escrever critérios de aceitação e o que muda na nuvem. Comece pela tabela de critérios de aceitação: se você não consegue preenchê-la, ainda não está pronto para testar.

Os problemas de desempenho nos programas SAP quase sempre são descobertos depois do go-live. Os tiles do Fiori expiram quando 300 usuários fazem login na troca de turno. Relatórios Z travam porque alguém executou uma consulta de ano fiscal sem delimitação contra uma tabela com 50 milhões de registros. Jobs em segundo plano se sobrepõem durante o fechamento mensal e a execução de lançamentos é abortada.

Os problemas de desempenho nos programas SAP raramente chegam de surpresa. A maioria era previsível, só não foi planejada. O padrão habitual: o teste funcional foi rigoroso. O teste de volume foi planejado e depois adiado quando o cronograma apertou. As consequências chegaram nas primeiras semanas de operação real.

Não são casos de borda. São previsíveis. A única questão é se o programa testou para eles ou se o negócio os descobre com pedidos reais em andamento.

Testes de desempenho ao longo do SAP Activate

1. 01

   Explore

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

2. 02

   Realize

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

3. 03

   Pré-UAT

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

4. 04

   Cutover

   Aprove o cutover com base nos critérios de aceitação acordados de antemão, não em opinião.

5. 05

   Hypercare

   Acompanhe 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 o desempenho significava testar a carga do servidor de aplicação e do banco de dados: tempo de execução do ABAP, desempenho do SQL, 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 (CPI), 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 não projetado para requisições simultâneas ou a latência de rede em um cenário híbrido. Testar só o back end não vai encontrar o problema. Testar o caminho inteiro vai.

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

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

Os fluxos de integração trazem um risco próprio. Fluxos que funcionaram em desenvolvimento e na QA com mensagens de teste isoladas podem formar fila ou falhar em silêncio nos volumes de produção. Se as filas de mensagens não forem dimensionadas para a carga real, os atrasos se acumulam. Os sintomas parecem outra coisa: falhas intermitentes em pedidos, divergências em faturas, dados presentes em um sistema e ausentes em outro.

1. Teste de carga verifica o comportamento sob o volume esperado. A palavra-chave é esperado. Você precisa de volumes de transações, números de usuários e sessões simultâneas reais. Muitos testes de carga falham porque usaram estimativas de volume que todos já sabiam serem otimistas.
2. Teste de estresse vai além dos limites do projeto para descobrir onde o sistema quebra. Se os volumes vão dobrar em dezoito meses, ele diz se a arquitetura aguenta e se o dimensionamento vira um problema antes da próxima revisão de infraestrutura.
3. Teste de longa duração (soak) mantém uma carga constante por um período prolongado para expor problemas que se acumulam com o tempo: vazamentos de memória, fragmentação e disputa entre cadeias de jobs em execuções repetidas. É o teste mais frequentemente pulado e aquele que teria detectado a falha de fechamento mensal descrita abaixo.
4. Teste de ponta a ponta acompanha o caminho completo que um usuário percorre: abertura do tile, chamada OData, processamento ABAP, leitura do banco de dados, renderização. É a única forma de encontrar problemas que ficam invisíveis quando cada camada é testada isoladamente.

Troca de turno e pico de login. Quando 200 usuários abrem o launchpad do Fiori às 8h, a autenticação e a renderização do launchpad disparam. Um sistema que funciona bem fora do pico pode ficar inutilizável nessa janela se os logins simultâneos nunca foram testados. Na indústria, no varejo e nos serviços financeiros, as tempestades de login geram as reclamações mais visíveis já no primeiro dia.

Fechamento mensal e anual. O cenário de maior risco na maioria dos programas: lançamentos em alto volume, cadeias de jobs com sequenciamento rígido e uma equipe financeira correndo contra um prazo fixo. Execute as cadeias de jobs de fechamento de ponta a ponta com os volumes do período de fechamento, não com as médias diárias.

Os jobs em lote costumam ser testados isoladamente, o que não reflete a realidade. No fim do mês, o processamento em segundo plano atinge o pico e muitos programas rodam em paralelo nos mesmos recursos. Um job mal otimizado pode bloquear outros cinco, e o fechamento estoura a janela.

Conversão do ECC para o S/4HANA. Código ECC estável se comporta de forma diferente no HANA. Muitos programas ficam bem mais rápidos; alguns apresentam perfis inesperados em determinados padrões de dados. O teste de regressão específico da conversão não é opcional. Meu guia de migração do ECC para o S/4HANA mostra onde isso se encaixa no plano de conversão.

Usuários em várias regiões. A latência de rede afeta todas as transações. Uma ordem de venda que leva dois segundos no país de hospedagem pode parecer quebrada a 3.000 milhas de distância se ninguém testou de lá. O RISE transfere 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.

Acorde os critérios com o negócio na fase Prepare, antes de qualquer teste. 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 de 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 de fechamento mensal	Volumes do período de fechamento, sequência completa	Conclui dentro da janela de fechamento acordada, sem abortos	Controller financeiro
Interface de pedidos de entrada	Volume de mensagens por hora no 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 abertas bloqueadas	Dono do relatório

“O sistema deve ser rápido o suficiente 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 sentido de tê-los.

Peça cada um destes pelo nome:

Expectativa	O que deve ser entregue	Por que importa
Níveis de serviço de desempenho	Limites por transação, interface e job, com critérios de aprovação e reprovação	Impede que a opinião do UAT se sobreponha às evidências
Escopo baseado em risco	Priorização por volume de usuários, pontos de integração e dependência de dados	Concentra os ciclos de teste nas cargas que importam
Participação entre equipes	Basis, infraestrutura, funcional, segurança e integração presentes durante as execuções	Evita a troca de culpas quando surgem lacunas
Ferramentas e ambientes prontos	Geradores de carga (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), monitoramento e atualizações de dados prontos antes do início dos ciclos	Torna a simulação realista
Dados de teste realistas	Dados mestre em volume de produção, chamadas reais de interface, mix representativo de transações	Faz os resultados anteciparem o comportamento no go-live
Relatório de desempenho	Mix de carga, tempos de resposta, CPU e memória, tempos de execução de jobs, taxas de erro	Dá à aprovação do cutover uma base de evidências
Plano de monitoramento pós-go-live	KPIs a acompanhar nos primeiros 30 a 60 dias	Confirma que o sistema em produção permanece dentro dos limites testados

Quatro erros aparecem com mais frequência, mesmo em grandes empresas com modelos de entrega maduros.

Tratar o teste funcional como teste de desempenho. Os testes funcionais provam que uma transação dá o resultado certo. Não dizem nada sobre 150 pessoas executando-a ao mesmo tempo.

Testar com volumes pequenos de dados. Um cliente com 200.000 linhas de pedido em aberto se comporta de forma diferente de um com 5.000. Filtros que retornam na hora em teste expiram em produção. Carregue volume nas áreas de alto risco.

Deixar o desempenho com a Basis. A Basis é dona do dimensionamento e do agendamento de jobs. Ela não é dona do desenho dos relatórios, da arquitetura dos serviços OData nem do desenho dos fluxos de integração, e são eles que determinam o desempenho da aplicação.

Dar a responsabilidade apenas à QA. A QA executa testes e reporta resultados. As decisões que causam problemas de desempenho são tomadas pelas equipes funcionais, técnicas e de Basis no desenho. Um líder de testes ou arquiteto em nível de programa precisa ter autoridade para questionar essas decisões cedo, e a RACI deve dizer quem pode bloquear o go-live por motivos de desempenho.

O RISE divide a responsabilidade

No RISE with SAP, a SAP é dona da infraestrutura: dimensionamento, região do hyperscaler, rede e disponibilidade da plataforma. O cliente e o parceiro são donos da camada de aplicação. O documento de papéis e responsabilidades do RISE da SAP deixa isso claro: localizar e ajustar instruções SQL caras continua com o cliente, a menos que você compre os serviços adicionais de aplicação da SAP.

Uma falha comum em programas RISE é supor que a SAP vai detectar os problemas de desempenho porque opera a infraestrutura. Ela detecta problemas de infraestrutura. Não detecta um serviço OData mal projetado, um job ABAP ineficiente ou um fluxo de integração que não escala. Registre essa 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 dos processos, como o tempo do fechamento e a vazão de pedidos, e a decisão de aceitação

O Public Edition e o GROW reduzem o escopo

No S/4HANA Cloud Public Edition, normalmente contratado pelo GROW with SAP, a SAP executa testes de desempenho na sua plataforma multi-tenant como parte do seu próprio padrão de produto e não espera que os clientes façam teste de carga no sistema compartilhado. Seus testes passam a se concentrar no que é seu: integrações customizadas, extensões, relatórios e analytics de alto volume, a sequência de fechamento e consolidação e o caminho de rede a partir dos seus locais. Problemas de desempenho na própria plataforma vão para o suporte da SAP.

A IA ajuda com scripts, não com arquitetura

Os fornecedores de ferramentas de teste de carga estão incorporando IA à manutenção de scripts e à análise de resultados, o que ajuda em programas nos quais a aplicação muda entre os ciclos. Teste essas promessas no seu próprio ambiente antes de pagar por elas. O SAP Cloud ALM pode ajudar a gerar casos de teste e requisitos, e assistentes de IA podem esboçar cenários a partir de descrições de processos.

Nada disso corrige a arquitetura. A IA não vai dizer que o serviço OData deveria ter sido projetado de outra forma, nem que um relatório é pesado demais para os seus volumes. Essas decisões ainda são tomadas por pessoas, no desenho, antes de qualquer teste.

A maioria dos programas com problemas de desempenho em produção não deixou de testar por completo. Testou sem critérios acordados, ou testou e depois aceitou as lacunas como problemas conhecidos sob pressão de cronograma. A disciplina está nos critérios e em fazê-los valer, não na ferramenta. Para ver onde o desempenho se encaixa entre os outros tipos de teste, consulte minha comparação de ferramentas de teste e validação do SAP e meu guia sobre os quality gates do SAP.

O que é o teste de desempenho SAP e por que ele importa?

Ele verifica como o SAP se comporta sob carga realista: tempos de resposta das transações dos usuários, tempos de execução dos jobs em segundo plano, vazão das interfaces e uso de recursos sob trabalho simultâneo.

A correção funcional e o desempenho são propriedades diferentes. Uma transação correta para um usuário pode expirar para 200. Um job que roda em dez minutos com dados de teste pode rodar por horas com os volumes de produção. Descobrir isso depois do go-live interrompe as operações, força mudanças emergenciais e prejudica a confiança dos usuários justamente quando a adesão é mais frágil.

Quando o teste de desempenho deve começar em um programa SAP?

A identificação de riscos começa na fase Explore, porque as escolhas de arquitetura definem os resultados de desempenho. Os testes ativos começam na fase Realize, quando a configuração está estável o bastante para que os resultados façam sentido. Uma configuração parcial dá números enganosos.

Conclua o ciclo final antes do UAT, não durante ele. Defeitos de desempenho encontrados no UAT espremem o cronograma restante e criam pressão para aceitá-los como problemas conhecidos.

Quem deve ser dono do teste de desempenho SAP?

O programa, não só a QA. A QA executa e reporta, mas as decisões que determinam o desempenho são tomadas no desenho, entre as equipes funcionais, técnicas e de Basis. Um arquiteto central ou líder de testes do programa precisa ter autoridade para questionar essas decisões cedo.

Deixe explícito na RACI: quem aprova os critérios de aceitação, quem responde pela correção quando os critérios falham e quem pode bloquear o go-live por motivos de desempenho.

Como o RISE with SAP muda a responsabilidade pelo teste de desempenho?

A SAP é dona da infraestrutura: dimensionamento, região, rede e disponibilidade da plataforma. O cliente e o parceiro respondem pelo desempenho da aplicação: configuração, extensões, desenho de OData e Fiori, fluxos de integração e KPIs de processo. O documento de papéis e responsabilidades do RISE da SAP deixa o ajuste de SQL com o cliente, a menos que sejam contratados serviços adicionais da SAP.

Registre essa divisão nos critérios de aceitação para que cada limite tenha um responsável.

Quais são os problemas de desempenho mais comuns no SAP Fiori?

Quatro padrões cobrem a maioria. Tempestades de login no início do turno, quando a autenticação e a renderização do launchpad disparam. Serviços OData que retornam grandes conjuntos de resultados ou fazem várias chamadas ao back end a cada interação. A camada de gateway se tornando um gargalo por si só, e por isso ela deve ser monitorada durante os testes. E apps customizados ou muito modificados, nos quais as premissas padrão de desempenho não se aplicam.

Como definir critérios de aceitação de desempenho para o SAP?

Nomeie a transação, a carga e o limite. Por exemplo: “A criação de pedidos termina em menos de 3 segundos para 95% das transações com 150 usuários simultâneos no perfil de entrada de pedidos.” Isso é testável.

“O sistema deve ser rápido o suficiente” não é. Acorde os critérios com o negócio na fase Prepare, com base em necessidades operacionais reais, e não os altere depois que os resultados chegarem.

O que acontece se o teste de desempenho for pulado ou comprimido?

Os problemas aparecem em produção: jobs estourando suas janelas e bloqueando outros, apps Fiori expirando no pico, o fechamento mensal levando o dobro do tempo e perdendo os prazos de relatórios, filas de interface acumulando.

Usuários que enfrentam problemas de desempenho nas primeiras semanas formam uma visão negativa do sistema, difícil de reverter. E a correção emergencial com o sistema em operação custa mais do que o teste teria custado, porque o que era uma decisão de desenho na fase Realize vira uma mudança arquitetural urgente.