 |
| Bellacosa Mainframe e a cobertura de testes em mainframe |
☕💣 TESTOU 100% DOS CASOS... E MESMO ASSIM QUEBROU EM PRODUÇÃO? O MAIOR MITO DOS TESTES EM MAINFRAME QUE AINDA ENGANA MUITA GENTE
Se existe uma frase que todo profissional de Mainframe já ouviu alguma vez, ela é:
"O programa foi totalmente testado."
Curiosamente, essa mesma frase costuma aparecer poucas horas antes de um incidente em produção.
E aqui está uma verdade que muitos profissionais descobrem apenas depois de alguns anos de guerra:
Não existe programa totalmente testado.
O que existe é um programa com um nível de cobertura suficientemente alto para reduzir o risco a um patamar aceitável.
A pergunta correta nunca deveria ser:
"O programa foi testado?"
Mas sim:
"Qual foi a cobertura real do teste?"
E mais importante ainda:
"O que ficou sem ser testado?"
Hoje vamos conversar sobre um dos assuntos mais importantes para analistas, desenvolvedores COBOL, testadores, líderes técnicos e gestores de aplicações Mainframe:
Como medir cobertura de testes, construir um plano realmente abrangente e aumentar drasticamente a qualidade das entregas.
Pegue seu café.
Porque cobertura de teste não é quantidade de cenários.
É ciência.
O grande erro: confundir quantidade com cobertura
Muitos profissionais acreditam que executar muitos casos de teste significa possuir alta cobertura.
Não significa.
Imagine um programa COBOL com:
20 IFs
5 EVALUATEs
3 loops
15 regras de negócio
Você executa 500 casos.
Mas todos seguem o mesmo caminho lógico.
Resultado:
500 execuções
cobertura baixíssima
Você apenas percorreu a mesma estrada centenas de vezes.
É como testar um elevador indo somente para o segundo andar.
Você pode apertar o botão mil vezes.
Ainda não sabe o que acontece no décimo quinto andar.
O que é cobertura de teste?
Cobertura é uma métrica que mede quanto do comportamento do software foi exercitado durante os testes.
Ela responde perguntas como:
Quantas instruções foram executadas?
Quantos IFs foram percorridos?
Quantas decisões foram avaliadas?
Quantos caminhos lógicos foram explorados?
Quantas regras de negócio foram validadas?
Quanto maior a cobertura, maior a confiança.
Mas atenção:
100% de cobertura não significa ausência de defeitos.
Significa apenas que tudo foi visitado.
Não necessariamente validado corretamente.
As camadas de cobertura
Um plano robusto costuma analisar múltiplas camadas.
1. Cobertura de instruções (Statement Coverage)
A mais básica.
Pergunta:
Cada linha executável foi executada ao menos uma vez?
Exemplo:
IF SALDO > 0
MOVE 'A' TO STATUS
ELSE
MOVE 'B' TO STATUS
END-IF
Se apenas SALDO > 0 foi testado:
MOVE 'A'
executou.
Mas:
MOVE 'B'
não.
Cobertura parcial.
Para atingir 100%, ambos os caminhos precisam ser executados.
2. Cobertura de decisões (Branch Coverage)
Mais importante.
Pergunta:
Cada decisão assumiu todos os resultados possíveis?
Exemplo:
IF CLIENTE-ATIVO
Devemos testar:
TRUE
FALSE
Muitos projetos param na cobertura de instruções.
Os melhores projetos vão além e medem cobertura de decisões.
3. Cobertura de condições
Exemplo:
IF IDADE > 18
AND RENDA > 5000
Precisamos validar:
| IDADE | RENDA |
|---|---|
| T | T |
| T | F |
| F | T |
| F | F |
Caso contrário, parte da lógica pode nunca ter sido exercitada.
4. Cobertura de caminhos (Path Coverage)
Aqui a brincadeira fica séria.
Imagine:
IF A
IF B
...
END-IF
END-IF
Agora existem vários caminhos:
A=T B=T
A=T B=F
A=F
Quanto mais IFs surgem, mais caminhos aparecem.
O crescimento é explosivo.
Por isso ninguém tenta cobrir absolutamente todos os caminhos em sistemas grandes.
O objetivo é cobrir os caminhos críticos.
O conceito mais importante do Mainframe
Cobertura de negócio
Esta é a cobertura que realmente paga as contas.
Perguntas:
Emissão de apólice funcionou?
Pagamento foi processado?
Cálculo de juros foi validado?
Baixa financeira foi testada?
Cancelamento foi exercitado?
O usuário não se importa se:
PERFORM 1000-PROCESSA
executou.
Ele se importa se o dinheiro caiu na conta correta.
Por isso:
Cobertura técnica sem cobertura funcional é uma ilusão perigosa.
Como construir um plano de teste abrangente
A técnica que uso para ensinar equipes é simples.
Divida os cenários em grupos.
Grupo 1 – Casos normais
Fluxo feliz.
O famoso Happy Path.
Exemplo:
Cliente válido.
Conta válida.
Saldo suficiente.
Arquivo disponível.
Tudo funcionando.
Esses testes validam o comportamento esperado.
Grupo 2 – Casos de fronteira
Aqui vivem os defeitos.
Exemplo:
Campo aceita:
0 a 999999
Testar:
0
1
999998
999999
Mas também:
-1
1000000
A maioria dos bugs aparece nos limites.
Grupo 3 – Casos inválidos
Todo sistema recebe lixo.
Você precisa descobrir como ele reage.
Exemplos:
CPF inválido.
Data inválida.
Arquivo vazio.
Campo nulo.
Código inexistente.
Registro duplicado.
Produção faz isso diariamente.
Seu teste também deve fazer.
Grupo 4 – Casos excepcionais
Os mais esquecidos.
Exemplo:
VSAM indisponível.
DB2 retornando erro.
Dataset cheio.
Timeout de CICS.
Lock de registro.
Fila MQ parada.
É justamente aqui que nascem os incidentes mais caros.
O método Bellacosa para testar COBOL
Quando olho um programa, sigo sempre esta sequência.
Entrada
O que entra?
Analise:
LINKAGE
COMMAREA
ARQUIVOS
DB2
MQ
VSAM
Liste tudo.
Processamento
O que acontece?
Mapeie:
IF
EVALUATE
PERFORM
GO TO
loops
Tudo que altera comportamento.
Saída
O que sai?
Arquivos.
Relatórios.
Tabelas.
Mensagens.
Retornos.
Abends.
Tudo deve ser validado.
A matriz de cobertura
Uma técnica extremamente poderosa.
Monte uma tabela.
| Regra | Testada |
|---|---|
| Regra 1 | Sim |
| Regra 2 | Sim |
| Regra 3 | Não |
| Regra 4 | Sim |
Agora faça o mesmo para:
programas
módulos
telas
transações
jobs
A matriz revela instantaneamente os buracos.
Cobertura para Batch
Em batch devemos validar:
Arquivo vazio
0 registros
Arquivo pequeno
10 registros
Arquivo médio
100.000 registros
Arquivo grande
10 milhões de registros
Registro inválido
Registro duplicado
Chave fora de sequência
Dataset inexistente
Espaço insuficiente
Return codes
Tudo isso precisa aparecer no plano.
Cobertura para CICS
Valide:
Entrada válida
Entrada inválida
PF Keys
Timeout
Commarea vazia
Commarea truncada
Falha de comunicação
Reentrada da transação
Muitos defeitos aparecem apenas em ambiente online.
Cobertura para DB2
Nunca teste apenas o SQLCODE 0.
Teste:
0
+100
-803
-811
-904
-911
-913
Grande parte dos problemas de produção surge justamente nos códigos de erro.
Cobertura para VSAM
Valide:
READ OK
NOT FOUND
DUPLICATE KEY
END OF FILE
OPEN ERROR
Muitos testes ignoram completamente os File Status.
Erro clássico.
Testes de performance também fazem parte da cobertura
Um programa pode estar funcionalmente correto.
Mas:
consumir CPU demais
gerar EXCP excessivo
aumentar elapsed time
E então falhar operacionalmente.
Portanto inclua:
volume realista
pico de carga
concorrência
consumo de recursos
Como medir cobertura no Mainframe
Hoje existem ferramentas especializadas.
Entre elas:
IBM Debug Tool
IBM Application Delivery Foundation
IBM Fault Analyzer
IBM Application Performance Analyzer
Compuware Topaz
Compuware Xpediter
Micro Focus Enterprise Analyzer
SonarQube para COBOL
Essas soluções conseguem mostrar:
linhas executadas
branches percorridos
percentuais de cobertura
áreas não testadas
Transformando percepção em números.
E números vencem opiniões.
A armadilha do 100%
Imagine:
IF VALOR > 1000
Você executa:
1001
e
999
Cobertura:
100%.
Mas você não testou:
1000
Exatamente o limite.
Portanto:
100% de cobertura não significa qualidade máxima.
Significa apenas que todos os pontos foram visitados.
O indicador que realmente importa
Depois de décadas observando projetos, cheguei a uma conclusão.
A melhor pergunta não é:
"Qual a cobertura?"
Mas:
"Qual o risco residual?"
Se uma rotina financeira movimenta bilhões:
95% pode ser insuficiente.
Se uma rotina gera relatório interno:
80% pode ser aceitável.
Cobertura deve ser analisada junto com criticidade.
A filosofia dos grandes times
Equipes maduras fazem quatro perguntas:
O que testamos?
O que não testamos?
Por que não testamos?
Qual o risco disso?
Quando essas respostas existem, o plano de teste deixa de ser um documento burocrático.
Ele vira uma ferramenta de gestão de risco.
Conclusão
O profissional júnior acredita que testar é executar casos.
O profissional experiente entende que testar é procurar defeitos.
E o veterano de Mainframe sabe algo ainda mais importante:
Cobertura não é uma porcentagem. É a medida da sua confiança antes de colocar um programa em produção.
Porque no mundo real ninguém é acordado às 3 da manhã por causa dos cenários que foram testados.
Somos acordados pelos cenários que esquecemos de testar.
E quase sempre eles estavam escondidos exatamente naquele IF, naquele SQLCODE, naquele File Status ou naquele registro de fronteira que alguém julgou improvável.
No Mainframe, assim como na aviação, o problema raramente está no voo que você simulou.
O problema está naquele que você acreditou que jamais aconteceria. ☕💣🚀
